Re: [PATCH 0/6] PR binutils/22875: More unsupported relocation handling target backend fixes

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Mar 29, 2018 at 2:41 PM, Maciej W. Rozycki <macro@mips.com> wrote:
> 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.

X86-64 shouldn't block the strip-13 test case change.  I can update x86
targets after your change is checked in.

>  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



-- 
H.J.