Re: Wishlist: declarations suitable for post mortem debugging

[Carlos O'Donell <carlos_odonell at mentor dot com>]

On 4/26/2012 5:49 AM, David Kastrup wrote:
> We have attributes like
> 
> /* This prints an "Assertion failed" message and aborts.  */
> extern void __assert_fail (__const char *__assertion, __const char *__file,
>                            unsigned int __line, __const char *__function)
>      __THROW __attribute__ ((__noreturn__));
> 
> in assert.h and
> 
> extern void abort (void) __THROW __attribute__ ((__noreturn__));
> 
> in stdlib.h.  These functions, in contrast to exit, have a side effect
> of dumping core as a regular effect of their execution.  The purpose is
> to enable post-mortem debugging.
> 
> The attribute __noreturn__ directly conflicts with that purpose since it
> tells the compiler it may trash the stack when calling the function, not
> requiring any useful information to be retained on the stack.  In
> particular, those functions may be _jumped_ to instead of called, or an
> existing call to these functions in an unrelated part of source may get
> recycled by jumping to it.
> 
> As a result, backtraces from the core dump are quite unreliable.  I
> have, on several occasions, spent days of futile debugging on backtraces
> that did not correspond with reality.

Thank you for your writeup and for posting to libc-help.

I agree completely with your rationale, but there are several wrinkles
that prevent the simple solution from working.

We need a new compiler attribute for this and nobody has stepped up to
do the compiler work.

Please see the full discussion here 4 years ago:
http://gcc.gnu.org/ml/gcc/2008-08/msg00060.html

CodeSourcery fixed this for ARM by ensuring that lr was saved when
calling noreturn functions and this is sufficient to unwind the stack.

Please see the ARM fix here:
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01234.html

This might not be a useful solution for other machines and therefore
we need a new compiler attribute to apply to these functions.

Does that seem like a more reasonable answer than before?

Cheers,
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026