search for: _unwind_resume_or_rethrow

When I compile some code with the near-trunk clang++ I get this: ... tail call void @_Unwind_Resume_or_Rethrow(i8* %exn2) noreturn unreachable ... declare void @_Unwind_Resume_or_Rethrow(i8*) ... Same with __cxa_throw. 'noreturn' is missing on declarations. This seems to be a bug. Also can _Unwind_Resume_or_Rethrow actually return? When I run some simple exception code in JIT I see that this f...

On Jul 15, 2010, at 3:31 PM, Yuri wrote: > When I compile some code with the near-trunk clang++ I get this: Please send clang-specific questions to cfe-dev at cs.uiuc.edu. > ... > tail call void @_Unwind_Resume_or_Rethrow(i8* %exn2) noreturn > unreachable > ... > declare void @_Unwind_Resume_or_Rethrow(i8*) > ... > > Same with __cxa_throw. 'noreturn' is missing on declarations. > This seems to be a bug. It really shouldn't make a difference; the call site should take priority an...

On Jul 15, 2010, at 5:51 PM, John McCall wrote: >> Also can _Unwind_Resume_or_Rethrow actually return? When I run some >> simple exception code in JIT I see that this function actually returns >> and then SEGVs. > > I have no idea what system you're on, but _Unwind_Resume_or_Rethrow really > isn't allowed to return. > It's not. But if the unwi...

On 07/15/2010 18:30, Bill Wendling wrote: > It's not. But if the unwind library can't handle something, then the _Unwind_Resume_or_Rethrow could fall out of the function (it would assert in debug mode). Darwin's implementation of _URoR in libunwind does this. > > Isn't unwind library supposed to call terminate() every time it can't handle something? Yuri

On Jul 15, 2010, at 6:52 PM, Yuri wrote: > On 07/15/2010 18:30, Bill Wendling wrote: >> It's not. But if the unwind library can't handle something, then the _Unwind_Resume_or_Rethrow could fall out of the function (it would assert in debug mode). Darwin's implementation of _URoR in libunwind does this. >> > Isn't unwind library supposed to call terminate() every time it can't handle something? > I don't see anything specifying that it should call t...

...d the inliner so it does its best to find the eh.selector for an > invoke, and propagates the information onto the things it inlines, would clang > make use of it (i.e. output cleanups rather than turning them into catch-alls)? We'd still have problems — cleanups would have to chain with _Unwind_Resume_or_Rethrow, because most of the platforms we support rely on correct compiler use of _Unwind_Resume — but it might be worthwhile. John.

...ot;_Unwind_SjLj_Resume" > - : > "_Unwind_Resume"); > + llvm_unwind_resume_libfunc = > + llvm_init_one_libfunc(USING_SJLJ_EXCEPTIONS ? > + "_Unwind_SjLj_Resume" : > "_Unwind_Resume_or_Rethrow"); > /* LLVM local end */ > } Seems unlikely, but I'll try it.

Hi John, On 07/12/10 01:01, John McCall wrote: > On Dec 6, 2010, at 1:58 PM, Duncan Sands wrote: >> The poor interaction between exception handling and inlining in LLVM is one of >> the main motivations for the new exception handling models proposed recently. >> Here I give my analysis of the origin of the problem in the hope of clarifying >> the situation. > >

On 01/13/2010 02:07 AM, Duncan Sands wrote: > Hi Dustin, the code generators do not support unwind, only the > interpreter does. Ah, the secret is not to even try to frob the gnorts. Manual unwinding, here I come. :-( I was going to say the interpreter doesn't either, but then I recalled it JITs when it can. I don't know how to call into libc from the interpreter to test that.

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

.... It would need to rewrite calls to _Unwind_Resume on cleanup-only paths if the enclosing invoke has a handler. The EH machinery does not expect a landing pad which claims to handle an exception to just call _Unwind_Resume before handling it; that's why we currently have to use hacks to call _Unwind_Resume_or_Rethrow instead. Also, some platforms provide an alternative to _Unwind_Resume that doesn't require the compiler to pass the exception pointer; we'd like to be able to use those. The 'dispatch' instruction simplifies this by presenting an obvious place to rewrite (which doesn't actua...

...this log: TRACE num=20 TRACE num=22 TRACE num=27 TRACE num=29 TRACE num=31 TRACE num=33 TRACE num=58 TRACE num=60 TRACE num=62 TRACE num=64 TRACE num=66 TRACE num=70 TRACE num=72 Stack dump: 0. Program arguments: lli -jit-enable-eh my.bc Bus error: 10 The line: TRACE num=72 is the next after _Unwind_Resume_or_Rethrow that is marked noreturn. Runing the same code as binary also bahaves in a similar way: 'llvm-as my.ll && llc -o my.s my.bc && as -o my.o my.s && g++ -o my my.o && my': TRACE num=20 TRACE num=22 TRACE num=27 TRACE num=29 TRACE num=31 TRACE num=33 TRACE num=...

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

...ny > specific > exception format (EH tables, DWARF, etc.), > > 3. hold off the generation of metadata as late as possible during > code > generation, and > > 4. use the `unwind' instruction to throw or rethrow instead of a > call to > `_Unwind_Resume_or_Rethrow'. > > To achieve these goals, we'll need these new llvm instructions and > intrinsics. > > > New Intrinsics > -------------- > > llvm.eh.filter: > > First the intrinsics. The first one is similar to Duncan's idea of a > filter > intrinsic. In f...

...Handling" document) without being tied to any specific exception format (EH tables, DWARF, etc.), 3. hold off the generation of metadata as late as possible during code generation, and 4. use the `unwind' instruction to throw or rethrow instead of a call to `_Unwind_Resume_or_Rethrow'. To achieve these goals, we'll need these new llvm instructions and intrinsics. New Intrinsics -------------- llvm.eh.filter: First the intrinsics. The first one is similar to Duncan's idea of a filter intrinsic. In fact, it's named the same. ;-) void llvm.eh.fil...

...Users/clang/libunwind/src/UnwindLevel1-gcc-ext.c:19: C:/Users/clang/libunwind/src/config.h:26:11: warning: keyword is hidden by macro definition [-Wkeyword-macro] #define static_assert(__b, __m) \ ^ C:/Users/clang/libunwind/src/UnwindLevel1-gcc-ext.c:33:1: warning: redeclaration of '_Unwind_Resume_or_Rethrow' should not add 'dllexport' attribute [-Wdll-attribute-on-redeclaration] _Unwind_Resume_or_Rethrow(_Unwind_Exception *exception_object) { ^ C:/Users/clang/libunwind/include\unwind.h:299:5: note: previous declaration is here _Unwind_Resume_or_Rethrow(_Unwind_Exception *exception_obje...

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

.... It would need to rewrite calls to _Unwind_Resume on cleanup-only paths if the enclosing invoke has a handler. The EH machinery does not expect a landing pad which claims to handle an exception to just call _Unwind_Resume before handling it; that's why we currently have to use hacks to call _Unwind_Resume_or_Rethrow instead. Nope, because when inlining through an invoke the inliner appends the invoke's catch info to everything it inlines. This is the key point that makes the cleanup problem go away. As an optimization it is possible to convert an invoke of _Unwind_Resume into a branch, but I think it wo...

...; preds = %normal44.i79.i.i %153 = call i8* @llvm.eh.exception() ; <i8*> [#uses=2] %154 = call i32 (i8*, i8*, ...)* @llvm.eh.selector(i8* %153, i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*), i8* null) ; <i32> [#uses=0] invoke void @_Unwind_Resume_or_Rethrow(i8* %153) to label %.noexc83.i.i unwind label %lpad51.preheader.i.i lpad51.preheader.i.i: ; preds = %Unwind.i74.i.i, %Unwind.i61.i.i %155 = icmp eq i8* %58, null ; <i1> [#uses=1] %156 = bitcast i8* %61 to %File* ; &l...

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