search for: __cxa_begin_catch

...ding John explicitly… Thanks, Reid. Andy, I understand why Windows EH needs custom lowering here, and using intrinsics seems like a fine approach, but I don’t understand why you’re proposing changing the Itanium code generation pattern. There’s no reason for backends to have special knowledge of __cxa_begin_catch, and it’s actually not a good idea for them to do so, because that’s unnecessarily language-specific and personality-specific; even today, Objective-C EH implementations do use separate personality and different begin/end catch functions. If we ever decide to support a libUnwind personality functi...

...n of C++ EH support on Windows, but I thought I should float it again with a subject that would be less likely to be missed by people who don't have a direct interest in Windows support. I would like to introduce two new intrinsics, llvm.eh.begincatch and llvm.eh.endcatch, to take the place of __cxa_begin_catch and __cxa_end_catch in the IR prior to the CodeGen prepare passes. For the majority of platforms the intrinsics will be directly mapped to the existing function calls during one of the CodeGen prepare passes. For MSVC-environment Windows targets there is no equivalent function call to be made, bu...

...Windows we look at the personality function and try to figure out what kind of preparation and tables it wants. > > It seems reasonable then that we could continue along the lines of classifying some personalities as "Itanium" personalities and lowering these new intrinsics out to __cxa_begin_catch / end_catch. You are over-estimating how similar the code-generation patterns are going to be here. The information flow from the unwind mechanism to the catch clause can differ quite wildly. Go look at what happens in the different ABIs when an exception with a non-trivial copy constructor is c...

...%eh_ptr = tail call i8* @llvm.eh.exception() ; <i8*> [#uses=2] 21 %eh_select = tail call i32 (i8*, i8*, ...)* @llvm.eh.selector.i32(i8* %eh_ptr, i8* bitcast (i32 (...)* @__gxx_personality_sj0 to i8*)) ; <i32> [#uses=0] 22 %2 = tail call i8* @__cxa_begin_catch(i8* %eh_ptr) nounwind ; <i8*> [#uses=0] 23 tail call void @__cxa_end_catch() 24 ret i32 0 25 } 26 27 declare i8* @__cxa_allocate_exception(i32) nounwind 28 29 declare void @__cxa_throw(i8*, i8*, void (i8*)*) noreturn 30 31...

...han Intrinsics. 3.b) I have been thinking about other possible control-flow-graph invariants of the landingpad blocks and the catch blocks that they lead to, but so far have not come up with very muchl, I wonder if anyone else is thinking about this...?... for example cleanups come before __cxa_begin_catch, but it isn't clear what is a cleanup and what isn't other than what comes before a __cxa_begin_catch and what comes after ? however, using that as the definition of cleanup, for C++ any InvokeInst that is so identified as cleanup then its only operand has to be terminate (I think...

> Please read and let me know your opinions! This definitely seems like an improvement on the current situation. >            .---------. >            | convoke | >            `---------' >                 | >                 v >     .-----------------------. >     |                       | >     v                       | >  %normal  

...%"<L2>", label %"<bb 5>" "<bb 5>": ; preds = %"<L1>" unwind "<L2>": ; preds = %"<L1>" %D.2112_2 = tail call i8* @__cxa_begin_catch(i8* %exc_ptr) nounwind tail call void @__cxa_end_catch() nounwind ret void return: ; preds = %entry ret void } define void @_Z1cv() { entry: invoke void @_Z1bv() to label %return unwind label %"<L1>" personality @__...

...declare i32 @llvm.eh.selector(i8*, i8*, ...) nounwind declare void @llvm.eh.resume(i8*, i32) declare void @_ZSt9terminatev() declare i32 @memcmp(i8*, i8*, i64) declare i64 @llvm.expect.i64(i64, i64) nounwind readnone declare void @_ZSt19__throw_logic_errorPKc(i8*) noreturn declare i8* @__cxa_begin_catch(i8*) declare void @__cxa_rethrow() declare void @__cxa_end_catch() declare void @__cxa_call_unexpected(i8*) declare void @_ZdlPv(i8*) nounwind declare void @_ZSt20__throw_length_errorPKc(i8*) noreturn declare void @_ZSt17__throw_bad_allocv() noreturn declare noalias i8* @_Znwm(i64)...

...r1 = private unnamed_addr constant [18 x i8] c"caught double %g\0A\00", align 1 > > define i32 @_Z3foov() uwtable optsize ssp { > entry: > invoke void @_Z3barv() optsize > to label %try.cont unwind label %lpad > > invoke.cont7: > %tmp0 = tail call i8* @__cxa_begin_catch(i8* %exn) nounwind > %tmp1 = bitcast i8* %tmp0 to i32* > %exn.scalar = load i32* %tmp1, align 4 > %call = tail call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([19 x i8]* @.str, i64 0, i64 0), > i32 %exn.scalar) optsize > tail ca...

On Dec 1, 2010, at 1:37 PM, Duncan Sands wrote: > Inlining > -------- > > Many a plausible seeming exception handling scheme has fallen by the way-side > because it interacts poorly with inlining. > > Here is how inlining would work with this scheme. It's pretty close to how > it works right now. Suppose you have > > invoke void @foo() > to

...M IR? (You could just specify that the llvm.eh.exception call has > to be at the start of a landing pad, but I think that is too prone to > being broken by optimisation passes.) > Well, it's not entirely magical. :-) It gets the exception object by calling __cxa_get_exception_ptr and __cxa_begin_catch (though both calls can be combined into __cxa_begin_catch, which is what we do). It's feasible to simply generate the llvm.eh.exception at the start of the catch block code and have that convert into the call to __cxa_begin_catch. My only concern is that we need to make sure that all...

...ER=lld >> CLANG_DEFAULT_RTLIB=compiler-rt >> LLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-musl >> LLVM_TARGET_ARCH=x86_64 >> LLVM_TARGETS_TO_BUILD=X86 >> >> When linking libc++.so there are a lot of undefined references to __cxa_allocate_exception, __cxa_begin_catch, __cxa_end_catch, __cxa_free_exception, __cxa_guard_abort, __cxa_guard_acquire, __cxa_guard_release, __cxa_pure_virtual, __cxa_rethrow, __cxa_throw, __gxx_personality_v0, _Unwind_Resume, vtable for __cxxabiv1::__class_type_info, vtable for __cxxabiv1::__si_class_type_info, vtable for __cxxabiv1::__...

....hidden __clang_call_terminate > .weak __clang_call_terminate > .align 16, 0x90 > .type __clang_call_terminate, at function > __clang_call_terminate: # @__clang_call_terminate > # BB#0: > pushq %rax > callq __cxa_begin_catch > callq _ZSt9terminatev > .Ltmp9: > .size __clang_call_terminate, .Ltmp9-__clang_call_terminate > > - Stephan > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/...

...t; 3.b) I have been thinking about other possible control-flow-graph invariants of the > landingpad blocks and the catch blocks that they lead to, but so far have not come up > with very muchl, I wonder if anyone else is thinking about this...?... > > for example cleanups come before __cxa_begin_catch, but it isn't clear what is a cleanup > and what isn't other than what comes before a __cxa_begin_catch and what comes after ? > As John mentioned, the EH representation is independent (and indeed ignorant) of things like this. The front-ends need to generate the correct code. >...

...integer %d\0A\00", align 1 @.str1 = private unnamed_addr constant [18 x i8] c"caught double %g\0A\00", align 1 define i32 @_Z3foov() uwtable optsize ssp { entry: invoke void @_Z3barv() optsize to label %try.cont unwind label %lpad invoke.cont7: %tmp0 = tail call i8* @__cxa_begin_catch(i8* %exn) nounwind %tmp1 = bitcast i8* %tmp0 to i32* %exn.scalar = load i32* %tmp1, align 4 %call = tail call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([19 x i8]* @.str, i64 0, i64 0), i32 %exn.scalar) optsize tail call void @__cxa_end_c...

..._DEFAULT_CXX_STDLIB=libc++ CLANG_DEFAULT_LINKER=lld CLANG_DEFAULT_RTLIB=compiler-rt LLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-musl LLVM_TARGET_ARCH=x86_64 LLVM_TARGETS_TO_BUILD=X86 When linking libc++.so there are a lot of undefined references to __cxa_allocate_exception, __cxa_begin_catch, __cxa_end_catch, __cxa_free_exception, __cxa_guard_abort, __cxa_guard_acquire, __cxa_guard_release, __cxa_pure_virtual, __cxa_rethrow, __cxa_throw, __gxx_personality_v0, _Unwind_Resume, vtable for __cxxabiv1::__class_type_info, vtable for __cxxabiv1::__si_class_type_info, vtable for __cxxabiv1::__...

...(i8*, i8*, ...) nounwind > declare void @llvm.eh.resume(i8*, i32) > declare void @_ZSt9terminatev() > declare i32 @memcmp(i8*, i8*, i64) > declare i64 @llvm.expect.i64(i64, i64) nounwind readnone > declare void @_ZSt19__throw_logic_errorPKc(i8*) noreturn > declare i8* @__cxa_begin_catch(i8*) > declare void @__cxa_rethrow() > declare void @__cxa_end_catch() > declare void @__cxa_call_unexpected(i8*) > declare void @_ZdlPv(i8*) nounwind > declare void @_ZSt20__throw_length_errorPKc(i8*) noreturn > declare void @_ZSt17__throw_bad_allocv() noreturn >...

...t; 3.b) I have been thinking about other possible control-flow-graph invariants of the > landingpad blocks and the catch blocks that they lead to, but so far have not come up > with very muchl, I wonder if anyone else is thinking about this...?... > > for example cleanups come before __cxa_begin_catch, but it isn't clear what is a cleanup > and what isn't other than what comes before a __cxa_begin_catch and what comes after ? The EH representation is independent of things like this. > however, using that as the definition of cleanup, for C++ any InvokeInst that is so > identif...

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.

...32 @memcmp(i8*, i8*, i64) > > In libc (libc.so) which should be pulled in by libstdc++. > > > declare i64 @llvm.expect.i64(i64, i64) nounwind readnone > > LLVM intrinsic. > > > declare void @_ZSt19__throw_logic_errorPKc(i8*) noreturn > > declare i8* @__cxa_begin_catch(i8*) > > declare void @__cxa_rethrow() > > declare void @__cxa_end_catch() > > declare void @__cxa_call_unexpected(i8*) > > declare void @_ZdlPv(i8*) nounwind > > declare void @_ZSt20__throw_length_errorPKc(i8*) noreturn > > declare void @_ZSt17...