summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* AArch64: remove arm64 triple enumerator.Tim Northover2014-07-231-6/+1
| | | | | | | | | | | | Having both Triple::arm64 and Triple::aarch64 is extremely confusing, and invites bugs where only one is checked. In reality, the only legitimate difference between the two (arm64 usually means iOS) is also present in the OS part of the triple and that's what should be checked. We still parse the "arm64" triple, just canonicalise it to Triple::aarch64, so there aren't any LLVM-side test changes. llvm-svn: 213743
* [PowerPC] ELFv2 dynamic loader supportUlrich Weigand2014-07-201-7/+24
| | | | | | | | | | | | | | | | | | | | | 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
* [RuntimeDyld, PowerPC] Fix/improve handling of TOC relocationsUlrich Weigand2014-06-271-55/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* [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
* Remove 'using std::errro_code' from lib.Rafael Espindola2014-06-131-8/+7
| | | | llvm-svn: 210871
* Remove all uses of 'using std::error_code' from headers.Rafael Espindola2014-06-131-0/+1
| | | | llvm-svn: 210866
* [RuntimeDyld] Add support for MachO __jump_table and __pointers sections, andLang Hames2014-05-121-1/+2
| | | | | | | | | | | SECTDIFF relocations on 32-bit x86. This fixes several of the MCJIT regression test failures that show up on 32-bit builds. <rdar://problem/16886294> llvm-svn: 208635
* [ARM64] Try and make the ELF MCJIT *slightly* less broken for ARM64.James Molloy2014-04-301-1/+7
| | | | | | | | | A bunch of switch cases were missing, not just for ARM64 but also for AArch64_BE. I've fixed all those, but there's zero testing as ExecutionEngine tests are disabled when crosscompiling and I don't have a native platform available to test on. llvm-svn: 207626
* Fix the build with MSVC 2013 by explicitly requesting llvm::make_uniqueReid Kleckner2014-04-291-13/+17
| | | | | | | MSVC 2013 provides std::make_unique, which it finds with ADL when one of the parameters is std::unique_ptr, leading to an ambiguous overload. llvm-svn: 207597
* PR19553: Memory leak in RuntimeDyldELF::createObjectImageFromFileDavid Blaikie2014-04-291-32/+48
| | | | | | | | | | | | | | | | This starts in MCJIT::getSymbolAddress where the unique_ptr<object::Binary> is release()d and (after a cast) passed to a single caller, MCJIT::addObjectFile. addObjectFile calls RuntimeDyld::loadObject. RuntimeDld::loadObject calls RuntimeDyldELF::createObjectFromFile And the pointer is never owned at this point. I say this point, because the alternative codepath, RuntimeDyldMachO::createObjectFile certainly does take ownership, so this seemed like a good hint that this was a/the right place to take ownership. llvm-svn: 207580
* [C++] Use 'nullptr'.Craig Topper2014-04-241-8/+9
| | | | llvm-svn: 207083
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-1/+2
| | | | | | | definition below all the header #include lines. This updates most of the miscellaneous other lib/... directories. A few left though. llvm-svn: 206845
* Add ARM big endian Target (armeb, thumbeb)Christian Pirker2014-03-281-0/+2
| | | | | | Reviewed at http://llvm-reviews.chandlerc.com/D3095 llvm-svn: 205007
* AArch64_BE Elf support for MC-JIT runtime dynamic linkerChristian Pirker2014-03-261-0/+1
| | | | llvm-svn: 204816
* [RuntimeDyld] clang-format files.Juergen Ributzka2014-03-211-380/+312
| | | | llvm-svn: 204507
* [RuntimeDyld] Allow processRelocationRef to process more than one relocation ↵Juergen Ributzka2014-03-211-10/+12
| | | | | | | | | | | | | entry at a time. Some targets require more than one relocation entry to perform a relocation. This change allows processRelocationRef to process more than one relocation entry at a time by passing the relocation iterator itself instead of just the relocation entry. Related to <rdar://problem/16199095> llvm-svn: 204439
* [ppc64] Patch in TOC restore code after all external function callsUlrich Weigand2014-03-111-3/+3
| | | | | | | | | | | | | | | | When resolving a function call to an external routine, the dynamic loader must patch the "nop" after the branch instruction to a load that restores the TOC register. Current code does that, but only with the *first* instance of a call to any particular external routine, i.e. at the point where it also allocates the call stub. With subsequent calls to the same routine, current code neglects to patch in the TOC restore code. This is a bug, and leads to corrupt TOC pointers in those cases. Fixed by patching in restore code every time. llvm-svn: 203580
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-081-8/+4
| | | | | | class. llvm-svn: 203344
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-061-1/+0
| | | | | | | | | | This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
* Consistently check 'IsCode' when allocating sections in RuntimeDyld (viaLang Hames2014-02-181-1/+3
| | | | | | | | | | | | | | findOrEmitSection). Vaidas Gasiunas's patch, r201259, fixed one instance where we were always allocating sections as text. This patch fixes the remaining buggy call sites. No test case: This isn't breaking anything that I know of, it's just inconsistent. <rdar://problem/15943542> llvm-svn: 201605
* [AArch64] Add missing PCRel relocations for AArch64 in RuntimeDyldELFBradley Smith2014-02-111-0/+42
| | | | llvm-svn: 201149
* Change the begin and end methods in ObjectFile to match the style guide.Rafael Espindola2014-02-101-2/+2
| | | | llvm-svn: 201108
* Simplify the handling of iterators in ObjectFile.Rafael Espindola2014-01-301-9/+4
| | | | | | | | | | | | None of the object file formats reported error on iterator increment. In retrospect, that is not too surprising: no object format stores symbols or sections in a linked list or other structure that requires chasing pointers. As a consequence, all error checking can be done on begin() and end(). This reduces the text segment of bin/llvm-readobj in my machine from 521233 to 518526 bytes. llvm-svn: 200442
* Enable EHABI by defaultRenato Golin2014-01-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | After all hard work to implement the EHABI and with the test-suite passing, it's time to turn it on by default and allow users to disable it as a work-around while we fix the eventual bugs that show up. This commit also remove the -arm-enable-ehabi-descriptors, since we want the tables to be printed every time the EHABI is turned on for non-Darwin ARM targets. Although MCJIT EHABI is not working yet (needs linking with the right libraries), this commit also fixes some relocations on MCJIT regarding the EH tables/lib calls, and update some tests to avoid using EH tables when none are needed. The EH tests in the test-suite that were previously disabled on ARM now pass with these changes, so a follow-up commit on the test-suite will re-enable them. llvm-svn: 200388
* Re-apply r196639: Add support for archives and object file caching under MCJIT.Lang Hames2014-01-081-0/+40
| | | | | | | | | I believe the bot failures on linux systems were due to overestimating the alignment of object-files within archives, which are only guaranteed to be two-byte aligned. I have reduced the alignment in RuntimeDyldELF::createObjectImageFromFile accordingly. llvm-svn: 198737
* Revert r196639 while I investigate a bot failure.Lang Hames2013-12-071-40/+0
| | | | llvm-svn: 196641
* Add support for archives and object file caching under MCJIT.Lang Hames2013-12-071-0/+40
| | | | | | Patch by Andy Kaylor, with minor edits to resolve merge conflicts. llvm-svn: 196639
* [mips] Resolve relocation for the stubs in MCJIT when load address is knownPetar Jovanovic2013-11-191-5/+4
| | | | | | | | | | Instead of processing relocation for branch to stubs right away, emit a modified relocation and add it to queue to be resolved later when final load address is known. This resolves seven MIPS MCJIT issues that were caused by missing relocation fixups at the end. llvm-svn: 195157
* Adding support for deregistering EH frames with MCJIT.Andrew Kaylor2013-10-161-0/+14
| | | | | | Patch by Yaron Keren llvm-svn: 192753
* Adding multiple object support to MCJIT EH frame handlingAndrew Kaylor2013-10-111-6/+24
| | | | llvm-svn: 192504
* Adding multiple GOT handling to RuntimeDyldELFAndrew Kaylor2013-10-051-55/+73
| | | | | | Patch by Ashok Thirumurthi llvm-svn: 192020
* This threads SectionName through the allocateCodeSection/allocateDataSection ↵Filip Pizlo2013-10-021-2/+2
| | | | | | | | | | | | | | | | | | APIs, both in C++ and C land. It's useful for the memory managers that are allocating a section to know what the name of the section is. At a minimum, this is useful for low-level debugging - it's customary for JITs to be able to tell you what memory they allocated, and as part of any such dump, they should be able to tell you some meta-data about what each allocation is for. This allows clients that supply their own memory managers to do this. Additionally, we also envision the SectionName being useful for passing meta-data from within LLVM to an LLVM client. This changes both the C and C++ APIs, and all of the clients of those APIs within LLVM. I'm assuming that it's safe to change the C++ API because that API is allowed to change. I'm assuming that it's safe to change the C API because we haven't shipped the API in a release yet (LLVM 3.3 doesn't include the MCJIT memory management C API). llvm-svn: 191804
* Adding PIC support for ELF on x86_64 platformsAndrew Kaylor2013-08-191-6/+196
| | | | llvm-svn: 188726
* Adding comments to document RuntimeDyld relocation handlingAndrew Kaylor2013-08-191-1/+21
| | | | llvm-svn: 188697
* Fixed RuntimeDyldELF absolute relocations.Richard Mitton2013-08-161-1/+11
| | | | | | | | | If an ELF relocation is pointed at an absolute address, it will have a symbol ID of zero. RuntimeDyldELF::processRelocationRef was not previously handling this case, and was instead trying to handle it as a section-relative fixup. I think this is the right fix here, but my elf-fu is poor on some of the more exotic platforms, so I'd appreciate it if anyone with greater knowledge could verify this. llvm-svn: 188572
* [Object] Split the ELF interface into 3 parts.Michael J. Spencer2013-08-081-4/+3
| | | | | | | | * ELFTypes.h contains template magic for defining types based on endianess, size, and alignment. * ELFFile.h defines the ELFFile class which provides low level ELF specific access. * ELFObjectFile.h contains ELFObjectFile which uses ELFFile to implement the ObjectFile interface. llvm-svn: 188022
* [PowerPC] Support powerpc64le as a syntax-checking target.Bill Schmidt2013-07-261-2/+3
| | | | | | | | | | | | | | | | | | | | | | | This patch provides basic support for powerpc64le as an LLVM target. However, use of this target will not actually generate little-endian code. Instead, use of the target will cause the correct little-endian built-in defines to be generated, so that code that tests for __LITTLE_ENDIAN__, for example, will be correctly parsed for syntax-only testing. Code generation will otherwise be the same as powerpc64 (big-endian), for now. The patch leaves open the possibility of creating a little-endian PowerPC64 back end, but there is no immediate intent to create such a thing. The LLVM portions of this patch simply add ppc64le coverage everywhere that ppc64 coverage currently exists. There is nothing of any import worth testing until such time as little-endian code generation is implemented. In the corresponding Clang patch, there is a new test case variant to ensure that correct built-in defines for little-endian code are generated. llvm-svn: 187179
* AArch64: don't mask off shift bits when processing JIT relocations.Tim Northover2013-07-251-4/+4
| | | | | | | This should actually make the MCJIT tests pass again on AArch64. I don't know how I missed their failure before. llvm-svn: 187120
* [mips] Use pristine object file while processing relocations.Akira Hatanaka2013-07-241-7/+20
| | | | | | | | | | | | | | | | | | | Similar to ARM change r182800, dynamic linker will read bits/addends from the original object rather than from the object that might have been patched previously. For the purpose of relocations for MCJIT stubs on MIPS, we internally use otherwise unused MIPS relocations. The change also enables MCJIT unit tests for MIPS (EL/BE), and the following two tests now pass: - MCJITTest.return_global and - MCJITTest.multiple_functions. These issues have been tracked as Bug 16250. Patch by Petar Jovanovic. llvm-svn: 187019
* AArch64: correct CodeGen of MOVZ/MOVK combinations.Tim Northover2013-07-011-7/+8
| | | | | | | | | | | | According to the AArch64 ELF specification (4.6.8), it's the assembler's responsibility to make sure the shift amount is correct in relocated MOVZ/MOVK instructions. This wasn't being obeyed by either the MCJIT CodeGen or RuntimeDyldELF (which happened to work out well for JIT tests). This commit should make us compliant in this area. llvm-svn: 185360
* Handle (at least don't crash on) relocations with no symbols.Rafael Espindola2013-06-051-6/+11
| | | | | | Should fix the MCJIT tests on PPC. llvm-svn: 183288
* Handle relocations that don't point to symbols.Rafael Espindola2013-06-051-8/+6
| | | | | | | | In ELF (as in MachO), not all relocations point to symbols. Represent this properly by using a symbol_iterator instead of a SymbolRef. Update llvm-readobj ELF's dumper to handle relocatios without symbols. llvm-svn: 183284
* Update RuntimeDyldELF::findOPDEntrySection the new relocation iterators.Rafael Espindola2013-06-031-3/+7
| | | | | | | This was missing from r182908. I didn't noticed it at the time because the MCJIT tests were disabled when building with cmake on ppc64 (which I fixed in r183143). llvm-svn: 183147
* ARM: use pristine object file while processing relocationsTim Northover2013-05-281-15/+23
| | | | | | | | | | | | | | Previously we would read-modify-write the target bits when processing relocations for the MCJIT. This had the problem that when relocations were processed multiple times for the same object file (as they can be), the result is not idempotent and the values became corrupted. The solution to this is to take any bits used in the destination from the pristine object file as LLVM emitted it. This should fix PR16013 and remote MCJIT on ARM ELF targets. llvm-svn: 182800
* AArch64: make RuntimeDyld relocations idempotentTim Northover2013-05-191-2/+22
| | | | | | | | | | AArch64 ELF uses .rela relocations so there's no need to actually make use of the bits we're setting in the destination However, we should make sure all bits are cleared properly since multiple runs of resolveRelocations are possible and these could combine to produce invalid results if stale versions remain in the code. llvm-svn: 182214
* r182085 introduced a change that triggered an assertion on ARM. This is an ↵David Tweed2013-05-171-2/+4
| | | | | | | | immediate fix which doesn't resolve the deeper problem. llvm-svn: 182098
* Change getRelocationAdditionalInfo to be ELF only.Rafael Espindola2013-05-091-4/+4
| | | | | | | It was only implemented for ELF where it collected the Addend, so this patch also renames it to getRelocationAddend. llvm-svn: 181502
* PowerPC: Fix unimplemented relocation on ppc64Adhemerval Zanella2013-05-061-0/+5
| | | | | | | This patch handles the R_PPC64_REL64 relocation type for powerpc64 for mcjit. llvm-svn: 181220
OpenPOWER on IntegriCloud