similar to: [LLVMdev] setjmp/longjmp exception handling: how?

I strongly advise you not to use SjLj exception handling. Use zero-cost-exceptions via DWARF instead. If you really want to pursue sjlj anyway, look at the ARM backend. It uses them for darwin targets. -Jim On Jul 12, 2013, at 9:09 AM, Nicolas Ojeda Bar <N.Ojeda.Bar at dpmms.cam.ac.uk> wrote: > Dear list, > > I want to add SJLJ exception handling to my frontend. Unfortunately,

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'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

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

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

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 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,

Jim Grosbach <grosbach at apple.com> writes: > I strongly advise you not to use SjLj exception handling. Use > zero-cost-exceptions via DWARF instead. On Windows, DWARF EH doesn't work when there are stack frames not compiled with DWARF EH support (i.e. OS code that invokes user-provided callbacks, a common practice on Windows.)

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

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

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 >

Thanks to the hard work of Bill Wendling (wendling at isanbard.org), LLVM now translates setjmp/longjmp calls into the LLVM "exception handling" instructions invoke & unwind. This means that all of the LLVM optimizers are now aware of the extra control flow edges made possible by setjmp & longjmp, so data flow analyses won't make incorrect transformations. A variety of

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:

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

The linker is going off in the weeds trying to parse the dwarf unwind info. The CIE has: Leh_frame_common_begin0: .long 0 ## CIE Identifier Tag .byte 1 ## DW_CIE_VERSION .asciz "zLR" ## CIE Augmentation .byte 1 ## CIE Code Alignment Factor .byte 120 ## CIE Data Alignment

This is an interesting problem. The GC code is being converted into 'invokes' instead of calls: define i32 @main() gc "shadow-stack" { entry: %gc_frame = alloca %gc_stackentry.main %gc_currhead = load %gc_stackentry** @llvm_gc_root_chain %gc_frame.map = getelementptr %gc_stackentry.main* %gc_frame, i32 0, i32 0, i32 1 store %gc_map* getelementptr inbounds (%gc_map.0*

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 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 In llvm src the file llvm/lib/Transforms/IPO/LowerSetJmp.cpp, it seems for sjlj-eh ? but this pass has no effect about c++ sjlj-eh. this pass is for future extend? zhangzw

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