similar to: [LLVMdev] catch all

2009/5/12 Duncan Sands <baldrick at free.fr>: >>  that's  right !  catch(all) has extra null arg, >> >> eh_select = tail call i32 (i8*, i8*, ...)* >> @llvm.eh.selector.i32(i8* %eh_ptr, i8* bitcast (i32 (...)* >> @__gxx_personality_v0 to i8*), i8* null)        ; <i32> [#uses=0] >> >> I have doubt  that  : >> the llvm-IR like above are

> that's right ! catch(all) has extra null arg, > > eh_select = tail call i32 (i8*, i8*, ...)* > @llvm.eh.selector.i32(i8* %eh_ptr, i8* bitcast (i32 (...)* > @__gxx_personality_v0 to i8*), i8* null) ; <i32> [#uses=0] > > I have doubt that : > the llvm-IR like above are all translated from catch(all) statement . I'm not sure what you are

Hi, catch_all.cpp: 1 int main() 2 { 3 try { 4 throw 34; 5 } 6 catch (...) {} 7 } llvm-gcc -O3 -S -emit-llvm catch_all.cpp -o catch_all.ll: 1 ; ModuleID = 'catch_all.cpp' 2 target datalayout =

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() {

On Dec 10, 2007, at 11:38 AM, Duncan Sands wrote: >>> ... If you force a "cleanup" by changing the selector call to: >>> %eh_select8.i = tail call i32 (i8*, i8*, ...)* >>> @llvm.eh.selector.i32( i8* %eh_ptr.i, i8* bitcast (i32 (...)* >>> @__gxx_personality_v0 to i8*), i32 0) >>> then it doesn't work either: the unwinder observes that

Hi Dale, > No, I don't want to change the semantics of invoke, at least I don't > think so. > When inlining, I want the inlined throw to reach cleanup code as it > does. > But I want the Unwind_Resume call that ends the cleanup code to be > replaced with a control transfer to the handler (or cleanup) in the > calling > function, i.e. the inliner needs to know

Hi Dale, > #include <cstdio> > class A { > public: > A() {} > ~A() {} > }; > void f() { > A a; > throw 5.0; > } > main() { > try { > f(); > } catch(...) { printf("caught\n"); } > } this example indeed shows the problem. Let me explain to see if we agree on what the problem is. Suppose we don't artificially

On Dec 9, 2007, at 1:01 PM, Duncan Sands wrote: > Hi Dale, > >> #include <cstdio> >> class A { >> public: >> A() {} >> ~A() {} >> }; >> void f() { >> A a; >> throw 5.0; >> } >> main() { >> try { >> f(); >> } catch(...) { printf("caught\n"); } >> } > > this example

(Mail system seems to have eaten this, sorry if it's a repeat) On Dec 8, 2007, at 12:48 AM, Duncan Sands wrote: > Hi Dale, > >> - Why was C++ claiming that every selector has a catch-all handler? > > this is easy: because the semantics of invoke require it. Yes, > really. > If unwinding reaches an invoke then control is required to jump to the > unwind basic

This is a revision of the second exception handling proposal I sent out. You can see it here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036484.html After much discussion, there are some changes to the proposal – some significant and some minor. One major point, this proposal does not address the issue of catching an exception thrown from a non-invoke instruction. However if done

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

Duncan Sands wrote: > I would just use the C personality function, __gcc_personality_v0, if > I were you. It should know where to jump to because the code generators > record the invoke unwind target in the dwarf exception handling info in > the object file. > > So I tried what you suggested, and it just gives me a bus error: define i32 @main(i32, i8**) nounwind {

I've been looking into a new way to implement exception handling in LLVM. The current model has many disadvantages, in my opinion. I try to address them with this proposal. I also try to make exception handling much more understandable to the normal human reader. :-) Any new proposal will need to address all present and future languages' exception handling methodologies. I

Hi Bill, there are a couple of things I didn't understand about your proposal, for example how it interacts with inlining, whether it is feasible to do the "turn invoke-of-Unwind_Resume into a branch" optimization and also whether in "resumedest" you still plan to use _Unwind_Resume to continue unwinding up the stack. Could you please show what the LLVM IR would look like

Hi Dale, > > ... Suppose we don't artificially add catch-alls to > > selectors. Then > > the above example compiles to: > > ... > I wasn't advocating this; agree it is wrong. it's maybe not as wrong as it seems since having an empty selector is equivalent to having a cleanup (IIRC) :) > > ... If you force a "cleanup" by changing the

On Dec 1, 2010, at 1:37 PM, Duncan Sands wrote: > Executive summary > ----------------- > > Remove the personality and list of catches out of eh.selector and stick them > directly on invoke instructions. > > The invoke instruction > ---------------------- > > The invoke instruction is modified by adding extra catch info to it: > > <result> = invoke

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 Evan, >>Is it possible to implement it without using MachineModuleInfo? but llvm-2.5 didn't , if implement it without using MachineModuleInfo, so I should create another ADT, but that is mostly same to MachineModuleInfo, that's repeat work! or less cost for me ! >> It's being removed. if so, what's the replacement of the MachineModuleInfo ? zhangzw

Hi Duncan, >>are you trying to get the name "@_ZTIi" or "@__cxa_throw"? yes! i want get the name @_ZTi or @__cxa_throw, the latter @__cxa_throw i can get it throw value->getName(), but the @_ZTi it did n't has name! zhangzw thanks 2009/3/26 Duncan Sands <baldrick at free.fr>: > Hi zhangzw, > >> invoke void @__cxa_throw(i8* %7, i8*

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