[LLVMdev] Clobbering llvm.eh.selector return

Duncan Sands baldrick at free.fr
Fri Feb 5 12:41:30 PST 2010

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 called even though none of the functions I have tested played with the exception 
> mechanism--fprintfs and C functions with static variables initialized in a certain way do the trick. I am assuming 
> that this is not a bug but rather that there is an unstated requirement that llvm.eh.exception, and llvm.eh.selector 
> must be the first calls in any landing pad. Is this true?

no, it's a bug.  The DwarfEHPrepare is supposed to take care of moving such
calls to the start of landing pads, but currently it only does this for
eh.exception (eh.selector is harder for various reasons).  This is on my list
of things to fix.



More information about the llvm-dev mailing list