elf: Add declarations for BPF

  The e_machine value is provisionary, but will serve for now.
I want to use this value in elfutils and systemtap.  I will
also propagate the value to llvm and their bpf backend.

The R_BPF_MAP_FD value is being used by llvm, although they are
using the name R_X86_64_64, which is perhaps less than ideal.  ;-)


r~



	* elf/elf.h (EM_BPF): New.
	(R_BPF_NONE, R_BPF_MAP_FD): New.
---
 elf/elf.h | 5 +++++
 1 file changed, 5 insertions(+)
  

On 06/07/2016 02:07 PM, Richard Henderson wrote:
> The e_machine value is provisionary, but will serve for now.
> I want to use this value in elfutils and systemtap.  I will
> also propagate the value to llvm and their bpf backend.
> 
> The R_BPF_MAP_FD value is being used by llvm, although they are
> using the name R_X86_64_64, which is perhaps less than ideal.  ;-)

Who defines the e_machine values these days?

When does it become final? Before glibc 2.24 is released on August 1st?

I'm OK with the change, but worried about a final value.
  

On Tue, 2016-06-07 at 15:10 -0400, Carlos O'Donell wrote:
> On 06/07/2016 02:07 PM, Richard Henderson wrote:
> > The e_machine value is provisionary, but will serve for now.
> > I want to use this value in elfutils and systemtap.  I will
> > also propagate the value to llvm and their bpf backend.
> > 
> > The R_BPF_MAP_FD value is being used by llvm, although they are
> > using the name R_X86_64_64, which is perhaps less than ideal.  ;-)
> 
> Who defines the e_machine values these days?

Apparently it is still SCO (at least it was a year ago):
http://moxielogic.org/blog/elf-machine-number.html
" Just send a nice email requesting the number assignment to
registry@sco.com and they'll increment their most recent number and add
you to the list."

But it might be that it moved to registry@uxsglobal.com. That seems to
be the last address used on the sysv-gabi mailinglist. If that also
doesn't work, then best to ask on the sysv-gabi mailinglist itself
generic-abi@googlegroups.com

Cheers,

Mark
  

On 06/07/2016 03:41 PM, Mark Wielaard wrote:
> On Tue, 2016-06-07 at 15:10 -0400, Carlos O'Donell wrote:
>> On 06/07/2016 02:07 PM, Richard Henderson wrote:
>>> The e_machine value is provisionary, but will serve for now.
>>> I want to use this value in elfutils and systemtap.  I will
>>> also propagate the value to llvm and their bpf backend.
>>>
>>> The R_BPF_MAP_FD value is being used by llvm, although they are
>>> using the name R_X86_64_64, which is perhaps less than ideal.  ;-)
>>
>> Who defines the e_machine values these days?
> 
> Apparently it is still SCO (at least it was a year ago):
> http://moxielogic.org/blog/elf-machine-number.html
> " Just send a nice email requesting the number assignment to
> registry@sco.com and they'll increment their most recent number and add
> you to the list."
> 
> But it might be that it moved to registry@uxsglobal.com. That seems to
> be the last address used on the sysv-gabi mailinglist. If that also
> doesn't work, then best to ask on the sysv-gabi mailinglist itself
> generic-abi@googlegroups.com

How did we get a temporary value without knowing who to contact? :}
  

On Wed, 2016-06-08 at 15:33 -0400, Carlos O'Donell wrote:
> How did we get a temporary value without knowing who to contact? :}

The glibc elf/elf.h file says how to construct one, and rth knows
l33t-speak! :)

        /* If it is necessary to assign new unofficial EM_* values,
        please
           pick large random numbers (0x8523, 0xa7f2, etc.) ... */
        
        #define EM_BPF         0xeb9f

Personally I like rth's suggestion best.
But an "official" number would be fine too of course.
  

On 06/08/2016 03:43 PM, Mark Wielaard wrote:
> On Wed, 2016-06-08 at 15:33 -0400, Carlos O'Donell wrote:
>> How did we get a temporary value without knowing who to contact? :}
> 
> The glibc elf/elf.h file says how to construct one, and rth knows
> l33t-speak! :)
> 
>         /* If it is necessary to assign new unofficial EM_* values,
>         please
>            pick large random numbers (0x8523, 0xa7f2, etc.) ... */
>         
>         #define EM_BPF         0xeb9f
> 
> Personally I like rth's suggestion best.
> But an "official" number would be fine too of course.

If it's an unofficial EM_* value, why check it into glibc upstream?

Lets just wait until we get the final value and avoid any problems?
  

On 08 Jun 2016 16:22, Carlos O'Donell wrote:
> On 06/08/2016 03:43 PM, Mark Wielaard wrote:
> > On Wed, 2016-06-08 at 15:33 -0400, Carlos O'Donell wrote:
> >> How did we get a temporary value without knowing who to contact? :}
> > 
> > The glibc elf/elf.h file says how to construct one, and rth knows
> > l33t-speak! :)
> > 
> >         /* If it is necessary to assign new unofficial EM_* values,
> >         please
> >            pick large random numbers (0x8523, 0xa7f2, etc.) ... */
> >         
> >         #define EM_BPF         0xeb9f
> > 
> > Personally I like rth's suggestion best.
> > But an "official" number would be fine too of course.
> 
> If it's an unofficial EM_* value, why check it into glibc upstream?
> 
> Lets just wait until we get the final value and avoid any problems?

agreed ... i think we're past the point in general where glibc needs to
get early values in order to make progress.
-mike