search for: _cxxframehandler3

...> // uncaught exception? Run ~Inner then ~Outer. > } I took a look at the IR that’s generated for this example. I see what you mean. So there is potentially cleanup code before and after every catch handler, right? Do you happen to know offhand what that looks like in the .xdata for the _CxxFrameHandler3 function? -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141125/9e6f22e6/attachment.html>

...m personality function and the libc++abi library. There are also LLVM clients, such as ldc, that provide Windows exception handling similar to what I am proposing by providing their own custom personality function. However, what I would like is to support Windows C++ exception handling using the __CxxFrameHandler3 function provided by the native Windows runtime library. Some of the primary challenges in supporting native Windows C++ exception handling are: 1. Catch and unwind handlers are called in a different frame context than the original function in which they are defined. 2. Windows exception handlin...

We already have something like what you describe in the form of mingw support. It runs on Windows and handles exceptions using a DWARF-style personality function and (I think) an LLVM-provided implementation of the libc++abi library. What this doesn't do is provide interoperability with MSVC-compiled objects. For instance, you can't throw an exception from MSVC-compiled code and catch

...stv.unwind.1 helper just calls ~Inner(), but not ~Outer. That’s actually intentional. The thing to keep in mind is that all of the landing pads are going to be effectively removed by the time the final object image is generated. They are just there to facilitate the table generation, and in the __CxxFrameHandler3 case they don’t mean quite the same thing that they mean elsewhere. (Maybe that’s an argument for using a different construct.) There’s also a good chance that I’m being inconsistent in how I chose to represent catch clauses versus cleanup clauses. In the case you refer to, if an exception throw...

...> // uncaught exception? Run ~Inner then ~Outer. > } I took a look at the IR that’s generated for this example. I see what you mean. So there is potentially cleanup code before and after every catch handler, right? Do you happen to know offhand what that looks like in the .xdata for the _CxxFrameHandler3 function? -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141203/6aced324/attachment.html>

...I took a look at the IR that’s generated for this example. I see what >> you mean. So there is potentially cleanup code before and after every >> catch handler, right? >> >> >> >> Do you happen to know offhand what that looks like in the .xdata for the >> _CxxFrameHandler3 function? >> > > I can't tell how the state tables arrange for the destructors to run in > the right order, but they can accomplish this without duplicating the > cleanup code into the outlined catch handler functions, which is nice. > > I think we may be able to address...

...; preds = %if.then br label %if.end ; From 'entry' invoke of Middle constructor ; outer needs post-catch cleanup lpad: ; preds = %if.end, %entry %2 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to i8*) cleanup catch i8* bitcast (i8** @_ZTIi to i8*) %3 = extractvalue { i8*, i32 } %2, 0 store i8* %3, i8** %exn.slot %4 = extractvalue { i8*, i32 } %2, 1 store i32 %4, i32* %ehselector.slot ; No pre-catch cleanup for this landingpad br label %catch.dispatch ; Fr...