Message ID | 1465322879-30114-1-git-send-email-rth@twiddle.net |
---|---|
State | New |
Headers | show |
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
diff --git a/elf/elf.h b/elf/elf.h index ce96bd5..2db03c3 100644 --- a/elf/elf.h +++ b/elf/elf.h @@ -261,6 +261,7 @@ typedef struct chances of collision with official or non-GNU unofficial values. */ #define EM_ALPHA 0x9026 +#define EM_BPF 0xeb9f /* Legal values for e_version (version). */ @@ -3566,6 +3567,10 @@ enum #define R_TILEGX_NUM 130 +/* BPF specific declarations. */ + +#define R_BPF_NONE 0 /* No reloc */ +#define R_BPF_MAP_FD 1 /* Map fd to pointer */ __END_DECLS