summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Return ErrorOr from getSymbolAddress.Rafael Espindola2015-07-031-2/+3
| | | | | | | It can fail trying to get the section on ELF and COFF. This makes sure the error is handled. llvm-svn: 241366
* Return ErrorOr from SymbolRef::getName.Rafael Espindola2015-07-021-6/+9
| | | | | | | | | | | | This function can really fail since the string table offset can be out of bounds. Using ErrorOr makes sure the error is checked. Hopefully a lot of the boilerplate code in tools/* can go away once we have a diagnostic manager in Object. llvm-svn: 241297
* Expose getFlags via ELFSectionRef.Rafael Espindola2015-06-261-7/+7
| | | | llvm-svn: 240779
* Add a ELFSectionRef class and use it to expose getSectionType.Rafael Espindola2015-06-261-3/+3
| | | | llvm-svn: 240778
* Simplify getSymbolType.Rafael Espindola2015-06-261-2/+1
| | | | | | | | This is still a really odd function. Most calls are in object format specific contexts and should probably be replaced with a more direct query, but at least now this is not too obnoxious to use. llvm-svn: 240777
* Change how symbol sizes are handled in lib/Object.Rafael Espindola2015-06-241-6/+6
| | | | | | | | | | | | | | COFF and MachO only define symbol sizes for common symbols. Reflect that in the class hierarchy by having a method for common symbols only in the base and a general one in ELF. This avoids the need of using a magic value for the size, which had a few problems * Most callers didn't check for it. * The ones that did could not tell the magic value from a file actually having that value. llvm-svn: 240529
* Remove object_error::success and use std::error_code() insteadRui Ueyama2015-06-091-3/+3
| | | | | | | | | | | | make_error_code(object_error) is slow because object::object_category() uses a ManagedStatic variable. But the real problem is that the function is called too frequently. This patch uses std::error_code() instead of object_error::success. In most cases, we return "success", so this patch reduces number of function calls to that function. http://reviews.llvm.org/D10333 llvm-svn: 239409
* Simplify another function that doesn't fail.Rafael Espindola2015-06-011-6/+3
| | | | llvm-svn: 238703
* Simplify interface of function that doesn't fail.Rafael Espindola2015-05-311-4/+2
| | | | llvm-svn: 238700
* [Mips64] Add support for MCJIT for MIPS64r2 and MIPS64r6Petar Jovanovic2015-05-281-1/+2
| | | | | | | | | | Add support for resolving MIPS64r2 and MIPS64r6 relocations in MCJIT. Patch by Vladimir Radosavljevic. Differential Revision: http://reviews.llvm.org/D9667 llvm-svn: 238424
* Reapply [RuntimeDyldELF] Fold Placeholder into AddendKeno Fischer2015-05-011-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reapplies r235060 and 235070, which were reverted because of test failures in LLDB. The failure was caused because at moment RuntimeDyld is processing relocations for all sections, irrespective of whether we actually load them into memory or not, but RuntimeDyld was not actually remembering where in memory the unrelocated section is. This commit includes a fix for that issue by remembering that pointer, though the longer term fix should be to stop processing unneeded sections. Original Summary: This allows us to get rid of the original unrelocated object file after we're done processing relocations (but before applying them). MachO and COFF already do not require this (currently we have temporary hacks to prevent ownership from being released, but those are brittle and should be removed soon). The placeholder mechanism allowed the relocation resolver to look at original object file to obtain more information that are required to apply the relocations. This is usually necessary in two cases: - For relocations targetting sub-word memory locations, there may be pieces of the instruction at the target address which we should not override. - Some relocations on some platforms allow an extra addend to be encoded in their immediate fields. The problem is that in the second case the information cannot be recovered after the relocations have been applied once because they will have been overridden. In the first case we also need to be careful to not use any bits that aren't fixed and may have been overriden by applying a first relocation. In the past both have been fixed by just looking at original object file. This patch attempts to recover the information from the first by looking at the relocated object file, while the extra addend in the second case is read upon relocation processing and addend to the regular addend. I have tested this on X86. Other platforms represent my best understanding of how those relocations should work, but I may have missed something because I do not have access to those platforms. We will keep the ugly workarounds in place for a couple of days, so this commit can be reverted if it breaks the bots. Differential Revision: http://reviews.llvm.org/D9028 llvm-svn: 236341
OpenPOWER on IntegriCloud