Re: [rfa/mips] Stop backtraces when we've lost the PC

[Daniel Jacobowitz <drow at false dot org>]

On Sun, Mar 07, 2004 at 07:56:18PM -0500, Andrew Cagney wrote:
> >Here's an updated version of a little hack I've been using since GDB 6.0.
> >If we are in a nested normal frame, i.e. something whose next frame is a
> >function that it called in the normal way, and we didn't find a saved PC,
> >we're going to be stuck in a loop.  We might have been able to figure out
> >the frame size, but not where the return address was stored; as the comment
> >says, this happens in glibc's clone function.  Of course the problem there
> >is that it _doesn't_ save $ra in the normal fashion; it won't return.
> >
> >Without this patch schedlock.exp falls apart, because backtraces continue
> >forever printing "clone()" on every line.
> >
> >OK?
> 
> No!
> 
> >+  if (frame_relative_level (next_frame) >= 0
> >+      && get_frame_type (next_frame) == NORMAL_FRAME
> >+      && !trad_frame_addr_p (info->saved_regs, NUM_REGS + PC_REGNUM))
> 
> The whole point of this recursive code is that you don't need to add 
> hacks that look down the stack at the type of more inner frames :-/
> 
> Can you post the relevant assembler so that we can determine why the 
> prologue analyzer is failing.

This is clone.  It can't be unwound past - there is no stack behind it
(we're in the child, here).

00113730 <__clone>:
  113730:       3c1c000c        lui     gp,0xc
  113734:       279ca5c0        addiu   gp,gp,-23104
  113738:       0399e021        addu    gp,gp,t9
  11373c:       27bdffe8        addiu   sp,sp,-24
  113740:       afbc0014        sw      gp,20(sp)
  113744:       10800010        beqz    a0,113788 <__clone+0x58>
  113748:       24020016        li      v0,22
  11374c:       10a0000e        beqz    a1,113788 <__clone+0x58>
  113750:       00000000        nop
  113754:       24a5ffe0        addiu   a1,a1,-32
  113758:       aca40000        sw      a0,0(a1)
  11375c:       aca70004        sw      a3,4(a1)
  113760:       00c02021        move    a0,a2
  113764:       24021018        li      v0,4120
  113768:       0000000c        syscall
  11376c:       14e00006        bnez    a3,113788 <__clone+0x58>
  113770:       00000000        nop
  113774:       10400008        beqz    v0,113798 <__thread_start>
  113778:       00000000        nop
  11377c:       03e00008        jr      ra
  113780:       27bd0018        addiu   sp,sp,24
  113784:       00000000        nop
  113788:       8f998290        lw      t9,-32112(gp)
  11378c:       27bd0018        addiu   sp,sp,24
  113790:       03200008        jr      t9
  113794:       00000000        nop
00113798 <__thread_start>:
  113798:       afbc0014        sw      gp,20(sp)
  11379c:       8fb90000        lw      t9,0(sp)
  1137a0:       8fa40004        lw      a0,4(sp)
  1137a4:       0320f809        jalr    t9
  1137a8:       00000000        nop
  1137ac:       8fbc0014        lw      gp,20(sp)
  1137b0:       00402021        move    a0,v0
  1137b4:       8f9991f4        lw      t9,-28172(gp)
  1137b8:       00000000        nop
  1137bc:       0320f809        jalr    t9
  1137c0:       00000000        nop

The last jalr is exit.

And here's its PDR (little endian):
 0e0c0 30371100 00000000 00000000 00000000  07..............
 0e0d0 00000000 10000000 1d000000 1d000000  ................
 0e0e0 98371100 00000000 00000000 00000000  .7..............
 0e0f0 00000000 00000000 00000000 00000000  ................

Frame register is sp, stack size is 16, no registers saved for clone. 
Then stack size 0, no registers saved, frame register is zero for
__thread_start, which is where we are.  I don't know why that didn't
terminate the stack trace right away, I'll bring the board back up
tomorrow to find out.

I'm pretty sure I had another case in mind when I wrote the first
version of this patch, but I can't think what it was now.  So maybe
this is the only one.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer