From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26698 invoked by alias); 7 Mar 2006 08:38:53 -0000 Received: (qmail 26685 invoked by uid 22791); 7 Mar 2006 08:38:50 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 07 Mar 2006 08:38:47 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k278cTDu018888; Tue, 7 Mar 2006 09:38:29 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id k278cSUt027838; Tue, 7 Mar 2006 09:38:28 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id k278cSMx005401; Tue, 7 Mar 2006 09:38:28 +0100 (CET) Date: Tue, 07 Mar 2006 15:01:00 -0000 Message-Id: <200603070838.k278cSMx005401@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: aoliva@redhat.com CC: gdb-patches@sources.redhat.com In-reply-to: (message from Alexandre Oliva on Tue, 07 Mar 2006 02:31:27 -0300) Subject: Re: Support Dwarf3 DW_CFA_val_* expressions References: <200603041017.k24AHjh7024812@elgar.sibelius.xs4all.nl> <20060304145755.GB20187@nevyn.them.org> 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/msg00110.txt.bz2 > 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. > 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). In any case, the frame ID should only change when we really enter a different frame. Perhaps you can explain in more detail what the problem is? > > 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. Mark