[LLVMdev] Clobbering llvm.eh.selector return

[Garrison Venn]

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