This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa/mips] Stop backtraces when we've lost the PC
- From: Daniel Jacobowitz <drow at false dot org>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sun, 7 Mar 2004 22:23:24 -0500
- Subject: Re: [rfa/mips] Stop backtraces when we've lost the PC
- References: <20040306231743.GA9379@nevyn.them.org> <404BC4B2.7000100@gnu.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