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.
