similar to: [LLVMdev] More questions on exception handling

Nicolas Geoffray wrote: > Hi Talin, > > You're not using the llvm intrinsics for exception handling, so your > code won't work. Using _Unwind_RaiseException should be OK, but your > main function must at least use llvm.eh.exception, > llvm.eh.selector.i32/64 and probably __cxa_begin_catch and __cxa_end_catch. > Let me ask a follow-up question then - if the

Now that I've got exceptions working, I'm kind of wondering how to handle the case of nested "try" blocks. Say I have some code that looks like this: try { try { if (test) { // throw something } else { return; } } catch e:Except1 { } catch e:Except2 { } finally { } // more code... } catch e:Except3 { } finally {

Since llvm-gcc is a rather large code base, which I have never looked at (or even run), could you give me a starting point of where to look? One thing I'd be interested in knowing is whether the llvm.eh.exception() intrinsic can be called more than once in a landing pad. Say for example I have a nested try block, so that there are two landing pads, one for the inner try block, and one for

Hi Talin, > Since llvm-gcc is a rather large code base, which I have never looked at > (or even run), could you give me a starting point of where to look? I meant: compile some nested C++ with llvm-gcc to see what it does. Otherwise, look in llvm-convert.cpp, especially EmitLandingPads. > One thing I'd be interested in knowing is whether the > llvm.eh.exception() intrinsic can

Hi Talin, You're not using the llvm intrinsics for exception handling, so your code won't work. Using _Unwind_RaiseException should be OK, but your main function must at least use llvm.eh.exception, llvm.eh.selector.i32/64 and probably __cxa_begin_catch and __cxa_end_catch. Nicolas Talin wrote: > I've been struggling for several days, trying to get native exceptions > to

Talin wrote: > Nicolas Geoffray wrote: >> Hi Talin, >> >> You're not using the llvm intrinsics for exception handling, so your >> code won't work. Using _Unwind_RaiseException should be OK, but your >> main function must at least use llvm.eh.exception, >> llvm.eh.selector.i32/64 and probably __cxa_begin_catch and __cxa_end_catch. >> >

Duncan Sands wrote: > Hi Talin, > >> So I tried what you suggested, and it just gives me a bus error: >> >> %eh_select34 = call i32 (i8*, i8*, ...)* >> @llvm.eh.selector.i32 ( >> i8* %eh_ptr, >> i8* bitcast (i32 (i32, i32, i64, i8*, %UnwindContext*)* >> @__gcc_personality_v0 to i8*), >>

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 {

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

I've been struggling for several days, trying to get native exceptions to work in my code. I managed to boil down the IR to the simplest possible example that I can think of. If anyone on this list can tell me what changes I need to make to the following code to get it to work (i.e. return 0 instead of a bus error), it would make my life immensely better. ; ModuleID =

Hi Talin, if you change @throwSomething so that it prints a message if the _Unwind_RaiseException call returns, then you will see that it does in fact return. define internal fastcc void @throwSomething() { entry: %throwable = malloc %Throwable call fastcc void @Throwable.construct(%Throwable* %throwable) %unwindInfo = getelementptr %Throwable* %throwable, i32 0, i32 1

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

(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

Hi Talin, > Now that I've got exceptions working, I'm kind of wondering how to > handle the case of nested "try" blocks. Say I have some code that looks > like this: take a look at what llvm-gcc does for this kind of thing. Ciao, Duncan.

Hi Talin, > 1) I'm trying to figure out the relationship between the __cxa_throw > function, and the _Unwind_RaiseException function mentioned in the ABI doc. > My guess is that _Unwind_RaiseException is the language-neutral > implementation of stack unwinding, and __cxa_throw is the C++ exception > semantics that are implemented on top of it. If that is the case, should I >

Hi, I'm trying to compile an llvm program which makes use of exception handling. While compiling the code with llc i get the following assertion failure llc: FunctionLoweringInfo.cpp:163: void llvm::FunctionLoweringInfo::clear(): Assertion `CatchInfoFound.size() == CatchInfoLost.size() && "Not all catch info was assigned to a landing pad!"' failed. 0 llc

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, > This is similar to my first proposal. yup, I still consider your first proposal to have been basically sound. But it also suffers from a major problem, > which stopped that proposal dead in its tracks. Namely, you have information in > one place which needs to be shared in two different, but possibly disjoint, > places: the type, filters, and personality information. In

I have a couple of questions/concerns. The main one has to do with the opacity of exception types - in other words, will it still be true that the exception types are opaque identifiers, and are only interpreted by the personality function? Since my object representations are not C++-like, I am not using any of the cxa_* C++ library functions. Instead, my code calls the _Unwind functions

On Dec 2, 2010, at 2:21 AM, Duncan Sands wrote: > Hi Bill, > >> This is similar to my first proposal. > > yup, I still consider your first proposal to have been basically sound. > > But it also suffers from a major problem, >> which stopped that proposal dead in its tracks. Namely, you have information in >> one place which needs to be shared in two