summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine
Commit message (Collapse)AuthorAgeFilesLines
...
* [MCJIT] Make stub_addr functionality in RuntimeDyldChecker work in release mode.Lang Hames2014-07-221-2/+0
| | | | | | | | | There's no reason to restrict this particular piece of RuntimeDyldChecker functionality to +Asserts builds. This should fix failures in MachO_x86-64_PIC_relocations.s on release bots. llvm-svn: 213708
* [MCJIT] Teach RuntimeDyldChecker to handle underscores at the start of symbols.Lang Hames2014-07-221-1/+1
| | | | | | | | RuntimeDyldChecker had been testing isalpha(Expr[0]) to recognise symbol tokens, and throwing unrecognized token errors when it hit symbols with leading underscores. This fixes that. llvm-svn: 213706
* [MCJIT] Improve stub_addr file-not-found diagnostic to help track down aLang Hames2014-07-221-2/+17
| | | | | | buildbot failure. llvm-svn: 213701
* [MCJIT] Refactor and add stub inspection to the RuntimeDyldChecker framework.Lang Hames2014-07-225-548/+777
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces a 'stub_addr' builtin that can be used to find the address of the stub for a given (<file>, <section>, <symbol>) tuple. This address can be used both to verify the contents of stubs (by loading from the returned address) and to verify references to stubs (by comparing against the returned address). Example (1) - Verifying stub contents: Load 8 bytes (assuming a 64-bit target) from the stub for 'x' in the __text section of f.o, and compare that value against the addres of 'x'. # rtdyld-check: *{8}(stub_addr(f.o, __text, x) = x Example (2) - Verifying references to stubs: Decode the immediate of the instruction at label 'l', and verify that it's equal to the offset from the next instruction's PC to the stub for 'y' in the __text section of f.o (i.e. it's the correct PC-rel difference). # rtdyld-check: decode_operand(l, 4) = stub_addr(f.o, __text, y) - next_pc(l) l: movq y@GOTPCREL(%rip), %rax Since stub inspection requires cooperation with RuntimeDyldImpl this patch pimpl-ifies RuntimeDyldChecker. Its implementation is moved in to a new class, RuntimeDyldCheckerImpl, that has access to the definition of RuntimeDyldImpl. llvm-svn: 213698
* 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
* [RuntimeDyld] Change the return type of decodeAddend to match the storage type.Juergen Ributzka2014-07-222-6/+6
| | | | llvm-svn: 213686
* Fixing an MSVC conversion warning about implicitly converting the shift ↵Aaron Ballman2014-07-211-1/+1
| | | | | | results to 64-bits. No functional change intended. llvm-svn: 213515
* [PowerPC] ELFv2 dynamic loader supportUlrich Weigand2014-07-203-20/+47
| | | | | | | | | | | | | | | | | | | | | This patch enables the new ELFv2 ABI in the runtime dynamic loader. The loader has to implement the following features: - In the ELFv2 ABI, do not look up a function descriptor in .opd, but instead use the local entry point when resolving a direct call. - Update the TOC restore code to use the new TOC slot linkage area offset. - Create PLT stubs appropriate for the ELFv2 ABI. Note that this patch also adds common-code changes. These are necessary because the loader must check the newly added ELF flags: the e_flags header bits encoding the ABI version, and the st_other symbol table entry bits encoding the local entry point offset. There is currently no way to access these, so I've added ObjectFile::getPlatformFlags and SymbolRef::getOther accessors. Reviewed by Hal Finkel. llvm-svn: 213491
* [MCJIT] Add a 'decodeAddend' method to RuntimeDyldMachO and teachLang Hames2014-07-192-26/+33
| | | | | | | | | | getBasicRelocationEntry to use this rather than 'memcpy' to get the relocation addend. Targets with non-trivial addend encodings (E.g. AArch64) can override decodeAddend to handle immediates with interesting encodings. No functional change. llvm-svn: 213435
* [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-172-2/+2
| | | | | | | | | | 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
* Drop the udis86 wrapper from llvm::sysAlp Toker2014-07-171-7/+0
| | | | | | | | This optional dependency on the udis86 library was added some time back to aid JIT development, but doesn't make much sense to link into LLVM binaries these days. llvm-svn: 213300
* [MCJIT] Significantly refactor the RuntimeDyldMachO class.Lang Hames2014-07-177-826/+1097
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [MCJIT] Improve a RuntimeDyldChecker diagnostic.Lang Hames2014-07-161-3/+7
| | | | | | | When a RuntimeDyldChecker test requests an invalid operand for an instruction, print the decoded instruction to aid diagnosis. llvm-svn: 213202
* [RuntimeDyld] Revert r211652 - MachO object GDB registration support.Lang Hames2014-07-152-144/+21
| | | | | | | | The registration scheme used in r211652 violated the read-only contract of MemoryBuffer. This caused crashes in llvm-rtdyld where macho objects were backed by read-only mmap'd memory. llvm-svn: 213086
* [RuntimeDyld] Handle endiannes differences between the host and target whileLang Hames2014-07-141-14/+19
| | | | | | | | | | reading MachO files magic numbers in RuntimeDyld. This is required now that we're testing cross-platform JITing (via RuntimeDyldChecker), and should fix some issues that David Fang has seen on PPC builds. llvm-svn: 213012
* [RuntimeDyld] Fix stub size and offset for AArch64 in RuntimeDyldMachO.h.Lang Hames2014-07-121-2/+10
| | | | | | <rdar://problem/17648000> llvm-svn: 212864
* [RuntimeDyld] Add GOT support for AArch64 to RuntimeDyldMachO.Lang Hames2014-07-111-24/+174
| | | | | | | | Test cases to follow once RuntimeDyldChecker supports introspection of stubs. Fixes <rdar://problem/17648000> llvm-svn: 212859
* [RuntimeDyld] Improve error diagnostic in RuntimeDyldChecker.Lang Hames2014-07-101-4/+15
| | | | | | | | | The compiler often emits assembler-local labels (beginning with 'L') for use in relocation expressions, however these aren't included in the object files. Teach RuntimeDyldChecker to warn the user if they try to use one of these in an expression, since it will never work. llvm-svn: 212777
* ExecutionEngine::create(): fix interpreter fallback when JIT is unavailableAlp Toker2014-07-011-7/+8
| | | | | | | | | | | ForceInterpreter=false shouldn't disable the interpreter completely because it can still be necessary to interpret if the target doesn't support JIT. No obvious way to test this in LLVM, but this matches what LLVMCreateExecutionEngineForModule() does and fixes the clang-interpreter example in the clang source tree which uses the ExecutionEngine. llvm-svn: 212086
* Fix build following r211956Alp Toker2014-06-281-1/+1
| | | | | | | RuntimeDyld now uses MCInst::dump_pretty() which introduces a dependency on 'MC'. llvm-svn: 211978
* [RuntimeDyld] Use a raw_ostream and llvm::format for int-to-string conversions.Lang Hames2014-06-271-17/+17
| | | | | | Some users' C++11 standard libraries don't support std::to_string yet. llvm-svn: 211961
* [RuntimeDyld] #include <cctype> header in RuntimeDyldChecker.cpp.Lang Hames2014-06-271-0/+1
| | | | | | Hopefully this will unbreak the windows bots. llvm-svn: 211958
* [RuntimeDyld] Add a framework for testing relocation logic in RuntimeDyld.Lang Hames2014-06-273-2/+654
| | | | | | | | | | | | | | | | | | | | 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
* Silencing some -Wcast-qual warnings. No functional changes intended.Aaron Ballman2014-06-271-2/+2
| | | | llvm-svn: 211923
* [RuntimeDyld, PowerPC] Fix/improve handling of TOC relocationsUlrich Weigand2014-06-272-56/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current PPC64 RuntimeDyld code to handle TOC relocations has two problems: - With recent linkers, in addition to the relocations that implicitly refer to the TOC base (R_PPC64_TOC*), you can now also use the .TOC. magic symbol with any other relocation to refer to the TOC base explicitly. This isn't currently used much in ELFv1 code (although it could be), but it is essential in ELFv2 code. - In a complex JIT environment with multiple modules, each module may have its own .toc section, and TOC relocations in one module must refer to *its own* TOC section. The current findPPC64TOC implementation does not correctly implement this; in fact, it will always return the address of the first TOC section it finds anywhere. (Note that at the time findPPC64TOC is called, we don't even *know* which module the relocation originally resided in, so it is not even possible to fix this routine as-is.) This commit fixes both problems by handling TOC relocations earlier, in processRelocationRef. To do this, I've removed the findPPC64TOC routine and replaced it by a new routine findPPC64TOCSection, which works analogously to findOPDEntrySection in scanning the sections of the ObjImage provided by its caller, processRelocationRef. This solves the issue of finding the correct TOC section associated with the current module. This makes it straightforward to implement both R_PPC64_TOC relocations, and relocations explicitly refering to the .TOC. symbol, directly in processRelocationRef. There is now a new problem in implementing the R_PPC64_TOC16* relocations, because those can now in theory involve *three* different sections: the relocation may be applied in section A, refer explicitly to a symbol in section B, and refer implicitly to the TOC section C. The final processing of the relocation thus may only happen after all three of these sections have been assigned final addresses. There is currently no obvious means to implement this in its general form with the common-code RuntimeDyld infrastructure. Fortunately, ppc64 code usually makes no use of this most general form; in fact, TOC16 relocations are only ever generated by LLVM for symbols residing themselves in the TOC, which means "section B" == "section C" in the above terminology. This special case can easily be handled with the current infrastructure, and that is what this patch does. [ Unhandled cases result in an explicit error, unlike the current code which silently returns the wrong TOC base address ... ] This patch makes the JIT work on both BE and LE (ELFv2 requires additional patches, of course), and allowed me to successfully run complex JIT scenarios (via mesa/llvmpipe). Reviewed by Hal Finkel. llvm-svn: 211885
* [RuntimeDyld] Teach MachOObjectImage to deregister itself with the debugger uponLang Hames2014-06-261-1/+4
| | | | | | destruction the same way ELFObjectImage does. llvm-svn: 211815
* [RuntimeDyld] Adds the necessary hooks to MCJIT to be able to debug generatedLang Hames2014-06-252-9/+124
| | | | | | | | MachO files using the GDB JIT debugging interface. Patch by Keno Fischer. Thanks Keno! llvm-svn: 211652
* Pass a unique_ptr<MemoryBuffer> to the constructors in the Binary hierarchy.Rafael Espindola2014-06-241-16/+20
| | | | | | | Once the objects are constructed, they own the buffer. Passing a unique_ptr makes that clear. llvm-svn: 211595
* Pass a std::unique_ptr& to the create??? methods is lib/Object.Rafael Espindola2014-06-231-1/+2
| | | | | | | | This makes the buffer ownership on error conditions very natural. The buffer is only moved out of the argument if an object is constructed that now owns the buffer. llvm-svn: 211546
* Revert "Replace Execution Engine's mutex with std::recursive_mutex."Zachary Turner2014-06-204-56/+57
| | | | | | | | | | This reverts commit 1f502bd9d7d2c1f98ad93a09ffe435e11a95aedd, due to GCC / MinGW's lack of support for C++11 threading. It's possible this will go back in after we come up with a reasonable solution. llvm-svn: 211401
* [RuntimeDyld] Fix ppc64 stub relocations on little-endianUlrich Weigand2014-06-201-5/+11
| | | | | | | | | | | | | | | When RuntimeDyldELF creates stub functions, it needs to install relocations that will resolve to the final address of the target routine. Since those are 16-bit relocs, they need to be applied to the least-significant halfword of the instruction. On big-endian ppc64, this means that addresses have to be adjusted by 2, which is what the code currently does. However, on a little-endian system, the address must *not* be adjusted; the least-significant halfword is the first one. This patch updates the RuntimeDyldELF code to take the target byte order into account. llvm-svn: 211384
* [RuntimeDyld] Support more PPC64 relocationsUlrich Weigand2014-06-201-4/+70
| | | | | | | | | | This adds support for several missing PPC64 relocations in the straight-forward manner to RuntimeDyldELF.cpp. Note that this actually fixes a failure of a large-model test case on PowerPC, allowing the XFAIL to be removed. llvm-svn: 211382
* Replace Execution Engine's mutex with std::recursive_mutex.Zachary Turner2014-06-184-57/+56
| | | | | | | | | | | | | This change has a bit of a trickle down effect due to the fact that there are a number of derived implementations of ExecutionEngine, and that the mutex is not tightly encapsulated so is used by other classes directly. Reviewed by: rnk Differential Revision: http://reviews.llvm.org/D4196 llvm-svn: 211214
* Remove more occurrences of the unused-mutex-parameter pattern.Zachary Turner2014-06-171-16/+9
| | | | | | | | | | | | | | | | This pattern loses some of its usefulness when the mutex type is statically polymorphic as opposed to runtime polymorphic, as swapping out the mutex type requires changing a significant number of function parameters, and templatizing the function parameter requires the methods to be defined in the headers. Furthermore, if LLVM is compiled with threads disabled then there may even be no mutex to acquire anyway, so it should not be up to individual APIs to know whether or not acquiring a mutex is required to use those APIs to begin with. It should be up to the user of the API. llvm-svn: 211125
* Cleanup more unreferenced MutexGuard parameters on functions.Zachary Turner2014-06-163-29/+29
| | | | | | | | | | | These parameters are intended to serve as sort of a contract that you cannot access the functions outside of a mutex. However, the entire JIT class cannot be accessed outside of a mutex anyway, and all methods acquire a lock as soon as they are entered. Since the containing class already is not intended to be thread-safe, it only serves to add code clutter. llvm-svn: 211071
* Clean up some unnecessary mutex guards.Zachary Turner2014-06-161-25/+24
| | | | | | | | | | | | | | | These were being used as unreferenced parameters to enforce that the methods must not be called without holding a mutex, but all of the methods in question were internal, and the methods were only exposed through an interface whose entire purpose was to serialize access to these structures, so expecting the methods to be accessed under a mutex is reasonable enough. Reviewed by: blaikie Differential Revision: http://reviews.llvm.org/D4162 llvm-svn: 211054
* Convert the Archive API to use ErrorOr.Rafael Espindola2014-06-161-2/+6
| | | | | | | | | Now that we have c++11, even things like ErrorOr<std::unique_ptr<...>> are easy to use. No intended functionality change. llvm-svn: 211033
* Using llvm::sys::swapByteOrder() for the common case of byte-swapping a ↵Artyom Skrobov2014-06-141-3/+3
| | | | | | value in place llvm-svn: 210978
* Renaming SwapByteOrder() to getSwappedBytes()Artyom Skrobov2014-06-141-3/+3
| | | | | | The next commit will add swapByteOrder(), acting in-place llvm-svn: 210973
* Remove 'using std::errro_code' from lib.Rafael Espindola2014-06-133-15/+12
| | | | llvm-svn: 210871
* Remove all uses of 'using std::error_code' from headers.Rafael Espindola2014-06-133-3/+3
| | | | llvm-svn: 210866
* Don't use 'using std::error_code' in include/llvm.Rafael Espindola2014-06-123-11/+14
| | | | | | This should make sure that most new uses use the std prefix. llvm-svn: 210835
* Remove system_error.h.Rafael Espindola2014-06-121-1/+1
| | | | | | | This is a minimal change to remove the header. I will remove the occurrences of "using std::error_code" in a followup patch. llvm-svn: 210803
* Add a Constant version of stripPointerCasts.Rafael Espindola2014-06-041-1/+1
| | | | | | Thanks to rnk for the suggestion. llvm-svn: 210205
* Allow alias to point to an arbitrary ConstantExpr.Rafael Espindola2014-06-031-2/+13
| | | | | | | | | | | | | | | | | | | | | This patch changes GlobalAlias to point to an arbitrary ConstantExpr and it is up to MC (or the system assembler) to decide if that expression is valid or not. This reduces our ability to diagnose invalid uses and how early we can spot them, but it also lets us do things like @test5 = alias inttoptr(i32 sub (i32 ptrtoint (i32* @test2 to i32), i32 ptrtoint (i32* @bar to i32)) to i32*) An important implication of this patch is that the notion of aliased global doesn't exist any more. The alias has to encode the information needed to access it in its metadata (linkage, visibility, type, etc). Another consequence to notice is that getSection has to return a "const char *". It could return a NullTerminatedStringRef if there was such a thing, but when that was proposed the decision was to just uses "const char*" for that. llvm-svn: 210062
* Updates in IntelJITEventListener.cpp - by Arch Robison.Elena Demikhovsky2014-06-011-2/+2
| | | | | | This patch updates IntelJITEventListener.cpp to account for revision 206654, which removed some methods from DILineInfo. llvm-svn: 209989
OpenPOWER on IntegriCloud