[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.