LLVM_REQUIRES_EH

Can anyone think of a good reason to keep this CMake variable around? AFAICT llvm should never need to be compiled with exception support, and the same applies for clang, lldb, lld, and all (?) other LLVM subprojects.

If there’s no reason to keep this around I can just remove it entirely.

I thought Linux distros compile LLVM with RTTI and exceptions enabled when packaging.

The question is why.

RTTI makes sense -- they may well need it.

But exceptions should work fine in the rest of the application even if LLVM
is compiled with them, no?

I looked at something related to this fairly recently.

The example in ``examples/ExceptionDemo/`` seems to require it.

Also these files also use it

lib/Transforms/Hello/CMakeLists.txt: if( NOT LLVM_REQUIRES_EH )
tools/bugpoint-passes/CMakeLists.txt: if( NOT LLVM_REQUIRES_EH )

I'm not entirely sure why though because I don't know what the export
files are for and why RTTI or EH changes anything about the exported
symbols.

Are you aware I recently added the ``LLVM_ENABLE_EH`` CMake option [1]
and that we actually export this information to clients of LLVM in
LLVMConfig.cmake (as ``LLVM_ENABLE_EH``, see [2])?

If you do decide to remove LLVM_REQUIRES_EH you need make sure that
LLVM_ENABLE_EH doesn't break.

[1] http://llvm.org/docs/CMake.html#frequently-used-cmake-variables
[2] http://llvm.org/docs/CMake.html#embedding-llvm-in-your-project

Thanks,
Dan.

I assume you meant to say "even if LLVM is compiled without them".

If so I was under the impression that if LLVM code built **without**
EH calls into the client code built **with** EH and that client code
then throws an exception that this exception would not be properly
propaged through the call stack. I've never tested this myself but my
reasoning came from [1] and in particular the following from [2]

Before detailing the library support for -fno-exceptions, first a
passing note on the things lost when this flag is used: it will break
exceptions trying to pass through code compiled with -fno-exceptions
whether or not that code has any try or catch constructs. If you might
have some code that throws, you shouldn't use -fno-exceptions. If you
have some code that uses try or catch, you shouldn't use
-fno-exceptions.

This is why I added the LLVM_ENABLE_EH option so if a client of LLVM
really wants to use exceptions they can.

[1] c++ - What are the consequences of mixing exception handling models in Visual Studio 2010? - Stack Overflow
[2] Exceptions

Thanks,
Dan.

[snip]

I can verify that this is a problem, and one that causes a crash.

We use the REQUIRES_EH flag along with some CMakeLists changes to make sure that EH is turned on for all builds (but could switch to the other flag). In most cases, mixed compiling shouldn't be a problem, but if something like a user-written ModulePass throws an exception, the program will break in interesting and magical ways since the stack isn't unwound correctly. For us, not using exceptions is out of the question, so we need to turn them on for LLVM.

That said, I don't have a particular preference on what flag is used, and it sounds like there is an alternative to REQUIRES_EH now, so I don't see a problem removing the old one (If I remember correctly it was messed up on Windows anyway).

Cheers,
Gordon Keiser
Software Development Engineer
Arxan Technologies

<snip>

I can verify that this is a problem, and one that causes a crash.

We use the REQUIRES_EH flag along with some CMakeLists changes to make sure that EH is turned on for all builds (but could switch to the other flag). In most cases, mixed compiling shouldn't be a problem, but if something like a user-written ModulePass throws an exception, the program will break in interesting and magical ways since the stack isn't unwound correctly. For us, not using exceptions is out of the question, so we need to turn them on for LLVM.

That said, I don't have a particular preference on what flag is used, and it sounds like there is an alternative to REQUIRES_EH now, so I don't see a problem removing the old one (If I remember correctly it was messed up on Windows anyway).

The ENABLE_EH CMake option globally enables building without
``-fno-exceptions`` (``/EHs-c-`` for MSVC) so you should probably give
it a go.

Note the change in compiler flags produced using ENABLE_EH is exactly
what REQUIRES_EH does so if REQUIRES_EH is broken under Windows then
ENABLE_EH will also probably be broken as well :frowning: . So if you have
problems with ENABLE_EH please submit a patch.

Thanks,
Dan Liew.