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

[Asiri Rathnayake via cfe-dev]

> 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


>
>
> 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
>
>
>
> *From:* cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] *On Behalf Of *Asiri
> Rathnayake via cfe-dev
> *Sent:* 28 November 2015 21:20
> *To:* Eric Lasota
> *Cc:* cfe-dev at lists.llvm.org
> *Subject:* Re: [cfe-dev] [RFC][libcxx] Fix and maintain the no-exceptions
> build of libcxx
>
>
>
> 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
>
>
>
>
>
>
>
> On Fri, Nov 27, 2015 at 7:03 AM, Asiri Rathnayake <
> asiri.rathnayake at gmail.com> wrote:
>
> 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
>
>
>
>
>
> On Thu, Nov 26, 2015 at 5:00 PM, via cfe-dev <cfe-dev at lists.llvm.org>
> wrote:
>
> 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.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151201/f1a060a8/attachment.html>