Fix symbol resolution of floating point libc builtins in MCJIT
authorReid Kleckner <reid@kleckner.net>
Thu, 13 Nov 2014 23:32:52 +0000 (23:32 +0000)
committerReid Kleckner <reid@kleckner.net>
Thu, 13 Nov 2014 23:32:52 +0000 (23:32 +0000)
commit9aeb04793a2e20a3302de899ec0d9c49ef350804
tree1c5d22b124da3a6e37f570c580e92dede55e81d6
parent60415e540b801cf84dab23c565e8d28730af9e5c
Fix symbol resolution of floating point libc builtins in MCJIT

Fix for LLI failure on Windows\X86: http://llvm.org/PR5053

LLI.exe crashes on Windows\X86 when single precession floating point
intrinsics like the following are used: acos, asin, atan, atan2, ceil,
copysign, cos, cosh, exp, floor, fmin, fmax, fmod, log, pow, sin, sinh,
sqrt, tan, tanh

The above intrinsics are defined as inline-expansions in math.h, and are
not exported by msvcr120.dll (Win32 API GetProcAddress returns null).

For an FREM instruction, the JIT compiler generates a call to a stub for
the fmodf() intrinsic, and adds a relocation to fixup at load time. The
loader searches the libraries for the function, but fails because the
symbol is not exported. So, the call target remains NULL and the
execution crashes.

Since the math functions are loaded at JIT/runtime, the JIT can patch
CALL instruction directly instead of the searching the libraries'
exported symbols.  However, this fix caused build failures due to
unresolved symbols like _fmodf at link time.

Therefore, the current fix defines helper functions in the Runtime
link/load library to perform the above operations.  The address of these
helper functions are used to patch up the CALL instruction at load time.

Reviewers: lhames, rnk

Reviewed By: rnk

Differential Revision: http://reviews.llvm.org/D5387

Patch by Swaroop Sridhar!

llvm-svn: 221947
llvm/lib/Support/Windows/DynamicLibrary.inc
llvm/lib/Support/Windows/explicit_symbols.inc
llvm/test/ExecutionEngine/frem.ll [new file with mode: 0644]