Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


             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