From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29578 invoked by alias); 8 Apr 2005 12:10:39 -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 29445 invoked from network); 8 Apr 2005 12:10:26 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 8 Apr 2005 12:10:26 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DJsJd-0005mO-IB; Fri, 08 Apr 2005 08:10:25 -0400 Date: Fri, 08 Apr 2005 12:10:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: Add a mechanism to stop backtraces using dwarf2 frame information Message-ID: <20050408121024.GA32446@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sources.redhat.com References: <20050302221552.GA1252@nevyn.them.org> <200503042111.j24LBNYD003249@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503042111.j24LBNYD003249@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-04/txt/msg00068.txt.bz2 On Fri, Mar 04, 2005 at 10:11:23PM +0100, Mark Kettenis wrote: > Date: Wed, 2 Mar 2005 17:15:53 -0500 > From: Daniel Jacobowitz > > I'd like opinions on this patch. > > I like it ;-). > > There are some times when it's just not possible to backtrace through > hand-written assembly. This can be true of anything which will never > return, and is often true of functions which are called or return in > a "unique" manner - the specific case that prompted me to write this was a > processor exception handler. In this instance there is a theoretical return > path, but it will almost always lead out of the binary into some other > running code, so backtracing through it isn't useful. Trying to apply > normal unwinding just produces garbage. > > Wouldn't it be useful for process startup code of UNIX processes > (crt0/crt1) and thread startup code too? Yes, absolutely. > I picked an idiom which GDB currently doesn't handle to mean "no backtrace > information is available": DW_CFA_undefined in the return address column. > Seems a plausible interpretation to me. This idiom implies that not only > is no DWARF unwinding data available, but also that more conventional means > of unwinding are unlikely to succeed. Obviously, if GDB has an earlier > sniffer which recognizes the particular location, we can continue > backtracing. This just stops us from falling back to the prologue > analyzers. > > So people should take a bit more care in stacking the sniffers; > nothing new there. > > What do you think of the idea? The patch? If both seem OK, I'll propose > the idiom to the DWARF working group. It doesn't require any changes to the > standard, but it might be nice to document it explicitly. > > Could you drop a note to the dwarf working group mailing list to get a > bit more opinions about this "abuse" of the standard before checking > this patch in? I did that. Andrew replied that he had suggested it previously; Todd Allen replied that it seemed like a good idea. Andrew also suggested an undefined CFA as a barrier, but the implementation of that will look a bit different; so, Andrew, if you would like an undefined CFA to have the same effect, feel free to implement it :-) I've checked in the patch now. -- Daniel Jacobowitz CodeSourcery, LLC