https://sourceware.org/bugzilla/show_bug.cgi?id=22840
Bug ID: 22840 Summary: Several TLS tests FAIL on Solaris/SPARC Product: binutils Version: 2.31 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: sparc*-sun-solaris2.* Target: sparc*-sun-solaris2.* Build: sparc*-sun-solaris2.* Several of the ld TLS tests FAIL on Solaris/SPARC (both in a sparc-sun-solaris2.11 and sparcv9-sun-solaris2.11 configuration): FAIL: 32-bit: TLS -fpic -shared transitions FAIL: 32-bit: TLS -fpic and -fno-pic exec transitions FAIL: 32-bit: TLS -fno-pic -shared FAIL: 32-bit: TLS -fpie FAIL: 32-bit: GOTDATA relocations FAIL: relaxed call WDISP30 relocation FAIL: 64-bit: TLS -fpic -shared transitions FAIL: 64-bit: TLS -fpic and -fno-pic exec transitions FAIL: 64-bit: TLS -fno-pic -shared FAIL: 64-bit: TLS -fpie FAIL: 64-bit: GOTDATA relocations There are several issues here: * Initially, the failures are like /var/gcc/binutils/sparcv7/obj/binutils/ld/ld-new: target elf32-sparc not found /var/gcc/binutils/sparcv7/obj/binutils/ld/ld-new: target elf32-sparc not found or the elf64-sparc equivalent. This happens because sparc.exp hardcodes -melf32_sparc resp. -melf64_sparc, while Solaris uses (and requires) the -melf32_sparc_sol2 resp. -melf64_sparc_sol2 emulations. Unfortunately, unlike the #ld: lines in the *.?d files which can be modified by setting options_regsub(ld) for perform the appropriate substitution, this is not currently possible for the arg to run_ld_link_tests. * To make some progress, I've hardcoded the Solaris values for now, which leads me to the next issues: The file format lines in the *.?d files under test all hardcode elf32-sparc or elf64-sparc, but should allow for elf32-sparc-sol2 (resp. elf32-sparc.*). * Even with that fixed, there are many failures due to the fact that the Solaris ABI requires a couple of additional symbols (cf. emultempl/solaris2.em (elf_solaris2_before_allocation), and those aren't currently expected in the output. I'm uncertain how best to handle that: allow for a postprocessing step after readelf that removes those from the output or augment the expected output accordingly? It seems regexp_diff currently has no support for optional or target-specific lines in the expected output. Rainer -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils