From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: eager@eagercon.com
Cc: wenbo.yang@simplnano.com, mark.kettenis@xs4all.nl,
gdb@sources.redhat.com
Subject: Re: frame cache
Date: Mon, 30 Jul 2007 23:07:00 -0000 [thread overview]
Message-ID: <200707302212.l6UMC0WN029743@brahms.sibelius.xs4all.nl> (raw)
In-Reply-To: <46AE5570.7080202@eagercon.com> (message from Michael Eager on Mon, 30 Jul 2007 14:17:36 -0700)
> Date: Mon, 30 Jul 2007 14:17:36 -0700
> From: Michael Eager <eager@eagercon.com>
>
> >> I don't see where there is any test in symtab.c or infrun.c
> >> which tests for debug info before calling SKIP_PROLOGUE which
> >> calls <target>_skip_prologue.
> >
> > Because if you want to use debugging information to skip prologue, you
> > write the code in this function. So, test should be place here in this
> > function.
>
> As I mentioned, in x86 or PowerPC there is no code to bypass analyzing
> the prologue, even if there is debug info. If prologue analysis is
> truly to be done "only as a last resort", and I agree that this should
> be the case, then this seems not to be represented in the gdb code.
In the context of the the frame cache, prologue analysis *is* only
done as a last resort for all targets that have DWARF CFI. We have a
stack of unwinders, and run down that stack until we find an unwinder
that can handle a particular frame. The unwinder that does the
prologue analysis comes last in that stack, after the DWARF unwinder.
So if there is DWARF CFI debug info for a frame, the prologue analysis
is never done. Of course in practice you're probably running lots of
code that doesn't have debug info because many vendors install
stripped libraries.
Now on some targets we also do prologue analysis when placing a
breakpoint on a function. In theory this should also be possible
using DWARF debug info, except that GCC doesn't (yet) provide that
information. We used to do this using line number information (and on
some targets we still do that), but that became unreliable when the
compiler started to agressively reschedule prologue instructions. And
then there were issues with the line number information generated by
GCC being wrong. However, this is only done when setting breakpoints,
so it shouldn't really be happening that much, and therefore isn't
very performance critical. It also doesn't really have anything to do
with the frame cache.
So I'm not really sure under which conditions you're observing the
excessive prologue analysis. If you're seeing it during frame
unwinding, it might be worth investigating why the DWARF frame
unwinder doesn't handle things. Perhaps you should consider
installing unstripped libraries, or seperate debug info for the
libraries on your system. If you are seeing it when breakpoints get
set, it is probably worth working on getting GCC to emit the proper
debug info and implementing support for it in GDB.
Mark
next prev parent reply other threads:[~2007-07-30 22:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-24 17:08 Michael Eager
2007-07-24 17:14 ` Michael Eager
2007-07-24 17:36 ` Daniel Jacobowitz
2007-07-24 18:19 ` Michael Eager
2007-07-24 18:34 ` Mark Kettenis
2007-07-24 18:34 ` Daniel Jacobowitz
2007-07-24 17:17 ` Daniel Jacobowitz
2007-07-24 18:10 ` Michael Eager
2007-07-24 18:22 ` Daniel Jacobowitz
2007-07-24 18:45 ` Michael Eager
2007-07-24 18:45 ` Mark Kettenis
2007-07-24 19:08 ` Michael Eager
2007-07-25 2:18 ` Paul Koning
2007-07-27 9:18 ` Wenbo Yang
2007-07-30 22:01 ` Michael Eager
2007-07-30 23:07 ` Mark Kettenis [this message]
2007-07-31 3:51 ` Wenbo Yang
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=200707302212.l6UMC0WN029743@brahms.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=eager@eagercon.com \
--cc=gdb@sources.redhat.com \
--cc=wenbo.yang@simplnano.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