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

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

[Daniel Jacobowitz]

I'd like opinions on this patch.

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.

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.

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.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

2005-03-02  Daniel Jacobowitz  <dan@codesourcery.com>

	* dwarf2-frame.c (struct dwarf2_frame_cache): New field
	undefined_retaddr.
	(dwarf2_frame_cache): Initialize undefined_retaddr.
	(dwarf2_frame_this_id): Return an invalid frame ID if
	undefined_retaddr.

Index: dwarf2-frame.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/dwarf2-frame.c,v
retrieving revision 1.48
diff -u -p -r1.48 dwarf2-frame.c
--- dwarf2-frame.c	11 Feb 2005 18:13:49 -0000	1.48
+++ dwarf2-frame.c	2 Mar 2005 22:04:58 -0000
@@ -1,6 +1,6 @@
 /* Frame unwinder for frames with DWARF Call Frame Information.
 
-   Copyright 2003, 2004 Free Software Foundation, Inc.
+   Copyright 2003, 2004, 2005 Free Software Foundation, Inc.
 
    Contributed by Mark Kettenis.
 
@@ -585,6 +585,9 @@ struct dwarf2_frame_cache
   /* DWARF Call Frame Address.  */
   CORE_ADDR cfa;
 
+  /* Set if the return address column was marked as undefined.  */
+  int undefined_retaddr;
+
   /* Saved registers, indexed by GDB register number, not by DWARF
      register number.  */
   struct dwarf2_frame_state_reg *reg;
@@ -748,6 +751,10 @@ incomplete CFI data; unspecified registe
       }
   }
 
+  if (fs->retaddr_column < fs->regs.num_regs
+      && fs->regs.reg[fs->retaddr_column].how == DWARF2_FRAME_REG_UNDEFINED)
+    cache->undefined_retaddr = 1;
+
   do_cleanups (old_chain);
 
   *this_cache = cache;
@@ -761,6 +768,9 @@ dwarf2_frame_this_id (struct frame_info 
   struct dwarf2_frame_cache *cache =
     dwarf2_frame_cache (next_frame, this_cache);
 
+  if (cache->undefined_retaddr)
+    return;
+
   (*this_id) = frame_id_build (cache->cfa, frame_func_unwind (next_frame));
 }
 

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

[Daniel Jacobowitz]

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

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

[Mark Kettenis]

   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

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

[Daniel Jacobowitz]

On Fri, Mar 04, 2005 at 10:11:23PM +0100, Mark Kettenis wrote:
>    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?

Yes, absolutely.

>    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?

I did that.  Andrew replied that he had suggested it previously; Todd
Allen replied that it seemed like a good idea.  Andrew also suggested
an undefined CFA as a barrier, but the implementation of that will look
a bit different; so, Andrew, if you would like an undefined CFA to have
the same effect, feel free to implement it :-)

I've checked in the patch now.

-- 
Daniel Jacobowitz
CodeSourcery, LLC