From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22221 invoked by alias); 24 Mar 2006 21:36:09 -0000 Received: (qmail 22211 invoked by uid 22791); 24 Mar 2006 21:36:08 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 24 Mar 2006 21:36:06 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FMtwx-0003Oc-De; Fri, 24 Mar 2006 16:36:03 -0500 Date: Fri, 24 Mar 2006 23:08:00 -0000 From: Daniel Jacobowitz To: Alexandre Oliva Cc: Mark Kettenis , gdb-patches@sources.redhat.com, roland@redhat.com Subject: Re: Support Dwarf3 DW_CFA_val_* expressions Message-ID: <20060324213603.GE26748@nevyn.them.org> Mail-Followup-To: Alexandre Oliva , Mark Kettenis , gdb-patches@sources.redhat.com, roland@redhat.com References: <200603041017.k24AHjh7024812@elgar.sibelius.xs4all.nl> <20060304145755.GB20187@nevyn.them.org> <200603070838.k278cSMx005401@elgar.sibelius.xs4all.nl> <20060311190811.GA26990@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00278.txt.bz2 On Sun, Mar 12, 2006 at 11:25:41PM -0300, Alexandre Oliva wrote: > On Mar 11, 2006, Daniel Jacobowitz wrote: > > > On Tue, Mar 07, 2006 at 02:46:00PM -0300, Alexandre Oliva wrote: > >> Using the address of the first instruction in the region wouldn't work > >> either. The hand-generated unwind info arranges for _L_mutex_lock_31 > >> on i386 to seem like it calls itself, for some reason I don't quite > >> understand. Jakub says the backtrace we get after my change is > >> correct, whereas *without* the patch we get this: > > > Where does this hand generated unwind info come from? > > Jakub's testcase submitted as part of the patch. OK, you and I were using "entry into a new frame" differently. Here's the function: 8048584: 8b 75 08 mov 0x8(%ebp),%esi 8048587: 8d 9d f8 fe ff ff lea 0xfffffef8(%ebp),%ebx 804858d: 85 f6 test %esi,%esi 804858f: 75 7c jne 804860d <_L_mutex_lock_156> 8048591: 81 c4 00 01 00 00 add $0x100,%esp ... 0804860d <_L_mutex_lock_156>: 804860d: 8d 4d 08 lea 0x8(%ebp),%ecx 8048610: e8 4b ff ff ff call 8048560 8048615: e9 77 ff ff ff jmp 8048591 Here's the frame info: 00000014 0000002c 00000018 FDE cie=00000000 pc=0804860d..0804861a DW_CFA_val_expression: r8 (DW_OP_breg8: 8) DW_CFA_advance_loc: 3 to 08048610 DW_CFA_val_expression: r8 (DW_OP_breg8: 5) DW_CFA_advance_loc: 4 to 08048614 DW_CFA_val_expression: r8 (DW_OP_breg8: 6; DW_OP_const4s: -382; DW_OP_minus; DW_OP_const4s: -520; DW_OP_plus) DW_CFA_nop DW_CFA_nop r8 is the return address column. That's %eip. So for the first two instructions of this "function", we claim that we return to the jump instruction. If you're going to put that in the unwind information, why shouldn't you expect GDB to show the jump as the next address in the backtrace? [Why the second one advances loc by 4 bytes instead of 5 I don't know. It looks like it might be a bug in the version of gas I used; the test looks OK.] Then, at the jump, the PC is unwound to PC + 6 - (-382) + (-520) [for reasons involving the difference of labels in different sections, AFAICT]. That puts us back where we came from. I assume these hoops are jumped through to reduce the size of the debug info, while maintaining its PIC-ness. Gotta be a better way... but I don't see any reason why, given this unwind info, GDB should not display the frame twice. Which I think means some version of your patch already posted is correct, minus any arguments about the test cases, but I'm no longer quite sure which version. -- Daniel Jacobowitz CodeSourcery