This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]