[LLVMdev] Windows EH support

Kaylor, Andrew andrew.kaylor at intel.com
Fri Dec 19 13:13:40 PST 2014

* Add support for unwinding in frames with no exception handlers

I’m not clear as to what needs to be done for this.  I know clang is intentionally generating errors when you compile code with an MSVC-environment target.  I’m guessing that just removing this block will be sufficient for clang to generate the IR we want.  Then it will be up to the back end to produce the correct unwinding support, which I think it may already be doing.

>> Do we not do this already? This shouldn't be hard, we already know how to emit the required pdata/xdata call frame information (CFI).

Like I said, clang spits out an error if you try to compile with exceptions enabled for an MSVC-environment target.  If you compile without exceptions enabled, it doesn’t generate the IR necessary to cleanup during unwind if an exception is thrown across a function.  I tested it by compiling functions with MSVC that call through a function compiled with clang and then throwing an exception across the clang-compiled function.  It unwinds correctly, but doesn’t do any cleanup.

I know that llvm has code to handle this with some personality functions (mingw, at least), but I don’t think it supports the “native” MSVC personality functions yet (__CxxFrameHandler3/4 in this case).  I suppose that will come out of the C++EH work with nothing extra to be done especially for SEH in the back end.  I just wanted to call it out in case there was something else I had overlooked.

Here’s the test case I have in mind.


#include <windows.h>
#include <stdio.h>

class MyClass {
  MyClass() { printf("Hello\n"); }
  ~MyClass() { printf("Goodbye\n"); }

void bar() {
  RaiseException(1, 0, 0, NULL);

void foo() {
  MyClass Fubar;

DWORD filter() {
    printf("In filter\n");

int main() {
    __try {
        __try {
        __except (filter()) {
            printf("In exception handler\n");
    __finally {
    return 0;


Compiling that with MSVC, it doesn’t execute the MyClass destructor if I compile with no /EH option, but it does execute the destructor with /EHa, having called it from __CxxFrameHandler3 while unwinding, on its way to the exception handler.  I understand that you aren’t worried about faithfully reproducing the behavior of /EHa, but we do at least want to clean up in cases like this, right?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141219/b61cafd8/attachment.html>

More information about the llvm-dev mailing list