Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Greg McGary <greg@mcgary.org>
To: Don Bowman <don@sandvine.com>
Cc: "'Daniel Jacobowitz'" <drow@mvista.com>,
	gdb@sources.redhat.com, echristo@redhat.com, greg@mcgary.org
Subject: Re: MIPS stack tracing
Date: Sat, 02 Feb 2002 11:16:00 -0000	[thread overview]
Message-ID: <msy9ibg0dz.fsf@mcgary.org> (raw)
In-Reply-To: <FE045D4D9F7AED4CBFF1B3B813C853371BC1C2@mail.sandvine.com>

Don Bowman <don@sandvine.com> writes:

> The gist of it is, walk backwards until you find 'jr ra',
> then walk forwards to the first non-null instruction. That's
> the start of a function. Look for a [d]addiu to the sp, that's
> the stack adjustment, look for a [d]addiu to the fp, that's
> the frame. Look for a s[w|d] of ra to the stack.
> Continue on up the stack.
> 
> However, gcc 3.0 is breaking the rules. It emits multiple
> 'jr ra' per function. Unfortunately, this appears to be
> rather tough to fix. The upshot is that the beginning of
> a function can't be reliably found, and it all falls apart
> from there. Prior to gcc 3.0 it was fine.

[ Cc'd to Eric Christopher who has a hand in the MIPS GCC backend, and
  with whom I briefly discussed this very issue a couple weeks ago. ]

Hmm...  GCC emitted multiple returns for MIPS long before 3.0.
I recall first observing it in early 1998, and it had probably
done it before.  Maybe GCC 3.0 does it more often?

Anyway, I had the same gripe about multiple returns breaking the ABI,
but since then I have had second thoughts that perhaps this isn't a
real problem.  I haven't looked at MIPS code recently, so don't know
for certain if my reasoning here is correct.  Since you have had your
nose buried in the code, you can tell me if my argument makes sense:

If a function has a frame, it never has multiple returns.  It always
branches to the epilogue where the call frame is torn down.  So, if a
function has multiple returns, that means it is frameless,
i.e. there's no prologue or epilogue.  Say you scan backward within a
frameless function.  You might hit an interior `jr $ra' or the one
that terminates the previous function.  When you then scan forward,
you'll find no stack adjustment and no store of $ra in any case.  In
call cases, you get the same answer: this function has no frame.
Therefore, multiple returns are harmless since they give no false
information about the call frame.

OTOH, Something that can cause trouble is the GCC block-reordering
optimization.  This can cause the epilogue to be located in the middle
of a function.  You can defeat it with `GCC -fno-reorder-blocks'.

Greg


  parent reply	other threads:[~2002-02-02 19:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-01 10:15 Don Bowman
2002-02-01 11:32 ` Daniel Jacobowitz
2002-02-02 11:16 ` Greg McGary [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-02-07  6:56 Don Bowman
2002-02-07  7:30 ` Daniel Jacobowitz
2002-02-06  9:40 Don Bowman
2002-02-06 16:45 ` Daniel Jacobowitz
2002-02-04  9:22 David Anderson
2002-02-03 15:49 Don Bowman
2002-02-03 12:29 Don Bowman
2002-02-03 12:29 ` Daniel Jacobowitz
2002-02-03 12:29   ` Andrew Cagney
2002-02-03 12:13     ` Daniel Jacobowitz
2002-02-03 12:29       ` Andrew Cagney
2002-02-02 12:14 Don Bowman
2002-02-02 14:45 ` Daniel Jacobowitz
2002-02-02 11:26 Don Bowman
2002-02-02 12:11 ` Stan Shebs
2002-02-02 10:58 David Anderson
2002-02-02  9:57 David Anderson
2002-01-31 14:27 Don Bowman
2002-02-01  9:37 ` Daniel Jacobowitz

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=msy9ibg0dz.fsf@mcgary.org \
    --to=greg@mcgary.org \
    --cc=don@sandvine.com \
    --cc=drow@mvista.com \
    --cc=echristo@redhat.com \
    --cc=gdb@sources.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