Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@chello.nl>
To: Michael Elizabeth Chastain <mec@shout.net>
Cc: ac131313@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [patch, rfc, 6.0] Change frame predicates to sniffers
Date: Sun, 13 Jul 2003 16:55:00 -0000	[thread overview]
Message-ID: <86u19qpdsc.fsf@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: Michael Elizabeth Chastain's message of "Sat, 12 Jul 2003 15:19:33 -0400"

Michael Elizabeth Chastain <mec@shout.net> writes:

> My test bed says: no regressions, no improvements.

Yup.  Andrews patches don't actually fix things yet.  To see any
improvements, the i386 frame unwinder (for stabs) and DWARF2 frame
unwinder need to be converted to make use of the new interfaces.

When I origionally checked in my new i386 frame unwinder I didn't
realise that by improving its prologue analyser I would introduce
regressions.  Let me explain what's happening.

For your testcases, the instructions after the function call are
optimized away.  This means that the return address of the called
frame points to the first instruction of the next function.  The
prologue analysis is done for this function instead of the function
that actually made the call.  Previously the prologue analyzer didn't
stop at the "current" PC, but instead it did a full analysis of the
prologue.  Since most prologues on the i386 start with the sequence

  push %ebp
  move %esp,%ebp

this means that it doesn't matter much which prologue we analyzed as
long as the frame pointer (%ebp) was set up correctly.  Since the
frame-pointer was set up correctly for the frame that made the call,
things seemed to be correct.

The new prologue analyzer notices that at the first instruction of a
function, the frame-pointer hasn't been setup yet, and the frame
unwinder uses the stack-pointer for unwinding.  This fails because we
haven't actually called the function we're analyzing.

We should be able to fix this by using the interfaces Andres is
proposing.  Therefore, Andres, please go ahead.

Mark


  reply	other threads:[~2003-07-13 16:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-12 19:19 Michael Elizabeth Chastain
2003-07-13 16:55 ` Mark Kettenis [this message]
2003-07-15 15:56 ` Andrew Cagney
  -- strict thread matches above, loose matches on Subject: below --
2003-07-14  5:35 Michael Elizabeth Chastain
2003-07-11 21:57 Andrew Cagney
2003-07-15 17:41 ` Andrew Cagney

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=86u19qpdsc.fsf@elgar.kettenis.dyndns.org \
    --to=kettenis@chello.nl \
    --cc=ac131313@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=mec@shout.net \
    /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