similar to: [LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR

Hi Reid, I’ve been following your proposal, and I’d be interested in helping out if I can. My main interest right now is in enabling C++ exception handling in clang for native (i.e. not mingw/cygwin) Windows targets (both 32-bit and 64-bit), but if I understand things correctly that will be closely related to your SEH work under the hood. I’m still trying to get up to speed on what is and is

I don’t really have a good enough feeling for the landingpad syntax yet to comment on the most natural way to extend it yet, but creating a synthetic cleanup function to call from the personality function is what I was thinking. With the current (trunk +/- a couple of weeks) clang, compiling for an “x86_64-pc-windows-msvc” target, I’m seeing a landingpad that looks like this: lpad:

On Mon, May 18, 2015 at 11:48 AM, Steve Cheng <steve.ckp at gmail.com> wrote: > On 2015-05-18 13:32:54 -0400, Reid Kleckner said: > >> >> Right, doing our own personality function is possible, but still has half >> the challenge of using __CxxFrameHandler3, and introduces a new runtime >> dependency that isn't there currently. Given that it won't save

Hi, I have a question about the IR model for SEH filters (as I want to use the same model for CLR filters). In particular, when an outer filter is invoked before entering an inner finally, which piece of IR reflects the filter's side-effects? To take a concrete example, consider this C code: void foo() { int x; __try { x = 0; __try { x = 2; may_throw(); }

Thanks for the additional information. Right now I’m experimenting with a mix of code compiled with MSVC and code compiled with clang, trying to get a C++ exception thrown and caught by the MSVC-compiled code across a function in the clang-compiled code. My goal here is to isolate a small part of what needs to be done in a way that lends itself to tinkering. I think this might lead me to the

On Sat, May 16, 2015 at 7:29 AM, Steve Cheng <steve.ckp at gmail.com> wrote: > On 2015-05-15 18:37:58 -0400, Reid Kleckner said: > > After a long tale of sorrow and woe, my colleagues and I stand here >> before you defeated. The Itanium EH representation is not amenable to >> implementing MSVC-compatible exceptions. We need a new representation that >> preserves

I don’t know much about SEH and haven’t had time to really dig into this, but the idea of outlining functions that need to know about the frame layout sounds a bit scary. Is it really necessary? I’m wondering if you can treat the cleanups and filter functions as portions of the same function, instead of outlining them to separate functions. Can you arrange to set up the base pointer on entry to

In the past people in #llvm suggested to me I should use landing pads instead of seh when it comes to Windows unless i really need seh. Looking at what gets generated win64 -gnu does use seh but calls the landing pad somehow, while win32 doesn't at all. It looks to me a custom win64 landing pad personality can also deal with things like Access Violation. Is there a way to make win32 also

Hi! I try to add more functionality to Win64 exception handling, based on the posted patches from Charles Davis and João Matos. But I have a question about how to map SEH handling to LLVM IR. The basic structure of SEH in C is as follows: __try { // Do something. } __except (filter(GetExceptionCode(), GetExceptionInformation())) { // Handle exception } How to

Hi Reid, Is this design supposed to be able to cope with asynchronous exceptions? I am having trouble imagining how this would work without adding the ability to associate landing pads with scopes in LLVM IR. Vadim On Tue, Nov 25, 2014 at 5:27 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Nov 25, 2014 at 3:09 PM, Kaylor, Andrew <andrew.kaylor at intel.com> > wrote:

Hi Kai, > I try to add more functionality to Win64 exception handling, based on the posted > patches from Charles Davis and João Matos. > > But I have a question about how to map SEH handling to LLVM IR. are you sure you don't mean: map LLVM IR to SEH? I.e. are you talking about how to implement LLVM's "dwarf" exception handling intrinsics and landingpad

Hi Reid, I've been working on the outlining code and have a prototype that produces what I want for a simple case. Now I'm thinking about the heuristics for recognizing the various logical pieces for C++ exception handling code and removing them once they’ve been cloned. I've been working from various comments you've made earlier in this thread, and I'd like to run something

Hi, Per Reid’s feedback, I have separated two SEH missing features. This thread now is only focusing on _local_unwind(), Jumping out of _finally. The design is documented in Wiki here: https://github.com/tentzen/llvm-project/wiki/Windows-SEH:-Local_Unwind-(aka:-Jumping-Out-of-_Finally) The implementation can be seen here:

Hi Reid, I'm trying to get a "big picture" view of everything that needs to be done for clang and llvm to support SEH and C++ exception handling for the "msvc" environment. I've put together a list, including work in progress, but I'm guessing that I've missed some details. Can you look this over and tell me if it matches your idea of what needs to be done?

Hi, I'm trying to get exception handling working in my compiler targetting LLVM. I've been working from the LLVM exception handling documentation (including http://llvm.org/docs/ExceptionHandling.html and http://wiki.llvm.org/HowTo:_Build_JIT_based_Exception_mechanism) and looking at g++-llvm's output. I've been trying to get a minimal test function to work, which simply invokes

Hi, This is a spin-off of previous Windows SEH RFC below. This RFC only focus on supporting HW Exception Handling. A detailed implementation can be seen in here: https://github.com/tentzen/llvm-project/commit/8a2421c274b683051e456cbe12c177e3b934fb5e It passes all MSVC SEH suite (excluding those with “Jumping out of _finally” ( _Local_Unwind)). Thanks, --Ten **** The rules for C code: ****

Hi, all, The intend of this thread is to complete the support for Windows SEH. Currently there are two major missing features: Jumping out of a _finally and Hardware exception handling. The document below is my proposed design and implementation to fully support SEH on LLVM. I have completely implemented this design on a branch in repo:

After a long tale of sorrow and woe, my colleagues and I stand here before you defeated. The Itanium EH representation is not amenable to implementing MSVC-compatible exceptions. We need a new representation that preserves information about how try-catch blocks are nested. WinEH background ------------------------------- Skip this if you already know a lot about Windows exceptions. On Windows,

Hi, Eli, Why are you under the impression that threw_exception() will not be called if optimizations are enabled? I don’t know if the -EHa Spec is clearly described in MSFT Webs. At least this proposal has described the rules for both C & C++ code. The very first rule clearly said that “no exception can move in or out of _try region., i.e., no potential faulty instruction can be moved

Have got anything started with the dispatchblock plan? From: Reid Kleckner [mailto:rnk at google.com] Sent: Wednesday, May 13, 2015 1:15 PM To: Kaylor, Andrew Cc: David Majnemer <david.majnemer at gmail.com> (david.majnemer at gmail.com); LLVM Developers Mailing List Subject: Re: [WinEH] A hiccup for the Windows C++ exception handling On Wed, May 13, 2015 at 11:03 AM, Kaylor, Andrew