[Bug libc/6522] abort should not be marked noreturn

["dak at gnu dot org" <sourceware-bugzilla at sourceware dot org>]

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