[iovisor-dev] [PATCH, BPF 1/5] BPF: Use a provisional ELF e_machine value

This same value for EM_BPF is being propagated to glibc,
elfutils, and binutils.

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.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

was 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.

This same value for EM_BPF is being propagated to glibc,
elfutils, and binutils.

great!
Can you share the link to glibc and the other patches?

https://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.

+ EM_BPF = 0xeb9f, // Linux kernel bpf virtual machine

was 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.

No, it's an unofficial number. But there's history for this.
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@sco.com 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~

This same value for EM_BPF is being propagated to glibc,
elfutils, and binutils.

great!
Can you share the link to glibc and the other patches?

Richard Henderson - [PATCH] elf: Add declarations for BPF

[PATCH] Add support for BPF - elfutils-devel - Fedora Mailing-Lists

I haven't sent one yet for binutils.

+ EM_BPF = 0xeb9f, // Linux kernel bpf virtual machine

Great, can that be assumed the final magic e_machine number for the ELF
header that eBPF loaders can check for as well then (I do like 0xeb9f ;))?

I'm quite fond of 0xeb9f myself. :wink:

I have sent a message to both registry@sco.com and registry@uxsglobal.com.
We'll see if that produces a response within a reasonable time frame. Failing
that, I'm tempted to just use 0xeb9f forever.

r~

Yeah, sounds good!

I got a response from registry@xinuos.com (registery@sco.com forwards to
there I believe). It took about 6 months to get a number assigned.