Re: RFC: Add a mechanism to stop backtraces using dwarf2 frame information

Mark Kettenis
2005-03-04T21:11:58Z

Date: Wed, 2 Mar 2005 17:15:53 -0500
From: Daniel Jacobowitz <drow@false.org>

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