rmaprath added a comment. In http://reviews.llvm.org/D20784#443708, @EricWF wrote:
> I don't like the direction of this patch, and it seems like the wrong > direction for what your trying to achieve as well. > If your trying to support a system with two variants of libc++abi, one that > throws and the other that does not, then you'll want libc++ to remain > unmodified so it can depend on the selected libc++abi to provide the correct > exception handling behavior. We do not allow linking a with-exceptions `libc++` library with a no-exceptions `libc++abi` library, that is not a use-case for us. We have either with-exceptions libraries or no-exceptions libraries, there is no overlap. This is why I went with the current approach (modify the no-exceptions libc++ variant to match the no-exceptions libc++abi variant). Note that our use-case is about code-size, we do not want exception handling routines (as well as exception tables) in our final image. We are not after a system where you can swap out the exceptions behaviour. Sorry if I wasn't clear about this. > I think these particular symbols should always be defined within libc++abi > (sorry if I said otherwise earlier, I didn't understand the implementation). > The -fno-exceptions build of libc++abi can build these symbols with very > simple definitions that is detached from the rest of the exception handling > machinery. > > My preference would be to create a new file > `cxa_no_exception_definitions.cpp` (bike shedding welcome) which builds > inplace of `cxa_exception.cpp` and contains definitions for these symbols. > For example. > > - `__cxa_uncaugh_exception()`/`__cxa_uncaught_exceptions()` always returns > zero. > - `__cxa_decrement_exception_refcount(ptr)`/`__cxa_increment_refcount(ptr)` > terminate if `ptr != nullptr`. > - `__cxa_primary_exception()` returns nullptr. > - `__cxa_rethrow_primary_exception(ptr)` returns as to hit the terminate call > in libc++. > > This way we are not conflating building libc++ without exceptions with > building libc++ against an ABI library which doesn't provide the exception > handling API. That too would work for us. I agree this is a bit more cleaner since it does not involve changes to `libc++`, so I will spin a patch for it on top of http://reviews.llvm.org/D20677. / Asiri http://reviews.llvm.org/D20784 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
