Tue Mar 13 11:33:00 GMT 2001
From: Andrew Cagney <firstname.lastname@example.org>
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,
> 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
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...
More information about the Gdb-patches