summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Windows/DynamicLibrary.inc
Commit message (Collapse)AuthorAgeFilesLines
* llvm-ar: Fix MinGW compilationHans Wennborg2020-02-281-1/+1
| | | | | | | | | | | | | | | | llvm-ar is using CompareStringOrdinal which is available only starting with Windows Vista (WINVER 0x600). Fix this by hoising WindowsSupport.h, which sets _WIN32_WINNT to 0x0601, up to llvm/include/llvm/Support and use it in llvm-ar. Patch by Cristian Adam! Differential revision: https://reviews.llvm.org/D74599 (cherry picked from commit 01f9abbb50b11dd26b9ccb7cb565cc955d2b9c74) This is for https://bugs.llvm.org/show_bug.cgi?id=44907
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Move some function declarations out of WindowsSupport.hZachary Turner2018-06-011-0/+1
| | | | | | | | | | | | | | | | | | The idea behind WindowsSupport.h is that it's in the source directory so that windows.h'isms don't leak out into the larger LLVM project. To that end, any symbol that references a symbol from windows.h must be in this private header, and not in a public header. However, we had some useful utility functions in WindowsSupport.h which have no dependency on the Windows API, but still only make sense on Windows. Those functions should be usable outside of Support since there is no risk of causing a windows.h leak. Although this introduces some preprocessor logic in some header files, It's not too egregious and it's better than the alternative of duplicating a ton of code. Differential Revision: https://reviews.llvm.org/D47662 llvm-svn: 333798
* Allow clients to specify search order of DynamicLibraries.Frederich Munch2017-07-121-0/+2
| | | | | | | | | | | | | | Summary: Different JITs and other clients of LLVM may have different needs in how symbol resolution should occur. Reviewers: v.g.vassilev, lhames, karies Reviewed By: v.g.vassilev Subscribers: pcanal, llvm-commits Differential Revision: https://reviews.llvm.org/D33529 llvm-svn: 307849
* Close DynamicLibraries in reverse order they were opened.Frederich Munch2017-06-051-1/+1
| | | | | | | | | | | | | | Summary: Matches C++ destruction ordering better and fixes possible problems of loaded libraries having inter-dependencies. Reviewers: efriedma, v.g.vassilev, chapuni Reviewed By: efriedma Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D33652 llvm-svn: 304720
* Refactor DynamicLibrary so searching for a symbol will have a defined order andFrederich Munch2017-04-271-103/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | libraries are properly unloaded when llvm_shutdown is called. Summary: This was mostly affecting usage of the JIT, where storing the library handles in a set made iteration unordered/undefined. This lead to disagreement between the JIT and native code as to what the address and implementation of particularly on Windows with stdlib functions: JIT: putenv_s("TEST", "VALUE") // called msvcrt.dll, putenv_s JIT: getenv("TEST") -> "VALUE" // called msvcrt.dll, getenv Native: getenv("TEST") -> NULL // called ucrt.dll, getenv Also fixed is the issue of DynamicLibrary::getPermanentLibrary(0,0) on Windows not giving priority to the process' symbols as it did on Unix. Reviewers: chapuni, v.g.vassilev, lhames Reviewed By: lhames Subscribers: danalbert, srhines, mgorny, vsk, llvm-commits Differential Revision: https://reviews.llvm.org/D30107 llvm-svn: 301562
* Revert "Refactor DynamicLibrary so searching for a symbol will have a ↵Frederich Munch2017-04-241-115/+103
| | | | | | | | | | defined order" The i686-mingw32-RA-on-linux bot is still having errors. This reverts commit r301236. llvm-svn: 301240
* Refactor DynamicLibrary so searching for a symbol will have a defined order andFrederich Munch2017-04-241-103/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | libraries are properly unloaded when llvm_shutdown is called. Summary: This was mostly affecting usage of the JIT, where storing the library handles in a set made iteration unordered/undefined. This lead to disagreement between the JIT and native code as to what the address and implementation of particularly on Windows with stdlib functions: JIT: putenv_s("TEST", "VALUE") // called msvcrt.dll, putenv_s JIT: getenv("TEST") -> "VALUE" // called msvcrt.dll, getenv Native: getenv("TEST") -> NULL // called ucrt.dll, getenv Also fixed is the issue of DynamicLibrary::getPermanentLibrary(0,0) on Windows not giving priority to the process' symbols as it did on Unix. Reviewers: chapuni, v.g.vassilev, lhames Reviewed By: lhames Subscribers: danalbert, srhines, mgorny, vsk, llvm-commits Differential Revision: https://reviews.llvm.org/D30107 llvm-svn: 301236
* Revert "Refactor DynamicLibrary so searching for a symbol will have a ↵Frederich Munch2017-04-241-112/+95
| | | | | | | | | | defined order.” The changes are causing the i686-mingw32 build to fail. This reverts commit r301153, and the changes for a separate warning on i686-mingw32 in r301155 and r301156. llvm-svn: 301157
* Fix warning converting from boolean to pointer introduced in r301153.Frederich Munch2017-04-241-1/+1
| | | | | | This reverts commit r301155, which was incorrect. llvm-svn: 301156
* Refactor DynamicLibrary so searching for a symbol will have a defined order andFrederich Munch2017-04-241-95/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | libraries are properly unloaded when llvm_shutdown is called. Summary: This was mostly affecting usage of the JIT, where storing the library handles in a set made iteration unordered/undefined. This lead to disagreement between the JIT and native code as to what the address and implementation of particularly on Windows with stdlib functions: JIT: putenv_s("TEST", "VALUE") // called msvcrt.dll, putenv_s JIT: getenv("TEST") -> "VALUE" // called msvcrt.dll, getenv Native: getenv("TEST") -> NULL // called ucrt.dll, getenv Also fixed is the issue of DynamicLibrary::getPermanentLibrary(0,0) on Windows not giving priority to the process' symbols as it did on Unix. Reviewers: chapuni, v.g.vassilev, lhames Reviewed By: lhames Subscribers: danalbert, srhines, mgorny, vsk, llvm-commits Differential Revision: https://reviews.llvm.org/D30107 llvm-svn: 301153
* Do not pollute the namespace in a header file.Kristof Beyls2017-03-311-7/+7
| | | | llvm-svn: 299203
* Cast to the right type on Windows.Vassil Vassilev2017-03-021-1/+1
| | | | llvm-svn: 296778
* Reland r296442 with modifications reverted in r296463.Vassil Vassilev2017-03-021-0/+12
| | | | | | | | | | | | | | Original commit message: "Allow externally dlopen-ed libraries to be registered as permanent libraries. This is also useful in cases when llvm is in a shared library. First we dlopen the llvm shared library and then we register it as a permanent library in order to keep the JIT and other services working. Patch reviewed by Vedant Kumar (D29955)!" llvm-svn: 296774
* Do not leak OpenedHandles.Vassil Vassilev2017-03-021-10/+2
| | | | llvm-svn: 296748
* Reformat a blank line.NAKAMURA Takumi2017-02-281-1/+1
| | | | llvm-svn: 296464
* Revert r296442 (and r296443), "Allow externally dlopen-ed libraries to be ↵NAKAMURA Takumi2017-02-281-26/+13
| | | | | | | | registered as permanent libraries." It broke clang/test/Analysis/checker-plugins.c llvm-svn: 296463
* Fix Win bots.Vassil Vassilev2017-02-281-2/+2
| | | | llvm-svn: 296443
* Allow externally dlopen-ed libraries to be registered as permanent libraries.Vassil Vassilev2017-02-281-12/+25
| | | | | | | | | | This is also useful in cases when llvm is in a shared library. First we dlopen the llvm shared library and then we register it as a permanent library in order to keep the JIT and other services working. Patch reviewed by Vedant Kumar (D29955)! llvm-svn: 296442
* Do not leak OpenedHandles.Vassil Vassilev2017-02-211-0/+2
| | | | | | Reviewed by Vedant Kumar (D30178) llvm-svn: 295737
* Revert r130657, "Windows/DynamicLibrary.inc: Clean up ELM_Callback. We may ↵NAKAMURA Takumi2016-03-071-1/+1
| | | | | | | | check the decl instead of the versions of individual libraries." We may assume the type of 1st argument as PCSTR in PENUMLOADED_MODULES_CALLBACK. PSTR was in the ancient mingw32. llvm-svn: 262810
* [Windows] Partially revert r254363 until I can test the right fix.Davide Italiano2015-12-011-2/+6
| | | | | | Reported by: David Blaikie llvm-svn: 254378
* [Windows] Follow-up r254363, remove return.Davide Italiano2015-12-011-3/+1
| | | | llvm-svn: 254364
* [Windows] Simplify assertion code. NFC.Davide Italiano2015-12-011-4/+2
| | | | llvm-svn: 254363
* Add Windows error code and tidy formatting for system errors.Paul Robinson2015-11-231-2/+2
| | | | | | Differential Revision: http://reviews.llvm.org/D14892 llvm-svn: 253888
* [Support] Lazy load of dbghlp.dll on WindowsLeny Kholodov2015-07-021-10/+20
| | | | | | | | | | | | | This patch changes linkage with dbghlp.dll for clang from static (at load time) to on demand (at the first use of required functions). Clang uses dbghlp.dll only in minor use-cases. First of all in case of crash and in case of plugin load. The dbghlp.dll library can be absent on system. In this case clang will fail to load. With lazy load of dbghlp.dll clang can work even if dbghlp.dll is not available. Differential Revision: http://reviews.llvm.org/D10737 llvm-svn: 241271
* Fix symbol resolution of floating point libc builtins in MCJITReid Kleckner2014-11-131-9/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Windows/DynamicLibrary.inc: Remove 'extern "C"' in ELM_Callback.NAKAMURA Takumi2014-09-231-1/+1
| | | | | | '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
* In this callback ModuleName includes the file path.Yaron Keren2014-09-221-26/+5
| | | | | | | | | | | | | | | 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
* Try to fix the windows build.Rafael Espindola2014-06-121-1/+1
| | | | llvm-svn: 210837
* Clean up language and grammar.Eric Christopher2014-05-201-1/+1
| | | | | | | Based on a patch by jfcaron3@gmail.com! PR19806 llvm-svn: 209216
* Rename Windows.h to WindowsSupport.h to avoid ambiguityReid Kleckner2014-02-121-1/+1
| | | | llvm-svn: 201258
* Revert "Revert "Windows: Add support for unicode command lines""David Majnemer2013-10-071-1/+8
| | | | | | | This reverts commit r192070 which reverted r192069, I forgot to regenerate the configure scripts. llvm-svn: 192079
* Revert "Windows: Add support for unicode command lines"David Majnemer2013-10-061-8/+1
| | | | | | | This is causing MinGW bots to fail. This reverts commit r192069. llvm-svn: 192070
* Windows: Add support for unicode command linesDavid Majnemer2013-10-061-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make DynamicLibrary use ManagedStatic. This is pretty simple and should just ↵Filip Pizlo2013-09-181-3/+3
| | | | | | | | | | 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
* Make DynamicLibrary thread-safe w/r/t call to dlerror() after dlopen(). PR10718Jordy Rose2011-08-221-2/+2
| | | | llvm-svn: 138260
* Unbork Windows build. Thanks, Francois.Jordy Rose2011-08-171-2/+2
| | | | llvm-svn: 137798
* Use DynamicLibrary instances as a way to get symbols from a specific ↵Jordy Rose2011-08-171-26/+52
| | | | | | library. Preparation for upcoming (preliminary) support for plugins for the static analyzer. llvm-svn: 137791
* Windows/DynamicLibrary.inc: Fix trivial warnings. Thanks to John Myers!NAKAMURA Takumi2011-07-091-1/+1
| | | | llvm-svn: 134812
* Windows/DynamicLibrary.inc: Clean up ELM_Callback. We may check the decl ↵NAKAMURA Takumi2011-05-011-31/+2
| | | | | | | | | 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
* Windows/DynamicLibrary.inc: ELM_Callback fix for mingw-w64.NAKAMURA Takumi2011-02-091-1/+11
| | | | llvm-svn: 125169
* Windows/DynamicLibrary.inc: Split explicit symbols into explicit_symbols.inc.NAKAMURA Takumi2011-02-051-60/+17
| | | | | | | 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
* Merge System into Support.Michael J. Spencer2010-11-291-0/+199
llvm-svn: 120298
OpenPOWER on IntegriCloud