From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23222 invoked by alias); 8 Mar 2004 03:23:26 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23209 invoked from network); 8 Mar 2004 03:23:25 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 8 Mar 2004 03:23:25 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B0BMS-0000Tt-Io; Sun, 07 Mar 2004 22:23:24 -0500 Date: Mon, 08 Mar 2004 03:23:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa/mips] Stop backtraces when we've lost the PC Message-ID: <20040308032324.GA1325@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20040306231743.GA9379@nevyn.them.org> <404BC4B2.7000100@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <404BC4B2.7000100@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03.o/txt/msg00146.txt 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23222 invoked by alias); 8 Mar 2004 03:23:26 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23209 invoked from network); 8 Mar 2004 03:23:25 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 8 Mar 2004 03:23:25 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B0BMS-0000Tt-Io; Sun, 07 Mar 2004 22:23:24 -0500 Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa/mips] Stop backtraces when we've lost the PC Message-ID: <20040308032324.GA1325@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20040306231743.GA9379@nevyn.them.org> <404BC4B2.7000100@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <404BC4B2.7000100@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00146.txt.bz2 Message-ID: <20040319000900.fPJUaAc_qPuBy3x_y0yZx1D2AIBqnwyAJtUdd1dGdlw@z> 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