summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/RuntimeDyld/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2019-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
* [mips][rtdyld] Move MIPS relocation resolution to a subclass and implement ↵Simon Dardis2016-12-131-0/+1
| | | | | | | | | | | | | | | N32 relocations N32 relocations are only correct for individual relocations at the moment. Support for relocation composition will follow in a later patch. Patch By: Daniel Sanders Reviwers: vkalintiris, atanasyan Differential Revision: https://reviews.llvm.org/D27467 llvm-svn: 289532
* [ExecutionEngine][RuntimeDyld] Move JITSymbol from ExecutionEngine to ↵Lang Hames2016-08-071-0/+1
| | | | | | | | | RuntimeDyld. JITSymbol really belongs in RuntimeDyld. This should fix the llvm-rtdyld link failures caused by r277943. llvm-svn: 277945
* modules: Add explicit dependency on intrinsics_genDuncan P. N. Exon Smith2015-06-161-0/+3
| | | | | | | | | `LLVM_ENABLE_MODULES` builds sometimes fail because `Intrinsics.td` needs to regenerate `Instrinsics.h` before anyone can include anything from the LLVM_IR module. Represent the dependency explicitly to prevent that. llvm-svn: 239796
* Fix the autoconf buildDavid Majnemer2015-03-071-1/+0
| | | | | | | | lib/ExecutionEngine/Targets has no Makefile, causing the autoconf build to fail. Solve this by bringing the COFF implementation of RuntimeDyld in line like the Mach-O and ELF implementations. llvm-svn: 231579
* ExecutionEngine: Preliminary support for dynamically loadable coff objectsDavid Majnemer2015-03-071-0/+2
| | | | | | | | | | Provide basic support for dynamically loadable coff objects. Only handles a subset of x64 currently. Patch by Andy Ayers! Differential Revision: http://reviews.llvm.org/D7793 llvm-svn: 231574
* [ExecutionEngine] Fix dependence issue by moving RTDyldMemoryManager intoLang Hames2015-02-151-0/+1
| | | | | | | | RuntimeDyld. This should fix http://llvm.org/PR22593. llvm-svn: 229343
* [MCJIT] Replace JITEventListener::anchor (temporarily removed in r222861), andLang Hames2014-11-271-1/+0
| | | | | | move GDBRegistrationListener into ExecutionEngine to avoid layering violation. llvm-svn: 222864
* [MCJIT] Reapply r222828 and r222810-r222812 with fix for MSVC move-op issues.Lang Hames2014-11-261-1/+1
| | | | llvm-svn: 222840
* Reverting r222828 and r222810-r222812 as they broke the build on Windows.Aaron Ballman2014-11-261-1/+1
| | | | | | http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/11753 llvm-svn: 222833
* [MCJIT] Clean up RuntimeDyld's quirky object-ownership/modification scheme.Lang Hames2014-11-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, when loading an object file, RuntimeDyld (1) took ownership of the ObjectFile instance (and associated MemoryBuffer), (2) potentially modified the object in-place, and (3) returned an ObjectImage that managed ownership of the now-modified object and provided some convenience methods. This scheme accreted over several years as features were tacked on to RuntimeDyld, and was both unintuitive and unsafe (See e.g. http://llvm.org/PR20722). This patch fixes the issue by removing all ownership and in-place modification of object files from RuntimeDyld. Existing behavior, including debugger registration, is preserved. Noteworthy changes include: (1) ObjectFile instances are now passed to RuntimeDyld by const-ref. (2) The ObjectImage and ObjectBuffer classes have been removed entirely, they existed to model ownership within RuntimeDyld, and so are no longer needed. (3) RuntimeDyld::loadObject now returns an instance of a new class, RuntimeDyld::LoadedObjectInfo, which can be used to construct a modified object suitable for registration with the debugger, following the existing debugger registration scheme. (4) The JITRegistrar class has been removed, and the GDBRegistrar class has been re-written as a JITEventListener. This should fix http://llvm.org/PR20722 . llvm-svn: 222810
* [RuntimeDyld] Add a framework for testing relocation logic in RuntimeDyld.Lang Hames2014-06-271-0/+1
| | | | | | | | | | | | | | | | | | | | This patch adds a "-verify" mode to the llvm-rtdyld utility. In verify mode, llvm-rtdyld will test supplied expressions against the linked program images that it creates in memory. This scheme can be used to verify the correctness of the relocation logic applied by RuntimeDyld. The expressions to test will be read out of files passed via the -check option (there may be more than one of these). Expressions to check are extracted from lines of the form: # rtdyld-check: <expression> This system is designed to fit the llvm-lit regression test workflow. It is format and target agnostic, and supports verification of images linked for remote targets. The expression language is defined in llvm/include/llvm/RuntimeDyldChecker.h . Examples can be found in test/ExecutionEngine/RuntimeDyld. llvm-svn: 211956
* Moving SectionMemoryManager to MCJIT to avoid cross dependency between JIT ↵Andrew Kaylor2012-11-281-1/+0
| | | | | | and RuntimeDyld llvm-svn: 168755
* Moving SectionMemoryManager into RuntimeDyld and adding unit tests for it.Andrew Kaylor2012-11-271-0/+1
| | | | | | | | The SectionMemoryManager now supports (and requires) applying section-specific page permissions. Clients using this memory manager must call either MCJIT::finalizeObject() or SectionMemoryManager::applyPermissions() before executing JITed code. See r168718 for changes from the previous implementation. llvm-svn: 168721
* Implement GDB integration for source level debugging of code JITed usingPreston Gurd2012-04-161-1/+2
| | | | | | | | | | | | | | | the MCJIT execution engine. The GDB JIT debugging integration support works by registering a loaded object image with a pre-defined function that GDB will monitor if GDB is attached. GDB integration support is implemented for ELF only at this time. This integration requires GDB version 7.0 or newer. Patch by Andy Kaylor! llvm-svn: 154868
* Adding a basic ELF dynamic loader and MC-JIT for ELF. Functionality is ↵Eli Bendersky2012-01-161-0/+1
| | | | | | | | currently basic and will be enhanced with future patches. Patch developed by Andy Kaylor and Daniel Malea. Reviewed on llvm-commits. llvm-svn: 148231
* build/CMake: Finish removal of add_llvm_library_dependencies.Daniel Dunbar2011-11-291-5/+0
| | | | llvm-svn: 145420
* Rewrite the CMake build to use explicit dependencies between libraries,Chandler Carruth2011-07-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specified in the same file that the library itself is created. This is more idiomatic for CMake builds, and also allows us to correctly specify dependencies that are missed due to bugs in the GenLibDeps perl script, or change from compiler to compiler. On Linux, this returns CMake to a place where it can relably rebuild several targets of LLVM. I have tried not to change the dependencies from the ones in the current auto-generated file. The only places I've really diverged are in places where I was seeing link failures, and added a dependency. The goal of this patch is not to start changing the dependencies, merely to move them into the correct location, and an explicit form that we can control and change when necessary. This also removes a serialization point in the build because we don't have to scan all the libraries before we begin building various tools. We no longer have a step of the build that regenerates a file inside the source tree. A few other associated cleanups fall out of this. This isn't really finished yet though. After talking to dgregor he urged switching to a single CMake macro to construct libraries with both sources and dependencies in the arguments. Migrating from the two macros to that style will be a follow-up patch. Also, llvm-config is still generated with GenLibDeps.pl, which means it still has slightly buggy dependencies. The internal CMake 'llvm-config-like' macro uses the correct explicitly specified dependencies however. A future patch will switch llvm-config generation (when using CMake) to be based on these deps as well. This may well break Windows. I'm getting a machine set up now to dig into any failures there. If anyone can chime in with problems they see or ideas of how to solve them for Windows, much appreciated. llvm-svn: 136433
* Add to RuntimeDyld support different object formatsDanil Malyshev2011-07-131-0/+1
| | | | llvm-svn: 135037
* Library-ize the dyld components of llvm-rtdyld.Jim Grosbach2011-03-211-0/+3
Move the dynamic linking functionality of the llvm-rtdyld program into an ExecutionEngine support library. Update llvm-rtdyld to just load an object file into memory, use the library to process it, then run the _main() function, if one is found. llvm-svn: 128031
OpenPOWER on IntegriCloud