From mboxrd@z Thu Jan  1 00:00:00 1970
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
Message-id: <200103131933.OAA07556@texas.cygnus.com>
X-SW-Source: 2001-03/msg00195.html

    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