similar to: [LLVMdev] Do the LLVM SJLJ intrinsics interact with C++ exception handling and execute C++ cleanup actions?

I'm trying to make sense in the support for setjmp/longjmp in Clang and LLVM, with only partial success. I'll try to summarize my findings in the hope that someone can shed some light on why things are the way they are and what I'm missing. Clang. Clang recognizes two forms of setjmp (all I say here applies to longjmp similarly): * __builtin_setjmp: gets lowered to calling the

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 28 April 2015 at 00:30, Reid Kleckner <rnk at google.com> wrote: > I think Paweł identified the problem. The frames on the stack between the > setjmp and longjmp must have valid unwind information, which is described > here: > https://msdn.microsoft.com/en-us/library/ft9x1kdx.aspx?f=255&MSPPError=-2147217396 > > In particular, it has this line about JITed code: >

Hi, I meet an issue when I verify machineinstrs for Powerpc testcases in llvm. llc -mtriple=powerpc64-unknown-linux-gnu < llvm/llvm/test/CodeGen/PowerPC/sj-ctr-loop.ll -verify-machineinstrs Bad machine code: MBB exits via unconditional fall-through but ends with a barrier instruction! *** function: main basic block: %bb.2 for.body.lr.ph (0x100275437e8) Content in block BB.2:

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

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

This is the only thing that I’ve found that works in terms of getting the exception to propagate out of the JITted function - change the “call” to an “invoke” and hook in the do-nothing landing-pad. https://gist.github.com/drmeister/7a35046f666826206973 Compare line 646 of the file above to the one that I just posted. > https://gist.github.com/drmeister/b97dec956c6ee9ffeb75 The first one

Okay. I understand builtin functions do not have to behave exactly the same way as standard library functions. What I wanted to know is what should the code generated by llvm (clang + llc) look like (I am working on the Mips back-end now). I guess there should be a behavior users expect to see who are using __builtin_setjmp/longjmp even they aren't the same as library functions. If the code

Logan, How would I dump the object file generated by the JIT compiler pipeline? Could you point me to an example of how something like that is done? I’m used to working with the JIT machinery in memory but not writing object files out to disk. I’m have code to generate object files for AOT compilation - is it done the same way? Best, .Chris. On Apr 12, 2015, at 2:27 PM, Logan Chien

The builtins are for internal compiler use in the context of SjLj exception handling. Any other use, including any direct calls of the builtins in user code, are a bad idea with no guaranteed behaviour. That they're exposed at all is, again, for historical purposes. Don't use them. -Jim On Apr 27, 2011, at 3:45 PM, Akira Hatanaka wrote: > Okay. I understand builtin functions do not

On Apr 27, 2011, at 4:08 PM, Joerg Sonnenberger wrote: > On Wed, Apr 27, 2011 at 03:55:53PM -0700, Jim Grosbach wrote: >> The builtins are for internal compiler use in the context of SjLj >> exception handling. Any other use, including any direct calls of the >> builtins in user code, are a bad idea with no guaranteed behaviour. >> That they're exposed at all is,

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

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,

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

Logan, I need to make a correction of the post that preceded this one! I was wrong when I said this: > When I load the bitcode file for this module and then dump it just before it is JITted, the “uwtable” attribute has disappeared - is this prune-eh doing its work even though it’s not listed above in the list of function pass managers? The “uwtable” attribute does not disappear! I had

Hi zhangzw, > In llvm src the file llvm/lib/Transforms/IPO/LowerSetJmp.cpp, it > seems for sjlj-eh ? it's not for sjlj-eh. The problem with setjmp/longjmp is that they can jump from one part of a function to any other part, which means that the control-flow graph is pointless; this makes everything more complicated. So how to deal with this? LLVM does have constructs that allow

Okay. Are you saying that you shouldn't use __builtin functions in general in your program or just __builtin_setjmp/longjmp? Also, are there any warnings issued by either clang or llvm if they are used in your program? On Wed, Apr 27, 2011 at 3:55 PM, Jim Grosbach <grosbach at apple.com> wrote: > The builtins are for internal compiler use in the context of SjLj exception >

On Wed, Apr 27, 2011 at 03:55:53PM -0700, Jim Grosbach wrote: > The builtins are for internal compiler use in the context of SjLj > exception handling. Any other use, including any direct calls of the > builtins in user code, are a bad idea with no guaranteed behaviour. > That they're exposed at all is, again, for historical purposes. Don't use them. Why is longjmp converted

Hi Christian, Thanks for your explanation. I know your situation now. I would suggest you to check the optimization pass used by the JIT compiler, especially IPO/PruneEH.cpp. It will try to add nounwind attribute to functions which will result in the problem you have mentioned earlier. Alternatively, as a workaround, try to add uwtable (function attribute) to the functions that are generated

On Feb 26, 2009, at 12:57 AM, Duncan Sands wrote: > So LLVM turns setjmp/longjmp > into a bunch of invokes and unwinds, in order to generate correct code > while not having to teach all the optimizers about setjmp/longjmp. > Setjmp/longjmp eh is something different. Or virtually identical. Bout the only difference is the number of registers saved and the order of those registers.