From: Daniel Jacobowitz <drow@false.org>
To: gdb-patches@sources.redhat.com
Cc: Mark Kettenis <kettenis@gnu.org>
Subject: Re: RFC: Add a mechanism to stop backtraces using dwarf2 frame information
Date: Fri, 04 Mar 2005 16:10:00 -0000 [thread overview]
Message-ID: <20050304160928.GA2654@nevyn.them.org> (raw)
In-Reply-To: <20050302221552.GA1252@nevyn.them.org>
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
next prev parent reply other threads:[~2005-03-04 16:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-02 22:16 Daniel Jacobowitz
2005-03-04 16:10 ` Daniel Jacobowitz [this message]
2005-03-04 21:11 ` Mark Kettenis
2005-04-08 12:10 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050304160928.GA2654@nevyn.them.org \
--to=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
--cc=kettenis@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox