This group is locked. No changes can be made to the group while it is locked.
Date
1 - 6 of 6
[PATCH, BPF 1/5] BPF: Use a provisional ELF e_machine value
|
Richard Henderson <rth@...>
This same value for EM_BPF is being propagated to glibc,
elfutils, and binutils. Signed-off-by: Richard Henderson <rth@...> --- include/llvm/Object/ELFObjectFile.h | 5 +++++ include/llvm/Support/ELF.h | 7 +++++++ include/llvm/Support/ELFRelocs/BPF.def | 9 +++++++++ lib/Object/ELF.cpp | 7 +++++++ lib/ObjectYAML/ELFYAML.cpp | 4 ++++ lib/Target/BPF/MCTargetDesc/BPFELFObjectWriter.cpp | 7 ++++++- tools/llvm-objdump/llvm-objdump.cpp | 1 + tools/llvm-readobj/ELFDumper.cpp | 1 + 8 files changed, 40 insertions(+), 1 deletion(-) create mode 100644 include/llvm/Support/ELFRelocs/BPF.def diff --git a/include/llvm/Object/ELFObjectFile.h b/include/llvm/Object/ELFObjectFile.h index 52cde1a..6911491 100644 --- a/include/llvm/Object/ELFObjectFile.h +++ b/include/llvm/Object/ELFObjectFile.h @@ -876,6 +876,8 @@ StringRef ELFObjectFile<ELFT>::getFileFormatName() const { return (EF.getHeader()->e_ident[ELF::EI_OSABI] == ELF::ELFOSABI_AMDGPU_HSA && IsLittleEndian) ? "ELF64-amdgpu-hsacobj" : "ELF64-amdgpu"; + case ELF::EM_BPF: + return "ELF64-BPF"; default: return "ELF64-unknown"; } @@ -938,6 +940,9 @@ unsigned ELFObjectFile<ELFT>::getArch() const { && IsLittleEndian) ? Triple::amdgcn : Triple::UnknownArch; + case ELF::EM_BPF: + return (IsLittleEndian ? Triple::bpfel : Triple::bpfeb); + default: return Triple::UnknownArch; } diff --git a/include/llvm/Support/ELF.h b/include/llvm/Support/ELF.h index 352fd8a..fb8ff71 100644 --- a/include/llvm/Support/ELF.h +++ b/include/llvm/Support/ELF.h @@ -320,6 +320,8 @@ enum { // an official value for Lanai. As soon as one is allocated, this enum will be // updated to use it. EM_LANAI = 0x8123, // Lanai 32-bit processor + + EM_BPF = 0xeb9f, // Linux kernel bpf virtual machine }; // Object file classes. @@ -614,6 +616,11 @@ enum { #include "ELFRelocs/WebAssembly.def" }; +// ELF Relocation types for BPF +enum { +#include "ELFRelocs/BPF.def" +}; + #undef ELF_RELOC // Section header. diff --git a/include/llvm/Support/ELFRelocs/BPF.def b/include/llvm/Support/ELFRelocs/BPF.def new file mode 100644 index 0000000..868974d --- /dev/null +++ b/include/llvm/Support/ELFRelocs/BPF.def @@ -0,0 +1,9 @@ +#ifndef ELF_RELOC +#error "ELF_RELOC must be defined" +#endif + +// No relocation +ELF_RELOC(R_BPF_NONE, 0) +// Map index in "maps" section to file descriptor +// within ld_64 instruction. +ELF_RELOC(R_BPF_MAP_FD, 1) diff --git a/lib/Object/ELF.cpp b/lib/Object/ELF.cpp index 9509389..4314ccc 100644 --- a/lib/Object/ELF.cpp +++ b/lib/Object/ELF.cpp @@ -105,6 +105,13 @@ StringRef getELFRelocationTypeName(uint32_t Machine, uint32_t Type) { break; } break; + case ELF::EM_BPF: + switch (Type) { +#include "llvm/Support/ELFRelocs/BPF.def" + default: + break; + } + break; default: break; } diff --git a/lib/ObjectYAML/ELFYAML.cpp b/lib/ObjectYAML/ELFYAML.cpp index 8e39a24..4a570d3 100644 --- a/lib/ObjectYAML/ELFYAML.cpp +++ b/lib/ObjectYAML/ELFYAML.cpp @@ -195,6 +195,7 @@ ScalarEnumerationTraits<ELFYAML::ELF_EM>::enumeration(IO &IO, ECase(EM_56800EX) ECase(EM_AMDGPU) ECase(EM_LANAI) + ECase(EM_BPF) #undef ECase } @@ -531,6 +532,9 @@ void ScalarEnumerationTraits<ELFYAML::ELF_REL>::enumeration( case ELF::EM_LANAI: #include "llvm/Support/ELFRelocs/Lanai.def" break; + case ELF::EM_BPF: +#include "llvm/Support/ELFRelocs/BPF.def" + break; default: llvm_unreachable("Unsupported architecture"); } diff --git a/lib/Target/BPF/MCTargetDesc/BPFELFObjectWriter.cpp b/lib/Target/BPF/MCTargetDesc/BPFELFObjectWriter.cpp index 115f010..50a88b7 100644 --- a/lib/Target/BPF/MCTargetDesc/BPFELFObjectWriter.cpp +++ b/lib/Target/BPF/MCTargetDesc/BPFELFObjectWriter.cpp @@ -28,7 +28,7 @@ protected: } BPFELFObjectWriter::BPFELFObjectWriter(uint8_t OSABI) - : MCELFObjectTargetWriter(/*Is64Bit*/ true, OSABI, ELF::EM_NONE, + : MCELFObjectTargetWriter(/*Is64Bit*/ true, OSABI, ELF::EM_BPF, /*HasRelocationAddend*/ false) {} BPFELFObjectWriter::~BPFELFObjectWriter() {} @@ -37,6 +37,11 @@ unsigned BPFELFObjectWriter::getRelocType(MCContext &Ctx, const MCValue &Target, const MCFixup &Fixup, bool IsPCRel) const { // determine the type of the relocation + // ??? Give these some proper names. + // ??? Note that R_BPF_MAP_FD (= R_X86_64_64) is the only relocation + // supported by the loader. Which others of these actually need + // to be emitted in the circumstances? + switch ((unsigned)Fixup.getKind()) { default: llvm_unreachable("invalid fixup kind!"); diff --git a/tools/llvm-objdump/llvm-objdump.cpp b/tools/llvm-objdump/llvm-objdump.cpp index 38550b9..fceb331 100644 --- a/tools/llvm-objdump/llvm-objdump.cpp +++ b/tools/llvm-objdump/llvm-objdump.cpp @@ -583,6 +583,7 @@ static std::error_code getRelocationValueString(const ELFObjectFile<ELFT> *Obj, case ELF::EM_ARM: case ELF::EM_HEXAGON: case ELF::EM_MIPS: + case ELF::EM_BPF: res = Target; break; case ELF::EM_WEBASSEMBLY: diff --git a/tools/llvm-readobj/ELFDumper.cpp b/tools/llvm-readobj/ELFDumper.cpp index 1f45b79..9447f83 100644 --- a/tools/llvm-readobj/ELFDumper.cpp +++ b/tools/llvm-readobj/ELFDumper.cpp @@ -948,6 +948,7 @@ static const EnumEntry<unsigned> ElfMachineType[] = { ENUM_ENT(EM_AMDGPU, "EM_AMDGPU"), ENUM_ENT(EM_WEBASSEMBLY, "EM_WEBASSEMBLY"), ENUM_ENT(EM_LANAI, "EM_LANAI"), + ENUM_ENT(EM_BPF, "EM_BPF"), }; static const EnumEntry<unsigned> ElfSymbolBindings[] = { -- 2.5.5 |
|
Alexei Starovoitov
On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-dev
<iovisor-dev@...> wrote: This same value for EM_BPF is being propagated to glibc,great! Can you share the link to glibc and the other patches? diff --git a/include/llvm/Support/ELF.h b/include/llvm/Support/ELF.hwas this id reserved this with whoever managing the numbers ? The only reason bpf backend used em_none is that we were couldn't figure out who's responsible for keeping these records. |
|
Richard Henderson <rth@...>
On 06/15/2016 10:14 PM, Alexei Starovoitov wrote:
On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-devhttps://sourceware.org/ml/libc-alpha/2016-06/msg00212.html https://lists.fedorahosted.org/archives/list/elfutils-devel@lists.fedorahosted.org/message/OEOF26ZHEJLHPOMRMOGDXTMYXUHPWVGA/ I haven't sent one yet for binutils. No, it's an unofficial number. But there's history for this.+ EM_BPF = 0xeb9f, // Linux kernel bpf virtual machinewas this id reserved this with whoever managing the numbers ? In binutils there's a comment /* If it is necessary to assign new unofficial EM_* values, please pick large random numbers (0x8523, 0xa7f2, etc.) to minimize the chances of collision with official or non-GNU unofficial values. NOTE: Do not just increment the most recent number by one. Somebody else somewhere will do exactly the same thing, and you will have a collision. Instead, pick a random number. Normally, each entity or maintainer responsible for a machine with an unofficial e_machine number should eventually ask registry@... for an officially blessed number to be added to the list above. */ It used to take years to get sco to answer such emails. r~ |
|
Daniel Borkmann
On 06/16/2016 06:57 PM, Richard Henderson via iovisor-dev wrote:
On 06/15/2016 10:14 PM, Alexei Starovoitov wrote:Great, can that be assumed the final magic e_machine number for the ELFOn Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-devhttps://sourceware.org/ml/libc-alpha/2016-06/msg00212.html header that eBPF loaders can check for as well then (I do like 0xeb9f ;))? was this id reserved this with whoever managing the numbers ?No, it's an unofficial number. But there's history for this. |
|
Richard Henderson <rth@...>
On 06/16/2016 12:55 PM, Daniel Borkmann wrote:
I'm quite fond of 0xeb9f myself. ;-)Great, can that be assumed the final magic e_machine number for the ELF+ EM_BPF = 0xeb9f, // Linux kernel bpf virtual machine I have sent a message to both registry@... and registry@.... We'll see if that produces a response within a reasonable time frame. Failing that, I'm tempted to just use 0xeb9f forever. r~ |
|
Daniel Borkmann
On 06/16/2016 10:59 PM, Richard Henderson wrote:
On 06/16/2016 12:55 PM, Daniel Borkmann wrote:Yeah, sounds good!I'm quite fond of 0xeb9f myself. ;-)Great, can that be assumed the final magic e_machine number for the ELF+ EM_BPF = 0xeb9f, // Linux kernel bpf virtual machine |