summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [ORC] Errorize the ORC APIs.Lang Hames2017-07-071-6/+27
| | | | | | | | This patch updates the ORC layers and utilities to return and propagate llvm::Errors where appropriate. This is necessary to allow ORC to safely handle error cases in cross-process and remote JITing. llvm-svn: 307350
* Revert [mips] Adds support for R_MIPS_26, HIGHER, HIGHEST relocations in ↵Sagar Thakur2017-06-221-32/+6
| | | | | | | | RuntimeDyld Reverting due to build bot failures llvm-svn: 306000
* [mips] Adds support for R_MIPS_26, HIGHER, HIGHEST relocations in RuntimeDyldSagar Thakur2017-06-221-6/+32
| | | | | | | | | After the N64 static relocation model support was added to llvm it is required to add its support in RuntimeDyld also because lldb uses ExecutionEngine for evaluating expressions. Reviewed by sdardis Differential: D31649 llvm-svn: 305997
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* [RuntimeDyld] Fix debug section relocation (pr20457)Pavel Labath2017-05-171-3/+7
| | | | | | | | | | | | | | | | | | Summary: Debug info sections, (or non-SHF_ALLOC sections in general) should be linked as if their load address was zero to emulate the behavior of the static linker. This bug was discovered because it was breaking lldb expression evaluation on linux. Reviewers: lhames Subscribers: aprantl, eugene, clayborg, lldb-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D32899 llvm-svn: 303239
* [ExecutionEngine] Make RuntimeDyld::MemoryManager responsible for tracking EHLang Hames2017-05-091-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | frames. RuntimeDyld was previously responsible for tracking allocated EH frames, but it makes more sense to have the RuntimeDyld::MemoryManager track them (since the frames are allocated through the memory manager, and written to memory owned by the memory manager). This patch moves the frame tracking into RTDyldMemoryManager, and changes the deregisterFrames method on RuntimeDyld::MemoryManager from: void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr, size_t Size); to: void deregisterEHFrames(); Separating this responsibility will allow ORC to continue to throw the RuntimeDyld instances away post-link (saving a few dozen bytes per lazy function) while properly deregistering frames when modules are unloaded. This patch also updates ORC to call deregisterEHFrames when modules are unloaded. This fixes a bug where an exception that tears down the JIT can then unwind through dangling EH frames that have been deallocated but not deregistered, resulting in UB. For people using SectionMemoryManager this should be pretty much a no-op. For people with custom allocators that override registerEHFrames/deregisterEHFrames, you will now be responsible for tracking allocated EH frames. Reviewed in https://reviews.llvm.org/D32829 llvm-svn: 302589
* [RuntimeDyld] Make RuntimeDyld honor the ProcessAllSections flag.Lang Hames2017-04-041-2/+2
| | | | | | | | | | | | | | | When the ProcessAllSections flag (introduced in r204398) is set RuntimeDyld is supposed to make a call to the client's memory manager for every section in each object that is loaded. Due to some missing checks, this was not happening in all cases. This patch adds the missing cases, and fixes the Orc unit test that verifies correct behavior for ProcessAllSections (The unit test had been silently bailing out due to an ordering issue: a change in the test order meant that this unit-test was running before the native target was registered. This issue has also been fixed in this patch). This fixes <rdar://problem/22789965> llvm-svn: 299449
* RuntimeDyldELF/AArch64: Implement basic GOT supportEugene Leviant2017-02-061-0/+26
| | | | | | | | | This patch implements two GOT relocations: R_AARCH64_ADR_GOT_PAGE and R_AARCH64_LD64_GOT_LO12_NC Differential revision: https://reviews.llvm.org/D28571 llvm-svn: 294191
* [mips][rtdyld] Move MIPS relocation resolution to a subclass and implement ↵Simon Dardis2016-12-131-3/+6
| | | | | | | | | | | | | | | 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
* [RuntimeDyld] Skip undefined symbols when building the symbol table.Lang Hames2016-11-301-0/+4
| | | | | | Storing these in the symbol table (with zero values) is just wasted space. llvm-svn: 288225
* Remove LLVM_NOEXCEPT and replace it with noexceptReid Kleckner2016-10-191-1/+1
| | | | | | | Now that we have dropped MSVC 2013, all supported compilers support noexcept and we can drop this portability macro. llvm-svn: 284672
* Re-apply r278065 (Weak symbol support in RuntimeDyld) with a fix for ELF.Lang Hames2016-08-091-0/+18
| | | | llvm-svn: 278149
* Revert r278065 while I investigate some build-bot breakage.Lang Hames2016-08-081-18/+0
| | | | llvm-svn: 278069
* [RuntimeDyld][Orc][MCJIT] Add partial weak-symbol support to RuntimeDyld.Lang Hames2016-08-081-0/+18
| | | | | | | | | | | | | | | This patch causes RuntimeDyld to check for existing definitions when it encounters weak symbols. If a definition already exists then the new weak definition is discarded. All symbol lookups within a "logical dylib" should now agree on the address of any given weak symbol. This allows the JIT to better match the behavior of the static linker for C++ code. This support is only partial, as it does not allow strong definitions that occur after the first weak definition (in JIT symbol lookup order) to override the previous weak definitions. Support for this will be added in a future patch. llvm-svn: 278065
* [RuntimeDyld] Remove symbol that is unused as of r277943.Lang Hames2016-08-071-1/+0
| | | | llvm-svn: 277944
* [RuntimeDyld] Replace manual flag checks with JITSymbolFlags::fromObjectSymbol.Lang Hames2016-08-071-13/+5
| | | | llvm-svn: 277943
* [ExecutionEngine] Refactor - Roll JITSymbolFlags functionality into JITSymbol.hLang Hames2016-08-041-1/+1
| | | | | | and remove the JITSymbolFlags header. llvm-svn: 277766
* [Orc] Fix common symbol support in ORC.Lang Hames2016-08-011-2/+8
| | | | | | | | | | | | | Common symbol support in ORC was broken in r270716 when the symbol resolution rules in RuntimeDyld were changed. With the switch to lazily materialized symbols in r277386, common symbols can be supported by having RuntimeDyld::emitCommonSymbols search for (but not materialize!) definitions elsewhere in the logical dylib. This patch adds the 'Common' flag to JITSymbolFlags, and the necessary check to RuntimeDyld::emitCommonSymbols. llvm-svn: 277397
* [ExecutionEngine][MCJIT][Orc] Replace RuntimeDyld::SymbolInfo with JITSymbol.Lang Hames2016-08-011-8/+8
| | | | | | | | | | | | | | | | This patch replaces RuntimeDyld::SymbolInfo with JITSymbol: A symbol class that is capable of lazy materialization (i.e. the symbol definition needn't be emitted until the address is requested). This can be used to support common and weak symbols in the JIT (though this is not implemented in this patch). For consistency, RuntimeDyld::SymbolResolver is renamed to JITSymbolResolver. For space efficiency a new class, JITEvaluatedSymbol, is introduced that behaves like the old RuntimeDyld::SymbolInfo - i.e. it is just a pair of an address and symbol flags. Instances of JITEvaluatedSymbol can be used in symbol-tables to avoid paying the space cost of the materializer. llvm-svn: 277386
* [LLVM][MIPS] Fix createStubFunction to emit JR encoding based on Arch.Nitesh Jain2016-07-151-1/+4
| | | | | | | | | | Reviewers: vkalintiris, dsanders Subscribers: jaydeep, bhushan, mohit.bhakkad, slthakur, llvm-commits Differential Revision: https://reviews.llvm.org/D21172 llvm-svn: 275559
* Reformat blank lines.NAKAMURA Takumi2016-07-041-2/+2
| | | | llvm-svn: 274481
* Reformat comment lines.NAKAMURA Takumi2016-07-041-1/+1
| | | | llvm-svn: 274480
* Untabify.NAKAMURA Takumi2016-07-041-4/+3
| | | | llvm-svn: 274479
* Reformat.NAKAMURA Takumi2016-07-041-4/+5
| | | | llvm-svn: 274478
* Thread Expected<...> up from libObject’s getSymbolAddress() for symbols to ↵Kevin Enderby2016-06-241-4/+4
| | | | | | | | | | | | | | | | | | | | | allow a good error message to be produced. This is nearly the last libObject interface that used ErrorOr and the last one that appears in llvm/include/llvm/Object/MachO.h . For Mach-O objects this is just a clean up because it’s version of getSymbolAddress() can’t return an error. I will leave it to the experts on COFF and ELF to actually add meaning full error messages in their tests if they wish. And also leave it to these experts to change the last two ErrorOr interfaces in llvm/include/llvm/Object/ObjectFile.h for createCOFFObjectFile() and createELFObjectFile() if they wish. Since there are no test cases for COFF and ELF error cases with respect to getSymbolAddress() in the test suite this is no functional change (NFC). llvm-svn: 273701
* [RuntimeDyld] Call the SymbolResolver::findSymbolInLogicalDylib method whenLang Hames2016-05-251-1/+5
| | | | | | | | | | | | | | | | | searching for external symbols, and fall back to the SymbolResolver::findSymbol method if the former returns null. This makes RuntimeDyld behave more like a static linker: Symbol definitions from within the current module's "logical dylib" will be preferred to external definitions. We can build on this behavior in the future to properly support weak symbol handling. Custom symbol resolvers that override the findSymbolInLogicalDylib method may notice changes due to this patch. Clients who have not overridden this method should generally be unaffected, however users of the OrcMCJITReplacement class may notice changes. llvm-svn: 270716
* Add FIXMEs to all derived classes of std::error_category.Peter Collingbourne2016-05-241-0/+3
| | | | | | | | This helps make clear that we're moving away from std::error_code. Differential Revision: http://reviews.llvm.org/D20592 llvm-svn: 270604
* Thread Expected<...> up from libObject’s getType() for symbols to allow ↵Kevin Enderby2016-05-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | llvm-objdump to produce a good error message. Produce another specific error message for a malformed Mach-O file when a symbol’s section index is more than the number of sections. The existing test case in test/Object/macho-invalid.test for macho-invalid-section-index-getSectionRawName now reports the error with the message indicating that a symbol at a specific index has a bad section index and that bad section index value. Again converting interfaces to Expected<> from ErrorOr<> does involve touching a number of places. Where the existing code reported the error with a string message or an error code it was converted to do the same. Also there some were bugs in the existing code that did not deal with the old ErrorOr<> return values.  So now with Expected<> since they must be checked and the error handled, I added a TODO and a comment: "// TODO: Actually report errors helpfully" and a call something like consumeError(NameOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. llvm-svn: 268298
* [RuntimeDyld] Plumb Error/Expected through the internals of RuntimeDyld.Lang Hames2016-04-271-66/+143
| | | | | | | | | | | | | Also replaces a number of calls to report_fatal_error with Error returns. The plumbing will make it easier to return errors originating in libObject. Replacing report_fatal_errors with Error returns will give JIT clients the opportunity to recover gracefully when the JIT is unable to produce/relocate code, as well as providing meaningful error messages that can be used to file bug reports. llvm-svn: 267776
* [RuntimeDyld] Fix conservative over-allocation of memory for common symbols.Lang Hames2016-04-211-4/+14
| | | | | | | | | The previous allocation code was over-estimating the amount of memory required. No test case: we don't currently have a good way to detect conervative over-allocation. llvm-svn: 267041
* Thread Expected<...> up from libObject’s getName() for symbols to allow ↵Kevin Enderby2016-04-201-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | llvm-objdump to produce a good error message. Produce another specific error message for a malformed Mach-O file when a symbol’s string index is past the end of the string table. The existing test case in test/Object/macho-invalid.test for macho-invalid-symbol-name-past-eof now reports the error with the message indicating that a symbol at a specific index has a bad sting index and that bad string index value. Again converting interfaces to Expected<> from ErrorOr<> does involve touching a number of places. Where the existing code reported the error with a string message or an error code it was converted to do the same. There is some code for this that could be factored into a routine but I would like to leave that for the code owners post-commit to do as they want for handling an llvm::Error. An example of how this could be done is shown in the diff in lib/ExecutionEngine/RuntimeDyld/RuntimeDyldImpl.h which had a Check() routine already for std::error_code so I added one like it for llvm::Error . Also there some were bugs in the existing code that did not deal with the old ErrorOr<> return values.  So now with Expected<> since they must be checked and the error handled, I added a TODO and a comment: “// TODO: Actually report errors helpfully” and a call something like consumeError(NameOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. Note there fixes needed to lld that goes along with this that I will commit right after this. So expect lld not to built after this commit and before the next one. llvm-svn: 266919
* Fix a crash in running llvm-objdump -t with an invalid Mach-O file alreadyKevin Enderby2016-03-231-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in the test suite. While this is not really an interesting tool and option to run on a Mach-O file to show the symbol table in a generic libObject format it shouldn’t crash. The reason for the crash was in MachOObjectFile::getSymbolType() when it was calling MachOObjectFile::getSymbolSection() without checking its return value for the error case. What makes this fix require a fair bit of diffs is that the method getSymbolType() is in the class ObjectFile defined without an ErrorOr<> so I needed to add that all the sub classes.  And all of the uses needed to be updated and the return value needed to be checked for the error case. The MachOObjectFile version of getSymbolType() “can” get an error in trying to come up with the libObject’s internal SymbolRef::Type when the Mach-O symbol symbol type is an N_SECT type because the code is trying to select from the SymbolRef::ST_Data or SymbolRef::ST_Function values for the SymbolRef::Type. And it needs the Mach-O section to use isData() and isBSS to determine if it will return SymbolRef::ST_Data. One other possible fix I considered is to simply return SymbolRef::ST_Other when MachOObjectFile::getSymbolSection() returned an error. But since in the past when I did such changes that “ate an error in the libObject code” I was asked instead to push the error out of the libObject code I chose not to implement the fix this way. As currently written both the COFF and ELF versions of getSymbolType() can’t get an error. But if isReservedSectionNumber() wanted to check for the two known negative values rather than allowing all negative values or the code wanted to add the same check as in getSymbolAddress() to use getSection() and check for the error then these versions of getSymbolType() could return errors. At the end of the day the error printed now is the generic “Invalid data was encountered while parsing the file” for object_error::parse_failed. In the future when we thread Lang’s new TypedError for recoverable error handling though libObject this will improve. And where the added // Diagnostic(… comment is, it would be changed to produce and error message like “bad section index (42) for symbol at index 8” for this case. llvm-svn: 264187
* [RuntimeDyld] Add a notifyObjectLoaded method to RuntimeDyld::MemoryManager.Lang Hames2016-01-101-1/+3
| | | | | | | | This is a more generic version of the MCJITMemoryManager::notifyObjectLoaded method: It provides only a RuntimeDyld reference (rather than an ExecutionEngine), and so can be used with ORC JIT stacks. llvm-svn: 257296
* [RuntimeDyld] Add alignment arguments to the reserveAllocationSpace method ofLang Hames2016-01-101-14/+17
| | | | | | | | | | | | | | RuntimeDyld::MemoryManager. The RuntimeDyld::MemoryManager::reserveAllocationSpace method is called when object files are loaded, and gives clients a chance to pre-allocate memory for all segments. Previously only the size of each segment (code, ro-data, rw-data) was supplied but not the alignment. This hasn't caused any problems so far, as most clients allocate via the MemoryBlock interface which returns page-aligned blocks. Adding alignment arguments enables finer grained allocation while still satisfying alignment restrictions. llvm-svn: 257294
* [Orc][RuntimeDyld] Prevent duplicate calls to finalizeMemory on shared memoryLang Hames2016-01-091-0/+11
| | | | | | | | | | | | | | | | | | | | | | | managers. Prior to this patch, recursive finalization (where finalization of one RuntimeDyld instance triggers finalization of another instance on which the first depends) could trigger memory access failures: When the inner (dependent) RuntimeDyld instance and its memory manager are finalized, memory allocated (but not yet relocated) by the outer instance is locked, and relocation in the outer instance fails with a memory access error. This patch adds a latch to the RuntimeDyld::MemoryManager base class that is checked by a new method: RuntimeDyld::finalizeWithMemoryManagerLocking, ensuring that shared memory managers are only finalized by the outermost RuntimeDyld instance. This allows ORC clients to supply the same memory manager to multiple calls to addModuleSet. In particular it enables the use of user-supplied memory managers with the CompileOnDemandLayer which must reuse the supplied memory manager for each function that is lazily compiled. llvm-svn: 257263
* [RuntimeDyld] DenseMap -> std::unordered_mapKeno Fischer2015-12-031-2/+2
| | | | | | | | | | | DenseMap is most applicable when both keys and values are small. In this case, the value violates that assumption, causing quite significant memory overhead. A std::unordered_map is more appropriate in this case (or at least fixed the memory problems I was seeing). Differential Revision: http://reviews.llvm.org/D14910 llvm-svn: 254651
* [RuntimeDyld] Don't allocate unnecessary stub buffer spaceSanjoy Das2015-11-231-4/+3
| | | | | | | | | | | | | | Summary: For relocation types that are known to not require stub functions, there is no need to allocate extra space for the stub functions. Reviewers: lhames, reames, maksfb Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14676 llvm-svn: 253920
* [RuntimeDyld] Add bounds checking to SectionEntry::advanceStubOffsetSanjoy Das2015-11-231-2/+4
| | | | | | | | | | | | | | Summary: Change SectionEntry to keep track of the size of its underlying allocation, and use that to bounds check advanceStubOffset. Reviewers: lhames, andrew.w.kaylor, reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14675 llvm-svn: 253919
* [RuntimeDyld] Add accessors to `SectionEntry`; NFCSanjoy Das2015-11-231-23/+16
| | | | | | | | | | | | | | | | Summary: Remove naked access to the data members in `SectionEntry` and route accesses through accessor functions. This makes it obvious how the instances of the class are used, and will also facilitate adding bounds checking to `advanceStubOffset` in a later change. Reviewers: lhames, loladiro, andrew.w.kaylor Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14674 llvm-svn: 253918
* [RuntimeDyld] Ignore ST_FILE symbols when constructing GlobalSymbolTableKeno Fischer2015-10-211-1/+2
| | | | | | | | | | | | | | Summary: ELF's STT_File symbols may overlap with regular globals in other files, so we should ignore them here in order to avoid having bogus entries in the symbol table that confuse us when resolving relocations. Reviewers: lhames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13888 llvm-svn: 250942
* [RuntimeDyld] Add support for absolute symbols.Lang Hames2015-10-181-15/+32
| | | | llvm-svn: 250639
* [RuntimeDyld] Don't try to get the contents of sections that don't have anyLang Hames2015-10-151-7/+7
| | | | | | | | | | | (e.g. bss sections). MachO and ELF have been silently letting this pass, but COFFObjectFile contains an assertion to catch this kind of (ab)use of the getSectionContents, and this was causing the JIT to crash on COFF objects with BSS sections. This patch should fix that. llvm-svn: 250371
* [RuntimeDyld] Fix performance problem in resolveRelocations with many sectionsKeno Fischer2015-10-101-7/+7
| | | | | | | | | | | | | | | Summary: Rather than just iterating over all sections and checking whether we have relocations for them, iterate over the relocation map instead. This showed up heavily in an artificial julia benchmark that does lots of compilation. On that particular benchmark, this patch gives ~15% performance improvements. As far as I can tell the primary reason why the original loop was so expensive is that Relocations[i] actually constructs a relocationList (allocating memory & doing lots of other unnecessary computing) if none is found. Reviewers: lhames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13545 llvm-svn: 249942
* [RuntimeDyld] Fix a bug in debugging output: all sections should be dumpedLang Hames2015-09-101-2/+13
| | | | | | | | | | | before any relocations have been applied, and again after all relocations have been applied. Previously each section was dumped before and after relocations targetting it were applied, but this only shows the impact of relocations that point to other symbols in the same section. llvm-svn: 247335
* [RuntimeDyld] Make sure code-sections aren't under-aligned.Lang Hames2015-08-141-0/+6
| | | | | | | | | | | | | | | | | | Code-section alignment should be at least as high as the minimum stub alignment. If the section alignment is lower it can cause padding to be emitted resulting in alignment errors if the section is mapped to a higher alignment on the target. E.g. If a text section with a 4-byte alignment gets 4-bytes of padding to guarantee 8-byte alignment for stubs but is re-mapped to an 8-byte alignment on the target, the 4-bytes of padding will push the stubs to 4-byte alignment causing a crash. No test case: There is currently no way to control host section alignment in llvm-rtdyld. This could be made testable by adding a custom memory manager. I'll look at that in a follow-up patch. llvm-svn: 245031
* [mips][mcjit] Calculate correct addend for HI16 and PCHI16 relocPetar Jovanovic2015-08-131-0/+3
| | | | | | | | | | | Previously, for O32 ABI we did not calculate correct addend for R_MIPS_HI16 and R_MIPS_PCHI16 relocations. This patch fixes that. Patch by Vladimir Radosavljevic. Differential Revision: http://reviews.llvm.org/D11186 llvm-svn: 244897
* Convert getSymbolSection to return an ErrorOr.Rafael Espindola2015-08-071-2/+3
| | | | | | | This function can actually fail since the symbol contains an index to the section and that can be invalid. llvm-svn: 244375
* [RuntimeDyld] Make LoadedObjectInfo::getLoadedSectionAddress take a SectionRefLang Hames2015-07-281-11/+17
| | | | | | rather than a string section name. llvm-svn: 243456
* Simplify by passing in the section of the symbol. NFC.Rafael Espindola2015-07-071-22/+5
| | | | llvm-svn: 241603
* [RuntimeDyld] Skip relocations for external symbols with 64-bit address ~0ULL.Lang Hames2015-07-041-6/+10
| | | | | | | | | | | Requested by Eugene Rozenfeld of the LLILC team, this feature allows JIT clients to skip relocations for selected external symbols by returning ~0ULL from their symbol resolver. If this value is returned for a given symbol, RuntimeDyld will skip all relocations for that symbol. The client will be responsible for applying the skipped relocations manually before the code is executed. llvm-svn: 241383
OpenPOWER on IntegriCloud