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:

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:

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?

Carlos O'Donell
Mentor Graphics / CodeSourcery
+1 (613) 963 1026

More information about the Libc-help mailing list