From: Daniel Jacobowitz <drow@false.org>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: RFC: DW_OP_call_frame_cfa, again
Date: Tue, 01 Sep 2009 22:50:00 -0000 [thread overview]
Message-ID: <20090901225003.GA28876@caradoc.them.org> (raw)
In-Reply-To: <m3skf6tu5i.fsf@fleche.redhat.com> <m37hxauldt.fsf@fleche.redhat.com>
On Tue, Aug 11, 2009 at 02:49:02PM -0600, Tom Tromey wrote:
> This version implements Daniel's idea of checking the frame unwinder.
> If you read the followup message (above) you'll see that this patch is
> different from what I talked about there; that approach doesn't work
> since the DWARF frame base sniffer is not registered for many
> architectures. Jan suggested the current approach.
Am I correct that this works only if all unwinders for this
architecture use the same CFA notion that DWARF-2 would? If so -
probably already a requirement - it deserves a comment.
> One further issue is that this interacts poorly with the i386 epilogue
> unwinder. I punted on this issue for the time being. However, with GCC
> 4.5, I think the DWARF unwinder is supposed to work fine for epilogues
> -- so can we make the epilogue unwinder conditional? Is this special
> unwinder only needed for reverse execution? If so, could we make it
> conditional on when that mode is enabled?
It's useful at other times. My canonical torture test for this is a
software watchpoint on a local variable, and then "next" over the
application's first call to printf - with glibc debug info. You'll go
through the PLT, ld.so, printf itself, nested functions, et cetera.
Without an epilogue unwinder the only reason this survives is an
in_epilogue_p or similar hack in the watchpoint checking code.
With GCC 4.5 the DWARF unwinder ought to work fine for epilogues on
specific platforms, not all.
On Tue, Sep 01, 2009 at 12:08:25PM -0600, Tom Tromey wrote:
> >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
>
> Tom> Here is a new version of my patch to implement DW_OP_call_frame_cfa.
> Tom> Previous thread here:
> Tom> http://sourceware.org/ml/gdb-patches/2009-06/msg00191.html
> Tom> With followup the next month (I wish our mailing list archive handled
> Tom> this more nicely):
> Tom> http://sourceware.org/ml/gdb-patches/2009-07/msg00570.html
>
> Here is an updated version. This fixes a couple of bugs found by
> testing it in Fedora rawhide.
>
> I'm happy with this version, so I plan to check it in next week or so.
> Comment soon if you think it needs some change.
Aside from above, this version seems fine.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2009-09-01 22:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-12 0:52 Tom Tromey
2009-09-01 18:08 ` Tom Tromey
2009-09-01 23:07 ` Doug Evans
2009-09-01 23:41 ` Tom Tromey
2009-09-01 23:24 ` Pedro Alves
2009-09-01 23:47 ` Tom Tromey
2009-09-02 14:53 ` Tom Tromey
2009-09-02 14:59 ` Pedro Alves
2009-09-02 16:48 ` Tom Tromey
2009-09-02 17:01 ` Pedro Alves
2009-09-01 22:50 ` Daniel Jacobowitz [this message]
2009-09-01 23:51 ` 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=20090901225003.GA28876@caradoc.them.org \
--to=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.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