From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13104 invoked by alias); 4 Mar 2005 21:11:58 -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 12688 invoked from network); 4 Mar 2005 21:11:44 -0000 Received: from unknown (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 4 Mar 2005 21:11:44 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id j24LBTA4021094; Fri, 4 Mar 2005 22:11:30 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id j24LBTqp003252; Fri, 4 Mar 2005 22:11:29 +0100 (CET) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id j24LBNYD003249; Fri, 4 Mar 2005 22:11:23 +0100 (CET) Date: Fri, 04 Mar 2005 21:11:00 -0000 Message-Id: <200503042111.j24LBNYD003249@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb-patches@sources.redhat.com In-reply-to: <20050302221552.GA1252@nevyn.them.org> (message from Daniel Jacobowitz on Wed, 2 Mar 2005 17:15:53 -0500) Subject: Re: RFC: Add a mechanism to stop backtraces using dwarf2 frame information References: <20050302221552.GA1252@nevyn.them.org> X-SW-Source: 2005-03/txt/msg00054.txt.bz2 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? 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? Mark