similar to: [LLVMdev] the different semantics between dwarf-eh and sjlj-eh

Hi, >There's definitely more to it than the current intrinsics, which are >there to support dwarf. that's to say we need modify the llvm-gcc so the front end can generate the sjlj-style IR, >SJLJ exceptions rely on runtime library >functions to register and unregister call frames which require >unwinding, so we need to modify LLVM to handle generating those call my

Hi, >There's definitely more to it than the current intrinsics, which are >there to support dwarf. from the exist llvm-ir it seems there are some common info for sjlj-eh and dwarf-eh! are there possible use the exist llvm-ir to generate exception table for sjlj-eh ? zhangzw

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, I'm doing to make llvm backend support sjlj-eh! I have try to use the llvm-IR to generate the sjlj-eh code, but I'm totally despair ! my major problem is that llvm-ir , I mean exception instrinstics are enough for codegen the sjlj-eh code? May I need to modify the llvm-gcc ? or someone can give some advice about llvm-backend 's support sjlj-eh ? best regards

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 Thu, 20 Dec 2007, Duncan Sands wrote: > Hi Dale, >> If these were visible to end users I would not like exposing sjlj, an   >> implementation detail; however my understanding is that they aren't.   >> On the basis that they're intended for use by llvm geeks, I think   >> either of these is an improvement, except in the second case I think   >> the

Hi, many people suggest that if we want llvm to support sjlj-eh, we should modify the llvm-gcc to generate sjlj-style IR. yeah, I'm digging into the llvm-gcc now. there are some functions, at the llvm-gcc e.g TreeToLLVM::CreateExceptionValues() , BasicBlock *TreeToLLVM::getPostPad(unsigned RegionNo), void TreeToLLVM::EmitLandingPads(), void TreeToLLVM::EmitPostPads() , void

Hi Dale, > Chris would like to turn on -enable-eh rather than -enable-correct-eh- > support in the llvm testsuite for those targets that support it.  The   > following patch is intended to turn it on for x86 and ppc.  Anton,   > Duncan, are you OK with this? yes, though see below. > Chris would also like to discuss renaming the EH command line   > options, and I have to agree

Chris would like to turn on -enable-eh rather than -enable-correct-eh- support in the llvm testsuite for those targets that support it. The following patch is intended to turn it on for x86 and ppc. Anton, Duncan, are you OK with this? -------------- next part -------------- A non-text attachment was scrubbed... Name: mf.patch Type: application/octet-stream Size: 669 bytes Desc: not

On Feb 17, 2009, at 8:59 AM, Duncan Sands wrote: > Excellent! To handle dwarf eh, LLVM has an intrinsic to get hold of > an exception object (eh.exception) and an intrinsic for matching the > exception against a list of typeinfo objects (eh.selector). These > get morphed into calls to the gcc unwinder lib by the code generator. > Can sj/lj follow a similar scheme? Don't see

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

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 Tuesday 17 February 2009 18:04:43 Mike Stump wrote: > On Feb 17, 2009, at 8:59 AM, Duncan Sands wrote: > > Excellent! To handle dwarf eh, LLVM has an intrinsic to get hold of > > an exception object (eh.exception) and an intrinsic for matching the > > exception against a list of typeinfo objects (eh.selector). These > > get morphed into calls to the gcc unwinder lib

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

Folks, I'm sorry for getting at this again, but this will not be the last discussion on the topic, so let's just get to business. We're about to merge the last critical patch to make EHABI compatible with other EH mechanisms in LLVM (D3079), and that has unearthed a few issues with the function attributes. Logan's blog post [1] contains a proposal to split unwinding from

in llvm-backend did't support sjlj-exceptions handlying,but support dwarf-excceptions handlying, my question is: if i want change llvm-backend to support, how should i Do ? anyone can give some clue? bestregards 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!

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,

Hello, Samuel > While we have been discussing this, my partner discovered the source of where the sj/lj stuff is coming from.  Does this mean that the LLVM libraries we're using are broken? > > Type.cpp > ..\..\..\..\llvm\lib/libLLVMCore.a(Type.cpp.obj):Type.cpp.text+0x722): undefined reference to `__gxx_personality_sj0' >

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,