elf/elf.h: Add new 386 and X86_64 relocations from binutils.
Commit Message
On Thu, Jan 28, 2016 at 05:03:28AM -0800, H.J. Lu wrote:
> On Thu, Jan 28, 2016 at 4:55 AM, Mark Wielaard <mjw@redhat.com> wrote:
> > The following new 386 and X86_64 were added to binutils. They are
> > non-dynamic relocations, so don't need direct handling in glibc.
> > But other programs, like elfutils, use the glibc elf.h definitions
> > for the names and numbers when inspecting ET_REL files.
> >
> > R_386_GOT32X was proposed in
> > https://groups.google.com/forum/#!topic/ia32-abi/GbJJskkid4I
> >
> > X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX were proposed in
> > https://groups.google.com/forum/#!topic/x86-64-abi/n9AWHogmVY0
> >
> > There also used to be R_X86_64_PC32_BND (39) and R_X86_64_PLT32_BND (40)
> > but those already got deprecated and now the numbers are simply reserved.
>
> We can't use them for anything else and linker still supports them, But
> assembler won't generate them.
OK, if we cannot reuse them, then it makes sense to just add them
and mark them deprecated in the comments. Then at least we got the
name and number for tools to recognize them.
Adjusted patch attached.
Thanks,
Mark
From 41fb17254b3278eeb888fa23c26acf4f02fa23da Mon Sep 17 00:00:00 2001
From: Mark Wielaard <mjw@redhat.com>
Date: Fri, 29 Jan 2016 09:49:01 +0100
Subject: [PATCH] elf/elf.h: Add new 386 and X86_64 relocations from binutils.
The following new 386 and X86_64 were added to binutils. They are
non-dynamic relocations, so don't need direct handling in glibc.
But other programs, like elfutils, use the glibc elf.h definitions
for the names and numbers when inspecting ET_REL files.
R_386_GOT32X was proposed in
https://groups.google.com/forum/#!topic/ia32-abi/GbJJskkid4I
X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX were proposed in
https://groups.google.com/forum/#!topic/x86-64-abi/n9AWHogmVY0
There also used to be R_X86_64_PC32_BND and R_X86_64_PLT32_BND
but those already got deprecated in
https://groups.google.com/d/msg/x86-64-abi/-hdQyMixt8Y/XFDOvioG85cJ
* elf/elf.h (R_386_GOT32X): New.
(R_386_NUM): Update.
(R_X86_64_PC32_BND): New, but deprecated.
(R_X86_64_PLT32_BND): New, but deprecated.
(R_X86_64_GOTPCRELX: New.
(R_X86_64_REX_GOTPCRELX): New.
(R_X86_64_NUM): Update.
---
ChangeLog | 10 ++++++++++
elf/elf.h | 15 ++++++++++++---
2 files changed, 22 insertions(+), 3 deletions(-)
Comments
On Fri, Jan 29, 2016 at 12:53 AM, Mark Wielaard <mjw@redhat.com> wrote:
> On Thu, Jan 28, 2016 at 05:03:28AM -0800, H.J. Lu wrote:
>> On Thu, Jan 28, 2016 at 4:55 AM, Mark Wielaard <mjw@redhat.com> wrote:
>> > The following new 386 and X86_64 were added to binutils. They are
>> > non-dynamic relocations, so don't need direct handling in glibc.
>> > But other programs, like elfutils, use the glibc elf.h definitions
>> > for the names and numbers when inspecting ET_REL files.
>> >
>> > R_386_GOT32X was proposed in
>> > https://groups.google.com/forum/#!topic/ia32-abi/GbJJskkid4I
>> >
>> > X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX were proposed in
>> > https://groups.google.com/forum/#!topic/x86-64-abi/n9AWHogmVY0
>> >
>> > There also used to be R_X86_64_PC32_BND (39) and R_X86_64_PLT32_BND (40)
>> > but those already got deprecated and now the numbers are simply reserved.
>>
>> We can't use them for anything else and linker still supports them, But
>> assembler won't generate them.
>
> OK, if we cannot reuse them, then it makes sense to just add them
> and mark them deprecated in the comments. Then at least we got the
> name and number for tools to recognize them.
>
I prefer to leave them out since tools won't know how to handle them if
they haven't known already.
----- Original Message -----
> > OK, if we cannot reuse them, then it makes sense to just add them
> > and mark them deprecated in the comments. Then at least we got the
> > name and number for tools to recognize them.
> >
> I prefer to leave them out since tools won't know how to handle them if
> they haven't known already.
OK, fair enough. I pushed the original change that leaves them out and
only mentions them in the comments as reserved.
Thanks,
Mark
> Em 31 de jan de 2016, às 08:55, Mark Wielaard <mjw@redhat.com> escreveu:
>
> ----- Original Message -----
>>> OK, if we cannot reuse them, then it makes sense to just add them
>>> and mark them deprecated in the comments. Then at least we got the
>>> name and number for tools to recognize them.
>> I prefer to leave them out since tools won't know how to handle them if
>> they haven't known already.
>
> OK, fair enough. I pushed the original change that leaves them out and
> only mentions them in the comments as reserved.
>
> Thanks,
>
> Mark
We are in hard freeze and this patch do not fall in any category we have defined which are allowed in this timeframe (since although this an update from binutils it does not prevent any current functionality).
Please revert and apply when 2.24 opens.
Hi,
----- Original Message -----
> > Em 31 de jan de 2016, às 08:55, Mark Wielaard <mjw@redhat.com> escreveu:
> > OK, fair enough. I pushed the original change that leaves them out and
> > only mentions them in the comments as reserved.
>
> We are in hard freeze and this patch do not fall in any category we have
> defined which are allowed in this timeframe (since although this an update
> from binutils it does not prevent any current functionality).
>
> Please revert and apply when 2.24 opens.
My apologies. I missed that.
commit 0f0f4d reverts the addition of these constants.
I'll apply it again when 2.24 opens.
Cheers,
Mark
On Sun, Jan 31, 2016 at 12:37:42PM -0500, Mark Wielaard wrote:
> ----- Original Message -----
> > > Em 31 de jan de 2016, às 08:55, Mark Wielaard <mjw@redhat.com> escreveu:
> > > OK, fair enough. I pushed the original change that leaves them out and
> > > only mentions them in the comments as reserved.
> >
> > We are in hard freeze and this patch do not fall in any category we have
> > defined which are allowed in this timeframe (since although this an update
> > from binutils it does not prevent any current functionality).
> >
> > Please revert and apply when 2.24 opens.
>
> My apologies. I missed that.
> commit 0f0f4d reverts the addition of these constants.
> I'll apply it again when 2.24 opens.
I pushed this to master now.
@@ -1,3 +1,13 @@
+2016-01-29 Mark Wielaard <mjw@redhat.com>
+
+ * elf/elf.h (R_386_GOT32X): New.
+ (R_386_NUM): Update.
+ (R_X86_64_PC32_BND): New, but deprecated.
+ (R_X86_64_PLT32_BND): New, but deprecated.
+ (R_X86_64_GOTPCRELX: New.
+ (R_X86_64_REX_GOTPCRELX): New.
+ (R_X86_64_NUM): Update.
+
2016-01-28 Steve Ellcey <sellcey@imgtec.com>
Joseph Myers <joseph@codesourcery.com>
@@ -1269,8 +1269,10 @@ typedef struct
argument, returning the TLS
offset for the symbol. */
#define R_386_IRELATIVE 42 /* Adjust indirectly by program base */
+#define R_386_GOT32X 43 /* Load from 32 bit GOT entry,
+ relaxable. */
/* Keep this the last entry. */
-#define R_386_NUM 43
+#define R_386_NUM 44
/* SUN SPARC specific definitions. */
@@ -3144,8 +3146,15 @@ enum
#define R_X86_64_TLSDESC 36 /* TLS descriptor. */
#define R_X86_64_IRELATIVE 37 /* Adjust indirectly by program base */
#define R_X86_64_RELATIVE64 38 /* 64-bit adjust by program base */
-
-#define R_X86_64_NUM 39
+#define R_X86_64_PC32_BND 39 /* Deprecated. */
+#define R_X86_64_PLT32_BND 40 /* Deprecated. */
+#define R_X86_64_GOTPCRELX 41 /* Load from 32 bit signed pc relative
+ offset to GOT entry without REX
+ prefix, relaxable. */
+#define R_X86_64_REX_GOTPCRELX 42 /* Load from 32 bit signed pc relative
+ offset to GOT entry with REX prefix,
+ relaxable. */
+#define R_X86_64_NUM 43
/* AM33 relocations. */