similar to: [LLVMdev] Exception Personality Function

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

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

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

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 =

Well, after much labor, I think I have managed to create a personality function that works. But I must say it is frightening how complicated all of this stuff is. -- Talin Duncan Sands wrote: > 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

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

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

Hi! I build VMKit and run some programs successfully. But when using java.util.concurrent.locks.ReentrantLock and java.util.concurrent.locks.Condition, I catch a Throwable : java.lang.UnsatisfiedLinkError: sun.misc.Unsafe.unpark(Ljava/lang/Object;)V after using the function : void java.util.concurrent.locks.Condition.await() My test program is as follows: *import* *java.lang*.*;

Is Phabricator down again? I'm starting to see the following: [Rendering Exception] Multiple exceptions during processing and rendering. - AphrontQueryConnectionException: Attempt to connect to phabricator at localhost failed with error #1040: Too many connections. - InvalidArgumentException: Argument 1 passed to AphrontView::setUser() must be an instance of PhabricatorUser, null

Yep, sorry, we ran out of space on the instance's database volume. I'll update this once we're back up. On Thu, Jul 11, 2013 at 9:07 PM, Justin Holewinski < justin.holewinski at gmail.com> wrote: > Is Phabricator down again? I'm starting to see the following: > > [Rendering Exception] Multiple exceptions during processing and rendering. > -

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

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

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

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

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 =

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 {

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

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

rsync and ajug lists, been pulling my hair out on this one. i have some java code which uses the Process object to spawn an rsync connection in --daemon mode. the exact same command executes properly when run from outside java (i.e .on the command line) on osx. it also executes correctly from within java on linux using a similar jdk (sun 1.4.1 vs sun 1.4.2 for osx) here is example code: