Re: MIPS stack tracing

[Greg McGary <greg at mcgary dot org>]

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