similar to: [LLVMdev] Clobbering llvm.eh.selector return

Hi Garrison, > I accidentally ran into a JIT scenario where a call instruction, executing an external non-generated C function, > executed between a llvm.eh.exception and a llvm.eh.selector instruction would clobber the register > (register index __builtin_eh_return_data_regno(1)), used by the return value of llvm.eh.selector. The behavior > of the call depends on the function

Funny I remember that code (DwarfEHPrepare), wondering at the time why it was doing this. Thanks for your response, as I can now stop trying figure out how I am introducing this error, and more importantly now will be able to go back to DwarfEHPrepare, and understand it better knowing one of its purposes. However the result of my tests indicates that the underlying register used by the

Hi Garrison, > I hacked together a version of DwarfEHPrepare.cpp which tries to deal with the ordering of llvm.eh.exception and llvm.eh.selector. > The hacked is contained within the attached patch. it looks like you tried to copy the code for eh.exception. There are two problems with this: (1) the eh.exception code really needs to be rewritten to make use of the new SSAUpdator (then all

Hi Duncan, I hacked together a version of DwarfEHPrepare.cpp which tries to deal with the ordering of llvm.eh.exception and llvm.eh.selector. The hacked is contained within the attached patch. Motivation: I recently created a decent amount of hand coded IR (via the llvm C++ API). In order to help me runtime debug the code, I created automatic constructors which would trace entries into the

Here is an alternative proposal to Bill's. It is closer to what we already have (which can be seen as a good or a bad thing!), and is also closer to what gcc does. It is more incremental than Bill's and introduces fewer new concepts. Executive summary ----------------- Remove the personality and list of catches out of eh.selector and stick them directly on invoke instructions. The

2010/1/22 James Williams <junk at giantblob.com> > > > 2010/1/22 Duncan Sands <baldrick at free.fr> > >> Hi James, >> >> >> I get the expected output (after changing i32 @llvm.eh.selector() to i64 >>> llvm.eh.selector.i64()) >>> >> >> in top-of-tree, llvm.eh.selector.i64 has been removed (though bitcode will >>

On Dec 1, 2010, at 1:37 PM, Duncan Sands wrote: > Executive summary > ----------------- > > Remove the personality and list of catches out of eh.selector and stick them > directly on invoke instructions. > > The invoke instruction > ---------------------- > > The invoke instruction is modified by adding extra catch info to it: > > <result> = invoke

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

Here http://llvm.org/docs/ExceptionHandling.html#llvm_eh_selector llvm.eh.selector is declared like this: i32 %llvm.eh.selector <http://llvm.org/docs/ExceptionHandling.html#llvm_eh_selector>(i8*, i8*, i8*, ...) But when clang++ (rev.121360) writes the module with exceptions, it writes it out like this: declare i32 @llvm.eh.selector(i8*, i8*, ...) nounwind Why there is such descrepancy?

Hi James, Looking at: %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 frame (function) called via

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

Yes. The issue here, as you pointed out, is that your personality function is not called at all. Even if you did nothing in the personality function, associated with the setup caused by llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be called. Your results are acting like either dwarf exception header info is not emitted (llvm::DwarfExceptionHandling = true; not executed

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

2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > Yes. The issue here, as you pointed out, is that your personality function > is not called at all. > Even if you did nothing in the personality function, associated with the > setup caused by > llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be > called. > Your results are acting like either

I think so. It also fails the same way on LLVM trunk from last week. The full backtrace is below. It appears that frame #3 is a compilation of __l_personality() and frame #14 is a compilation of f(). The compilation of __l_personality appears to have been triggered by the need to output DWARF information for f(). -- James #0 0x00007ffff6ed84b5 in *__GI_raise (sig=<value optimised out>) at

This is an interesting problem. The GC code is being converted into 'invokes' instead of calls: define i32 @main() gc "shadow-stack" { entry: %gc_frame = alloca %gc_stackentry.main %gc_currhead = load %gc_stackentry** @llvm_gc_root_chain %gc_frame.map = getelementptr %gc_stackentry.main* %gc_frame, i32 0, i32 0, i32 1 store %gc_map* getelementptr inbounds (%gc_map.0*

Hi James, Just wanted to update you. As you implied the problem here is that the personality function has to be jitted before the code that contains the corresponding llvm.eh.selector intrinsic instruction is jitted. I verified this by creating a generated version of the personality function which unless I jitted first, gave me the same error when running the code. Since you are using tools

On Nov 24, 2010, at 9:01 PM, Bill Wendling wrote: > On Nov 24, 2010, at 6:41 PM, John McCall wrote: >> What you mean is that, given a resume or invoke edge, we need to be able to find the dispatch for the target region. There are ways to make that happen without tagged edges; for example, you could make the landing pad a special subclass of BasicBlock with a pointer to the dispatch,

The linker is going off in the weeds trying to parse the dwarf unwind info. The CIE has: Leh_frame_common_begin0: .long 0 ## CIE Identifier Tag .byte 1 ## DW_CIE_VERSION .asciz "zLR" ## CIE Augmentation .byte 1 ## CIE Code Alignment Factor .byte 120 ## CIE Data Alignment

Hi, If I type define i32 @main() gc "shadow-stack" { entry: %0 = alloca i8* %1 = call i8* @malloc(i64 1) store i8* %1, i8** %0 call void @llvm.gcroot(i8** %0, i8* null) ret i32 0 } declare i8* @malloc(i64) declare void @llvm.gcroot(i8**, i8*) nounwind in test.ll and then do > llc test.ll > gcc test.s I get the error ld: in