[RFC][libcxx] Fix and maintain the no-exceptions build of libcxx

Wouldn’t the better thing to do be to assert rather than call abort (like vector’s exceptions already do, for instance)? One important use case of no-exception builds is to completely optimize out throwing paths and the checks leading to them, which wouldn’t happen if the exceptional path called abort.

Hello,

Asserts getting optimized away is a problem, as then an exceptional code path will simply ignore the error and continue. Of course, one can argue that an exceptional state in a no-exceptions library is something that is OK to be ignored.

In my latest patch [1], the user has the option to override the default abort behaviour by providing a custom __libcxx_noexceptions_abort() function. I think with this mechanism you can achieve the old behaviour if desired.

Cheers,

  • Asiri

[1] http://reviews.llvm.org/D14653

There are cases where exceptions paths being UB is preferable for optimization reasons, but I guess that’s not common (MS’s standard library throws via an external call, libstdc++ calls abort()…). Allowing a custom handler sounds OK.

If you’re going to change exceptional cases to call abort though, then it’d be good to make other cases to be consistent with that approach, like vector’s __throw_length_error and __throw_out_of_range, regex’s __throw_regex_error, and possibly others.

Hi Eric,

If you're going to change exceptional cases to call abort though, then
it'd be good to make other cases to be consistent with that approach, like
vector's __throw_length_error and __throw_out_of_range, regex's
__throw_regex_error, and possibly others.

The initial patch [1] only proposes the framework for fixing the tests and
updating the library sources. I kept it minimal to make the review easier.
I have a giant local patch that fixes the rest of the tests (removes the
XFAILS) and the remaining library sources. And yes, vector's
__throw_length_error, __throw_out_of_range and regex's __throw_regex_error
are all updated in it (and many other places).

I'm still waiting for the approval of this initial patch so that I can
upstream the rest.

Best,

- Asiri

[1] http://reviews.llvm.org/D14653

Just a thought.

Since an implementation that does not support Exception Handling cannot by definition be ISO C++ compliant, a reasonable compromise to calling ‘abort’ might be to call ‘terminate’ wherever a ‘throw’ is expected from the Standard library. Since a program that does not support exception handling cannot have any ‘catch’ clauses, calling ‘terminate’ would in effect have the same semantic effect as a ‘throw’ where no ‘catch’ exists. This would also allow the programmer to use ‘set_terminate’ in an approximation to the Standard. If this not set, it will default to ‘abort’ anyway.

Certainly the need for a good C++ library for embedded systems is essential, and unfortunately the impact of EH keeps a lot of programmers using C instead. For our implementation I build the libraries with EH disabled, though I do keep RTTI enabled.

All the best,

MartinO

Since an implementation that does not support Exception Handling cannot by
definition be ISO C++ compliant, a reasonable compromise to calling ‘abort’
might be to call ‘terminate’ wherever a ‘throw’ is expected from the
Standard library. Since a program that does not support exception handling
cannot have any ‘catch’ clauses, calling ‘terminate’ would in effect have
the same semantic effect as a ‘throw’ where no ‘catch’ exists. This
would also allow the programmer to use ‘set_terminate’ in an
approximation to the Standard. If this not set, it will default to ‘abort’
anyway.

Note that terminate() is defined in <exception> header. I'd rather avoid
that header when using the -fno-exceptions library variant. But I think
this is not a problem, a competent linker would still be able to throw away
the unused exception handling machinery even when the <exception> header is
included (the library itself will have to be compiled with
-ffunction-sections and -fdata-sections).

At any rate, current proposal [1] allows the default abort-if-no-exceptions
behaviour to be overridden.

Best,

- Asiri

[1] http://reviews.llvm.org/D14653