search for: __builtin_eh_return_data_regno

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...

Clang does indeed built it with one warning. [ 55%] Building C object lib/CMakeFiles/CompilerRT-Common.dir/gcc_personality_v0.c.o /export/home/edward/lab/llvm/build/compiler-rt/lib/gcc_personality_v0.c:232:36: warning: implicit declaration of function '__builtin_eh_return_data_regno' is invalid in C99 [-Wimplicit-function-declaration] _Unwind_SetGR(context, __builtin_eh_return_data_regno(0), ^ 1 diagnostic generated. I committed a fix for the other warnings and a fix for each of the #endif, I did not think they where ve...

There's an Apple internal bug for that. I've cloned it to Bugzilla as: <http://llvm.org/bugs/show_bug.cgi?id=5034> Implement __builtin_eh_return_data_regno() I can probably make the cmake configure stage fail up front if none of the supported mechanisms are found. I'll look at that. Thanks for the feedback! Shantonu Sent from my MacBook On Sep 22, 2009, at 9:01 PM, Edward O'Callaghan wrote: > Clang does indeed built it with one war...

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...

..., 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 tha...

Seems pretty clear cut to me. #if defined(HAVE_OSATOMIC_COMPARE_AND_SWAP_INT) && defined (HAVE_OSATOMIC_COMPARE_AND_SWAP_LONG) ... #elif defined(__WIN32__) ... #elif defined(HAVE_SYNC_BOOL_COMPARE_AND_SWAP_INT) && defined (HAVE_SYNC_BOOL_COMPARE_AND_SWAP_LONG) ... #else #error unknown atomic compare-and-swap primitive #endif The problem isn't mismatched #if/#endif. The

...t; used? Or it's just the same as those specified in calling convention? This is an ABI decision that your unwinder needs to know about, but the ones used in a normal function call are fairly typical. I believe the information is transmitted to the __gxx_personality_v0 function via Clang's __builtin_eh_return_data_regno intrinsic, which should be consistent. > - EH_RETURN: > > I see some targets define their own EH_RETURN SDNode, others don't. What > is EH_RETURN, and under what circumstances I should define my own EH_RETURN > SDNode? Not sure about this, I'm afraid. My suggestion wo...

No, As it worked fine before. I can't see the #if that goes with +#elif defined(__WIN32__) as you removed -#if TARGET_OS_MAC. Please go over your #if / #endif blocks and trail the #endif with a comment. I am willing to bet there is a problem there. Thanks for your time, Edward. 2009/9/23 Shantonu Sen <ssen at apple.com>: > Sounds like your system compiler doesn't support

Hi All, I would like to know in order to support exception handling for particular target, what need to be done. After doing some investigation, I can think of the following items with questions: - CFI directives: This is for .eh_frame section. Basically all the targets insert CFI directives in FrameLowering, but I am not sure exactly when/where I should do so. -