Wishlist: declarations suitable for post mortem debugging
Carlos O'Donell
carlos_odonell@mentor.com
Thu Apr 26 14:05:00 GMT 2012
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
More information about the Libc-help
mailing list