On Thu, Aug 14, 2014 at 6:01 PM, Reid Kleckner <rnk at google.com> wrote:> 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140814/89a4faae/attachment.html>
On 15 August 2014 02:48, Chandler Carruth <chandlerc at google.com> wrote:> > On Thu, Aug 14, 2014 at 6:01 PM, Reid Kleckner <rnk at google.com> wrote: >> >> 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 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] http://stackoverflow.com/questions/6524259/what-are-the-consequences-of-mixing-exception-handling-models-in-visual-studio-2 [2] https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_exceptions.html Thanks, Dan.
> On 15 August 2014 02:48, Chandler Carruth <chandlerc at google.com> wrote: >> >> On Thu, Aug 14, 2014 at 6:01 PM, Reid Kleckner <rnk at google.com> wrote: >>> >>> 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 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] >[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