Commit Graph

18 Commits

Author SHA1 Message Date
Reid Kleckner 9aeb04793a 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
2014-11-13 23:32:52 +00:00
NAKAMURA Takumi bbae11bd2d Windows/DynamicLibrary.inc: Remove 'extern "C"' in ELM_Callback.
'extern "C" static' is not accepted by g++-4.7. Rather to tweak, I just removed 'extern "C"', since it doesn't affect the ABI.

llvm-svn: 218290
2014-09-23 01:09:46 +00:00
Yaron Keren fb06908989 In this callback ModuleName includes the file path.
Comparing ModuleName to the file names listed will 
always fail. 

I wonder how this code ever worked and what its 
purpose was. Why exclude the msvc runtime DLLs
but not exclude all Windows system DLLs?

Anyhow, it does not function as intended.

clang-formatted as well.

llvm-svn: 218276
2014-09-22 21:40:15 +00:00
Rafael Espindola adccf860ac Try to fix the windows build.
llvm-svn: 210837
2014-06-12 21:53:57 +00:00
Eric Christopher 650c8f2a06 Clean up language and grammar.
Based on a patch by jfcaron3@gmail.com!
PR19806

llvm-svn: 209216
2014-05-20 17:11:11 +00:00
Reid Kleckner d59e2faae1 Rename Windows.h to WindowsSupport.h to avoid ambiguity
llvm-svn: 201258
2014-02-12 21:26:20 +00:00
David Majnemer 61eae2e30c Revert "Revert "Windows: Add support for unicode command lines""
This reverts commit r192070 which reverted r192069, I forgot to
regenerate the configure scripts.

llvm-svn: 192079
2013-10-07 01:00:07 +00:00
David Majnemer f636cf422e Revert "Windows: Add support for unicode command lines"
This is causing MinGW bots to fail.
This reverts commit r192069.

llvm-svn: 192070
2013-10-06 20:44:34 +00:00
David Majnemer 80bea0c315 Windows: Add support for unicode command lines
Summary:
The MSVCRT deliberately sends main() code-page specific characters.
This isn't too useful to LLVM as we end up converting the arguments to
UTF-16 and subsequently attempt to use the result as, for example, a
file name.  Instead, we need to have the ability to access the Unicode
command line and transform it to UTF-8.

This has the distinct advantage over using the MSVC-specific wmain()
function as our entry point because:
 - It doesn't work on cygwin.
 - It only work on MinGW with caveats and only then on certain versions.
 - We get to keep our entry point as main(). :)

N.B.  This patch includes fixes to other parts of lib/Support/Windows
s.t. we would be able to take advantage of getting the Unicode paths.
E.G.  clang spawning clang -cc1 would want to give it Unicode arguments.

Reviewers: aaron.ballman, Bigcheese, rnk, ruiu

Reviewed By: rnk

CC: llvm-commits, ygao

Differential Revision: http://llvm-reviews.chandlerc.com/D1834

llvm-svn: 192069
2013-10-06 20:25:49 +00:00
Filip Pizlo 57093e88e0 Make DynamicLibrary use ManagedStatic. This is pretty simple and should just work as
advertised - but it does have the caveat that calls to DynamicLibrary::AddSymbol will 
"reset" if you shutdown llvm and try to come back for seconds.  This is a subtle 
behavior change, but I'm assuming that nobody is affected by it.

llvm-svn: 190946
2013-09-18 16:40:14 +00:00
Jordy Rose 5765f4c24c Make DynamicLibrary thread-safe w/r/t call to dlerror() after dlopen(). PR10718
llvm-svn: 138260
2011-08-22 19:01:52 +00:00
Jordy Rose 1a3ca9201a Unbork Windows build. Thanks, Francois.
llvm-svn: 137798
2011-08-17 00:59:50 +00:00
Jordy Rose a19917da7c Use DynamicLibrary instances as a way to get symbols from a specific library. Preparation for upcoming (preliminary) support for plugins for the static analyzer.
llvm-svn: 137791
2011-08-17 00:29:32 +00:00
NAKAMURA Takumi ee24d32071 Windows/DynamicLibrary.inc: Fix trivial warnings. Thanks to John Myers!
llvm-svn: 134812
2011-07-09 08:41:20 +00:00
NAKAMURA Takumi 4471f82e91 Windows/DynamicLibrary.inc: Clean up ELM_Callback. We may check the decl instead of the versions of individual libraries.
autoconf: Add checking ELM_Callback decl for mingw32 and mingw-w64.
cmake/config-ix.cmake: Add checking ELM_Callback decl for win32.

llvm-svn: 130657
2011-05-01 13:29:49 +00:00
NAKAMURA Takumi 684ef5e7bd Windows/DynamicLibrary.inc: ELM_Callback fix for mingw-w64.
llvm-svn: 125169
2011-02-09 04:18:12 +00:00
NAKAMURA Takumi 03a541f5c4 Windows/DynamicLibrary.inc: Split explicit symbols into explicit_symbols.inc.
config.h.* have conditions whether each symbol is defined or not.
Autoconf and CMake may check symbols in libgcc.a for JIT on Mingw.

llvm-svn: 124950
2011-02-05 15:11:53 +00:00
Michael J. Spencer 447762da85 Merge System into Support.
llvm-svn: 120298
2010-11-29 18:16:10 +00:00