bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/25802] Several 64-bit SPARC tests FAIL: relocation truncated to


From: ro at CeBiTec dot Uni-Bielefeld.DE
Subject: [Bug ld/25802] Several 64-bit SPARC tests FAIL: relocation truncated to fit
Date: Thu, 11 Jun 2020 16:31:36 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=25802

--- Comment #3 from Rainer Orth <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #2 from Nick Clifton <nickc at redhat dot com> ---
> Hi Rainer,
>
>>  I wonder how best to handle this: bfd/elfxx-sparc.c 
>> (_bfd_sparc_elf_relocate_section) already silently ignores the overflow in a
>> few select cases (like .stab sections), following the lead of Solaris ld. 
>
> Do you know if the Solaris linker ignores overflow in other cases as well ?
> IE should we be emulating the Solaris linker and ignoring more overflows ?

I'd have to ask the Solaris linker engineer (Ali Bahrami, you may know
him) that.  I haven't found anything in the OpenSolaris linker sources,
though.

>>  As expected, the tests do PASS if I do this unconditionally for the 
>> 3 affected relocs.
>> 
>> This may or may not be a hack, though.
>
> It probably is a hack, modulo the answer to the question above of course.
>
> Are you able to examine a Solaris linked binary and find out how
> those relocs were resolved ?  Ie is the debug info correct or corrupt
> or just uninitialised ?

After linking the ld-elf/eh5 test with Solaris ld instead of ld-new, I
tried the following:

* Run readelf -u on the result, which comes up blank:

The decoding of unwind sections for machine type Sparc v9 is not currently
supported.

* However, elfdump -u (the native Solaris ELF object dumping utility)
  produces results that seem at least well formed and possibly sensible
  (attached).

* I've also run readelf -wf (also attached) and visually compared it to
  eh5.d (is there a manual way to perform a comparison between readelf
  etc. output and a .d file?): the first few sections seemed to match.

> One possibility that occurs to me is that the Solaris linker is using
> a different linker script to the bfd linker (or whatever it uses) and
> so placing the sections in different places.  Places which are more
> amenable to resolving the relocs.

The Solaris linker doesn't use explicit linker scripts (and has a
different mapfile syntax compared to GNU ld).  However, the internal
rules (in the Solaris syntax) are documented in the Linkers and
Libraries Guide:

https://docs.oracle.com/cd/E37838_01/html/E36783/gjqaz.html#scrolltoc

> It also occurs to me that maybe the bug is in the assembler, in that it 
> should be generating R_SPARC_UA64 relocs instead of R_SPARC_UA32 relocs.
> Not being a Solaris expert however, I do not know if this is the case.

Me neither: I'm just the messenger ;-)  Unfortunately, the Solaris/SPARC
assembler doesn't support the .cfi_* directives, otherwise I could have
tried to use it to assemble the input and compare.  Are there C sources
corresponding to the eh5*.s files that I could feed through
Solaris/SPARC gcc configure to use as instead of gas?

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]