https://sourceware.org/bugzilla/show_bug.cgi?id=25802
--- Comment #10 from Rainer Orth <ro at CeBiTec dot Uni-Bielefeld.DE> --- >> --- Comment #8 from Rainer Orth <ro at gcc dot gnu.org> --- >> Patch posted. > > Scratch that. I've think I've finally found what's going on: > > While the SPARC psABI and SCD list > > R_SPARC_UA32 23 V-word32 S + A > > i.e. overflow checks on the calculated value, the corresponding entry in > the OpenSolaris/Illumos sources ($SRC/uts/sparc/krtld/doreloc.c) has > > https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/sparc/krtld/doreloc.c#L109 > > /* R_SPARC_UA32 */ {0x0, FLG_RE_UNALIGN, 4, 0, 0}, > > So unlike other similar case like R_SPARC_32 it lacks the FLG_RE_VERIFY > flag, so no overflow checks are performed despite the ABIs. This dates > back to at least Solaris 2.5.1 back in 1996, maybe earlier. > > I'll check with Ali about the history. I've done that now: as it turns out, not checking R_SPARC_UA32 (unlike R_SPARC_32) is a historical oversight going 30 years back. While hesitant to change Solaris ld since this doesn't seem to have caused issues for 3 decades, he strongly advised against changing gld in this respect. > This may or may not be related to this snippet in elfxx-sparc.c: > > /* The Solaris native linker silently disregards overflows. > We don't, but this breaks stabs debugging info, whose > relocations are only 32-bits wide. Ignore overflows in > this case and also for discarded entries. */ > if ((r_type == R_SPARC_32 > || r_type == R_SPARC_UA32 > || r_type == R_SPARC_DISP32) > && (((input_section->flags & SEC_DEBUGGING) != 0 > && strcmp (bfd_section_name (input_section), > ".stab") == 0) > || _bfd_elf_section_offset (output_bfd, info, > input_section, > rel->r_offset) > == (bfd_vma)-1)) > > and should be achievable with a check for r_type == R_SPARC_UA32 && > ...target_os == is_solaris. Before getting Ali's feedback, I tried such a patch and re-discovered that one of the four failing tests FAIL: --gc-sections with multiple debug sections for a function section wasn't about R_SPARC_UA32 at all, but about R_SPARC_32. Therefore I'll try to link all four tests with -Ttext=0x0x80000000, failing that, xfail the first three. -- You are receiving this mail because: You are on the CC list for the bug.
