This is the mail archive of the
mailing list for the glibc project.
Re: Wishlist: declarations suitable for post mortem debugging
- From: Carlos O'Donell <carlos_odonell at mentor dot com>
- To: David Kastrup <dak at gnu dot org>
- Cc: <libc-help at sourceware dot org>
- Date: Thu, 26 Apr 2012 10:04:52 -0400
- Subject: Re: Wishlist: declarations suitable for post mortem debugging
- References: <firstname.lastname@example.org>
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?
Mentor Graphics / CodeSourcery
+1 (613) 963 1026