From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5698 invoked by alias); 7 Mar 2006 17:46:11 -0000 Received: (qmail 5685 invoked by uid 22791); 7 Mar 2006 17:46:10 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 07 Mar 2006 17:46:07 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k27Hk5JQ019240 for ; Tue, 7 Mar 2006 12:46:05 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k27Hk4121094; Tue, 7 Mar 2006 12:46:04 -0500 Received: from free.oliva.athome.lsd.ic.unicamp.br (vpn50-112.rdu.redhat.com [172.16.50.112]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id k27Hk3xf026683; Tue, 7 Mar 2006 12:46:03 -0500 Received: from free.oliva.athome.lsd.ic.unicamp.br (free.oliva.athome.lsd.ic.unicamp.br [127.0.0.1]) by free.oliva.athome.lsd.ic.unicamp.br (8.13.5/8.13.5) with ESMTP id k27Hk1Vc031179; Tue, 7 Mar 2006 14:46:01 -0300 Received: (from aoliva@localhost) by free.oliva.athome.lsd.ic.unicamp.br (8.13.5/8.13.5/Submit) id k27Hk04C031178; Tue, 7 Mar 2006 14:46:00 -0300 To: Mark Kettenis Cc: gdb-patches@sources.redhat.com, roland@redhat.com Subject: Re: Support Dwarf3 DW_CFA_val_* expressions References: <200603041017.k24AHjh7024812@elgar.sibelius.xs4all.nl> <20060304145755.GB20187@nevyn.them.org> <200603070838.k278cSMx005401@elgar.sibelius.xs4all.nl> From: Alexandre Oliva Date: Tue, 07 Mar 2006 19:55:00 -0000 In-Reply-To: <200603070838.k278cSMx005401@elgar.sibelius.xs4all.nl> (Mark Kettenis's message of "Tue, 7 Mar 2006 09:38:28 +0100 (CET)") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00117.txt.bz2 On Mar 7, 2006, Mark Kettenis wrote: >> From: Alexandre Oliva >> Date: Tue, 07 Mar 2006 02:31:27 -0300 >> >> On Mar 4, 2006, Daniel Jacobowitz wrote: >> >> > On Sat, Mar 04, 2006 at 09:01:43AM -0300, Alexandre Oliva wrote: >> >> > It's also good to have a few testcases, >> >> > but I don't completely understand the testcases :( >> >> >> >> You're not alone in that feeling, I assure you :-) >> >> > Like Mark, I am happier with the code than the testcases. In fact, >> > I'd rather not have the tests at all than have something quite >> > so overkill. >> Fair enough... Those tests uncovered a problem with the way our >> dwarf2 code identifies frames, though: it uses the function start >> address and the CFA to identify a stack frame, whereas it should use >> the PC and the CFA. > Nope, using the function address is the correct thing to do. > Otherwise you'll end up with a different frame ID if you single-step > to the next instruction for example. So I see :-( Sorry for posting the patch before testing was even started. >> In some corner cases, such as the one exercised by the i386 >> testcase, if you're on the second instruction of the region covered >> by the hand-generated unwind info and ask for a backtrace, GDB >> complains that the stack is corrupt, but the only problem is that >> the dwarf2 machinery gets confused by the same-CFA, same-function >> pair of stack frames. This is fixed in the revised patch below. > That fix is wrong! Either your hand-generated unwind info is wrong > (or incomplete) or GDB needs to do something more clever (like perhaps > using the address of the first instruction in the region covered by > the unwind info). 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: 0x080486bc in _L_mutex_lock_31 () 1: x/i $pc 0x80486bc <_L_mutex_lock_31>: lea 0x8(%ebp),%ecx (gdb) where #0 0x080486bc in _L_mutex_lock_31 () #1 0x080486c4 in _L_mutex_lock_31 () Previous frame identical to this frame (corrupt stack?) (gdb) disass foo Dump of assembler code for function foo: 0x08048540 : push %ebp 0x08048541 : mov %esp,%ebp 0x08048543 : sub $0x108,%esp 0x08048549 : mov %ebx,0xfffffff8(%ebp) 0x0804854c : lea 0xfffffef8(%ebp),%ebx 0x08048552 : mov %esi,0xfffffffc(%ebp) 0x08048555 : mov 0x8(%ebp),%esi 0x08048558 : test %esi,%esi 0x0804855a : jne 0x80486bc <_L_mutex_lock_31> 0x08048560 : mov 0xfffffff8(%ebp),%ebx 0x08048563 : mov 0xfffffffc(%ebp),%esi 0x08048566 : mov %ebp,%esp 0x08048568 : pop %ebp 0x08048569 : ret End of assembler dump. (gdb) disass Dump of assembler code for function _L_mutex_lock_31: 0x080486bc <_L_mutex_lock_31+0>: lea 0x8(%ebp),%ecx 0x080486bf <_L_mutex_lock_31+3>: call 0x8048690 0x080486c4 <_L_mutex_lock_31+8>: jmp 0x8048560 0x080486c9 <_L_mutex_lock_31+13>: nop 0x080486ca <_L_mutex_lock_31+14>: nop 0x080486cb <_L_mutex_lock_31+15>: nop End of assembler dump. > In any case, the frame ID should only change when > we really enter a different frame. My understanding is that the intention *is* to represent debug info as an entry into a new frame, but I don't quite understand why it would be correct to have two entries for the same function, as in the stack trace below (generated by the incorrectly-patched GDB). (gdb) si 0x080486bc in _L_mutex_lock_31 () 1: x/i $pc 0x80486bc <_L_mutex_lock_31>: lea 0x8(%ebp),%ecx (gdb) where #0 0x080486bc in _L_mutex_lock_31 () #1 0x080486c4 in _L_mutex_lock_31 () #2 0x08048560 in foo (x=3) at ../../../gdb/testsuite/gdb.dwarf2/cfa-val-expr-1.c:91 #3 0x08048582 in fn2 () at ../../../gdb/testsuite/gdb.dwarf2/cfa-val-expr-1.c:237 #4 0x08048598 in fn1 () at ../../../gdb/testsuite/gdb.dwarf2/cfa-val-expr-1.c:244 #5 0x080485fb in main () at ../../../gdb/testsuite/gdb.dwarf2/cfa-val-expr-1.c:252 Roland, do you happen to know what the point is of the two stack frames for _L_mutex_lock_31? Could we perhaps do away with them, so as to avoid the problem entirely, given that GDB is apparently doing the right thing? As an aside, I don't quite see that GDB's approach to identifying stack frames by using the stack pointer and the function entry point is entirely correct for architectures in which recursive functions don't necessarily change the stack pointer: consider an architecture with register windows that use a separate stack, like IA64, with the further assumption that one wouldn't need to save the return address on the regular stack because the register window machinery would take care of saving it. > Perhaps you can explain in more detail what the problem is? Is the above enough? >> > And you're not correct that older GCCs could run them >> > far enough to test; they'll fail to build because of the use of >> > __attribute__((cleanup)) >> >> Oops, indeed, sorry about that. The testcases must definitely be >> amended if they're to remain. Should they? > I think the tests need to be simplified. Tricky. The very point of the tests is to test the complex CFA expressions. I could easily remove all of the cleanup and run-time unwinding stuff (is this what you meant?), but taking out the hairy bits would render the test pointless. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}