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: Testing Call frame information in .debug_frame section


Hello Petr,

On 13 February 2011 08:04, Petr Hluzín <petr.hluzin@gmail.com> wrote:
>
>
> GDB does not use CFI on Atmel AVR, see avr-tdep.c. There is only one
> call to frame_unwind_append_unwinder().

Yes. I have looked into the code and it looked like the support is not
present. But my understanding is still incomplete. frame-unwind.h/c
files are what I have been looking through. Even if it is supported in
other targets like ARM perhaps, how do we use that? Which of the gdb
commands' processing involves frame unwinding following dwarf2/3/4...?


>
> I am glad to hear that GCC can somehow emit CFI data. What is the
> state of the implementation?

It has macros which is defined can fill .debug_frame with CIE and FDE
information. The implementation from target side is very minimal.

* The prologue instructions that modify frame/stack pointer have to be
marked with RTX_FRAME_RELATED_P().
* The hook INCOMING_RETURN_ADDR_RTX should know how to access return
address on stack. The return address can be stored in memory or in
some register.
*  Likewise, hook INCOMING_FRAME_SP_OFFSET should specify the stack
pointer offset from its previous frame but before prologue of the
current function.

The macros are documented in stack layout and calling conventions of
gcc internals. Emitting CFI is optional in GCC. I used DWARF2 standard
and the output seemed to comply it. (For now I am manually verifying
the dump of debug_frame section)


> I tried to use CFI statements in GAS (binutils), but it cannot parse
> them and provides misleading diagnostics. (I even submitted a patch
> for that but never received any response.)

Sounds interesting. Can you provide the link?

>
> I tried to improve GDB's ability to scan prologues a year ago, however
> I ran out of enthusiasm. (The better scanner would allow stack
> reconstruction even without .debug_frame/CFI info.)
>

How does GDB currently use information from .debug_frame section? From
the chat rooms I came to know that current GDB can limp along without
CFI information. It tries to scan the prologues and epilogues and
build frame information is what I came to know. Although I did not
analyze how.

> I think I know where and how to hook the new CFI-based unwinder.
> However I am not familiar with .debug_frame unwinding in GDB.
> I am interested in writing the unwinder. I will need an example ELF
> with trivial code run-able in simulator and lots of faith/enthusiasm.
> (Assuming the compiler implements this spec:
> http://dwarfstd.org/doc/DWARF4.pdf, or dwarf-2.0.0.pdf)
>

:-)


Anitha


> --
> Petr Hluzin


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