This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 0/6] PR binutils/22875: More unsupported relocation handling target backend fixes
On Thu, 29 Mar 2018, H.J. Lu wrote:
> > Also the x86-64 backend seems to mishandle unsupported relocations that
> > have the recently added (with commit 78984959cb38 ("x86-64: Add
> > R_X86_64_converted_reloc_bit")) R_X86_64_converted_reloc_bit bit set. I
> > found a possible fix too complicated for me to afford the time required to
> > sort it now, so I'm leaving it up to H.J. to address. More details will
> > follow with strip-13 test case updates. NB `readelf -r' does not handle
> > R_X86_64_converted_reloc_bit either and reports an unrecognized relocation
> > instead.
>
> R_X86_64_converted_reloc_bit is a bit internal to linker. What problems did
> you see? How can I reproduce it?
If R_X86_64_converted_reloc_bit is set in a relocation present in an
input object file, such as with the strip-13 test case, then the bit is
silently removed by `objcopy' or `strip' in processing rather than being
complained about.
In the said test case an invalid relocation 241 is used and as it happens
(241 & ~R_X86_64_converted_reloc_bit) is an invalid relocation number on
x86-64 as well, so the tool correctly reports an error, but only because
the number is invalid after masking, and confusingly it also complains
about relocation 0x71 rather than 0xf1, i.e.:
$ readelf -r strip-13.o
Relocation section '.rela.text' at offset 0x44 contains 2 entries:
Offset Info Type Sym. Value Sym. Name + Addend
000000000000 0000000000f1 unrecognized: f1 f1
000000000000 000000000000 R_X86_64_NONE 0
$ strip -g strip-13.o -o strip-13-strip.o
strip: strip-13.o: unsupported relocation type 0x71
strip: strip-13rela.o: bad value
$
If the relocation number after masking turns out valid, then processing
continues rather than reporting an error and a relocation is produced in
output with the bit cleared in its number.
An upcoming change I am going to propose will uncover it by changing the
invalid relocation number in the strip-13 test case from 241 to 143,
causing x86-64 ELF targets to regress in testing due to this handling
problem:
$ readelf -r strip-13-143.o
Relocation section '.rela.text' at offset 0x44 contains 2 entries:
Offset Info Type Sym. Value Sym. Name + Addend
000000000000 00000000008f unrecognized: 8f 8f
000000000000 000000000000 R_X86_64_NONE 0
$ strip -g strip-13-143.o -o strip-13-143-strip.o
$ readelf -r strip-13-143-strip.o
Relocation section '.rela.text' at offset 0xc8 contains 2 entries:
Offset Info Type Sym. Value Sym. Name + Addend
000000000000 00000000000f R_X86_64_PC8 8f
000000000000 000000000000 R_X86_64_NONE 0
$
I'll try to post the patches tonight; otherwise I will only be able to get
back to it Tuesday next week, due to public holidays. If you can work on
fixing this problem with x86-64 soon, then I can defer committing strip-13
updates once they have been approved (which I expect to cause no hassle as
I believe they are a real improvement), so that you avoid the regression
showing up in x86-64 testing.
OTOH if as you say R_X86_64_converted_reloc_bit is internal, then there's
no need to do anything for `readelf'. Thanks for clarifying the use of
R_X86_64_converted_reloc_bit.
HTH,
Maciej