search for: __gcc_personality_v0

Hello, Why does LLVM use __gcc_personality_v0 instead of __gxx_personality_v0 function when it lowers llvm.gcroot intrinsic? For my try-catch codegen I use last one (so does clang) and it conflicts with __gcc_personality_v0 produced by LLVM? I know how to solve it with my own GC plug-in, just wondering. And what's the difference betwee...

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**) nounwin...

...at there are no Exception Tables generated any more such >>> as the one below: you need to add a landingpad instruction to the start of each basic block with is that unwind target of an invoke. Since you only seem to be interested in cleanups, something like this should do: declare i32 @__gcc_personality_v0(i32, i64, i8*, i8*) ... invoke void @foo() to label %cont unwind label %lp lp: %tmp = landingpad { i8*, i32 } personality i32 (i32, i64, i8*, i8*)* @__gcc_personality_v0 cleanup ... Ciao, Duncan. >> >> got some example bitcode for which you see this (or, rather, don't...

...> except that if my personality function doesn't do anything, then the > landing pad is skipped entirely, and control resumes at the non-unwind > target of the original invoke instruction, as if no exception had been > thrown at all. 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. Ciao, Duncan. >> Nicolas >> >> >> Talin wrote: >> >>> I've been struggling for sever...

On 09/02/2011 05:58 PM, Duncan Sands wrote: > Hi Yiannis, > >> I have been using llvm 2.8 (i know ancient history!) for a backend that i was >> implementing. I have been trying to port my patches to latest llvm (svn build) >> lately but i have one problem as far as the Exception Handling mechanism is >> concerned. It seems that there are no Exception Tables generated

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

...ied 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*), >> i32 1) >> > > try changing i32 1 to i32 0. Also, feel free to send me something > I can compile, and I will try it here. > File attached. I compile and run with: llvm-as -f ExTest.ll && llc -f ExTest.bc && gcc -g -o ExTe...

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*), > i32 1) try changing i32 1 to i32 0. Also, feel free to send me something I can compile, and I will try it here. Ciao, Duncan.

...ch-clause the lifetimes of these hard registers ostensibly starts at the LandingpadInst, but for purposes of PHI lowering and Register Allocation they _must_ actually start at the beginning of the BasicBlock -- since that is where control flow will return to from the _Unwind_RaiseException / __gcc_personality_v0 calls, and it is the _Unwind_ and _personality_ functions that physically set those hard registers, not the "LandingpadInst". Somehow PHI lowering and register allocation need to be prohibited from using those hard registers for spill code at the beginning of a "landing pad bloc...

...correct. Just tested to make sure. Invoking _Unwind_RaiseException(...) directly still sets up personality function (and calls it during exception search/cleanup), in corresponding frame headers for frame containing invoke. Well ... ok, at least in a JIT execution environment. :-) I thought maybe __gcc_personality_v0(...) was being called instead. However, I also just tested with a garbage exception (offset exception ptr by 1000), being passed in to _Unwind_RaiseException(...), with the result that the personality function was still called with the cleanup landing pad correctly found. This personality ignore...

..."cleanup" which apparently doesn't count. (To force cleanups to be run in this situation you have to call the gcc forced unwind routine after calling Unwind_RaiseException). Of course you would probably like to have your handler be considered a real handler. Sadly you can't use __gcc_personality_v0 for this: it only handles cleanups, and if it sees something else (eg: if you specify a catch-all in the selector) then it tells the unwinder to keep on unwinding, which is not what you want. So indeed you either need to write your own personality routine or use a more powerful personality functio...

...; the lifetimes of these hard registers ostensibly starts at the LandingpadInst, > but for purposes of PHI lowering and Register Allocation they _must_ actually > start at the beginning of the BasicBlock -- since that is where control flow will > return to from the _Unwind_RaiseException / __gcc_personality_v0 calls, > and it is the _Unwind_ and _personality_ functions that physically set those > hard registers, not the "LandingpadInst". > > Somehow PHI lowering and register allocation need to be prohibited from > using those hard registers for spill code at the beginning of a &...

...sibly starts at the >> LandingpadInst, >> but for purposes of PHI lowering and Register Allocation they >> _must_ actually >> start at the beginning of the BasicBlock -- since that is where >> control flow will >> return to from the _Unwind_RaiseException / __gcc_personality_v0 >> calls, >> and it is the _Unwind_ and _personality_ functions that physically >> set those >> hard registers, not the "LandingpadInst". >> >> Somehow PHI lowering and register allocation need to be prohibited >> from >> using those h...

...Found PythonInterp: /usr/bin/python3.5 (found version "3.5.2") -- Constructing LLVMBuild project information -- Found Git: /usr/bin/git (found version "2.7.4") -- Linker detection: GNU ld -- Targeting X86 -- Looking for fopen in c -- Looking for fopen in c - found -- Looking for __gcc_personality_v0 in gcc_s -- Looking for __gcc_personality_v0 in gcc_s - found -- Performing Test LIBCXXABI_HAS_NODEFAULTLIBS_FLAG -- Performing Test LIBCXXABI_HAS_NODEFAULTLIBS_FLAG - Success -- Performing Test LIBCXXABI_HAS_NOSTDINCXX_FLAG -- Performing Test LIBCXXABI_HAS_NOSTDINCXX_FLAG - Success -- Looking for...

Hi Garrison, > %7 = invoke i8* (...)* bitcast (i32 (%struct._Unwind_Exception*)* > @_Unwind_RaiseException to i8* (...)*)(i64* %6) > to label %8 unwind label %.finally_pad ; <i8*> [#uses=0] > > I am not sure this is going to work, at least from the way I've played > with the system. > In my examples the _Unwind_RaiseException(...) is called from a

...libunwind resides in a subdirectory of libc++abi. There seems to be some desire from multiple parties that it be moved into compiler-rt or a separate repository. Currently, when using compiler-rt as the runtime library (on Linux) we use libgcc_s and libgcc_eh as the builtins serve as the home for __gcc_personality_v0. This error handling personality requires unwinding support, which these libraries provide. This dependency can be fulfilled with libunwind. The concern that has been raised with adjusting this dependency has been that libunwind is not guaranteed to be built and installed unless libc++abi is pre...

...ler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Using Release VC++ CRT: MD -- Looking for os_signpost_interval_begin -- Looking for os_signpost_interval_begin - not found -- Looking for fopen in c -- Looking for fopen in c - not found -- Looking for __gcc_personality_v0 in gcc_s -- Looking for __gcc_personality_v0 in gcc_s - not found -- Looking for __absvdi2 in gcc -- Looking for __absvdi2 in gcc - not found -- Performing Test LIBUNWIND_HAS_NODEFAULTLIBS_FLAG -- Performing Test LIBUNWIND_HAS_NODEFAULTLIBS_FLAG - Failed -- Performing Test LIBUNWIND_HAS_NOSTDINCXX_...

...hich > works in the current version of LLVM (even if it's platform specific)? You currently have to use a gcc library routine. At some point cxa_throw and the analogous routines for other languages end up calling _Unwind_RaiseException. You may want to use that along with the C personality __gcc_personality_v0. Ciao, Duncan.

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. > > I see. OK, I will try that. I was hoping to be able to test the exception type in the personality funct...

...ch apparently doesn't count. > (To force cleanups to be run in this situation you have to call the gcc > forced unwind routine after calling Unwind_RaiseException). > > Of course you would probably like to have your handler be considered a > real handler. Sadly you can't use __gcc_personality_v0 for this: it > only handles cleanups, and if it sees something else (eg: if you specify > a catch-all in the selector) then it tells the unwinder to keep on > unwinding, which is not what you want. > > So indeed you either need to write your own personality routine or use > a more...