This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Internal abort call optimization?
- From: "Daniel Berlin" <dberlin at dberlin dot org>
- To: "David Kastrup" <dak at gnu dot org>
- Cc: gcc at gnu dot org
- Date: Tue, 17 Jun 2008 12:56:26 -0400
- Subject: Re: Internal abort call optimization?
- References: <86abhki2n0.fsf@lola.quinscape.zz>
On Tue, Jun 17, 2008 at 9:58 AM, David Kastrup <dak@gnu.org> wrote:
>
> Hi, I reported a problem I have with abort to the glibc bug tracker at
> <URL:http://sourceware.org/bugzilla/show_bug.cgi?id=6522> which might
> provide some reading material.
>
> Anyway, it has been pointed out to me that the requested change would
> not accomplish much anyway since GCC has its own builtin notion of the
> abort function.
>
> So here is my beef with the current way abort calls get optimized:
> basically it boils down to the interaction of -fcrossjumping (enabled
> with -O2) and the noreturn attribute of abort. The combination of both
> optimizations means that usually only one abort call will actually get
> compiled into a compilation unit, and all calls will instead jump there
> without bothering to clean the stack (after all, it is a noreturn
> function).
You are about 3 years late to the party on this one :)
http://gcc.gnu.org/ml/gcc/2005-03/msg00568.html
Realistically, you are not going to be able to get good stacktraces
with optimized code for *other* reasons, abort is just the first thing
you hit.
You are much better off making an abort that gives you more correct
info (see, for example gcc's fancy_abort) than trying to take the info
you get at some random point in an optimized program, and then trying
to build it into something useful for the user (as abort does).