RE: MIPS stack tracing

[Don Bowman <don@sandvine.com>]

> Greg McGary <greg@mcgary.org> 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.

I've personally never observed multiple returns prior to 3.0, but perhaps 
I had some optimisation disabled which caused it.

I don't think you're correct about the no-multiple returns when there's
a frame. Here's a snippet of assembly from a function of mine.
As you can see, the stack is adjusted by 64 at the top. There
is an interior return which deadjusts the stack, and there's more
further down in the function.

 <osiSemaphore::Init(osiSemaphoreType)>:
0080102d        move    v0,a0
24470004        addiu   a3,v0,4
27bdffc0        addiu   sp,sp,-64
00a0402d        move    t0,a1
  ...
afa00030        sw      zero,48(sp)
dfbf0038        ld      ra,56(sp)
03e00008        jr      ra
27bd0040        addiu   sp,sp,64
00000000        nop
0c000000        jal     0 <osiSemaphore::Init(osiSemaphoreType)>
  ...

I've been debugging through gdb for a day or so now, I think 
I'm on to something. It appears that find_proc_desc is switching
to the heuristic approach even though I have a symbol table.
It sucessfully find the symbols, but given a PC, can't find
the symbol that its in. This may be due to the sign-extension
on the addresses (eg ffffffff80000000). I'm hoping to get a
fix for gdb today and send in a patch.

--don