https://sourceware.org/bugzilla/show_bug.cgi?id=25802
Nick Clifton <nickc at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nickc at redhat dot com --- 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 ? > 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 ? 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. 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. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.