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

[Mark Kettenis <mark.kettenis@xs4all.nl>]

   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