From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2514 invoked by alias); 11 Mar 2006 19:08:16 -0000 Received: (qmail 2505 invoked by uid 22791); 11 Mar 2006 19:08:15 -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; Sat, 11 Mar 2006 19:08:14 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FI9Rj-00074E-QT; Sat, 11 Mar 2006 14:08:11 -0500 Date: Mon, 13 Mar 2006 02:25: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: <20060311190811.GA26990@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> 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/msg00172.txt.bz2 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? The NPTL I'm looking at doesn't have any for that function, either an older build I had around or a current CVS checkout. I'm very suspicious of your description of it. > > 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). If the intention is to represent an entry into a new frame, then the debugger should be displaying two frames. > 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. Testing hand-written dwarf2/dwarf3 is entirely fine, even if we have to arch-restrict the tests. -- Daniel Jacobowitz CodeSourcery