OSDN Git Service

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)
commit016f651f8d47815498a93d38db48ff9cdc7fc306
tree64b91737ab24bf5eee46d29e095610b4afe9d259
parent4dc6aa2c1737cf77b5621dc00920cb7165470682
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!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221947 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Support/Windows/DynamicLibrary.inc
lib/Support/Windows/explicit_symbols.inc
test/ExecutionEngine/frem.ll [new file with mode: 0644]