From: David Taylor <taylor@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: frameless_look_for_prologue
Date: Tue, 13 Mar 2001 11:33:00 -0000 [thread overview]
Message-ID: <200103131933.OAA07556@texas.cygnus.com> (raw)
From: Andrew Cagney <ac131313@cygnus.com>
Date: Fri, 09 Mar 2001 15:33:24 -0500
David Taylor wrote:
>
> I believe that every target that does:
>
> set_gdbarch_frameless_function_invocation (gdbarch,
> frameless_look_for_prologue);
>
> has a bug.
>
> The function frameless_look_for_prologue invokes PROLOGUE_FRAMELESS_P
> with one argument -- the pc of the *START* of the function.
>
> For backtraces, get_prev_frame wants to know not "does this function
> eventually set up a frame if I execute far enough into it", but rather
> "does this function have a frame at the point where the program has
> currently stopped".
I don't think this is right. As far as I know, the behavour is:
o gdb sets a breakpoint at the end
of the function prologue
i.e. break foo
not break *foo
o the target runs through to the end of
the prologue so that the stack frame's
construction is complete.
Sometimes the inferior stops at a location prior to the end of the
prologue -- examples: on receipt of a signal or due to a watchpoint.
GDB can only do correct backtraces after the frame has been
constructed. GDB doesn't handle backtraces part way through a stack
frame.
You need a frame for all the functions other than frame 0. If frame 0
hasn't been constructed, you can still potentially do the backtrace.
As far as I know, to make things so that GDB could re-construct a
partially built frame, GDB would need to understand things like dwarf2's
live range splitting stuff (correct name?) along with a few other dwarf2
(?) features which would, together, let GDB construct its frame frame
based on an aribtrary function address.
Agreed. While a partially constructed frame can cause problems, you
can make a better decision than now by limiting the decision to the
[function start pc, current pc) range.
On the processor where I first saw the problem, the frame is
constructed in the *middle* of the prologue -- some registers are
saved before it is done and some are saved afterwards. And it was a
watchpoint that triggered the stop...
enjoy,
Andrew
next reply other threads:[~2001-03-13 11:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-13 11:33 David Taylor [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-03-09 6:50 frameless_look_for_prologue David Taylor
2001-03-09 12:55 ` frameless_look_for_prologue Andrew Cagney
2001-03-09 13:48 ` frameless_look_for_prologue Michael Snyder
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=200103131933.OAA07556@texas.cygnus.com \
--to=taylor@cygnus.com \
--cc=ac131313@cygnus.com \
--cc=gdb-patches@sourceware.cygnus.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