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

On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-dev
<iovisor-dev at lists.iovisor.org> wrote:
> 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.

On 06/15/2016 10:14 PM, Alexei Starovoitov wrote:
> On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-dev
> <iovisor-dev at lists.iovisor.org> wrote:
>> 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 at
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 at 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~

On 06/16/2016 06:57 PM, Richard Henderson via iovisor-dev
wrote:
> On 06/15/2016 10:14 PM, Alexei Starovoitov wrote:
>> On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-dev
>> <iovisor-dev at lists.iovisor.org> wrote:
>>> 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 at
lists.fedorahosted.org/message/OEOF26ZHEJLHPOMRMOGDXTMYXUHPWVGA/
>
> 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 ;))?
>> 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 at 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~
> _______________________________________________
> iovisor-dev mailing list
> iovisor-dev at lists.iovisor.org
> https://lists.iovisor.org/mailman/listinfo/iovisor-dev
>