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

[Martin J. O'Riordan via cfe-dev]

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

 

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/20151130/51e782ef/attachment.html>