llvm dev - Feb 2010 - [LLVMdev] Clobbering llvm.eh.selector return

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? I ask because I am
trying to isolate code to prove to myself that
I am not introducing a bug causing this before I go off and start tracing
through llvm dwarf emission.
http://llvm.org/docs/ExceptionHandling.html does not specify that these
instructions must be the first ones in a landing pad,
but all the examples I've seen have this property.

Thanks in advance

Garrison

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.

Ciao,

Duncan.

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 exception/unwind (get/setGR(built in reg.
index 1)), mechanism is shared for other uses.
If this is true, what criteria is used to identify whether this register is
going to be used. I can image future efforts directed toward
changing or adding to the exception mechanism needing to know what to avoid
before the passes that actually lower the graphs
into machine/assembly code have been executed.

Thanks again for the info.

Garrison

On Feb 5, 2010, at 15:41, Duncan Sands wrote:
> 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.
> 
> Ciao,
> 
> Duncan.