Bug 69388 - Allow functexcept.cc definitions to be replaced
Summary: Allow functexcept.cc definitions to be replaced
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 6.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-20 12:30 UTC by Jonathan Wakely
Modified: 2018-05-02 12:46 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2017-01-24 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Wakely 2016-01-20 12:30:42 UTC
Choosing the non-throwing versions of the __throw_* definitions in src/c++11/functexcept.cc requires rebuilding libstdc++ with -fno-exceptions, which is not usually practical.

It would be helpful to allow them to be replaced by the application, so that a custom libstdc++ isn't needed. Maybe they could be declared weak, and we could provide an extension header for users to include (or an object file to link to) that has alternative definitions.

This would mean that even exceptions thrown from inside the compiled library code (rather than just inline/template code in headers) could be transformed into abort calls per-application without using a rebuilt libstdc++.so

The Taller Technologies guys are looking into using different multlib builds for -fexceptions / -fno-exceptions, this might make that unnecesary (at least for targets that support symbol interposition and/or weak symbols).
Comment 1 Jonathan Wakely 2016-01-20 12:31:17 UTC
It would also offer a better way for Firefox to do:
https://dxr.mozilla.org/mozilla-central/source/memory/mozalloc/throw_gcc.h
Comment 2 Nathan Froyd 2017-01-24 16:01:08 UTC
Firefox's custom implementation of the __throw_* functions also wound up biting us when libc++ started defining functions with identical names:

https://bugzilla.mozilla.org/show_bug.cgi?id=1329520
Comment 3 Jonathan Wakely 2017-01-24 16:07:23 UTC
Following discussion with one of the libc++ developers, we're considering some common API that would allow an aplication to globally turn those throws into aborts, so that redefining them would be unnecessary.

One possibility is to link to some new lib (say, libnothrow.so) which would run a static initializer or provide a definition for a weak symbol, causing the __throw_xxx functions to unconditionally abort. That would not require a special libstdc++ built without exceptions, and would mean that the choice is fixed by the app at link-time (not dependent on which libstdc++.so happens to be chosen by the dynamic linker, one that throws or one that aborts).
Comment 4 Dimitry Andric 2017-01-24 17:31:18 UTC
(In reply to Jonathan Wakely from comment #3)
> Following discussion with one of the libc++ developers, we're considering
> some common API that would allow an aplication to globally turn those throws
> into aborts, so that redefining them would be unnecessary.

As I discussed with libc++ maintainer Eric Fiselier, it would be nice if those functions called terminate() in the 'fatal' case instead.  Then you at least have some standardized way of overriding the termination with your own mechanism, which appears to be what the Mozilla authors wanted to achieve.

(Note that even gcc redefines abort() so it can catch it in its own way... :)
Comment 5 Jonathan Wakely 2017-01-24 18:10:57 UTC
(In reply to Dimitry Andric from comment #4)
> As I discussed with libc++ maintainer Eric Fiselier, it would be nice if
> those functions called terminate() in the 'fatal' case instead.  Then you at
> least have some standardized way of overriding the termination with your own
> mechanism, which appears to be what the Mozilla authors wanted to achieve.

I thought the point of the mozilla hacks is to ensure that the functions terminate the program instead of throwing an exception (which is the default). Simply changing __builtin_abort to std::terminate won't help: the default will still be to throw an exception.

Whether they should terminate or abort is an entirely separate question, and unrelated to the mozilla hacks AFAICS.
Comment 6 Jakub Jelinek 2018-05-02 10:11:32 UTC
GCC 8.1 has been released.