1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2025-01-31 12:41:49 +01:00

202 lines
7.2 KiB
C
Raw Normal View History

//===-- RuntimeDyldMachOX86_64.h ---- MachO/X86_64 specific code. -*- C++ -*-=//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#ifndef LLVM_LIB_EXECUTIONENGINE_RUNTIMEDYLD_TARGETS_RUNTIMEDYLDMACHOX86_64_H
#define LLVM_LIB_EXECUTIONENGINE_RUNTIMEDYLD_TARGETS_RUNTIMEDYLDMACHOX86_64_H
#include "../RuntimeDyldMachO.h"
#define DEBUG_TYPE "dyld"
namespace llvm {
class RuntimeDyldMachOX86_64
: public RuntimeDyldMachOCRTPBase<RuntimeDyldMachOX86_64> {
public:
typedef uint64_t TargetPtrT;
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through 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
2015-03-30 03:37:06 +00:00
RuntimeDyldMachOX86_64(RuntimeDyld::MemoryManager &MM,
RuntimeDyld::SymbolResolver &Resolver)
: RuntimeDyldMachOCRTPBase(MM, Resolver) {}
unsigned getMaxStubSize() override { return 8; }
unsigned getStubAlignment() override { return 1; }
relocation_iterator
processRelocationRef(unsigned SectionID, relocation_iterator RelI,
const ObjectFile &BaseObjT,
ObjSectionToIDMap &ObjSectionToID,
StubMap &Stubs) override {
const MachOObjectFile &Obj =
static_cast<const MachOObjectFile &>(BaseObjT);
MachO::any_relocation_info RelInfo =
Obj.getRelocation(RelI->getRawDataRefImpl());
uint32_t RelType = Obj.getAnyRelocationType(RelInfo);
if (RelType == MachO::X86_64_RELOC_SUBTRACTOR)
return processSubtractRelocation(SectionID, RelI, Obj, ObjSectionToID);
assert(!Obj.isRelocationScattered(RelInfo) &&
"Scattered relocations not supported on X86_64");
RelocationEntry RE(getRelocationEntry(SectionID, Obj, RelI));
RE.Addend = memcpyAddend(RE);
RelocationValueRef Value(
getRelocationValueRef(Obj, RelI, RE, ObjSectionToID));
bool IsExtern = Obj.getPlainRelocationExternal(RelInfo);
if (!IsExtern && RE.IsPCRel)
Remove getRelocationAddress. 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
2015-07-06 14:55:37 +00:00
makeValueAddendPCRel(Value, RelI, 1 << RE.Size);
if (RE.RelType == MachO::X86_64_RELOC_GOT ||
RE.RelType == MachO::X86_64_RELOC_GOT_LOAD)
processGOTRelocation(RE, Value, Stubs);
else {
RE.Addend = Value.Offset;
if (Value.SymbolName)
addRelocationForSymbol(RE, Value.SymbolName);
else
addRelocationForSection(RE, Value.SectionID);
}
return ++RelI;
}
void resolveRelocation(const RelocationEntry &RE, uint64_t Value) override {
DEBUG(dumpRelocationToResolve(RE, Value));
const SectionEntry &Section = Sections[RE.SectionID];
uint8_t *LocalAddress = Section.getAddressWithOffset(RE.Offset);
// If the relocation is PC-relative, the value to be encoded is the
// pointer difference.
if (RE.IsPCRel) {
// FIXME: It seems this value needs to be adjusted by 4 for an effective
// PC address. Is that expected? Only for branches, perhaps?
uint64_t FinalAddress = Section.getLoadAddressWithOffset(RE.Offset);
Value -= FinalAddress + 4;
}
switch (RE.RelType) {
default:
llvm_unreachable("Invalid relocation type!");
case MachO::X86_64_RELOC_SIGNED_1:
case MachO::X86_64_RELOC_SIGNED_2:
case MachO::X86_64_RELOC_SIGNED_4:
case MachO::X86_64_RELOC_SIGNED:
case MachO::X86_64_RELOC_UNSIGNED:
case MachO::X86_64_RELOC_BRANCH:
writeBytesUnaligned(Value + RE.Addend, LocalAddress, 1 << RE.Size);
break;
case MachO::X86_64_RELOC_SUBTRACTOR: {
uint64_t SectionABase = Sections[RE.Sections.SectionA].getLoadAddress();
uint64_t SectionBBase = Sections[RE.Sections.SectionB].getLoadAddress();
assert((Value == SectionABase || Value == SectionBBase) &&
"Unexpected SUBTRACTOR relocation value.");
Value = SectionABase - SectionBBase + RE.Addend;
writeBytesUnaligned(Value, LocalAddress, 1 << RE.Size);
break;
}
case MachO::X86_64_RELOC_GOT_LOAD:
case MachO::X86_64_RELOC_GOT:
case MachO::X86_64_RELOC_TLV:
Error("Relocation type not implemented yet!");
}
}
void finalizeSection(const ObjectFile &Obj, unsigned SectionID,
const SectionRef &Section) {}
private:
void processGOTRelocation(const RelocationEntry &RE,
RelocationValueRef &Value, StubMap &Stubs) {
SectionEntry &Section = Sections[RE.SectionID];
assert(RE.IsPCRel);
assert(RE.Size == 2);
Value.Offset -= RE.Addend;
RuntimeDyldMachO::StubMap::const_iterator i = Stubs.find(Value);
uint8_t *Addr;
if (i != Stubs.end()) {
Addr = Section.getAddressWithOffset(i->second);
} else {
Stubs[Value] = Section.getStubOffset();
uint8_t *GOTEntry = Section.getAddressWithOffset(Section.getStubOffset());
RelocationEntry GOTRE(RE.SectionID, Section.getStubOffset(),
MachO::X86_64_RELOC_UNSIGNED, Value.Offset, false,
3);
if (Value.SymbolName)
addRelocationForSymbol(GOTRE, Value.SymbolName);
else
addRelocationForSection(GOTRE, Value.SectionID);
Section.advanceStubOffset(8);
Addr = GOTEntry;
}
RelocationEntry TargetRE(RE.SectionID, RE.Offset,
MachO::X86_64_RELOC_UNSIGNED, RE.Addend, true, 2);
resolveRelocation(TargetRE, (uint64_t)Addr);
}
relocation_iterator
processSubtractRelocation(unsigned SectionID, relocation_iterator RelI,
const ObjectFile &BaseObjT,
ObjSectionToIDMap &ObjSectionToID) {
const MachOObjectFile &Obj =
static_cast<const MachOObjectFile&>(BaseObjT);
MachO::any_relocation_info RE =
Obj.getRelocation(RelI->getRawDataRefImpl());
unsigned Size = Obj.getAnyRelocationLength(RE);
uint64_t Offset = RelI->getOffset();
uint8_t *LocalAddress = Sections[SectionID].getAddressWithOffset(Offset);
unsigned NumBytes = 1 << Size;
Thread Expected<...> up from libObject’s getName() for symbols to allow 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
2016-04-20 21:24:34 +00:00
Expected<StringRef> SubtrahendNameOrErr = RelI->getSymbol()->getName();
if (!SubtrahendNameOrErr) {
std::string Buf;
raw_string_ostream OS(Buf);
logAllUnhandledErrors(SubtrahendNameOrErr.takeError(), OS, "");
OS.flush();
report_fatal_error(Buf);
}
auto SubtrahendI = GlobalSymbolTable.find(*SubtrahendNameOrErr);
unsigned SectionBID = SubtrahendI->second.getSectionID();
uint64_t SectionBOffset = SubtrahendI->second.getOffset();
int64_t Addend =
SignExtend64(readBytesUnaligned(LocalAddress, NumBytes), NumBytes * 8);
++RelI;
Thread Expected<...> up from libObject’s getName() for symbols to allow 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
2016-04-20 21:24:34 +00:00
Expected<StringRef> MinuendNameOrErr = RelI->getSymbol()->getName();
if (!MinuendNameOrErr) {
std::string Buf;
raw_string_ostream OS(Buf);
logAllUnhandledErrors(MinuendNameOrErr.takeError(), OS, "");
OS.flush();
report_fatal_error(Buf);
}
auto MinuendI = GlobalSymbolTable.find(*MinuendNameOrErr);
unsigned SectionAID = MinuendI->second.getSectionID();
uint64_t SectionAOffset = MinuendI->second.getOffset();
RelocationEntry R(SectionID, Offset, MachO::X86_64_RELOC_SUBTRACTOR, (uint64_t)Addend,
SectionAID, SectionAOffset, SectionBID, SectionBOffset,
false, Size);
addRelocationForSection(R, SectionAID);
return ++RelI;
}
};
}
#undef DEBUG_TYPE
#endif