Re: Testing Call frame information in .debug_frame section

[Petr HluzÃn <petr dot hluzin at gmail dot com>]

Hi Anitha

On 13 February 2011 10:57, Anitha Boyapati <anitha.boyapati@gmail.com> wrote:
> 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 do not know how is .debug_frame/dwarf/CFI used on any arch.
If an architecture uses debugging info then "backtrace" and many other
commands use the info.

>>
>> I am glad to hear that GCC can somehow emit CFI data. What is the
>> state of the implementation?
>
> ...
> 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)

So it seems to be fished in avr-gcc?

>> 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?

Just go to binutils web and search for my name in the patch tracker.
Oh wait, they do not have one. Maybe this is the reason they forgot to
reply to my patches.

Here you have it:
http://xfree86.cygwin.ru/ml/binutils/2010-08/msg00109.html
(You might also like "add pretty-printing of AVR register names":
http://xfree86.cygwin.ru/ml/binutils/2010-08/msg00108.html)

>>
>> 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.

It does not use .debug_frame section (on AVR). It only looks up the
starting address of current function (the prologue scanner needs just
that).

-- 
Petr Hluzin