Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: andrew.stubbs@st.com, gdb-patches@sourceware.org
Subject: Re: [RFC] Move the frame zero PC check earlier
Date: Mon, 24 Jul 2006 19:32:00 -0000	[thread overview]
Message-ID: <20060724193245.GB13612@nevyn.them.org> (raw)
In-Reply-To: <200607221122.k6MBMrdP000084@elgar.sibelius.xs4all.nl>

On Sat, Jul 22, 2006 at 01:22:53PM +0200, Mark Kettenis wrote:
> But the "having a saved pc of zero" is only one of the conventions
> used for terminating the frame chain.  So the DWARF-2 unwinder would
> still fail to do the right thing for ISA/ABI's that use a different
> convention.  So I think we need an ISA/ABI-specefic callback to
> determine whether a frame is the outermost frame, just like we already
> have for signal trampolines.

I'm fine with this; it seems easy enough to work with.  Have you got
any other conventions in mind?  For functions which might use the DWARF
unwinder, I've only seen the return address undefined convention (which
we basically made up), and the PC == 0 convention.  We could implement
e.g. %ebp == 0, but you've pointed out that it can misfire with
-fomit-frame-pointer.

Where would the PC==0 test be applied?  I and several others in
this thread have said that it makes sense in every case for every
platform - that's why I wanted it in frame.c, rather than in each
individual unwinder.  I can't tell from this paragraph whether we've
convinced you, or whether you would push it out to the individual
architectures to decide.  I'm unhappy with individual architecture
knobs for basically the same reason we've agreed it shouldn't be a user
knob.

> The outermost frame is special, just like sigtramp and dummy frames.
> Why not introduce a new frame type OUTERMOST_FRAME and make
> get_prev_frame() return NULL if that's the type of THIS_FRAME's?  This
> would require some changes to the current frame unwinder
> infrastructure, since the type is currently hardcoded into the
> unwinder.  That would have the additional benefit that we could get
> rid of the bogosity that we have multiple frame unwinder definitions
> in the DWARF-2 unwinder just to handle signal trampolines.

I suspect that OUTERMOST_FRAME would be a lot of trouble.  There's a
lot of checks on frame types that look for "abnormal" frames via
->type != NORMAL_FRAME; but a function called by an OUTERMOST_FRAME was
a normal call, just like a function called by a NORMAL_FRAME.  That's
why I suggested a new unwinder method in struct frame_unwind.

-- 
Daniel Jacobowitz
CodeSourcery


  reply	other threads:[~2006-07-24 19:32 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-10 18:03 Daniel Jacobowitz
2006-05-11 10:42 ` Andrew STUBBS
2006-05-11 22:24 ` Jim Blandy
2006-05-11 22:32   ` Daniel Jacobowitz
2006-05-12  6:21     ` Jim Blandy
2006-05-12 12:46       ` Daniel Jacobowitz
2006-05-13 10:14 ` Mark Kettenis
2006-05-13 15:17   ` Daniel Jacobowitz
2006-05-13 15:46     ` Daniel Jacobowitz
2006-05-13 17:08       ` Mark Kettenis
2006-05-13 16:49     ` Mark Kettenis
2006-05-13 18:53       ` Daniel Jacobowitz
2006-05-16 21:38       ` Daniel Jacobowitz
2006-05-16 22:19         ` Mark Kettenis
2006-05-16 22:46           ` Daniel Jacobowitz
2006-05-16 23:53             ` PAUL GILLIAM
2006-05-18  1:35               ` Joel Brobecker
2006-05-18  9:31                 ` Jim Blandy
2006-05-18 10:09                   ` Andrew STUBBS
2006-05-18 17:36                     ` Jim Blandy
2006-05-18 18:09                       ` PAUL GILLIAM
2006-05-18 20:04                         ` Jim Blandy
2006-05-18 20:43                           ` Mark Kettenis
2006-05-18 23:31                             ` Jim Blandy
2006-05-20 22:26                               ` Mark Kettenis
2006-05-21  2:12                                 ` Daniel Jacobowitz
2006-07-21 15:52                                   ` Andrew STUBBS
2006-07-22 11:23                                     ` Mark Kettenis
2006-07-24 19:32                                       ` Daniel Jacobowitz [this message]
2006-07-26 22:16                                         ` Mark Kettenis
2006-07-26 22:25                                           ` Daniel Jacobowitz
2006-05-19  3:32                             ` Daniel Jacobowitz
2006-05-20 21:30                               ` Mark Kettenis
2006-05-19 12:26                             ` Eli Zaretskii
2006-05-19 18:12                               ` Jim Blandy
2006-05-19 18:53                                 ` Eli Zaretskii
2006-05-22 23:15                                   ` Jim Blandy
2006-05-15 13:57   ` Andrew STUBBS

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=20060724193245.GB13612@nevyn.them.org \
    --to=drow@false.org \
    --cc=andrew.stubbs@st.com \
    --cc=gdb-patches@sourceware.org \
    --cc=mark.kettenis@xs4all.nl \
    /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