* [Bug libc/6522] abort should not be marked noreturn
2008-05-15 9:13 [Bug libc/6522] New: abort should not be marked noreturn dak at gnu dot org
@ 2008-05-28 12:56 ` dak at gnu dot org
2008-06-12 15:21 ` madcoder at debian dot org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: dak at gnu dot org @ 2008-05-28 12:56 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From dak at gnu dot org 2008-05-28 12:56 -------
To add some more substance: I know of at least 5 different Emacs developers who
have independently wasted in the order of days making sense of failed assertions
because of the useless state of the stack frame for post mortem debugging.
The file DEBUG in the Emacs distribution contains the advice to compile with
-fno-crossjumping which helps somewhat (but most people only read this after
having wasted a lot of time).
So this problem is not academical. It would be nice to at least get some sort
of minimal feedback.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6522
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libc/6522] abort should not be marked noreturn
2008-05-15 9:13 [Bug libc/6522] New: abort should not be marked noreturn dak at gnu dot org
2008-05-28 12:56 ` [Bug libc/6522] " dak at gnu dot org
@ 2008-06-12 15:21 ` madcoder at debian dot org
2008-06-13 6:20 ` drepper at redhat dot com
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: madcoder at debian dot org @ 2008-06-12 15:21 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From madcoder at debian dot org 2008-06-12 15:20 -------
This is wrong and will break any function that has a non void return type and
that specify that code is unreachable using abort(), without "returning"
anything after abort().
This is perfectly valid code, there is quite a lot of it out there, and such a
change would gratuitously break it.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6522
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libc/6522] abort should not be marked noreturn
2008-05-15 9:13 [Bug libc/6522] New: abort should not be marked noreturn dak at gnu dot org
2008-05-28 12:56 ` [Bug libc/6522] " dak at gnu dot org
2008-06-12 15:21 ` madcoder at debian dot org
@ 2008-06-13 6:20 ` drepper at redhat dot com
2008-06-13 8:45 ` dak at gnu dot org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: drepper at redhat dot com @ 2008-06-13 6:20 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From drepper at redhat dot com 2008-06-13 06:20 -------
Changing glibc to make debugging easier at the cost of speed or cost size won't
happen. *Especially* since there are work arounds. Just add the gcc flag.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
http://sourceware.org/bugzilla/show_bug.cgi?id=6522
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libc/6522] abort should not be marked noreturn
2008-05-15 9:13 [Bug libc/6522] New: abort should not be marked noreturn dak at gnu dot org
` (2 preceding siblings ...)
2008-06-13 6:20 ` drepper at redhat dot com
@ 2008-06-13 8:45 ` dak at gnu dot org
2008-06-13 14:28 ` drepper at redhat dot com
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: dak at gnu dot org @ 2008-06-13 8:45 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From dak at gnu dot org 2008-06-13 08:45 -------
(In reply to comment #2)
> This is wrong and will break any function that has a non void return type and
> that specify that code is unreachable using abort(), without "returning"
> anything after abort().
How will it "break" anything? Unreachable code is not forbidden by any C
standard as far as I know.
> This is perfectly valid code, there is quite a lot of it out there, and such a
> change would gratuitously break it.
Perfectly valid according to which C standard? Can you give an example for code
which would rely on the noreturn optimization and would fail without it?
(In reply to comment #3)
> Changing glibc to make debugging easier at the cost of speed or cost size won't
> happen. *Especially* since there are work arounds. Just add the gcc flag.
Let me put this more bluntly: the current behavior breaks abort's principal
functionality.
abort raises SIGABRT. The default action for SIGABRT is
Signal Value Action Comment
----------------------------------------------------------------------
SIGABRT 6 Core Abort signal from abort(3)
So the default action is a core dump, and the core dump is junk when gcc
performs noreturn optimizations. If people don't want a core dump, they will
use exit(255) instead of abort.
We are not talking about "making debugging easier". We are talking about abort
being able to function as intended at all.
If you don't consider it appropriate to remove the noreturn attribute (which is
an expedience), you might consider implementing an attribute "uniquecall" or
"debug" or so which will basically enable "-fno-crossjumping" just for calls of
abort. In that manner, the core dump at least points to a unique call point for
abort, and it becomes theoretically possible for the compiler/debugger combo to
untangle any noreturn optimizations that have been done at that particular call
point.
If the abort call can be jumped to from several different locations (possibly
even different functions), untangling the stack frame becomes no longer possible
and the core dump, the principal output of abort, is useless.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|WONTFIX |
http://sourceware.org/bugzilla/show_bug.cgi?id=6522
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libc/6522] abort should not be marked noreturn
2008-05-15 9:13 [Bug libc/6522] New: abort should not be marked noreturn dak at gnu dot org
` (3 preceding siblings ...)
2008-06-13 8:45 ` dak at gnu dot org
@ 2008-06-13 14:28 ` drepper at redhat dot com
2008-06-16 19:39 ` bmark at us dot ibm dot com
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: drepper at redhat dot com @ 2008-06-13 14:28 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From drepper at redhat dot com 2008-06-13 14:27 -------
Stop reopening. You have your remedy, you're just too lazy to do any work
yourself and so would rather see everyone suffer. And
> Let me put this more bluntly: the current behaviour breaks abort's principal
> functionality.
is of course total nonsense. The main functionality is to abort the process and
that is done.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |WONTFIX
http://sourceware.org/bugzilla/show_bug.cgi?id=6522
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libc/6522] abort should not be marked noreturn
2008-05-15 9:13 [Bug libc/6522] New: abort should not be marked noreturn dak at gnu dot org
` (4 preceding siblings ...)
2008-06-13 14:28 ` drepper at redhat dot com
@ 2008-06-16 19:39 ` bmark at us dot ibm dot com
2008-06-17 9:20 ` dak at gnu dot org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: bmark at us dot ibm dot com @ 2008-06-16 19:39 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From bmark at us dot ibm dot com 2008-06-16 19:38 -------
The ISO C std 9899:1999, Sec 7.20.4.1 makes it clear:
The specification of abort() is
void abort(void);
and under "Returns" is the single sentence:
The abort function does not return to its caller.
IEEE POSIX 1003.1-2001 reiterates the above. I hope this answers the questions
concerning the specification, and why we intend to remain in conformance.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6522
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libc/6522] abort should not be marked noreturn
2008-05-15 9:13 [Bug libc/6522] New: abort should not be marked noreturn dak at gnu dot org
` (5 preceding siblings ...)
2008-06-16 19:39 ` bmark at us dot ibm dot com
@ 2008-06-17 9:20 ` dak at gnu dot org
2008-06-17 11:41 ` schwab at suse dot de
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: dak at gnu dot org @ 2008-06-17 9:20 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From dak at gnu dot org 2008-06-17 09:19 -------
(In reply to comment #6)
> The ISO C std 9899:1999, Sec 7.20.4.1 makes it clear:
> The specification of abort() is
> void abort(void);
> and under "Returns" is the single sentence:
> The abort function does not return to its caller.
>
> IEEE POSIX 1003.1-2001 reiterates the above. I hope this answers the questions
> concerning the specification, and why we intend to remain in conformance.
Huh? Nobody suggested letting abort return to its caller. My proposal has
nothing whatsoever to do with complying or not complying to the above spec. The
SPEC does _not_ state "The optimizer should ensure that abort is entered with a
stack state not containing useful information for the ensuing core dump".
Yes, certainly abort should not return. But making use of this information in
the current manner means that abort is called without an identifiable call
context and associated identifiable register/stackframe/value state. And for a
function with the distinguishing feature of creating a core dump, that's a
rather hefty drawback. The resulting core dump is quite often useless, and not
useless in the usual "things may get executed and assigned in strange orders"
sense, but rather in the "utter garbage masquerading as something sensible and
wasting you hours of head-scratching" sense.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6522
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libc/6522] abort should not be marked noreturn
2008-05-15 9:13 [Bug libc/6522] New: abort should not be marked noreturn dak at gnu dot org
` (6 preceding siblings ...)
2008-06-17 9:20 ` dak at gnu dot org
@ 2008-06-17 11:41 ` schwab at suse dot de
2008-06-17 11:55 ` dak at gnu dot org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: schwab at suse dot de @ 2008-06-17 11:41 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From schwab at suse dot de 2008-06-17 11:41 -------
Removing noreturn from abort will not eliminate the problem, the compiler will
still combine two calls if they appear in similar enough contexts. In the
following example the compiler will still generate only a single call to abort,
no matter how it is declared.
#include <stdlib.h>
int bar (int);
#ifdef USE_ABORT1
void abort1 (void);
#define abort abort1
#endif
int
foo (int a)
{
int b;
if (a == 1)
{
b = bar (a);
if (!b) abort ();
}
else if (a == 2)
{
b = bar (a + 1);
if (!b) abort ();
}
else
b = a;
return b;
}
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6522
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libc/6522] abort should not be marked noreturn
2008-05-15 9:13 [Bug libc/6522] New: abort should not be marked noreturn dak at gnu dot org
` (7 preceding siblings ...)
2008-06-17 11:41 ` schwab at suse dot de
@ 2008-06-17 11:55 ` dak at gnu dot org
2008-06-17 13:38 ` joseph at codesourcery dot com
2008-06-17 13:44 ` dak at gnu dot org
10 siblings, 0 replies; 12+ messages in thread
From: dak at gnu dot org @ 2008-06-17 11:55 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From dak at gnu dot org 2008-06-17 11:54 -------
(In reply to comment #8)
> Removing noreturn from abort will not eliminate the problem, the compiler will
> still combine two calls if they appear in similar enough contexts.
Quite correct. However, this will occur at a junction of the code paths with
compatible and recognizable stack frame. So the inconvenience is more or less
"par for optimization". You will still be able to examine variable values (even
if they move through registers) and figure out what function you are in.
The optimal solution would, as I stated at the bottom of comment #4, introduce
some attribute that could effectively enable -fno-crossjumping for abort calls
only. In that manner, the "noreturn" optimizations would have a chance to be
tracked by debugging information since the return address would uniquely
identify the context of the stack frame.
This would require work in the compiler and might be the most elegant solution
in the long run. Leaving off "noreturn" in the meantime would provide an
expedience that gets rid of the most productivity-wasting artifacts.
If nothing is done at all, at least the GCC documentation would warrant a strong
warning about the particular effects of the (standard for -O) -fcrossjumping
option on post mortem debugging.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6522
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libc/6522] abort should not be marked noreturn
2008-05-15 9:13 [Bug libc/6522] New: abort should not be marked noreturn dak at gnu dot org
` (8 preceding siblings ...)
2008-06-17 11:55 ` dak at gnu dot org
@ 2008-06-17 13:38 ` joseph at codesourcery dot com
2008-06-17 13:44 ` dak at gnu dot org
10 siblings, 0 replies; 12+ messages in thread
From: joseph at codesourcery dot com @ 2008-06-17 13:38 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From joseph at codesourcery dot com 2008-06-17 13:37 -------
Subject: Re: abort should not be marked noreturn
On Tue, 17 Jun 2008, dak at gnu dot org wrote:
> The optimal solution would, as I stated at the bottom of comment #4, introduce
> some attribute that could effectively enable -fno-crossjumping for abort calls
> only. In that manner, the "noreturn" optimizations would have a chance to be
> tracked by debugging information since the return address would uniquely
> identify the context of the stack frame.
>
> This would require work in the compiler and might be the most elegant solution
> in the long run. Leaving off "noreturn" in the meantime would provide an
> expedience that gets rid of the most productivity-wasting artifacts.
The compiler provides a noreturn attribute for abort automatically.
Whether the header provides it doesn't matter unless you use
-fno-builtin-abort.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6522
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libc/6522] abort should not be marked noreturn
2008-05-15 9:13 [Bug libc/6522] New: abort should not be marked noreturn dak at gnu dot org
` (9 preceding siblings ...)
2008-06-17 13:38 ` joseph at codesourcery dot com
@ 2008-06-17 13:44 ` dak at gnu dot org
10 siblings, 0 replies; 12+ messages in thread
From: dak at gnu dot org @ 2008-06-17 13:44 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From dak at gnu dot org 2008-06-17 13:44 -------
(In reply to comment #10)
> The compiler provides a noreturn attribute for abort automatically.
> Whether the header provides it doesn't matter unless you use
> -fno-builtin-abort.
That would suggest that this report should better have been filed with GCC than
with glibc since it would seem that a header change will usually not make a
dfference.
Thanks for that information, appreciated. Now I can move elsewhere in order to
let my head bashed in.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6522
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 12+ messages in thread