From: Anitha Boyapati <anitha.boyapati@gmail.com>
To: "Petr Hluzín" <petr.hluzin@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: Testing Call frame information in .debug_frame section
Date: Sun, 13 Feb 2011 09:57:00 -0000 [thread overview]
Message-ID: <AANLkTimOXF1V__SSFs1gtqJh5nc183EdeHm5NoeU6YXs@mail.gmail.com> (raw)
In-Reply-To: <AANLkTi=Rnu-wb2W8FejN=XQHmHuTq7rZovKuDdO-QLwi@mail.gmail.com>
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
next prev parent reply other threads:[~2011-02-13 9:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-01 13:04 Anitha Boyapati
2011-02-13 2:34 ` Petr Hluzín
2011-02-13 9:57 ` Anitha Boyapati [this message]
2011-02-13 15:11 ` Petr Hluzín
2011-02-15 17:41 ` Richard Henderson
2011-02-15 18:09 ` Anitha Boyapati
2011-02-15 18:48 ` Richard Henderson
2011-02-15 19:15 ` Anitha Boyapati
2011-02-15 19:03 ` [avr] gas support for cfi info Richard Henderson
2011-02-15 22:45 ` Petr Hluzín
2011-02-16 17:59 ` Richard Henderson
2011-02-16 22:49 ` Petr Hluzín
2011-02-17 16:12 ` Richard Henderson
2011-02-17 16:16 ` Tristan Gingold
2011-02-17 15:35 ` Anitha Boyapati
2011-02-17 16:05 ` Richard Henderson
2011-02-17 19:53 ` Richard Henderson
2011-02-22 16:18 ` Anitha Boyapati
2011-02-22 17:51 ` Richard Henderson
2011-02-15 18:18 ` Testing Call frame information in .debug_frame section Anitha Boyapati
2011-02-15 22:12 ` Petr Hluzín
2011-02-14 16:42 ` Tom Tromey
2011-02-14 22:43 ` Petr Hluzín
2011-02-15 15:06 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTimOXF1V__SSFs1gtqJh5nc183EdeHm5NoeU6YXs@mail.gmail.com \
--to=anitha.boyapati@gmail.com \
--cc=gdb@sourceware.org \
--cc=petr.hluzin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox