Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@redhat.com>
To: Jim Blandy <jimb@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: report failure to restore selected frame, but continue
Date: Thu, 10 Apr 2003 01:55:00 -0000	[thread overview]
Message-ID: <3E94CEEC.3060302@redhat.com> (raw)
In-Reply-To: <vt2k7e3tklp.fsf@zenia.red-bean.com>

Jim,

The opening line should state up front that ``An architecture 
incorrectly using it's stack pointer as the frame ID's stack address 
...''.  That way, the specific bug identified by 1155, is made clear 
from the start.  At present it isn't mentioned until the third paragraph.

I should also note that frame_id_eq() is ~week from being `fixed'.  You 
may want to drop that part.

enjoy,
Andrew

> + # Suppose an architecture uses the stack pointer as its frame base
> + # (that is, the 'base' member of its frame ID).  (Ignore functions
> + # that use alloca for the moment.)  This means that the youngest
> + # frame's base is the top of the stack.  If that function calls a
> + # frameless function, then the caller and callee frames will have
> + # identical base addresses.  frame_id_eq is supposed to use both the
> + # base and pc fields of the ID's to decide whether they're eq, but as
> + # of 4-2003 it doesn't, so code like frame_find_by_id can't
> + # distinguish between those two frames.
> + #
> + # This means that, on such architectures, if the marker function we're
> + # stopped at in this test is frameless, GDB doesn't properly restore
> + # the selected frame after an inferior function call:
> + # infrun.c:restore_selected_frame will select the youngest frame (the
> + # marker function), not its caller (main).
> + #
> + # Changing frame_id_eq isn't really a full solution, though.  By
> + # definition, a frame base is constant over the lifetime of the frame.
> + # However, the stack pointer changes as a function's prologue code
> + # sets up the stack frame, making it unsuitable for use as a frame
> + # base.  The address of the inner end of each frame --- furthest from
> + # the stack pointer --- would work better here; it remains unchanged
> + # through frame allocation, frame teardown, and any alloca'ing that
> + # might happen in between.
> + #
> + # Of course, strictly speaking, that just shifts the problem around:
> + # if there's a younger frame sitting on top of a frameless frame, then
> + # they'll have identical ID's.  But frameless functions can't call
> + # other functions directly, at least using the standard ABI --- they
> + # have no place to save the return address.  Only signal delivery
> + # frames and inferior calls can be there, and those have all sorts of
> + # other associated magic.
> + #
> + # Anyway, if GDB fails to restore the selected frame properly after
> + # the inferior function call above, all the subsequent tests will
> + # fail.  We should detect report that failure, but let the marker call
> + # finish so that the rest of the tests can run undisturbed.



      parent reply	other threads:[~2003-04-10  1:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-09 21:40 Jim Blandy
2003-04-09 22:14 ` David Carlton
2003-04-09 23:21   ` Jim Blandy
2003-04-10  1:55 ` Andrew Cagney [this message]

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=3E94CEEC.3060302@redhat.com \
    --to=ac131313@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@redhat.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