Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@redhat.com>
To: Richard.Earnshaw@arm.com
Cc: Michael Snyder <msnyder@cygnus.com>,
	gdb-patches@sources.redhat.com, cagney@redhat.com,
	rearnsha@arm.com
Subject: Re: [RFA] arm_skip_prologue: recognize "str r(0123), [r11, #-nn]"
Date: Tue, 23 Apr 2002 10:47:00 -0000	[thread overview]
Message-ID: <3CC59B63.17E26EBC@redhat.com> (raw)
In-Reply-To: <200204230954.KAA01842@cam-mail2.cambridge.arm.com>

Richard Earnshaw wrote:
> 
> > >
> > > GCC sometimes generates these stores as discrete instructions.
> > >
> > > 2002-04-22  Michael Snyder  <msnyder@redhat.com>
> > >
> > >     * arm-tdep.c (arm_skip_prologue): Recognize str r(0123), [r11, #-nn].
> > >
> >
> > Are you sure these should really be considered part of the prologue?
> >
> >
> >
> 
> Ok, here's how I think we should consider this.
> 
> If a DWARF-encoded sequence would consider these as part of the prologue
> (ie they are described as prologue instructions, then the unwinder should
> consider them similarly.  If, however, it considers them as part of the
> function body then the manual unwinder should also do so.

Richard, 

This disassembly method is only invoked if there is no dwarf info.
If we do have line numbers etc, we use those by preference.
So when we are disassembling, we cannot rely on hints from the
debug info.

I have confirmed that, when there is debug info, 
these instructions are lumped with the prologue.

> 
> If the latter is correct, then we should also handle storing into the
> stack so that we can also handle frameless functions.
> 
> R.


  reply	other threads:[~2002-04-23 17:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-22 16:29 Michael Snyder
2002-04-23  2:36 ` Richard Earnshaw
2002-04-23  2:55   ` Richard Earnshaw
2002-04-23 10:47     ` Michael Snyder [this message]
2002-04-24  2:08       ` Richard Earnshaw
2002-04-24 14:23         ` Michael Snyder
2002-04-23 10:46   ` 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=3CC59B63.17E26EBC@redhat.com \
    --to=msnyder@redhat.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=cagney@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=msnyder@cygnus.com \
    --cc=rearnsha@arm.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