[PATCH] D20677: Make it possible to build a -fno-exceptions libc++abi variant.

Eric Fiselier via cfe-commits cfe-commits at lists.llvm.org
Fri May 27 14:20:22 PDT 2016


EricWF added a comment.

In http://reviews.llvm.org/D20677#442687, @rmaprath wrote:

> In http://reviews.llvm.org/D20677#442559, @EricWF wrote:
>
> > I have an issue with this change since it allows a libc++abi built without exceptions to be used in a program compiled with them. I assert that this should not be supported in any way.
> >
> > My personal preference would be to remove as much of the exception API from the library when it's built without exceptions. This should cause link errors if a program contains any code that throws. If this is not done it creates bugs within code like `__terminate` as mentioned in an inline comment.
> >
> > I would like to see another revision of this patch that removes as much of the exception API as possible. Looking at the symbols defined in `cxxabi.h` I would say ever symbol in sections 2.4 and 2.5 should not longer be defined in the library.
>
>
> That sounds generally OK to me. The toolchain I'm working on (ARM Compiler 6) has an elaborate mechanism (based on build attributes) to select the correct variant of libraries. In other words, if any of your objects are compiled with exceptions, you are guaranteed to no select any of the no-exceptions library variants. This avoids the problem you mentioned altogether.


Note that that behavior will cause different issues in some cases. If you  link an executable  to two libraries, `libfoo.so` and `libbar.so`, where one was compiled with exceptions and the other without you'll get two copies of libc++abi in the program. Now you have two copies of the global terminate handler and two copies of `__terminate` for the linker to select from.
If it selects the nothrow `__terminate` and the terminate handler throws an exception your in trouble.

That's not a reason to hold up this patch, but it is a potential problem you should be aware of.


http://reviews.llvm.org/D20677





More information about the cfe-commits mailing list