summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/Support/DynamicLibrary
Commit message (Collapse)AuthorAgeFilesLines
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-194-16/+12
| | | | | | | | | | | | | | | | | 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
* Fix DynamicLibraryTests build on Windows when ↵Michael Platings2018-11-281-0/+7
| | | | | | | | | | | | | | | | | LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is ON extract_symbols.py (introduced in D18826) expects all of its library arguments to be in the same directory - typically <config>/lib. DynamicLibraryLib.lib is instead to be found in lib/<config>. This patch intended to make DynamicLibraryLib.lib be created in <config>/lib alongside most of the other libraries. I previously tried passing absolute paths to extract_symbols.py but this generated command lines that were too long for Visual Studio 2015: D54587 Differential Revision: https://reviews.llvm.org/D54701 llvm-svn: 347764
* [Unittests] Change linker flags of dynamic library testsMikhail Maltsev2018-06-111-1/+8
| | | | | | | | | | | | | | | | | | | A recent change https://reviews.llvm.org/D46898 which had no intended behavior change, actually modified the linker flags used when linking the dynamic libraries used by the DynamicLibraryTests unit test. This made the test fail in our testing environment which runs the tests from an NFS share. Prior to D46898 the two libraries used by the test were different (because the library name used to be embedded into the binary), and after the change they became bit-to-bit identical. This causes dlopen to return the same handle when these two libraries are loaded from an NFS share, and the test expects two different handles. This patch reverts the part of D46898 that is responsible for changing the linker flags. Differential Revision: https://reviews.llvm.org/D47469 llvm-svn: 334394
* use standard llvm cmake formatting for targets defined in plugin testsNico Weber2018-05-181-3/+9
| | | | llvm-svn: 332709
* Give shared modules in unittests the platform-native extension, make ↵Nico Weber2018-05-162-12/+7
| | | | | | | | | | | | | | | | | PipSqueak a MODULE As far as I can tell from revision history, there's no good reason to call these files .so instead of .dll in Windows, so use the normal extension. Also change PipSquak from SHARED to MODULE -- it's never passed to target_link_libraries() and only loaded via dlopen(), so MODULE is more appropriate. This makes it possible to delete a workaround for SHARED ldflags being not quite right as well. No intended behavior change. https://reviews.llvm.org/D46898 llvm-svn: 332487
* Rename three cxx files in unittests to cpp.Nico Weber2018-05-153-5/+8
| | | | | | | | | | | | LLVM uses cpp as its C++ file extension, these are the only three cxx file in the monorepo. These files apparently were called to escape a CMake check -- use the LLVM_OPTIONAL_SOURCES mechanism that's meant as an escape for this case instead. No intended behavior change. https://reviews.llvm.org/D46843 llvm-svn: 332368
* [CMake] Use PRIVATE in target_link_libraries for executablesShoaib Meenai2017-12-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use target_link_libraries without an explicit scope specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables. Dependencies added in this way apply to both the target and its dependencies, i.e. they become part of the executable's link interface and are transitive. Transitive dependencies generally don't make sense for executables, since you wouldn't normally be linking against an executable. This also causes issues for generating install export files when using LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM library dependencies, which are currently added as interface dependencies. If clang is in the distribution components but the LLVM libraries it depends on aren't (which is a perfectly legitimate use case if the LLVM libraries are being built static and there are therefore no run-time dependencies on them), CMake will complain about the LLVM libraries not being in export set when attempting to generate the install export file for clang. This is reasonable behavior on CMake's part, and the right thing is for LLVM's build system to explicitly use PRIVATE dependencies for executables. Unfortunately, CMake doesn't allow you to mix and match the keyword and non-keyword target_link_libraries signatures for a single target; i.e., if a single call to target_link_libraries for a particular target uses one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must also be updated to use those keywords. This means we must do this change in a single shot. I also fully expect to have missed some instances; I tested by enabling all the projects in the monorepo (except dragonegg), and configuring both with and without shared libraries, on both Darwin and Linux, but I'm planning to rely on the buildbots for other configurations (since it should be pretty easy to fix those). Even after this change, we still have a lot of target_link_libraries calls that don't specify a scope keyword, mostly for shared libraries. I'm thinking about addressing those in a follow-up, but that's a separate change IMO. Differential Revision: https://reviews.llvm.org/D40823 llvm-svn: 319840
* [cmake] Pass -Wl,-z,nodelete on Linux to prevent unloadingMichal Gorny2017-11-271-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | Prevent unloading shared libraries on Linux when dlclose() is called. This is necessary since command-line option parsing API relies on registering the global option instances in the option parser instance which can be loaded in a different shared library. Given that we can't reliably remove those options when a library is unloaded, the parser ends up containing dangling references. Since glibc has relatively complex library unloading rules, some of the LLVM libraries can be unloaded while others (including the Support library) stay loaded causing quite a mayhem. To reliably prevent that, just forbid unloading all libraries -- it's a very bad idea anyway. While the issue arguably happens only with BUILD_SHARED_LIBS, it may affect any library reusing llvm::cl interface. Based on patch provided Ross Hayward on https://bugs.gentoo.org/617154. Previously hit by Fedora back in Feb 2016: https://lists.freedesktop.org/archives/mesa-dev/2016-February/107242.html Differential Revision: https://reviews.llvm.org/D40459 llvm-svn: 319105
* Move these CMake projects into the Tests folder on IDEs like Visual Studio ↵Aaron Ballman2017-11-041-0/+2
| | | | | | rather than leave it in the root directory. NFC. llvm-svn: 317414
* Allow clients to specify search order of DynamicLibraries.Frederich Munch2017-07-121-0/+10
| | | | | | | | | | | | | | 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
* Revert r305313 & r305303, self-hosting build-bot isn’t liking it.Frederich Munch2017-06-133-39/+3
| | | | llvm-svn: 305318
* Fix self hosting build-bot failure from r305303 by adjusting ↵Frederich Munch2017-06-131-0/+1
| | | | | | DynamicLibraryTests compile flags. llvm-svn: 305313
* Force RegisterStandardPasses to construct std::function in the IPO library.Frederich Munch2017-06-133-3/+38
| | | | | | | | | | | | | | Summary: Fixes an issue using RegisterStandardPasses from a statically linked object before PassManagerBuilder::addGlobalExtension is called from a dynamic library. Reviewers: efriedma, theraven Reviewed By: efriedma Subscribers: mehdi_amini, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D33515 llvm-svn: 305303
* Export the required symbol from DynamicLibraryTestsRoger Ferrer Ibanez2017-06-125-4/+23
| | | | | | | | | | | | | | | | | Running unittests/Support/DynamicLibrary/DynamicLibraryTests fails when LLVM is configured with -DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON, because the test's version script only contains symbols extracted from the static libraries, that the test links with, but not those from the main object/executable itself. The patch moves the one symbol, needed by the test, to a static library. Fixes https://bugs.llvm.org/show_bug.cgi?id=32893 Patch by Momchil Velikov. Differential Revision: https://reviews.llvm.org/D33789 llvm-svn: 305181
* Re-sort #include lines for unittests. This uses a slightly modifiedChandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | clang-format (https://reviews.llvm.org/D33932) to keep primary headers at the top and handle new utility headers like 'gmock' consistently with other utility headers. No other change was made. I did no manual edits, all of this is clang-format. This should allow other changes to have more clear and focused diffs, and is especially motivated by moving some headers into more focused libraries. llvm-svn: 304786
* Close DynamicLibraries in reverse order they were opened.Frederich Munch2017-06-054-35/+88
| | | | | | | | | | | | | | 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
* Revert "Export the required symbol from DynamicLibraryTests"Roger Ferrer Ibanez2017-05-262-2/+0
| | | | | | This breaks sanitizer-x86_64-linux-fast buildbot. llvm-svn: 304005
* Export the required symbol from DynamicLibraryTestsRoger Ferrer Ibanez2017-05-262-0/+2
| | | | | | | | | | | | | | | | Running unittests/Support/DynamicLibrary/DynamicLibraryTests fails when LLVM is configured with LLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON, because the test's version script only contains symbols extracted from the static libraries, that the test links with, but not those from the main object/executable itself. The patch explicitly exports the one symbol needed by the test. This change fixes https://bugs.llvm.org/show_bug.cgi?id=32893 Patch authored by Momchil Velikov. Differential Revision: https://reviews.llvm.org/D33490 llvm-svn: 303979
* Reapply part of rL303015, fixing just the DynamicLibaryTest. AddDimitry Andric2017-05-171-1/+3
| | | | | | | retrieval of the original argv[0] from the GoogleTest framework, so it is more likely the correct main executable path is found. llvm-svn: 303289
* Revert r303015, because it has the unintended side effect of breakingDimitry Andric2017-05-171-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | driver-mode recognition in clang (this is because the sysctl method always returns one and only one executable path, even for an executable with multiple links): Fix DynamicLibraryTest.cpp on FreeBSD and NetBSD Summary: After rL301562, on FreeBSD the DynamicLibrary unittests fail, because the test uses getMainExecutable("DynamicLibraryTests", Ptr), and since the path does not contain any slashes, retrieving the main executable will not work. Reimplement getMainExecutable() for FreeBSD and NetBSD using sysctl(3), which is more reliable than fiddling with relative or absolute paths. Also add retrieval of the original argv[] from the GoogleTest framework, to use as a fallback for other OSes. Reviewers: emaste, marsupial, hans, krytarowski Reviewed By: krytarowski Subscribers: krytarowski, llvm-commits Differential Revision: https://reviews.llvm.org/D33171 llvm-svn: 303285
* Fix DynamicLibraryTest.cpp on FreeBSD and NetBSDDimitry Andric2017-05-141-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: After rL301562, on FreeBSD the DynamicLibrary unittests fail, because the test uses getMainExecutable("DynamicLibraryTests", Ptr), and since the path does not contain any slashes, retrieving the main executable will not work. Reimplement getMainExecutable() for FreeBSD and NetBSD using sysctl(3), which is more reliable than fiddling with relative or absolute paths. Also add retrieval of the original argv[] from the GoogleTest framework, to use as a fallback for other OSes. Reviewers: emaste, marsupial, hans, krytarowski Reviewed By: krytarowski Subscribers: krytarowski, llvm-commits Differential Revision: https://reviews.llvm.org/D33171 llvm-svn: 303015
* Fix a few pedantic warnings.Frederich Munch2017-04-271-2/+2
| | | | | | | | | | | | Reviewers: zturner, hansw, hans Reviewed By: hans Subscribers: hans, llvm-commits Differential Revision: https://reviews.llvm.org/D32611 llvm-svn: 301595
* Limit disabling of warnings emitted from r301571 by checking __GNUC__.Frederich Munch2017-04-271-1/+1
| | | | llvm-svn: 301572
* Fix warnings from test added in r301562 on Windows (when built without ↵Frederich Munch2017-04-271-0/+10
| | | | | | exceptions). llvm-svn: 301571
* Refactor DynamicLibrary so searching for a symbol will have a defined order andFrederich Munch2017-04-274-0/+207
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-244-207/+0
| | | | | | | | | | 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-244-0/+207
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-244-207/+0
| | | | | | | | | | 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
* Refactor DynamicLibrary so searching for a symbol will have a defined order andFrederich Munch2017-04-244-0/+207
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
OpenPOWER on IntegriCloud