similar to: [LLVMdev] Platform-independent Exception Handling

On Feb 9, 2013, at 4:14 PM, Anthony Bryant <antjbryant at gmail.com> wrote: > Greetings, > > I'm trying to implement exception handling in my front end. I have a > prototype working using the Itanium ABI on Linux x86_64, but I'm not > sure how to proceed for other platforms. > > So I was wondering: which OS/architecture combinations support > zero-cost EH,

Hi Bill, Thanks for the response, I just have a couple more questions. On 11 February 2013 06:45, Bill Wendling <wendling at apple.com> wrote: > As far as which OS/architectures support zero-cost EH and which > support SJLJ, LLVM is designed to assume that Intel supports zero-cost > exceptions and ARM supports SjLj exceptions. However, it's all in the > personality function

On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote: > On Jul 22, 2011, at 10:29 PM, Bill Wendling wrote: > >> // Restrictions: >> >> There are several new invariants which will be enforced by the verifier: >> >> 1. A landing pad block is a basic block which is the unwind destination of an >> invoke instruction. >> 2. A landing pad block

On Jul 22, 2011, at 11:52 PM, Cameron Zwarich wrote: > On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote: > >> On Jul 22, 2011, at 10:29 PM, Bill Wendling wrote: >> >>> // Restrictions: >>> >>> There are several new invariants which will be enforced by the verifier: >>> >>> 1. A landing pad block is a basic block which is

On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be> wrote: > Reid Kleckner wrote: > > On Fri, Sep 16, 2016 at 10:13 AM, Jonas Maebe via llvm-dev > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > model. In order to ensure that changes performed in a try/setjmp==0 > > block survive

I was thinking about this last night, and I came up with a third alternative which I think looks very promising. It’s basically a re-working of the previous alternative to use the landingpad concept rather than arbitrary fake logic, but it uses a single landing pad for the entire function that mimics the logic of the personality function to dispatch unwinding calls and catch handlers. I believe

Hi, In our (non-C) compiler we use setjmp/longjmp to implement exception handling. For the initial implementation LLVM backend, I'm keeping that model. In order to ensure that changes performed in a try/setjmp==0 block survive the longjmp, the changes must be done via volatile operations. Given that volatility is a property of individual load/store instructions rather than of memory slots in

On 30/09/16 20:10, Reid Kleckner wrote: > On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be > <mailto:jonas-devlists at watlock.be>> wrote: > > So, can I use invoke and landingpad without using any of the other > exception handling intrinsics? (in combination with a dummy personality > function) Or will LLVM in all cases insist on

Hi Duncan, thanks ! hehe . >> Why do you want the names anyway? because i 'am working on llvm to support sjlj-eh for my target. for my side, I lookup the llvm invoke instruction to build the sjlj-eh on sjlj-eh it's need store the landing pad index to stack before call __cxa_throw, but it seems no ! in llvm-backend because it only suport dwarf-eh! so i have to build

Hi all, Following John's, Duncan's and Bill's proposals about exception handling, I thought I'd summarise what has been discussed so far. ** The problems we're trying to solve are: P1. Different languages have different EH concepts and IR needs to be agnostic (as possible) about that P2. Inlining and optimisations (currently) destroy the EH semantics and produce code that

What? Yet another EH proposal?! This one is different from the others in that I'm planning to start implementing this shortly. But I want your feedback! I've all ready gotten a lot of feedback from Chris, John, Jim, Eric, and many others. Now is your turn! Please read this proposal and send me your comments, suggestions, and concerns. -bw

On 6 March 2014 18:09, Mark Seaborn <mseaborn at chromium.org> wrote: > LowerAtomic "lowers atomic intrinsics to non-atomic form for use in a > known non-preemptible environment". LowerInvoke strips out exception > handling by converting invokes to calls, so that landingpads, resumes, etc. > become dead and can be removed by a later pass. > > (As an aside,

Dear list, I want to add SJLJ exception handling to my frontend. Unfortunately, there doesn't seem to be any examples in the documentation as to how to use the intrinsics @llvm.eh.sjlj.setjmp @llvm.eh.sjlj.longjmp @llvm.eh.sjlj.lsda @llvm.eh.sjlj.callsite Is there a way to force Clang to use SJLJ exception handling for C++? That way I would be able to look at its output to learn how to use

> I dont have a concrete design right now and I am happy to take any other ideas Three ideas come to mind, none of which are perfect: 1) I'm tempted to say that now that we have token type, landingpad should generally produce a token, the pointer should be extracted with the @llvm.eh.exceptionpointer intrinsic instead of an extractvalue, and the selector should likewise be extracted with

Hi Duncan, >>I don't get it. Sorry my bad English! hehe. >>What has this got to do with determining the >>names "@__cxa_throw" and "@_ZTi"? Record the Information into the MachineModule Info, so in Dwarfwriter or SjLjWriter(my sjlj-eh name) can build the except table correctly! 2009/3/26 Duncan Sands <baldrick at free.fr>: > Hi zhangzw,

Hi zhangzw, > >> Why do you want the names anyway? > > because i 'am working on llvm to support sjlj-eh for my target. > for my side, I lookup the llvm invoke instruction to build the sjlj-eh > on sjlj-eh it's need store the landing pad index to stack before > call __cxa_throw, > but it seems no ! in llvm-backend because it only suport dwarf-eh!

It seems a little backwards to me to check the landingpad's type as the first check, since the personality dictates the landingpad's type. That said, yes I see how #4 is expedient in allowing personalities using the two main types to lump themselves into EHPersonality::Unknown. As for supporting selector and exception pointer extraction for landingpad of token type, I think you'll

Hi, I was comparing the way LLVM generates the exception table and it looks a bit different from what GCC (arm-none-eabi-g++) generates. Maybe that's because clang is not generating ARM IR when I do: $ clang -c -emit-llvm -march=arm -mcpu=cortex-a8 -mtriple=arm-none-eabi exception.cpp -o exception.clang.bc clang: warning: argument unused during compilation: '-mcpu=cortex-a8' clang:

Hello, Renato > Anyone has any idea on the status of exception handling in clang/LLVM? > DwarfException cannot be easily overwritten, and adding target specific > code to it seems wrong... Neither llvm-gcc nor clang support exceptions on ARM (except, maybe, sjlj excheptions on arm/darwin). I have some patched uncommitted for EH on ARM but they are too far from being complete. -- With

On Sun, Dec 18, 2016 at 02:23:01PM +0100, Jonas Maebe via llvm-dev wrote: > Recap: we use setjmp/longjmp for our exception handling on all platforms in > our regular (non-LLVM) code generators. I'd like to use the same > infrastructure with the LLVM code generator for code interoperability > purposes (the LLVM SjLj personality is not binary-compatible with our > existing