Exceptions on Windows & MSVC

Hello everyone,

I was wondering what is the status regarding exceptions for the windows-msvc target? The corresponding part of the documentation (llvm/decs/ExceptionHandling.rst) hasn’t been updated since 2015, was there any progress since?

This is most likely known, but there’s significant divergence between the behavior of MSVC cl.exe and clang-cl.exe:

Consider:

void crash() {

struct A {

~A() {}

} Obj;

*(volatile int *)0x11 = 0;

}

#ifdef SEH

#define TRY __try

#define CATCH_ALL __except (1)

#else

#define TRY try

#define CATCH_ALL catch (…)

#endif

int main() {

TRY { crash(); }

CATCH_ALL {}

return 0;

}

using try/catch (SEH not defined):

I wasn’t able to find where we say this in the docs, but the important thing to understand is that LLVM is currently incapable of representing non-call instructions that might throw an exception. So, in your example with the destructor, LLVM thinks there are no potentially throwing operations in this function, so there is no need to emit an exceptional destructor cleanup. I didn’t read through the tables to see what actually happens in practice, but it should mostly be explained by the above.

If we do anything at all with /EHa in clang-cl, we just flip the bit that says “run destructor cleanups even when a non-C++ exception occurs”. I can’t remember if anyone actually hooked that up, though.

Aaron expressed interest in implementing support for non-call exceptions in LLVM. I’m happy to help review the design and code, but neither I nor anyone on my team is currently planning to work on this.

Here: https://clang.llvm.org/docs/MSVCCompatibility.html ?

Asynchronous Exceptions (SEH): Partial. Structured exceptions (__try /
__except / __finally) mostly work on x86 and x64. LLVM does not model
asynchronous exceptions, so it is currently impossible to catch an
asynchronous exception generated in the same frame as the catching
__try.

Michael