This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Arm, prepare custom frame for gdb.


On 25 May 2011 01:08, dpc@ucore.info <dpc@ucore.info> wrote:
> Hi,
>
> I'm writing a ARM exception handlers, and I'd like to make gdb use the
> interrupted code backtrace as ancestor of handling code. This would
> allow to break on supervisor logic and `backtrace` command would
> display the backtrace of interrupted non-supervisor code as well.
>
> Obviously the handler is written in assembler. I'm dumping whole
> context and moving on to C code that handles the required logic. When
> I'm doing `backtrace` inside the C code, the backtrace is displayed to
> the point of assembler code for exception entering and "Backtrace
> stopped: previous frame identical to this frame (corrupt stack?)"
>
> The C code is using virtual frame pointer (I think) as fp/ip does not
> seem to be used on disassembled code. -O2 is causing -fomit-frame, I
> guess.
>
> I'm trying to put some values in ip / fp before calling C code so that
> gdb recognizes dumped exception context as a stack frame and
> interrupted code as a "caller". However without luck. It seems to me
> that gdb does not use the hard frame (fp) registers in case of lacking
> virtual frame pointers.
>
> I suspect the following could be possible:
>
> - add some linker symbols to assembler code so that gdb recognizes
> dumped interrupt context as frame
> - set some option in gdb so it uses fp for finding frame
>
> or, might be, I just don't set the fp correctly (but I think I do).
>
> Could anyone help me with an insights, links or example code how to
> achieve what I've described?

Some background: Debuggers use debugging/unwind info if available for
a frame. If a function does not have one it may fall back to frame
pointer linking, however this means the debugger will not know content
of registers (at the callsite) of any outer function beyond the frame.
This is acceptable for optimized code - when all interesting variables
reside on the stack. If your exception routine is not explicitly
called by an application (i.e. the asm routine is a processor trap or
a hardware interrupt) then registers will contain useful info which
would be unrecoverable if debugger used only frame pointer. (Debugger
may fall back to prologue analysis which does not have the limitation
- if it succeeds.)

Basically you have to add CFI annotations to your assembler code -
after each instruction which alters stack layout or swaps content of
not-saved-yet registers.

See documentation [1]. An example is [2] - the only one year ago,
there might be more examples these days.
I might try write the annotation if you want to but I am not exactly
familiar with ARM.

GAS's documentation about CFI and its purpose or even meaning is
terse. I guess it is secret, so do not tell anyone.
Also the CFI directives might not be supported on your architecture.
It is not written anywhere and it were not on my arch.

[1] http://sourceware.org/binutils/docs/as/CFI-directives.html
[2] http://www.logix.cz/michal/devel/gas-cfi/

-- 
Petr Hluzin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]