2012-01-22 15:05:02 +08:00
|
|
|
//===-- RuntimeDyldELF.h - Run-time dynamic linker for MC-JIT ---*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// ELF support for MC-JIT runtime dynamic linker.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-08-14 00:26:38 +08:00
|
|
|
#ifndef LLVM_LIB_EXECUTIONENGINE_RUNTIMEDYLD_RUNTIMEDYLDELF_H
|
|
|
|
#define LLVM_LIB_EXECUTIONENGINE_RUNTIMEDYLD_RUNTIMEDYLDELF_H
|
2012-01-22 15:05:02 +08:00
|
|
|
|
|
|
|
#include "RuntimeDyldImpl.h"
|
2013-10-05 09:52:09 +08:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2012-01-22 15:05:02 +08:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
namespace llvm {
|
2012-10-29 18:47:04 +08:00
|
|
|
namespace {
|
2014-03-22 04:28:42 +08:00
|
|
|
// Helper for extensive error checking in debug builds.
|
2014-06-13 09:25:41 +08:00
|
|
|
std::error_code Check(std::error_code Err) {
|
2014-03-22 04:28:42 +08:00
|
|
|
if (Err) {
|
|
|
|
report_fatal_error(Err.message());
|
2012-10-29 18:47:04 +08:00
|
|
|
}
|
2014-03-22 04:28:42 +08:00
|
|
|
return Err;
|
|
|
|
}
|
[MCJIT] Clean up RuntimeDyld's quirky object-ownership/modification scheme.
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
2014-11-26 14:53:26 +08:00
|
|
|
|
2012-10-29 18:47:04 +08:00
|
|
|
} // end anonymous namespace
|
|
|
|
|
2012-01-22 15:05:02 +08:00
|
|
|
class RuntimeDyldELF : public RuntimeDyldImpl {
|
[MCJIT] Clean up RuntimeDyld's quirky object-ownership/modification scheme.
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
2014-11-26 14:53:26 +08:00
|
|
|
|
2014-03-22 04:28:42 +08:00
|
|
|
void resolveRelocation(const SectionEntry &Section, uint64_t Offset,
|
|
|
|
uint64_t Value, uint32_t Type, int64_t Addend,
|
|
|
|
uint64_t SymOffset = 0);
|
|
|
|
|
|
|
|
void resolveX86_64Relocation(const SectionEntry &Section, uint64_t Offset,
|
|
|
|
uint64_t Value, uint32_t Type, int64_t Addend,
|
2013-08-20 07:27:43 +08:00
|
|
|
uint64_t SymOffset);
|
2012-03-31 00:45:19 +08:00
|
|
|
|
2014-03-22 04:28:42 +08:00
|
|
|
void resolveX86Relocation(const SectionEntry &Section, uint64_t Offset,
|
|
|
|
uint32_t Value, uint32_t Type, int32_t Addend);
|
|
|
|
|
|
|
|
void resolveAArch64Relocation(const SectionEntry &Section, uint64_t Offset,
|
|
|
|
uint64_t Value, uint32_t Type, int64_t Addend);
|
|
|
|
|
|
|
|
void resolveARMRelocation(const SectionEntry &Section, uint64_t Offset,
|
|
|
|
uint32_t Value, uint32_t Type, int32_t Addend);
|
|
|
|
|
|
|
|
void resolveMIPSRelocation(const SectionEntry &Section, uint64_t Offset,
|
|
|
|
uint32_t Value, uint32_t Type, int32_t Addend);
|
|
|
|
|
|
|
|
void resolvePPC64Relocation(const SectionEntry &Section, uint64_t Offset,
|
|
|
|
uint64_t Value, uint32_t Type, int64_t Addend);
|
|
|
|
|
|
|
|
void resolveSystemZRelocation(const SectionEntry &Section, uint64_t Offset,
|
|
|
|
uint64_t Value, uint32_t Type, int64_t Addend);
|
2012-01-22 15:05:02 +08:00
|
|
|
|
2014-03-08 15:51:20 +08:00
|
|
|
unsigned getMaxStubSize() override {
|
2014-07-23 20:32:47 +08:00
|
|
|
if (Arch == Triple::aarch64 || Arch == Triple::aarch64_be)
|
2013-10-16 05:32:56 +08:00
|
|
|
return 20; // movz; movk; movk; movk; br
|
|
|
|
if (Arch == Triple::arm || Arch == Triple::thumb)
|
|
|
|
return 8; // 32-bit instruction and 32-bit address
|
|
|
|
else if (Arch == Triple::mipsel || Arch == Triple::mips)
|
|
|
|
return 16;
|
|
|
|
else if (Arch == Triple::ppc64 || Arch == Triple::ppc64le)
|
|
|
|
return 44;
|
|
|
|
else if (Arch == Triple::x86_64)
|
|
|
|
return 6; // 2-byte jmp instruction + 32-bit relative address
|
|
|
|
else if (Arch == Triple::systemz)
|
|
|
|
return 16;
|
|
|
|
else
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-03-08 15:51:20 +08:00
|
|
|
unsigned getStubAlignment() override {
|
2013-10-16 05:32:56 +08:00
|
|
|
if (Arch == Triple::systemz)
|
|
|
|
return 8;
|
|
|
|
else
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
[MCJIT] Clean up RuntimeDyld's quirky object-ownership/modification scheme.
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
2014-11-26 14:53:26 +08:00
|
|
|
void findPPC64TOCSection(const ObjectFile &Obj,
|
|
|
|
ObjSectionToIDMap &LocalSections,
|
[RuntimeDyld, PowerPC] Fix/improve handling of TOC relocations
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
2014-06-27 18:32:14 +08:00
|
|
|
RelocationValueRef &Rel);
|
[MCJIT] Clean up RuntimeDyld's quirky object-ownership/modification scheme.
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
2014-11-26 14:53:26 +08:00
|
|
|
void findOPDEntrySection(const ObjectFile &Obj,
|
|
|
|
ObjSectionToIDMap &LocalSections,
|
2012-10-25 21:13:48 +08:00
|
|
|
RelocationValueRef &Rel);
|
|
|
|
|
2013-08-20 07:27:43 +08:00
|
|
|
uint64_t findGOTEntry(uint64_t LoadAddr, uint64_t Offset);
|
|
|
|
size_t getGOTEntrySize();
|
|
|
|
|
2014-03-08 15:51:20 +08:00
|
|
|
void updateGOTEntries(StringRef Name, uint64_t Addr) override;
|
2013-08-20 07:27:43 +08:00
|
|
|
|
2014-01-25 01:20:08 +08:00
|
|
|
// Relocation entries for symbols whose position-independent offset is
|
2013-10-05 09:52:09 +08:00
|
|
|
// updated in a global offset table.
|
|
|
|
typedef SmallVector<RelocationValueRef, 2> GOTRelocations;
|
|
|
|
GOTRelocations GOTEntries; // List of entries requiring finalization.
|
|
|
|
SmallVector<std::pair<SID, GOTRelocations>, 8> GOTs; // Allocated tables.
|
2013-08-20 07:27:43 +08:00
|
|
|
|
2013-10-12 05:25:48 +08:00
|
|
|
// When a module is loaded we save the SectionID of the EH frame section
|
|
|
|
// in a table until we receive a request to register all unregistered
|
|
|
|
// EH frame sections with the memory manager.
|
|
|
|
SmallVector<SID, 2> UnregisteredEHFrameSections;
|
2013-10-16 08:14:21 +08:00
|
|
|
SmallVector<SID, 2> RegisteredEHFrameSections;
|
2013-10-12 05:25:48 +08:00
|
|
|
|
2012-01-22 15:05:02 +08:00
|
|
|
public:
|
[MCJIT] Clean up RuntimeDyld's quirky object-ownership/modification scheme.
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
2014-11-26 14:53:26 +08:00
|
|
|
RuntimeDyldELF(RTDyldMemoryManager *mm);
|
|
|
|
virtual ~RuntimeDyldELF();
|
|
|
|
|
|
|
|
std::unique_ptr<RuntimeDyld::LoadedObjectInfo>
|
|
|
|
loadObject(const object::ObjectFile &O) override;
|
2012-04-17 06:12:58 +08:00
|
|
|
|
2014-03-08 15:51:20 +08:00
|
|
|
void resolveRelocation(const RelocationEntry &RE, uint64_t Value) override;
|
2014-03-21 15:26:41 +08:00
|
|
|
relocation_iterator
|
|
|
|
processRelocationRef(unsigned SectionID, relocation_iterator RelI,
|
[MCJIT] Clean up RuntimeDyld's quirky object-ownership/modification scheme.
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
2014-11-26 14:53:26 +08:00
|
|
|
const ObjectFile &Obj,
|
|
|
|
ObjSectionToIDMap &ObjSectionToID,
|
2014-03-21 15:26:41 +08:00
|
|
|
const SymbolTableMap &Symbols, StubMap &Stubs) override;
|
[MCJIT] Clean up RuntimeDyld's quirky object-ownership/modification scheme.
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
2014-11-26 14:53:26 +08:00
|
|
|
bool isCompatibleFile(const object::ObjectFile &Obj) const override;
|
2014-03-08 15:51:20 +08:00
|
|
|
void registerEHFrames() override;
|
|
|
|
void deregisterEHFrames() override;
|
[MCJIT] Clean up RuntimeDyld's quirky object-ownership/modification scheme.
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
2014-11-26 14:53:26 +08:00
|
|
|
void finalizeLoad(const ObjectFile &Obj,
|
2014-05-13 05:39:59 +08:00
|
|
|
ObjSectionToIDMap &SectionMap) override;
|
2012-01-22 15:05:02 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
} // end namespace llvm
|
|
|
|
|
2012-03-31 00:45:19 +08:00
|
|
|
#endif
|