similar to: [LLVMdev] sjlj-exceptions handlying

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

On Tuesday 17 February 2009 02:21:55 zhengjian zhang wrote: > 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? It's hard to say - I'm not sure anyone here knows how gcc handles sj/lj style exceptions, or has a good

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

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

> > I'm not sure anyone here knows how gcc handles sj/lj style exceptions, > > Or, reworded slightly, some people here wrote it. :-) 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

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, >> 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 ? >No. There should be support from llvm-gcc. sjlj eh and dwarf eh have >different semantics different semantics ? ! I think llvm-gcc generate the IR should not include the exception

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

On Feb 17, 2009, at 12:50 AM, Duncan Sands wrote: > I'm not sure anyone here knows how gcc handles sj/lj style exceptions, Or, reworded slightly, some people here wrote it. :-)

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!

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

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

On Dec 20, 2007, at 9:47 AM, Chris Lattner wrote: > 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

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

here are the cpp file: $ cat -n eh1.catch.cpp 1 #include <iostream> 2 3 int main() 4 { 5 try { 6 throw 78; 7 } 8 catch (int){ 9 10 std::cout << "at catch\n"; 11 12 } 13 } LLVM-IR: $ llvm-g++ -S -emit-llvm eh1.catch.cpp -o eh1.catch.ll ... 46 define i32 @main() {

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,