llvm-project/lld/lib/ReaderWriter/MachO/StubAtoms_x86_64.hpp

217 lines
6.1 KiB
C++
Raw Normal View History

//===- lib/ReaderWriter/MachO/StubAtoms_x86_64.hpp ------------------------===//
//
// The LLVM Linker
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
2013-11-15 11:09:26 +08:00
#ifndef LLD_READER_WRITER_MACHO_STUB_ATOMS_X86_64_H
#define LLD_READER_WRITER_MACHO_STUB_ATOMS_X86_64_H
#include "llvm/ADT/ArrayRef.h"
#include "lld/Core/DefinedAtom.h"
#include "lld/Core/SharedLibraryAtom.h"
#include "lld/Core/File.h"
#include "lld/Core/Reference.h"
#include "ReferenceKinds.h"
using llvm::makeArrayRef;
[lld] Introduce registry and Reference kind tuple The main changes are in: include/lld/Core/Reference.h include/lld/ReaderWriter/Reader.h Everything else is details to support the main change. 1) Registration based Readers Previously, lld had a tangled interdependency with all the Readers. It would have been impossible to make a streamlined linker (say for a JIT) which just supported one file format and one architecture (no yaml, no archives, etc). The old model also required a LinkingContext to read an object file, which would have made .o inspection tools awkward. The new model is that there is a global Registry object. You programmatically register the Readers you want with the registry object. Whenever you need to read/parse a file, you ask the registry to do it, and the registry tries each registered reader. For ease of use with the existing lld code base, there is one Registry object inside the LinkingContext object. 2) Changing kind value to be a tuple Beside Readers, the registry also keeps track of the mapping for Reference Kind values to and from strings. Along with that, this patch also fixes an ambiguity with the previous Reference::Kind values. The problem was that we wanted to reuse existing relocation type values as Reference::Kind values. But then how can the YAML write know how to convert a value to a string? The fix is to change the 32-bit Reference::Kind into a tuple with an 8-bit namespace (e.g. ELF, COFFF, etc), an 8-bit architecture (e.g. x86_64, PowerPC, etc), and a 16-bit value. This tuple system allows conversion to and from strings with no ambiguities. llvm-svn: 197727
2013-12-20 05:58:00 +08:00
using namespace llvm::MachO;
namespace lld {
namespace mach_o {
//
// X86_64 Stub Atom created by the stubs pass.
//
class X86_64StubAtom : public SimpleDefinedAtom {
public:
X86_64StubAtom(const File &file, const Atom &lazyPointer)
: SimpleDefinedAtom(file) {
this->addReference(Reference::KindNamespace::mach_o,
Reference::KindArch::x86_64, X86_64_RELOC_SIGNED, 2,
&lazyPointer, 0);
}
ContentType contentType() const override {
return DefinedAtom::typeStub;
}
uint64_t size() const override {
return 6;
}
ContentPermissions permissions() const override {
return DefinedAtom::permR_X;
}
ArrayRef<uint8_t> rawContent() const override {
static const uint8_t instructions[] =
{ 0xFF, 0x25, 0x00, 0x00, 0x00, 0x00 }; // jmp *lazyPointer
assert(sizeof(instructions) == this->size());
return makeArrayRef(instructions);
}
};
//
// X86_64 Stub Helper Common Atom created by the stubs pass.
//
class X86_64StubHelperCommonAtom : public SimpleDefinedAtom {
public:
X86_64StubHelperCommonAtom(const File &file, const Atom &cache,
const Atom &binder)
: SimpleDefinedAtom(file) {
this->addReference(Reference::KindNamespace::mach_o,
Reference::KindArch::x86_64, X86_64_RELOC_SIGNED, 3,
&cache, 0);
this->addReference(Reference::KindNamespace::mach_o,
Reference::KindArch::x86_64, X86_64_RELOC_SIGNED, 11,
&binder, 0);
}
ContentType contentType() const override {
return DefinedAtom::typeStubHelper;
}
uint64_t size() const override {
return 16;
}
ContentPermissions permissions() const override {
return DefinedAtom::permR_X;
}
ArrayRef<uint8_t> rawContent() const override {
static const uint8_t instructions[] =
{ 0x4C, 0x8D, 0x1D, 0x00, 0x00, 0x00, 0x00, // leaq cache(%rip),%r11
0x41, 0x53, // push %r11
0xFF, 0x25, 0x00, 0x00, 0x00, 0x00, // jmp *binder(%rip)
0x90 }; // nop
assert(sizeof(instructions) == this->size());
return makeArrayRef(instructions);
}
};
//
// X86_64 Stub Helper Atom created by the stubs pass.
//
class X86_64StubHelperAtom : public SimpleDefinedAtom {
public:
X86_64StubHelperAtom(const File &file, const Atom &helperCommon)
: SimpleDefinedAtom(file) {
this->addReference(Reference::KindNamespace::mach_o,
Reference::KindArch::x86_64,
[lld] Introduce registry and Reference kind tuple The main changes are in: include/lld/Core/Reference.h include/lld/ReaderWriter/Reader.h Everything else is details to support the main change. 1) Registration based Readers Previously, lld had a tangled interdependency with all the Readers. It would have been impossible to make a streamlined linker (say for a JIT) which just supported one file format and one architecture (no yaml, no archives, etc). The old model also required a LinkingContext to read an object file, which would have made .o inspection tools awkward. The new model is that there is a global Registry object. You programmatically register the Readers you want with the registry object. Whenever you need to read/parse a file, you ask the registry to do it, and the registry tries each registered reader. For ease of use with the existing lld code base, there is one Registry object inside the LinkingContext object. 2) Changing kind value to be a tuple Beside Readers, the registry also keeps track of the mapping for Reference Kind values to and from strings. Along with that, this patch also fixes an ambiguity with the previous Reference::Kind values. The problem was that we wanted to reuse existing relocation type values as Reference::Kind values. But then how can the YAML write know how to convert a value to a string? The fix is to change the 32-bit Reference::Kind into a tuple with an 8-bit namespace (e.g. ELF, COFFF, etc), an 8-bit architecture (e.g. x86_64, PowerPC, etc), and a 16-bit value. This tuple system allows conversion to and from strings with no ambiguities. llvm-svn: 197727
2013-12-20 05:58:00 +08:00
LLD_X86_64_RELOC_LAZY_IMMEDIATE, 1, this, 0);
this->addReference(Reference::KindNamespace::mach_o,
Reference::KindArch::x86_64, X86_64_RELOC_SIGNED, 6,
&helperCommon, 0);
}
ContentType contentType() const override {
return DefinedAtom::typeStubHelper;
}
uint64_t size() const override {
return 10;
}
ContentPermissions permissions() const override {
return DefinedAtom::permR_X;
}
ArrayRef<uint8_t> rawContent() const override {
static const uint8_t instructions[] =
{ 0x68, 0x00, 0x00, 0x00, 0x00, // pushq $lazy-info-offset
0xE9, 0x00, 0x00, 0x00, 0x00 }; // jmp helperhelper
assert(sizeof(instructions) == this->size());
return makeArrayRef(instructions);
}
};
//
// X86_64 Lazy Pointer Atom created by the stubs pass.
//
class X86_64LazyPointerAtom : public SimpleDefinedAtom {
public:
X86_64LazyPointerAtom(const File &file, const Atom &helper,
const Atom &shlib)
: SimpleDefinedAtom(file) {
this->addReference(Reference::KindNamespace::mach_o,
Reference::KindArch::x86_64, X86_64_RELOC_UNSIGNED, 0,
&helper, 0);
this->addReference(Reference::KindNamespace::mach_o,
Reference::KindArch::x86_64,
[lld] Introduce registry and Reference kind tuple The main changes are in: include/lld/Core/Reference.h include/lld/ReaderWriter/Reader.h Everything else is details to support the main change. 1) Registration based Readers Previously, lld had a tangled interdependency with all the Readers. It would have been impossible to make a streamlined linker (say for a JIT) which just supported one file format and one architecture (no yaml, no archives, etc). The old model also required a LinkingContext to read an object file, which would have made .o inspection tools awkward. The new model is that there is a global Registry object. You programmatically register the Readers you want with the registry object. Whenever you need to read/parse a file, you ask the registry to do it, and the registry tries each registered reader. For ease of use with the existing lld code base, there is one Registry object inside the LinkingContext object. 2) Changing kind value to be a tuple Beside Readers, the registry also keeps track of the mapping for Reference Kind values to and from strings. Along with that, this patch also fixes an ambiguity with the previous Reference::Kind values. The problem was that we wanted to reuse existing relocation type values as Reference::Kind values. But then how can the YAML write know how to convert a value to a string? The fix is to change the 32-bit Reference::Kind into a tuple with an 8-bit namespace (e.g. ELF, COFFF, etc), an 8-bit architecture (e.g. x86_64, PowerPC, etc), and a 16-bit value. This tuple system allows conversion to and from strings with no ambiguities. llvm-svn: 197727
2013-12-20 05:58:00 +08:00
LLD_X86_64_RELOC_LAZY_TARGET, 0, &shlib, 0);
}
ContentType contentType() const override {
return DefinedAtom::typeLazyPointer;
}
Alignment alignment() const override {
return Alignment(3);
}
uint64_t size() const override {
return 8;
}
ContentPermissions permissions() const override {
return DefinedAtom::permRW_;
}
ArrayRef<uint8_t> rawContent() const override {
static const uint8_t bytes[] =
{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
return makeArrayRef(bytes);
}
};
//
// X86_64 NonLazy (GOT) Pointer Atom created by the stubs pass.
//
class X86_64NonLazyPointerAtom : public SimpleDefinedAtom {
public:
X86_64NonLazyPointerAtom(const File &file)
: SimpleDefinedAtom(file) {}
X86_64NonLazyPointerAtom(const File &file, const Atom &shlib)
: SimpleDefinedAtom(file) {
this->addReference(Reference::KindNamespace::mach_o,
Reference::KindArch::x86_64, X86_64_RELOC_UNSIGNED, 0,
&shlib, 0);
}
ContentType contentType() const override {
return DefinedAtom::typeGOT;
}
Alignment alignment() const override {
return Alignment(3);
}
uint64_t size() const override {
return 8;
}
ContentPermissions permissions() const override {
return DefinedAtom::permRW_;
}
ArrayRef<uint8_t> rawContent() const override {
static const uint8_t bytes[] =
{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
return makeArrayRef(bytes);
}
};
} // namespace mach_o
} // namespace lld
2013-11-15 11:09:26 +08:00
#endif // LLD_READER_WRITER_MACHO_STUB_ATOMS_X86_64_H