From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4236 invoked by alias); 4 Mar 2005 16:10:07 -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 3809 invoked from network); 4 Mar 2005 16:09:24 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 4 Mar 2005 16:09:24 -0000 Received: from drow by nevyn.them.org with local (Exim 4.44 #1 (Debian)) id 1D7FMm-0000ih-3a; Fri, 04 Mar 2005 11:09:28 -0500 Date: Fri, 04 Mar 2005 16:10:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Cc: Mark Kettenis Subject: Re: RFC: Add a mechanism to stop backtraces using dwarf2 frame information Message-ID: <20050304160928.GA2654@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com, Mark Kettenis References: <20050302221552.GA1252@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050302221552.GA1252@nevyn.them.org> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00047.txt.bz2 On Wed, Mar 02, 2005 at 05:15:53PM -0500, Daniel Jacobowitz wrote: > 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. For Your Entertainment, here's two examples of how to use this feature. One uses the gas .cfi directives; it is simpler to write but has a couple of drawbacks: - It goes in .eh_frame, which is loadable and thus takes up RAM unless explicitly discarded. - It requires you to know the number of the return address column for your architecture. The other uses .debug_frame, which only has one alternative - it's a bit bulkier in the source code. Though that can be worked around with macros. An unpatched GDB will backtrace normally from foo to main, and get stuck in a loop backtracing from baz. A patched GDB will stop cleanly after either foo or baz. .globl main .type main, %function main: call foo call baz ret .globl foo .type foo, %function foo: .cfi_startproc .cfi_escape 0x7, 0x8 ret .cfi_endproc baz: ret .Lend_baz: .section .debug_frame,"",@progbits .Lframe0: .long .LECIE0-.LSCIE0 # Length of Common Information Entry .LSCIE0: .long 0xffffffff # CIE Identifier Tag .byte 0x1 # CIE Version .ascii "\0" # CIE Augmentation .uleb128 0x1 # CIE Code Alignment Factor .sleb128 -4 # CIE Data Alignment Factor .byte 0x0 # CIE RA Column .byte 0xc # DW_CFA_def_cfa .uleb128 0x0 .uleb128 0x0 .byte 0x7 # DW_CFA_undefined .byte 0x0 # ... column 0 .align 4 .LECIE0: .LSFDE0: .long .LEFDE0-.LASFDE0 # FDE Length .LASFDE0: .long .Lframe0 # FDE CIE offset .long baz # FDE initial location .long .Lend_baz-baz # FDE address range .align 4 .LEFDE0: -- Daniel Jacobowitz CodeSourcery, LLC