This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Internal abort call optimization?


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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]