This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: frameless_look_for_prologue
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: frameless_look_for_prologue
- From: David Taylor <taylor at cygnus dot com>
- Date: Tue, 13 Mar 2001 14:33:13 -0500
- cc: gdb-patches at sourceware dot cygnus dot com
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