search for: __except

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 translate this? - The filter expression is basically a nested function which is called with the exception code and exception information. - The body of the __except statement is the landing pad. It...

...ap LLVM IR to SEH? I.e. are you talking about how to implement LLVM's "dwarf" exception handling intrinsics and landingpad instruction using SEH? Ciao, Duncan. > > The basic structure of SEH in C is as follows: > > __try { > // Do something. > } > __except (filter(GetExceptionCode(), GetExceptionInformation())) > { > // Handle exception > } > > How to translate this? > > - The filter expression is basically a nested function which is called with the > exception code and exception information. > - The body of the...

On Wed, Dec 3, 2014 at 1:41 PM, Reid Kleckner <rnk at google.com> wrote: > On Wed, Dec 3, 2014 at 1:27 PM, Vadim Chugunov <vadimcn at gmail.com> wrote: > >> If we added unwind target to every potentially throwing instruction >> (loads, stores, all binary operations), wouldn't all such instructions have >> to become BB terminators? I'd expect that CFG

...start outlining, I’m just picking them up as I go. It seems like that may need to change. -Andy From: Reid Kleckner [mailto:rnk at google.com] Sent: Wednesday, December 03, 2014 1:32 PM To: Kaylor, Andrew Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR I went ahead and implemented @llvm.frameallocate in a patch here: http://reviews.llvm.org/D6493 Andrew, do you have a wip patch for outlining, or any lessons learned from attempting it? I think outlining is now the next step, so let me know if there's something you're actively...

...sed Windows SEH for the COFF format. That is, implementing synchronous exceptions using the native platform's asynchronous exception framework. I am concerned with representing the handling of asynchronous exceptions in LLVM as there is language-level support in Windows C++ compilers via __try/__except/__finally blocks (Clang already supports this at the AST level). I believe that this is not currently possible and needs new no-op instructions or a change in syntax. A SEH-block in C++ consists of a __try block and either of two following blocks: * A __except block consisting of a filter and bod...

...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): | (default) | /EHa | /EHs | ----------------------------...

...king? > > The "big dynamic alloca" approach does work, at least conceptually. It's more or less what MSVC does. They emit the normal code, then the epilogue, then a special prologue that resets ebp/rbp, and then continue with normal emission. Any local variables declared in the __except block are allocated in the parent frame and are accessed via ebp. Any calls create new stack adjustments to new allocate argument memory. > > This approach sounds far scarier to me, personally, and will significantly complicate a part of LLVM that is already poorly understood and hard to hac...

If we added unwind target to every potentially throwing instruction (loads, stores, all binary operations), wouldn't all such instructions have to become BB terminators? I'd expect that CFG would then end up consisting mostly of single-instruction BBs. This can't be good for compilation performance and optimizations... Another vague idea: what if lifetime.start() returned some kind

...dition to noinline, we need to invent > another function attribute to prevent functionattrs from inferring nounwind > and readonly, or the optimizers will delete the invoke unwind edge or > entire call site. > > --- > > The next challenge is actually catching the exception. The __except > construct allows the user to evaluate a (mostly) arbitrary expression to > decide if the exception should be caught. Code generated by MSVC catches > these exceptions with an exception handler provided by the CRT. This > handler is analogous to personality functions (__gxx_personality...

...t; > > > From: Reid Kleckner [mailto:rnk at google.com <mailto:rnk at google.com>] > Sent: Thursday, November 13, 2014 4:22 PM > > > To: Kaylor, Andrew > Cc: LLVM Developers Mailing List; John McCall > Subject: Re: [LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR > > > > Focusing on cleanups is probably a good way to start. The trouble is that your personality function can't just reset rsp and jump to the landing pad, or it will trash the state of the unwinder that's still on the stack. Everything in the landing pad basic...

I was wondering if the upcoming LLVM 3.5 release will have support for Microsoft Windows Structured Exception handling (e.g., __try/__except/__finally)? Thanks, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140730/e3d18989/attachment.html>

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

...format. That is, implementing > synchronous exceptions using the native platform's asynchronous > exception framework. > > I am concerned with representing the handling of asynchronous > exceptions in LLVM as there is language-level support in Windows C++ > compilers via __try/__except/__finally blocks (Clang already supports > this at the AST level). I believe that this is not currently possible > and needs new no-op instructions or a change in syntax. > > A SEH-block in C++ consists of a __try block and either of two > following blocks: > > * A __except blo...

...t;> >> The "big dynamic alloca" approach does work, at least conceptually. It's more or less what MSVC does. They emit the normal code, then the epilogue, then a special prologue that resets ebp/rbp, and then continue with normal emission. Any local variables declared in the __except block are allocated in the parent frame and are accessed via ebp. Any calls create new stack adjustments to new allocate argument memory. >> >> This approach sounds far scarier to me, personally, and will significantly complicate a part of LLVM that is already poorly understood and har...

Hi all, In my MSVC-compiled project I am using MCJIT to run some generated code. I faced that in case of Win64 ('x86_64-pc-win32-elf') __try/__except block doesn't work - the stack can not be unwound. I have found that the only way to fix it is implementing my own *registerEHFrames* function of the Memory Manager (but I'm not sure this helps). Maybe someone had a success solving the same problem? What would be the best approach to catch...

...importantly, what can I do to help? Thanks, Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Reid Kleckner Sent: Monday, November 10, 2014 3:39 PM To: LLVM Developers Mailing List; John McCall Subject: Re: [LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR Hm, this idea won't work. If we point to labels from landingpadinst then passes like SimplifyCFG will consider the blocks to be unreachable. I realized this by looking at llvm-dis output after hacking in asmparser support for this syntax. :) I'll have to think longer. On Mon,...

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:

...f in the landingpad comes in, right? Anyway, I think I’m making progress. :-) -Andy From: Reid Kleckner [mailto:rnk at google.com] Sent: Thursday, November 13, 2014 4:22 PM To: Kaylor, Andrew Cc: LLVM Developers Mailing List; John McCall Subject: Re: [LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR Focusing on cleanups is probably a good way to start. The trouble is that your personality function can't just reset rsp and jump to the landing pad, or it will trash the state of the unwinder that's still on the stack. Everything in the landing pad basically has to be outlined...

...g, probably starting with manual changes to the IR that simulate the process. -Andy From: Reid Kleckner [mailto:rnk at google.com] Sent: Thursday, November 13, 2014 11:51 AM To: Kaylor, Andrew Cc: LLVM Developers Mailing List; John McCall Subject: Re: [LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR Cool! Apologies for the following stream of consciousness brain dump... On Wed, Nov 12, 2014 at 5:07 PM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote: Hi Reid, I’ve been following your proposal, and I’d be interested in helping out...

> We should also think about how to call std::terminate when cleanup dtors throw. The current representation for Itanium is inefficient. As a strawman, I propose making @__clang_call_terminate an intrinsic: … That sounds like a good starting point. > Chandler expressed strong concerns about this design, however, as @llvm.eh.get_capture_block adds an ordering constraint on CodeGen. Once