Internal abort call optimization?

Internal abort call optimization?

[David Kastrup]

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

This is egregiously bad when using the generated coredump (abort
triggers SIGABRT) for debugging failed assertions or other aborts:
neither the call/return location is correctly associated with the source
code, nor is the stack/register state interpretable using debugging
info.

Given that the distinguishing feature of abort over exit is the creation
of a core dump, it would be good if this core dump would actually be
useful.  I know several people who have spent days debugging at the
wrong place, including myself.  Currently Emacs contains in etc/DEBUG
the instructions

    ** When you are trying to analyze failed assertions, it will be
    essential to compile Emacs either completely without optimizations or
    at least (when using GCC) with the -fno-crossjumping option.  Failure
    to do so may make the compiler recycle the same abort call for all
    assertions in a given function, rendering the stack backtrace useless
    for identifying the specific failed assertion.

However, the problem is obviously not restricted to Emacs.  If the
"noreturn" attribute for the internal abort were removed, at least only
abort calls with compatible stack frame and the same (tentative)
followup code would get folded.  That would avoid the worst
head-scratchers when trying to figure out what went wrong.

Probably better would be to just disable the crossjumping optimization
for calls of abort.  Maybe this would warrant a new attribute.

Thanks for caring,

-- 
David Kastrup

Re: Internal abort call optimization?

[Andi Kleen]

David Kastrup <dak@gnu.org> writes:
>
> However, the problem is obviously not restricted to Emacs.  If the
> "noreturn" attribute for the internal abort were removed, at least only
> abort calls with compatible stack frame and the same (tentative)
> followup code would get folded.  That would avoid the worst
> head-scratchers when trying to figure out what went wrong.

Without noreturn gcc wouldn't know there is no return needed after
the abort().  Disabling cross jumping would be probably better.
I know of a couple of more cases where such an attribute would 
be useful.

-Andi

Re: Internal abort call optimization?

[Richard Guenther]

On Tue, Jun 17, 2008 at 11:33 AM, Andi Kleen <andi@firstfloor.org> wrote:
> David Kastrup <dak@gnu.org> writes:
>>
>> However, the problem is obviously not restricted to Emacs.  If the
>> "noreturn" attribute for the internal abort were removed, at least only
>> abort calls with compatible stack frame and the same (tentative)
>> followup code would get folded.  That would avoid the worst
>> head-scratchers when trying to figure out what went wrong.
>
> Without noreturn gcc wouldn't know there is no return needed after
> the abort().  Disabling cross jumping would be probably better.
> I know of a couple of more cases where such an attribute would
> be useful.

You can also build with -fno-builtin-abort.

Richard.

Re: Internal abort call optimization?

[Andi Kleen]

Richard Guenther wrote:
> On Tue, Jun 17, 2008 at 11:33 AM, Andi Kleen <andi@firstfloor.org> wrote:
>> David Kastrup <dak@gnu.org> writes:
>>> However, the problem is obviously not restricted to Emacs.  If the
>>> "noreturn" attribute for the internal abort were removed, at least only
>>> abort calls with compatible stack frame and the same (tentative)
>>> followup code would get folded.  That would avoid the worst
>>> head-scratchers when trying to figure out what went wrong.
>> Without noreturn gcc wouldn't know there is no return needed after
>> the abort().  Disabling cross jumping would be probably better.
>> I know of a couple of more cases where such an attribute would
>> be useful.
> 
> You can also build with -fno-builtin-abort.

But it would still cross jump the call then wouldn't it?

-Andi

Re: Internal abort call optimization?

[Richard Guenther]

On Tue, Jun 17, 2008 at 12:04 PM, Andi Kleen <andi@firstfloor.org> wrote:
> Richard Guenther wrote:
>> On Tue, Jun 17, 2008 at 11:33 AM, Andi Kleen <andi@firstfloor.org> wrote:
>>> David Kastrup <dak@gnu.org> writes:
>>>> However, the problem is obviously not restricted to Emacs.  If the
>>>> "noreturn" attribute for the internal abort were removed, at least only
>>>> abort calls with compatible stack frame and the same (tentative)
>>>> followup code would get folded.  That would avoid the worst
>>>> head-scratchers when trying to figure out what went wrong.
>>> Without noreturn gcc wouldn't know there is no return needed after
>>> the abort().  Disabling cross jumping would be probably better.
>>> I know of a couple of more cases where such an attribute would
>>> be useful.
>>
>> You can also build with -fno-builtin-abort.
>
> But it would still cross jump the call then wouldn't it?

In principle yes, but the situations cross jumping applies would be less, as the
compiler no longer knows abort will not return (it'll also get you some extra
warnings because of this).

Richard.

Re: Internal abort call optimization?

[Andrew Pinski]

On Tue, Jun 17, 2008 at 12:04 PM, Andi Kleen <andi@firstfloor.org> wrote:
> But it would still cross jump the call then wouldn't it?

Depends if they return to the same basic block next ...

-- Pinski

Re: Internal abort call optimization?

[Steven Bosscher]

On Tue, Jun 17, 2008 at 3:58 PM, David Kastrup <dak@gnu.org> wrote:
> Probably better would be to just disable the crossjumping optimization
> for calls of abort.  Maybe this would warrant a new attribute.

Read the long thread starting at
http://gcc.gnu.org/ml/gcc/2005-03/msg00568.html and let it rest ;-)

Gr.
Steven

Re: Internal abort call optimization?

[Daniel Berlin]

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

Re: Internal abort call optimization?

[David Kastrup]

"Daniel Berlin" <dberlin@dberlin.org> writes:

> You are about 3 years late to the party on this one :)
>
> http://gcc.gnu.org/ml/gcc/2005-03/msg00568.html

Yup.

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

Oh, we are not talking about "not good stacktraces" here.  We are
talking about "completely different location, possibly even in a
different function, and debug info that has nothing to do with the
actual state of the stack frame".

"Not good" is expected with optimization.  "Catastrophically misleading"
is a different category.  Since one of the main points of "abort" _is_
the stack trace, that's a particularly bad function call to optimize in
this manner.  Omitting either the -fcrossjumping _or_ the noreturn
optimizations would get this back into the "expected consequence of
optimization on debugging" scale.  It is the combination of them that
makes it impossible for the debugger to figure out the current call
situation and temporary variable/register/stackframe assignments.

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

But fancy_abort does not help in examining variables: they may be
sitting on the stack or in registers.  Without noreturn optimizations,
at least the compiler would only crossjump to abort calls with equal
continuation and equal data locations, so examining variables is still
possible in the debugger and one can get a good guess at where one is
currently.  And without crossjumping, the debugging info might tell the
debugger just how garbled the current data locations are.  But with both
active, stack data and return addresses are garbage.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum