summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/RuntimeDyld/Targets/RuntimeDyldMachOAArch64.h
Commit message (Collapse)AuthorAgeFilesLines
* Simplify decoupling between RuntimeDyld/RuntimeDyldChecker, add 'got_addr' util.Lang Hames2019-04-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This patch reduces the number of functions in the interface between RuntimeDyld and RuntimeDyldChecker by combining "GetXAddress" and "GetXContent" functions into "GetXInfo" functions that return a struct describing both the address and content. The GetStubOffset function is also replaced with a pair of utilities, GetStubInfo and GetGOTInfo, that fit the new scheme. For RuntimeDyld both of these functions will return the same result, but for the new JITLink linker (https://reviews.llvm.org/D58704) these will provide the addresses of PLT stubs and GOT entries respectively. For JITLink's use, a 'got_addr' utility has been added to the rtdyld-check language, and the syntax of 'got_addr' and 'stub_addr' has been changed: both functions now take two arguments, a 'stub container name' and a target symbol name. For llvm-rtdyld/RuntimeDyld the stub container name is the object file name and section name, separated by a slash. E.g.: rtdyld-check: *{8}(stub_addr(foo.o/__text, y)) = y For the upcoming llvm-jitlink utility, which creates stubs on a per-file basis rather than a per-section basis, the container name is just the file name. E.g.: jitlink-check: *{8}(got_addr(foo.o, y)) = y llvm-svn: 358295
* 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
* [RuntimeDyld][MachO] Add support for MachO::ARM64_RELOC_POINTER_TO_GOT reloc.Lang Hames2018-05-231-8/+48
| | | | llvm-svn: 333130
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-1/+1
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* Reapply r329133 with fix.Lang Hames2018-04-041-5/+36
| | | | llvm-svn: 329136
* Revert r329133 "[RuntimeDyld][AArch64] Add some error pluming / generation..."Lang Hames2018-04-041-32/+4
| | | | | | This broke a number of buildbots. Looking in to it now... llvm-svn: 329135
* [RuntimeDyld][AArch64] Add some error pluming / generation to catch unhandledLang Hames2018-04-031-4/+32
| | | | | | relocation types on AArch64. llvm-svn: 329133
* [RuntimeDyld][MachO] Fix assertion in encodeAddend, add missing directive toLang Hames2018-03-011-3/+5
| | | | | | | | | | | | test case. r326290 fixed the assertion for decodeAddend, but not encodeAddend. The regression test failed to catch this because it was missing the subsections_via_symbols flag, so the desired relocation was not applied. This patch also fixes the formatting of the assertion from r326290. llvm-svn: 326406
* [RuntimeDyld][MachO] Support ARM64_RELOC_BRANCH26 for BL instructions byLang Hames2018-02-281-2/+4
| | | | | | relaxing an assertion. llvm-svn: 326290
* Replace "fallthrough" comments with LLVM_FALLTHROUGHJustin Bogner2016-08-171-2/+4
| | | | | | | This is a mechanical change of comments in switches like fallthrough, fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead. llvm-svn: 278902
* [ExecutionEngine][MCJIT][Orc] Replace RuntimeDyld::SymbolInfo with JITSymbol.Lang Hames2016-08-011-1/+1
| | | | | | | | | | | | | | | | 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
* [RuntimeDyld] Thread Error through some APIs, remove calls to ↵Lang Hames2016-05-181-15/+5
| | | | | | report_fatal_error. llvm-svn: 269881
* [RuntimeDyld] Plumb Error/Expected through the internals of RuntimeDyld.Lang Hames2016-04-271-6/+13
| | | | | | | | | | | | | 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
* Thread Expected<...> up from libObject’s getName() for symbols to allow ↵Kevin Enderby2016-04-201-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [RuntimeDyld][AArch64] Add support for the MachO ARM64_RELOC_SUBTRACTOR reloc.Lang Hames2016-01-211-1/+53
| | | | llvm-svn: 258438
* [RuntimeDyld] Add accessors to `SectionEntry`; NFCSanjoy Das2015-11-231-7/+7
| | | | | | | | | | | | | | | | 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][AArch64] Add explicit addends before calling relocationValueRef.Lang Hames2015-08-111-5/+4
| | | | | | relocationValueRef uses the addend, so it has to be set before the call. llvm-svn: 244574
* Remove getRelocationAddress.Rafael Espindola2015-07-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally added in r139314. Back then it didn't actually get the address, it got whatever value the relocation used: address or offset. The values in different object formats are: * MachO: Always an offset. * COFF: Always an address, but when talking about the virtual address of sections it says: "for simplicity, compilers should set this to zero". * ELF: An offset for .o files and and address for .so files. In the case of the .so, the relocation in not linked to any section (sh_info is 0). We can't really compute an offset. Some API mappings would be: * Use getAddress for everything. It would be quite cumbersome. To compute the address elf has to follow sh_info, which can be corrupted and therefore the method has to return an ErrorOr. The address of the section is also the same for every relocation in a section, so we shouldn't have to check the error and fetch the value for every relocation. * Use a getValue and make it up to the user to know what it is getting. * Use a getOffset and: * Assert for dynamic ELF objects. That is a very peculiar case and it is probably fair to ask any tool that wants to support it to use ELF.h. The only tool we have that reads those (llvm-readobj) already does that. The only other use case I can think of is a dynamic linker. * Check that COFF .obj files have sections with zero virtual address spaces. If it turns out that some assembler/compiler produces these, we can change COFFObjectFile::getRelocationOffset to subtract it. Given COFF format, this can be done without the need for ErrorOr. The getRelocationAddress method was never implemented for COFF. It also had exactly one use in a very peculiar case: a shortcut for adding the section value to a pcrel reloc on MachO. Given that, I don't expect that there is any use out there of the C API. If that is not the case, let me know and I will add it back with the implementation inlined and do a proper deprecation. llvm-svn: 241450
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-231-1/+1
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-191-1/+1
| | | | | | | | | | | | | The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137
* [MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo throughLang Hames2015-03-301-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MCJIT. This patch decouples the two responsibilities of the RTDyldMemoryManager class, memory management and symbol resolution, into two new classes: RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver. The symbol resolution interface is modified slightly, from: uint64_t getSymbolAddress(const std::string &Name); to: RuntimeDyld::SymbolInfo findSymbol(const std::string &Name); The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld and others to reason about non-strong/non-exported symbols. The memory management interface removes the following method: void notifyObjectLoaded(ExecutionEngine *EE, const object::ObjectFile &) {} as it is not related to memory management. (Note: Backwards compatibility *is* maintained for this method in MCJIT and OrcMCJITReplacement, see below). The RTDyldMemoryManager class remains in-tree for backwards compatibility. It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which just subclasses RuntimeDyld::MemoryManager and reintroduces the notifyObjectLoaded method for backwards compatibility). The EngineBuilder class retains the existing method: EngineBuilder& setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm); and includes two new methods: EngineBuilder& setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM); EngineBuilder& setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR); Clients should use EITHER: A single call to setMCJITMemoryManager with an RTDyldMemoryManager. OR (exclusive) One call each to each of setMemoryManager and setSymbolResolver. This patch should be fully compatible with existing uses of RTDyldMemoryManager. If it is not it should be considered a bug, and the patch either fixed or reverted. If clients find the new API to be an improvement the goal will be to deprecate and eventually remove the RTDyldMemoryManager class in favor of the new classes. llvm-svn: 233509
* Fix undefined behavior (shift of negative value) in ↵Alexey Samsonov2015-01-101-2/+2
| | | | | | | | | | | | | | RuntimeDyldMachOAArch64::encodeAddend. Test Plan: regression test suite with/without UBSan. Reviewers: lhames, ributzka Subscribers: aemerson, llvm-commits Differential Revision: http://reviews.llvm.org/D6908 llvm-svn: 225568
* [MCJIT] Remove the local symbol table from RuntimeDlyd - it's not needed.Lang Hames2014-11-271-2/+2
| | | | | | | | All symbols have to be stored in the global symbol to enable cross-rtdyld-instance linking, so the local symbol table content is redundant. llvm-svn: 222867
* [MCJIT] Reapply r222828 and r222810-r222812 with fix for MSVC move-op issues.Lang Hames2014-11-261-6/+7
| | | | llvm-svn: 222840
* Reverting r222828 and r222810-r222812 as they broke the build on Windows.Aaron Ballman2014-11-261-7/+6
| | | | | | 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-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [MCJIT] Defer application of AArch64 MachO GOT relocations until resolve time.Lang Hames2014-10-211-5/+5
| | | | | | | | | | On AArch64, GOT references are page relative (ADRP + LDR), so they can't be applied until we know exactly where, within a page, the GOT entry will be in the target address space. Fixes <rdar://problem/18693976>. llvm-svn: 220347
* [MCJIT] Rewrite RuntimeDyldMachO and its derived classes to use the 'Offset'Lang Hames2014-09-071-3/+3
| | | | | | | | | | field of RelocationValueRef, rather than the 'Addend' field. This is consistent with RuntimeDyldELF's use of RelocationValueRef, and more consistent with the semantics of the data being stored (the offset from the start of a section or symbol). llvm-svn: 217328
* [MCJIT] Make sure eh-frame fixups use the target's pointer type, not the host's.Lang Hames2014-09-041-0/+3
| | | | | | | If the wrong pointer type is used it can cause corruption of the frame description entries. llvm-svn: 217124
* Add override to overriden virtual methods, remove virtual keywords.Benjamin Kramer2014-09-031-1/+1
| | | | | | No functionality change. Changes made by clang-tidy + some manual cleanup. llvm-svn: 217028
* Canonicalize header guards into a common format.Benjamin Kramer2014-08-131-3/+3
| | | | | | | | | | Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
* [MCJIT] Simplify immediate decoding code in the RuntimeDyldMachO hierarchy.Lang Hames2014-08-081-5/+8
| | | | | | | | | | | Cleanup only: no functional change. This patch makes RuntimeDyldMachO targets directly responsible for decoding immediates, rather than letting them implement catch a callback from generic code. Since this is a very target specific operation, it makes sense to let the target-specific code drive it. llvm-svn: 215255
* [MCJIT] Replace a c-style cast with reinterpret_cast + static_cast.Lang Hames2014-08-071-4/+4
| | | | | | | | | | C-style casts (and reinterpret_casts) result in implementation defined values when a pointer is cast to a larger integer type. On some platforms this was leading to bogus address computations in RuntimeDyldMachOAArch64. This should fix http://llvm.org/PR20501. llvm-svn: 215143
* [MCJIT] Fix the ARM BR24 relocation in RuntimeDyldMachO.Lang Hames2014-07-301-1/+1
| | | | | | | | | | We now (1) correctly decode the branch immediate, (2) modify the immediate to corretly treat it as PC-rel, and (3) properly populate the stub entry. Previously we had been doing each of these wrong. <rdar://problem/17750739> llvm-svn: 214285
* [RuntimeDyld][AArch64] Make encode/decodeAddend also work on big-endian hosts.Juergen Ributzka2014-07-291-18/+31
| | | | llvm-svn: 214205
* [RuntimeDyld][AArch64] Make encode/decodeAddend more typesafe by using the ↵Juergen Ributzka2014-07-291-6/+8
| | | | | | relocation enum type. NFCI. llvm-svn: 214204
* RuntimeDyldMachOAArch64.h: Fix a warning. [-Wunused-variable]NAKAMURA Takumi2014-07-231-0/+1
| | | | llvm-svn: 213710
* Appease the buildbots.Juergen Ributzka2014-07-221-0/+1
| | | | llvm-svn: 213694
* [RuntimeDyld][MachO][AArch64] Add a helper function for encoding addends in ↵Juergen Ributzka2014-07-221-75/+110
| | | | | | | | | | | | | instructions. Factor out the addend encoding into a helper function and simplify the processRelocationRef. Also add a few simple rtdyld tests. More tests to come once GOTs can be tested too. Related to <rdar://problem/17768539> llvm-svn: 213689
* [RuntimeDyld][MachO][AArch64] Implement the decodeAddend method.Juergen Ributzka2014-07-221-0/+92
| | | | | | | This adds the required functionality to decode the immediate encoded in an instruction that is referenced in a relocation entry. llvm-svn: 213688
* [RuntimeDyld][MachO][AArch64] Add assertion to check for duplicate addend ↵Juergen Ributzka2014-07-221-4/+4
| | | | | | | | | | definition. In MachO for AArch64 it is possible to have an explicit addend defined by the ARM64_RELOC_ADDEND relocation or having an addend encoded within the instruction. Only one of them are allowed per relocation. llvm-svn: 213687
* [MCJIT] [AArch64] Make sure to propegate ARM64_RELOC_ADDEND values into theLang Hames2014-07-181-1/+3
| | | | | | | | | | RelocationEntry. No test case yet, as this primarily hits GOT entries, which RuntimeDyldChecker can't examine yet. I'm actively working on features that will enable us to test this. llvm-svn: 213408
* [MCJIT] Fix the alignment requirements for ARM and AArch64 which were mistakenlyLang Hames2014-07-171-1/+1
| | | | | | | | | | relaxed in the big RuntimeDyldMachO cleanup of r213293. No test case yet - this was found via inspection and there's no easy way to test GOT alignment in RuntimeDyldChecker at the moment. I'm working on adding support for this now, and hope to have a test case for this soon. llvm-svn: 213331
* [MCJIT] Significantly refactor the RuntimeDyldMachO class.Lang Hames2014-07-171-0/+253
The previous implementation of RuntimeDyldMachO mixed logic for all targets within a single class, creating problems for readability, maintainability, and performance. To address these issues, this patch strips the RuntimeDyldMachO class down to just target-independent functionality, and moves all target-specific functionality into target-specific subclasses RuntimeDyldMachO. The new class hierarchy is as follows: class RuntimeDyldMachO Implemented in RuntimeDyldMachO.{h,cpp} Contains logic that is completely independent of the target. This consists mostly of MachO helper utilities which the derived classes use to get their work done. template <typename Impl> class RuntimeDyldMachOCRTPBase<Impl> : public RuntimeDyldMachO Implemented in RuntimeDyldMachO.h Contains generic MachO algorithms/data structures that defer to the Impl class for target-specific behaviors. RuntimeDyldMachOARM : public RuntimeDyldMachOCRTPBase<RuntimeDyldMachOARM> RuntimeDyldMachOARM64 : public RuntimeDyldMachOCRTPBase<RuntimeDyldMachOARM64> RuntimeDyldMachOI386 : public RuntimeDyldMachOCRTPBase<RuntimeDyldMachOI386> RuntimeDyldMachOX86_64 : public RuntimeDyldMachOCRTPBase<RuntimeDyldMachOX86_64> Implemented in their respective *.h files in lib/ExecutionEngine/RuntimeDyld/MachOTargets Each of these contains the relocation logic specific to their target architecture. llvm-svn: 213293
OpenPOWER on IntegriCloud