[Bug gas/20118] New: gas should set .init_array etc. sh_entsize to word size
https://sourceware.org/bugzilla/show_bug.cgi?id=20118
Bug ID: 20118
Summary: gas should set .init_array etc. sh_entsize to word
size
Product: binutils
Version: 2.26
Status: NEW
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Solaris elfdump complains about sh_entsize being 0for .init_array etc.
sections. The following example is on Solaris/x86, but the same applies to any
ELF target.
$ cat ia-i386.s
.text
.globl init
.type init, @function
init:
ret
.size init, .-init
.section.init_array,"aw"
.align 4
.long init
$ gas-2.26 --32 ia-i386.s -o ia-i386.o
$ elfdump -N .init_array ia-i386.o
ia-i386.o: .init_array: zero sh_entsize information, expected 0x4
Init/Fini Array Section: .init_array
index value derived-address name
[0] 0 0 init
$ elfdump -c -N .init_array ia-i386.o
Section Header[4]: sh_name: .init_array
sh_addr: 0 sh_flags: [ SHF_WRITE SHF_ALLOC ]
sh_size: 0x4 sh_type:[ SHT_INIT_ARRAY ]
sh_offset:0x38sh_entsize: 0
sh_link: 0 sh_info:0
sh_addralign: 0x4
Solaris/x86 as behaves the same, while Solaris/SPARC correctly sets
sh_entsize to the respective word size.
Solaris ld also gets it right:
$ cat ia-cc.c
void init()
{
}
$ gcc -c ia-cc.c
$ ld -r -zinitarray=init ia-cc.o -o ia-cc-ld.o
$ elfdump -N .init_array ia-cc-ld.o
Init/Fini Array Section: .init_array
index value derived-address name
[0] 0 0 init
$ elfdump -c -N .init_array ia-cc-ld.o
Section Header[2]: sh_name: .init_array
sh_addr: 0 sh_flags: [ SHF_WRITE SHF_ALLOC ]
sh_size: 0x4 sh_type:[ SHT_INIT_ARRAY ]
sh_offset:0x3csh_entsize: 0x4 (1 entry)
sh_link: 0 sh_info:0
sh_addralign: 0x4
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
[Bug ld/20179] New: ld -pie -z text errors out for SPARC TLS objects: read-only segment has dynamic relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=20179 Bug ID: 20179 Summary: ld -pie -z text errors out for SPARC TLS objects: read-only segment has dynamic relocations Product: binutils Version: 2.26 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.* Created attachment 9296 --> https://sourceware.org/bugzilla/attachment.cgi?id=9296&action=edit input object When running the gcc testsuite on Solaris 12 with gas and gld, the PIE tests FAIL with a gld error: FAIL: gcc.dg/torture/tls/run-le.c -O0 -pie -fpie (test for excess errors) Excess errors: /vol/gcc/bin/gld-2.26: read-only segment has dynamic relocations. The failure can be reproduced with $ gld-2.26 -pie -z text -o run-le.exe run-le.o -lc gld-2.26: warning: cannot find entry symbol _start; defaulting to 0330 gld-2.26: read-only segment has dynamic relocations. Linking the exact same object with /bin/ld works just fine: $ ld -z type=pie -z text -o run-le.exe run-le.o -lc Checking which symbols triggers setting DT_TEXTREL, I find that tls_le is the culprit: $ elfdump -s run-le.o|grep tls_le [7] 0 0x4 TLS GLOB D0 .tdata tls_le $ elfdump -r run-le.o Relocation Section: .rela.text index type offset value addend section symbol [0] R_SPARC_TLS_LE_HIX22 0x4 0 0 .text tls_le [1] R_SPARC_TLS_LE_LOX10 0x8 0 0 .text tls_le [2] R_SPARC_TLS_LE_HIX220x20 0 0 .text tls_le [3] R_SPARC_TLS_LE_LOX100x24 0 0 .text tls_le However, the situation on Solaris/x86 is similar $ elfdump -s run-le.o|grep tls_le [11] 0 0x4 TLS GLOB D0 .tdata tls_le $ elfdump -r run-le.o |grep tls_le [2] R_386_TLS_LE0x15 0 .text tls_le [5] R_386_TLS_LE0x31 0 .text tls_le and yet the warning doesn't trigger. 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
[Bug ld/20989] New: Every 64-bit Solaris 12/SPARC executable dies with SIGILL
https://sourceware.org/bugzilla/show_bug.cgi?id=20989 Bug ID: 20989 Summary: Every 64-bit Solaris 12/SPARC executable dies with SIGILL Product: binutils Version: 2.27 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.12 Target: sparc-sun-solaris2.12 Build: sparc-sun-solaris2.12 For some time, Solaris 12 provides its own set of CRTs. Cf. https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01638.html for some backgroup. When recently the __start_crt_compiler function in crt1.o was changed from [29] 00 FUNC WEAK D0 UNDEF __start_crt_compiler to [29] 00 FUNC WEAK H0 UNDEF __start_crt_compiler (i.e. hidden visibility), every single 64-bit executable started to die with SIGILL if linked with gld. Both 32-bit and /bin/ld are fine instead. Here's what I found: /usr/lib/sparcv9/crt1.o has __start_crt+0x64: 40 00 00 00 call +0x0 <__start_crt+0x64> Relocation Section: .rela.text index type offset value addend section symbol [20] R_SPARC_WPLT30 0xe4 0 0 .text __start_crt_compiler __start_crt starts at .text+0x80 [30] 0x80 0xa4 FUNC GLOB D0 .text __start_crt [29] 00 FUNC WEAK H0 UNDEF __start_crt_compiler When linking with /bin/ld, the resulting executable turns into: __start_crt+0x64: 40 00 00 00 call +0x0 <__start_crt+0x64> [76] 0x10b80 0xa4 FUNC GLOB D0 .text__start_crt [32]00 FUNC LOCL H0 ABS __start_crt_compiler while when I use gld instead, I get __start_crt+0x64: 7f ff fe 4f call -0x6c4<0x1> [53] 0x10660 0xa4 FUNC GLOB D0 .text __start_crt 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
[Bug ld/20989] Every 64-bit Solaris 12/SPARC executable dies with SIGILL
https://sourceware.org/bugzilla/show_bug.cgi?id=20989 --- Comment #3 from Rainer Orth --- Created attachment 9722 --> https://sourceware.org/bugzilla/attachment.cgi?id=9722&action=edit input objects and executables -- 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
[Bug ld/21250] New: ld --sysroot without --with-sysroot searches default dirs
https://sourceware.org/bugzilla/show_bug.cgi?id=21250 Bug ID: 21250 Summary: ld --sysroot without --with-sysroot searches default dirs Product: binutils Version: 2.28 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Playing around with gcc --sysroot, I noticed a weird ld behaviour. I've observed this with native gcc mainline and gld 2.28, on both i386-pc-solaris2.12 and x86_64-pc-linux-gnu, so I suppose it's target independent: * When binutils have been configured without --with-sysroot and I point gcc at a non-existant/empty --sysroot directory, header files aren't found during compilation, just as expected. Once I add a copy of usr/include, compilation succeeds but startup files gcc searches itself (like crt1.o and friends) aren't found. Adding them (to /usr/lib instead of /usr/lib64 as I'd would have expected on Linux) causes both the startup files to be found and the link to succeed *although there's no libc.so/libc.so.6 below *. * However, if I configure binutils with --with-sysroot pointing to a non-existant directory, the exact same ld invocation now fails to find libc.so, as it should. * Unlike ld, gold (2.27 in this case) gets this right, however: a default gold build doesn't find libc.so if it's missing below . Besides, ld.texinfo incorrectly claims that --sysroot only works when binutils have been configured with --with-sysroot, which is no longer true. It seems this was true until binutils 2.25,however. 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
[Bug ld/21251] New: Support $SYSROOT in ld -L and INPUT command
https://sourceware.org/bugzilla/show_bug.cgi?id=21251 Bug ID: 21251 Summary: Support $SYSROOT in ld -L and INPUT command Product: binutils Version: 2.28 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Using = to refer to the sysroot prefix in both the -L option and the INPUT command is not very expressive/mnemonic. It would seem useful to additionall support $SYSROOT similarly to $ORIGIN and $LIB. -- 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
[Bug libctf/29291] New: ld-ctf/data-func-conflicted*.d FAIL with -g3 -O0
https://sourceware.org/bugzilla/show_bug.cgi?id=29291 Bug ID: 29291 Summary: ld-ctf/data-func-conflicted*.d FAIL with -g3 -O0 Product: binutils Version: 2.39 (HEAD) Status: NEW Severity: normal Priority: P2 Component: libctf Assignee: unassigned at sourceware dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: amd64--c-solaris2.11, x86_64-pc-linux-gnu When investigating a different CTF issue on Solaris, I built binutils trunk with gcc 12.1.0 -g3 -O0. This caused two CTF tests to FAIL that PASS with the regular -g -O2: FAIL: Conflicted data syms, partially indexed, stripped, with variables FAIL: Conflicted data syms, partially indexed, stripped ld.log shows regexp_diff match failure regexp "^Variable section: .* \(0x10 bytes\)$" line "Variable section: 0x5c -- 0x73 (0x18 bytes)" regexp_diff match failure regexp "^Type section: .* \(0x118 bytes\)$" line "Type section: 0x74 -- 0x197 (0x124 bytes)" regexp_diff match failure regexp "^funcs -> .*$" line "foo -> 0xf: (kind 5) void *(*) () (aligned at 0x8)" regexp_diff match failure regexp "^other_func -> .*$" line "funcs -> 0xe: (kind 4) void **([16])(*) (const char *restrict, int (*)(*) (const char *)) (size 0x80) (aligned at 0x8) -> 0xc: (kind 3) void **(*) (const char *restrict, int (*)(*) (const char *)) (size 0x8) (aligned at 0x8) -> 0xb: (kind 5) void *(*) (const char *restrict, int (*)(*) (const char *)) (aligned at 0x8)" FAIL: Conflicted data syms, partially indexed, stripped, with variables regexp_diff match failure regexp "^Type section: .* \(0x118 bytes\)$" line "Type section: 0x5c -- 0x17f (0x124 bytes)" FAIL: Conflicted data syms, partially indexed, stripped Seen on Solaris/amd64 and Linux/x86_64, probably generic. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29292] New: Several CTF tests FAIL on Solaris
https://sourceware.org/bugzilla/show_bug.cgi?id=29292 Bug ID: 29292 Summary: Several CTF tests FAIL on Solaris Product: binutils Version: 2.39 (HEAD) Status: NEW Severity: normal Priority: P2 Component: libctf Assignee: unassigned at sourceware dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.11 When building binutils trunk with gcc 12.1.0, several CTF tests FAIL: FAIL: Arrays (conflicted) FAIL: Conflicting cycle 1.B-1 FAIL: Conflicting cycle 1.B-2 FAIL: Conflicting cycle 1.parent FAIL: Conflicting cycle 2.A-1 FAIL: Conflicting cycle 2.A-2 FAIL: Conflicting cycle 2.parent FAIL: Conflicting cycle 3.C-1 FAIL: Conflicting cycle 3.C-2 FAIL: Conflicting cycle 3 FAIL: Conflicting Enums FAIL: Conflicting Typedefs FAIL: cross-TU-cyclic-conflicting FAIL: cross-TU-into-cycle FAIL: /vol/src/gnu/binutils/hg/master/dist/libctf/testsuite/libctf-lookup/ambiguous-struct.c FAIL: /vol/src/gnu/binutils/hg/master/dist/libctf/testsuite/libctf-regression/libctf-repeat-cu.exp FAIL: /vol/src/gnu/binutils/hg/master/dist/libctf/testsuite/libctf-regression/pptrtab.c (Btw., the libctf test names shouldn't contain full pathnames: this makes comparing test results between different builds unnecessarily difficult.) E.g. for libctf-regression/libctf-repeat-cu.exp I get $ ../binutils/objdump --ctf tmpdir/libctf-repeat-cu-main.so tmpdir/libctf-repeat-cu-main.so: file format elf64-x86-64-sol2 ../binutils/objdump: error: ctf_arc_bufopen(): cannot open CTF ../binutils/objdump: CTF open failure: Buffer does not contain CTF data. ../binutils/objdump: tmpdir/libctf-repeat-cu-main.so: file in wrong format Looking at the .ctf section of the shared object, I find that the header is missing: $ od -x dump.ctf |head 000 * 100 010c 120 dff2 0e04 compared to the same operation on Linux/x86_64: $ od -x dump.x86_64.ctf |head 000 3eeb d762 f2a4 8b47 0002 020 0002 0210 040 0048 060 0005 100 0110 010c 120 dff2 0e04 On a hunch, I disabled HAVE_MMAP in libctf/ctf-archive.c and with two exceptions the tests now all PASS: FAIL: Diagnostics - Invalid CU name offset FAIL: Diagnostics - Non-zero parlabel in parent I haven't yet found what's wrong: if the mmap code makes some unportable assumption or Solaris mmap is weird in some way. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29411] New: ld warning on SPARC: LOAD segment with RWX permissions
https://sourceware.org/bugzilla/show_bug.cgi?id=29411 Bug ID: 29411 Summary: ld warning on SPARC: LOAD segment with RWX permissions Product: binutils Version: 2.39 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: sparcv9-sun-solaris2.11, sparc64-sun-linux-gnu Target: sparcv9-sun-solaris2.11, sparc64-sun-linux-gnu Build: sparcv9-sun-solaris2.11, sparc64-sun-linux-gnu When trying to build LLVM main on Debian/sparc64, I saw lots of warnings: /usr/bin/ld: warning: bin/llvm-readobj has a LOAD segment with RWX permissions /usr/bin/ld is GNU ld (GNU Binutils for Debian) 2.38.50.20220707 However, the same issue exists on Solaris 11/SPARC. AFAICS, this happens as follows (taking the Solaris example): $ readelf -l /lib/libc.so.1 [...] Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PT_SUNWCAP 0xf4 0x00f4 0x 0x001a0 0x001a0 R 0x4 LOAD 0x00 0x 0x 0x213913 0x213913 R E 0x1 LOAD 0x214000 0x00224000 0x 0x0b9b8 0x11124 RWE 0x1 [...] Section to Segment mapping: Segment Sections... 00 .SUNW_cap 01 .SUNW_cap .SUNW_capinfo .SUNW_capchain .dynamic .SUNW_syminfo .hash .SUNW_ldynsym .dynsym .dynstr .SUNW_version .SUNW_versym .SUNW_dynsymsort .SUNW_dyntlssort .SUNW_dynsymnsort .SUNW_phname .SUNW_reloc .rela.plt .rodata .rodata1 .text .init .fini .SUNW_dof 02 .got .plt .data .picdata .bss Looking at the sections in segment 02, I find only one that is RWE: $ readelf -S /lib/libc.so.1 [...]Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [...] [25] .plt PROGBITS00224ca0 214ca0 0002a4 0c WAX 0 0 4 However, this is exactly as prescribed by the respective psABIs: * 32-bit SPARC: SYSTEM V APPLICATION BINARY INTERFACE SPARC Processor Supplement, Third Edition p. 5-5 - 5-8, Procedure Linkage Table * 64-bit SPARC V9: SPARC COMPLIANCE DEFINITION 2.4.1 p. 5P-4 - 5P-8, Procedure Linkage Table I have no idea what to do here, but warning about ABI-compliant binaries seems strange. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29424] New: ld chokes on DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29424 Bug ID: 29424 Summary: ld chokes on DW_FORM_rnglistx Product: binutils Version: 2.39 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: sparc64-unknown-linux-gnu Target: sparc64-unknown-linux-gnu Build: sparc64-unknown-linux-gnu When building LLVM main on Debian 11/sparc64, I ran into a very weird error linking one of the compiler-rt testcases, Sanitizer-sparc-Test (the 32-bit version): I see several instances of /usr/bin/ld: /usr/bin/ld: DWARF error: invalid or unhandled FORM value: 0x23 where 0x23 is DW_FORM_rnglistx, which clang emits with -gdwarf-5 (the default). Initially, I used a patch to default to -gdwarf-4 on this target, which avoids emitting DW_FORM_rnglistx: https://reviews.llvm.org/D130566 to avoid this. I couldn't reproduce the problem on Ubuntu 20.04, however. Later on, it turned out that the error only happens when there are several undefined referenes to libatomic functions. When I do link with -latomic, both the references become resolved and the DWARF error vanishes. I've originally seen this with the bundled GNU ld 2.38.50.20220707, but it also reprodues with 2.38.90.20220728. I cannot tell what to do about this error: ignore the problem, stating `don't do this'. I don't have (and probably won't have the time to create) a smaller testcase: the bundle of objects (sparc64-rnglistx.tar.xz) is ca. 1.5 MB, too large to attach here. I've done this on gcc202 in the GCC cfarm, just in case. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29424] ld chokes on DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29424 --- Comment #1 from Rainer Orth --- Created attachment 14237 --> https://sourceware.org/bugzilla/attachment.cgi?id=14237&action=edit Debian 11/sparc64 testcse I see the binutils bugzilla filesize limit is way larger than GCC's, so attaching the testcase. Apart from the object files, it includes two shell scripts: * sst-la.sh contains the ld invocation with -latomic included, no error * sst-no-la.sh is the same, just without -latomic, which shows the error -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29411] ld warning on SPARC: LOAD segment with RWX permissions
https://sourceware.org/bugzilla/show_bug.cgi?id=29411 Rainer Orth changed: What|Removed |Added Resolution|--- |FIXED URL||https://sourceware.org/pipe ||rmail/binutils/2022-July/12 ||2057.html Target Milestone|--- |2.39 Assignee|unassigned at sourceware dot org |ro at gcc dot gnu.org Status|REOPENED|RESOLVED --- Comment #10 from Rainer Orth --- Fully fixed for binutils 2.39. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29512] New: ld non-canon ref to canon protected function check breaks Solaris/x86
https://sourceware.org/bugzilla/show_bug.cgi?id=29512 Bug ID: 29512 Summary: ld non-canon ref to canon protected function check breaks Solaris/x86 Product: binutils Version: 2.39 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: ro at gcc dot gnu.org CC: hjl.tools at gmail dot com Target Milestone: --- Host: i?86-pc-solaris2.11 Target: i?86-pc-solaris2.11 Build: i?86-pc-solaris2.11 While I'd successfully bootstrapped gcc trunk with binutils from the 2.39 branch on Solaris 11.4/x86 some time ago,trying the same with the actual release broke: genmatch fails to link with /vol/gcc/bin/gld-2.39: ../libcpp/libcpp.a(macro.o): non-canonical reference to canonical protected function `gmtime@@SYSVABI_1.3' in /lib/libc.so /vol/gcc/bin/gld-2.39: failed to set dynamic section sizes: bad value collect2: error: ld returned 1 exit status make[3]: *** [Makefile:3040: build/genmatch] Error 1 >From the description of the patch introducing this (late in the 2.39 release cycle), I get the impression that this imposes a glibc requirement on all x86 ELF targets. By disabling the check in bfd/elf32-i386.c and bfd/elf64-x86-64.c, I managed to finish the bootstrap successfully. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 Rainer Orth changed: What|Removed |Added Status|WAITING |NEW --- Comment #24 from Rainer Orth --- Sorry for dropping the ball on this one for so long. However, some time ago the issue broke the gcc trunk build with D included since d21 didn't run due to the unsupported reloc. I've now refreshed your patch and had to make two amendements: When linking GCC's gcc.dg/torture/tls/run-ie.c without and with -fPIC, the assertion would fire in two cases that seem legit: * r_type = R_386_TLS_IE, r_type_tls = R_386_TLS_LE * r_type = R_386_TLS_GOTIE, r_type_tls = R_386_TLS_LE If I let those two in, the gcc bootstrap finishes successfully and the testsuite run shows no regressions compared to a gas/ld build. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #25 from Rainer Orth --- Created attachment 14568 --> https://sourceware.org/bugzilla/attachment.cgi?id=14568&action=edit Augmented patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 Rainer Orth changed: What|Removed |Added Attachment #14568|0 |1 is obsolete|| --- Comment #27 from Rainer Orth --- Created attachment 14577 --> https://sourceware.org/bugzilla/attachment.cgi?id=14577&action=edit Augmented patch, incorporating review comments Like so? I wonder if it would be possible to move the declaration of expected_tls_le to its use. Given that binutils now requires C99, that would certainly be clearer, but differ in style from the rest of the file. Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu as well as a full all-languages gcc bootstrap. As an additional experiment, I've enabled ld-i386/tls.exp on Solaris/x86. Before this patch, only two tests FAIL: FAIL: TLS GD/LD -> IE transition without PLT FAIL: TLS GD/LD -> IE transition without PLT (-z now) The error is the expected Running: tmpdir/tls-1d > tmpdir/tls-1d.out ld.so.1: tls-1d: fatal: relocation error: R_386_UNKNOWN37: file tmpdir/tls-1d: symbol gd: offset size (0 bytes) is not supported With the patch, those two tests continue to FAIL. However, the error is different: /var/gcc/binutils/i386/obj/binutils-2.40-branch-local/ld/tmpdir/ld/collect-ld: warning: /usr/lib/crtn.o: missing .note.GNU-stack section implies executable stack /var/gcc/binutils/i386/obj/binutils-2.40-branch-local/ld/tmpdir/ld/collect-ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /var/gcc/binutils/i386/obj/binutils-2.40-branch-local/ld/tmpdir/ld/collect-ld: BFD (GNU Binutils) 2.39.90.20230111 assertion fail /vol/src/gnu/binutils/hg/binutils-2.40-branch/local/bfd/elf32-i386.c:3377 /var/gcc/binutils/i386/obj/binutils-2.40-branch-local/ld/tmpdir/ld/collect-ld: BFD (GNU Binutils) 2.39.90.20230111 assertion fail /vol/src/gnu/binutils/hg/binutils-2.40-branch/local/bfd/elf32-i386.c:3377 /var/gcc/binutils/i386/obj/binutils-2.40-branch-local/ld/tmpdir/ld/collect-ld: BFD (GNU Binutils) 2.39.90.20230111 assertion fail /vol/src/gnu/binutils/hg/binutils-2.40-branch/local/bfd/elf32-i386.c:3377 collect2: error: ld returned 1 exit status On top of that, there are four new failures +FAIL: TLS GD/LD -> LE transition without PLT (dynamic) +FAIL: TLS GD/LD -> LE transition without PLT (dynamic, -z now) +FAIL: TLS GD/LD -> LE transition without PLT (PIE) +FAIL: TLS GD/LD -> LE transition without PLT (PIE, -z now) which show the same error. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #29 from Rainer Orth --- Created attachment 14590 --> https://sourceware.org/bugzilla/attachment.cgi?id=14590&action=edit Augmented^2 patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #30 from Rainer Orth --- (In reply to H.J. Lu from comment #28) > (In reply to Rainer Orth from comment #27) > > Created attachment 14577 [details] > > Augmented patch, incorporating review comments > > expected_tls_le should be unsigned int. The check will be > > if (r_type_tls == expected_tls_le) Ah, I misunderstood. Patch updated. > > /var/gcc/binutils/i386/obj/binutils-2.40-branch-local/ld/tmpdir/ld/collect- > > ld: BFD (GNU Binutils) 2.39.90.20230111 assertion fail > > /vol/src/gnu/binutils/hg/binutils-2.40-branch/local/bfd/elf32-i386.c:3377 > > collect2: error: ld returned 1 exit status > > > > On top of that, there are four new failures > > > > +FAIL: TLS GD/LD -> LE transition without PLT (dynamic) > > +FAIL: TLS GD/LD -> LE transition without PLT (dynamic, -z now) > > +FAIL: TLS GD/LD -> LE transition without PLT (PIE) > > +FAIL: TLS GD/LD -> LE transition without PLT (PIE, -z now) > > > > which show the same error. > > So TLS doesn't work for Solaris. I don't think so. On the contrary, I'd expect an assertion BFD_ASSERT (r_type == R_386_TLS_LE_32)' to trigger on Solaris with a patch whose primary purpose is to avoid the emission of R_386_TLS_LE_32. I've adjusted the assertion to BFD_ASSERT (r_type == expected_tls_le); and now (with ld-i386/tls.exp enabled on Solaris), all those tests PASS there and still do on Linux/i686. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 Rainer Orth changed: What|Removed |Added URL||https://sourceware.org/pipe ||rmail/binutils/2023-January ||/125706.html --- Comment #32 from Rainer Orth --- (In reply to H.J. Lu from comment #31) > (In reply to Rainer Orth from comment #29) > > Created attachment 14590 [details] > > Augmented^2 patch > > LGTM. Please send it to the binutils mailing list. Thanks. Done now. Thanks a lot for the fix and your patience. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/30013] New: [2.40 regression] Assertion failed: one_type != two_type, file libctf/ctf-dedup.c, line 2342, function sort_output_mapping
https://sourceware.org/bugzilla/show_bug.cgi?id=30013 Bug ID: 30013 Summary: [2.40 regression] Assertion failed: one_type != two_type, file libctf/ctf-dedup.c, line 2342, function sort_output_mapping Product: binutils Version: 2.40 Status: NEW Severity: normal Priority: P2 Component: libctf Assignee: unassigned at sourceware dot org Reporter: ro at gcc dot gnu.org CC: nick.alcock at oracle dot com Target Milestone: --- When I recently upgraded my self-compiled version used for gcc bootstraps from 2.39 to 2.40, a couple of testsuite regressions occured: +FAIL: gcc.dg/debug/20020220-1.c -gctf (test for excess errors) Excess errors: Assertion failed: one_type != two_type, file /vol/src/gnu/binutils/binutils-2.40/libctf/ctf-dedup.c, line 2342, function sort_output_mapping collect2: fatal error: ld terminated with signal 6 [Abort] +FAIL: gcc.dg/debug/20020220-1.c -gctf execution test +FAIL: gcc.dg/debug/20050907-1.c -gctf (test for excess errors) +FAIL: gcc.dg/debug/pr36690-3.c -gctf (test for excess errors) +FAIL: gcc.dg/debug/pr36690-3.c -gctf execution test +FAIL: gcc.dg/debug/pr37616.c -gctf (test for excess errors) +FAIL: gcc.dg/debug/pr37616.c -gctf execution test +FAIL: gcc.dg/debug/pr41893-1.c -gctf (test for excess errors) +FAIL: gcc.dg/debug/pr49032.c -gctf (test for excess errors) +FAIL: gcc.dg/debug/pr65771.c -gctf (test for excess errors) They happen on Solaris/sparc and x86, 32 and 64-bit. It turns out that the assertion failure occurs when qsort_r is missing from libc (as on Solaris 11.3, unlike Solaris 11.4). However, there's nothing Solaris-specific here: if I disable qsort_r in config.status on Linux/i686 --- config.status.dist 2023-01-17 16:51:27.241499000 +0100 +++ config.status 2023-01-17 16:51:42.380104000 +0100 @@ -820,2 +820,2 @@ -S["NEED_CTF_QSORT_R_FALSE"]="" -S["NEED_CTF_QSORT_R_TRUE"]="#" +S["NEED_CTF_QSORT_R_FALSE"]="#" +S["NEED_CTF_QSORT_R_TRUE"]="" @@ -1050,2 +1049,0 @@ -D["HAVE_QSORT_R"]=" 1" -D["HAVE_QSORT_R_ARG_LAST"]=" 1" (there sems to be no way to do this otherwise, e.g. by presetting autoconf cache variables), I get exactly the same failure, so there seems to be something wrong with ctf-qsort_r.c. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 Rainer Orth changed: What|Removed |Added Target Milestone|--- |2.41 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #34 from Rainer Orth --- Fixed for binutils 2.41. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/22721] New: [2.30, 2.31 regression] Solaris/x86 TLS transition failures with linker plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=22721 Bug ID: 22721 Summary: [2.30, 2.31 regression] Solaris/x86 TLS transition failures with linker plugin 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 CC: hjl.tools at gmail dot com Target Milestone: --- Host: i386-pc-solaris2.11 Target: i386-pc-solaris2.11 Build: i386-pc-solaris2.11 When I recently tried a gcc mainline bootstrap on Solaris 11/x86 with gas and gld from the binutils 2.30 branch, I found a couple of gcc testsuite regressions: UNRESOLVED: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o execute -O0 -flto -flto-partition=none -fuse-linker-plugin UNRESOLVED: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o execute -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects UNRESOLVED: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o execute -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects UNRESOLVED: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o execute -O2 -flto -fuse-linker-plugin FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O0 -flto -flto-partition=none -fuse-linker-plugin FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -fuse-linker-plugin FAIL: gcc.dg/torture/tls/run-gd.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) WARNING: gcc.dg/torture/tls/run-gd.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects compilation failed to produce executable FAIL: gcc.dg/torture/tls/run-ld.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) WARNING: gcc.dg/torture/tls/run-ld.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects compilation failed to produce executable both for 32 and 64-bit. The regression is present on binutils mainline, too. E.g. for the run-gd.c test, the link fails with /vol/gcc/bin/gld-2.29.90: /var/tmp//ccDiJVLa.ltrans0.ltrans.o: TLS transition from R_386_TLS_GD to R_386_TLS_IE_32 against `tls_gd' at 0x15 in section `.text.startup' failed /vol/gcc/bin/gld-2.29.90: final link failed: Nonrepresentable section on output Since this only happens with -fuse-linker-plugin, I'm a bit at a loss how to produce a standalone testcase. A reghunt identified this patch as the culprit: The first bad revision is: changeset: 91181:891260873d9a user:H.J. Lu date:Sun Aug 06 08:40:56 2017 -0700 summary: x86: Lookup __tls_get_addr or ___tls_get_addr once 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
[Bug ld/22721] [2.30, 2.31 regression] Solaris/x86 TLS transition failures with linker plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=22721 Rainer Orth changed: What|Removed |Added Target Milestone|--- |2.30 -- 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
[Bug ld/22727] New: [2.30, 2.31 regression] Thousands of EH-related execution failures on Solaris/SPARC
https://sourceware.org/bugzilla/show_bug.cgi?id=22727 Bug ID: 22727 Summary: [2.30, 2.31 regression] Thousands of EH-related execution failures 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 CC: hjl.tools at gmail dot com Target Milestone: 2.30 Host: sparc-sun-solaris2.11 Target: sparc-sun-solaris2.11 Build: sparc-sun-solaris2.11 When trying the binutils 2.30 branch on Solaris 11/SPARC with gcc mainline, I found ca. 8500 testsuite regressions, most/all related to EH failures. E.g. FAIL: g++.dg/cpp0x/bad_array_new1.C -std=c++11 execution test When I replace the newly-built libstdc++.so.6 with the system one, the test executes fine. gdb is lead completely astray for this failure Thread 2 received signal SIGILL, Illegal instruction. [Switching to Thread 1 (LWP 1)] 0xff17383c in standard_subs () from ../../../sparc-sun-solaris2.11/libstdc++-v3/src/.libs/libstdc++.so.6 (gdb) where #0 0xff17383c in standard_subs () from ../../../sparc-sun-solaris2.11/libstdc++-v3/src/.libs/libstdc++.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) display/i $pc 1: x/i $pc => 0xff17383c :ldq [ %o5 + -1688 ], %f62 but dbx shows a clearer picture: signal SEGV (no mapping at the fault address) in (unknown) at 0xff17380c 0xff17380c: npos+0x36110: ld [%i3 - 2924], %f31 Current function is __cxa_throw 80 __cxa_eh_globals *globals = __cxa_get_globals (); (dbx) where [1] 0xff17380c(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xff17380c =>[2] __cxa_throw(obj = 0x25888, tinfo = 0x20cd8, dest = 0x20eb8), line 80 in "eh_throw.cc" [3] __cxa_throw_bad_array_new_length(), line 42 in "eh_aux_runtime.cc" [4] f(0x, 0x1, 0x0, 0xfeed0200, 0x0, 0x0), at 0x10a48 [5] main(0x1, 0xffbfea14, 0xffbfea1c, 0x0, 0x0, 0x107c0), at 0x10a74 Comparing that call to __cxa_get_globals in the new (gld 2.30.0-linked) libstdc++.so.6 0xff0722f8 <__cxxabiv1::__cxa_get_globals()>:save %sp, -96, %sp 0xff0722fc <__cxxabiv1::__cxa_get_globals()+4>: sethi %hi(0), %g1 0xff072300 <__cxxabiv1::__cxa_get_globals()+8>: add %g1, 4, %g1! 0x4 0xff072304 <__cxxabiv1::__cxa_get_globals()+12>: sethi %hi(0x105c00), %l7 0xff072308 <__cxxabiv1::__cxa_get_globals()+16>: call 0xff06f4a0 <__sparc_get_pc_thunk.l7> 0xff07230c <__cxxabiv1::__cxa_get_globals()+20>: add %l7, 0xf8, %l7 ! 0x105cf8 0xff072310 <__cxxabiv1::__cxa_get_globals()+24>: sethi %hi(0), %i0 0xff072314 <__cxxabiv1::__cxa_get_globals()+28>: add %l7, %g1, %o0 0xff072318 <__cxxabiv1::__cxa_get_globals()+32>: call 0xff17380c 0xff07231c <__cxxabiv1::__cxa_get_globals()+36>: xor %i0, 0, %i0 0xff072320 <__cxxabiv1::__cxa_get_globals()+40>: add %o0, %i0, %i0 0xff072324 <__cxxabiv1::__cxa_get_globals()+44>: rett %i7 + 8 0xff072328 <__cxxabiv1::__cxa_get_globals()+48>: nop with a gld 2.29-linked libstdc++.so.6: 0xff072240 <__cxxabiv1::__cxa_get_globals()>:save %sp, -96, %sp 0xff072244 <__cxxabiv1::__cxa_get_globals()+4>: sethi %hi(0), %g1 0xff072248 <__cxxabiv1::__cxa_get_globals()+8>: add %g1, 4, %g1! 0x4 0xff07224c <__cxxabiv1::__cxa_get_globals()+12>: sethi %hi(0x105c00), %l7 0xff072250 <__cxxabiv1::__cxa_get_globals()+16>: call 0xff06f3e8 <__sparc_get_pc_thunk.l7> 0xff072254 <__cxxabiv1::__cxa_get_globals()+20>: add %l7, 0x1b0, %l7 ! 0x105db0 0xff072258 <__cxxabiv1::__cxa_get_globals()+24>: sethi %hi(0), %i0 0xff07225c <__cxxabiv1::__cxa_get_globals()+28>: add %l7, %g1, %o0 0xff072260 <__cxxabiv1::__cxa_get_globals()+32>: call 0xff17a1c0 <__tls_get_addr@plt> 0xff072264 <__cxxabiv1::__cxa_get_globals()+36>: xor %i0, 0, %i0 0xff072268 <__cxxabiv1::__cxa_get_globals()+40>: add %o0, %i0, %i0 0xff07226c <__cxxabiv1::__cxa_get_globals()+44>: rett %i7 + 8 0xff072270 <__cxxabiv1::__cxa_get_globals()+48>: nop shows that what used to be a call to __tls_get_addr is now a call to some random address, causing the SEGV/ILL. Disassembling that function gives Disassembly of section .text.__cxa_get_globals: <__cxa_get_globals>: 0: 9d e3 bf a0 save %sp, -96, %sp 4: 03 00 00 00 sethi %hi(0), %g1 8: 82 00 60 00 add %g1, 0, %g1! 0 <__cxa_get_globals> c: 2f 00 00 00 sethi %hi(0), %l7 10: 40 00 00 00 call 10 <__cxa_get_globals+0x10&
[Bug ld/22732] New: Test failures on targets without support for all-static binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=22732 Bug ID: 22732 Summary: Test failures on targets without support for all-static binaries 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: --- Target: *-*-solaris2.* A couple of ld testcases FAIL on Solaris because that platform doesn't support all-static binaries, i.e. there's intentionally no libc.a and libm.a: FAIL: static preinit array FAIL: static init array FAIL: static fini array FAIL: static init array mixed FAIL: No PLT (static 1d) FAIL: No PLT (static 1j) FAIL: No PLT (static 1d) FAIL: No PLT (static 1j) FAIL: LTO 2 E.g. static preinit array FAILs like this: /var/gcc/reghunt/tls-trans/gcc8-bu91180/bin/ld: cannot find -lc collect2: error: ld returned 1 exit status 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
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 Rainer Orth changed: What|Removed |Added CC||hjl.tools at gmail dot com Version|2.22|2.30 --- Comment #1 from Rainer Orth --- I just had the same problem again (this time with gas/gld 2.30) on Solaris 11.4/x86: I tried to build gcc mainline with --enable-host-shared --enable-languages=jit, but running cc1 fails: /var/gcc/regression/trunk/11.4-gcc-gas-gld/build/./gcc/xgcc -B/var/gcc/regression/trunk/11.4-gcc-gas-gld/build/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=/vol/gcc/src/hg/trunk/solaris/gcc/testsuite/selftests ld.so.1: cc1: fatal: relocation error: R_386_UNKNOWN37: file /var/gcc/regression/trunk/11.4-gcc-gas-gld/build/gcc/cc1: symbol __gmpfr_emin: offset size (0 bytes) is not supported xgcc: fatal error: Killed signal terminated program cc1 compilation terminated. make[3]: *** [Makefile:1972: s-selftest-c] Error 1 R_386_UNKNOWN37 above is R_386_TLS_TPOFF32, and the current (Solaris 11.4) has #define R_386_UNKNOWN24 24 #define R_386_UNKNOWN25 25 #define R_386_UNKNOWN26 26 #define R_386_UNKNOWN27 27 #define R_386_UNKNOWN28 28 #define R_386_UNKNOWN29 29 #define R_386_UNKNOWN30 30 #define R_386_UNKNOWN31 31 #define R_386_UNKNOWN37 37 /* reserved for future expansion */ #define R_386_SIZE3238 /* reserved for future expansion */ #define R_386_TLS_GOTDESC 39 /* reserved for future expansion */ #define R_386_TLS_DESC_CALL 40 /* reserved for future expansion */ #define R_386_TLS_DESC 41 /* reserved for future expansion */ #define R_386_IRELATIVE 42 /* GNU/Linux specific (STT_GNU_IFUNC) */ 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
[Bug binutils/22823] bfd/libbfd.h:268:4: error: cast between incompatible function types from ‘bfd_boolean (*)(bfd *)’ {aka ‘int (*)(struct bfd *)’} to ‘bfd_boolean (*)(bfd *, bfd *)’ {aka ‘int (*)(st
https://sourceware.org/bugzilla/show_bug.cgi?id=22823 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-09 CC||ro at gcc dot gnu.org Target Milestone|--- |2.31 Ever confirmed|0 |1 --- Comment #1 from Rainer Orth --- I'm seeing the same (a regression, if you can call it that), from gcc 7.1. You can work around this by configuring with --disable-werror. -- 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
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #13 from Rainer Orth --- Created attachment 10807 --> https://sourceware.org/bugzilla/attachment.cgi?id=10807&action=edit assembler output -- 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
[Bug ld/22839] New: Several plugin tests FAIL on 32-bit Solaris/SPARC
https://sourceware.org/bugzilla/show_bug.cgi?id=22839 Bug ID: 22839 Summary: Several plugin tests FAIL on 32-bit 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.11 Target: sparc-sun-solaris2.11 Build: sparc-sun-solaris2.11 When running make check on 32-bit Solaris/SPARC, a couple of plugin tests FAIL: FAIL: load plugin with source FAIL: plugin claimfile lost symbol with source FAIL: plugin claimfile replace symbol with source FAIL: plugin claimfile resolve symbol with source FAIL: plugin claimfile replace file with source FAIL: plugin set symbol visibility with source FAIL: plugin ignore lib with source FAIL: plugin claimfile replace lib with source FAIL: plugin 2 with source lib FAIL: load plugin 2 with source FAIL: load plugin 2 with source and -r FAIL: plugin 3 with source lib FAIL: load plugin 3 with source FAIL: load plugin 3 with source and -r FAIL: PR ld/20070 It's always the same pattern, it seems (for the first one here): Hello from testplugin. tv[0]: LDPT_MESSAGE func@0x1363fc tv[1]: LDPT_API_VERSION value0x1 (1) tv[2]: LDPT_GNU_LD_VERSION value 0xe6 (230) tv[3]: LDPT_LINKER_OUTPUT value0x1 (1) tv[4]: LDPT_OUTPUT_NAME 'tmpdir/main.x' tv[5]: LDPT_REGISTER_CLAIM_FILE_HOOK func@0x135d88 tv[6]: LDPT_REGISTER_ALL_SYMBOLS_READ_HOOK func@0x135d48 tv[7]: LDPT_REGISTER_CLEANUP_HOOK func@0x135d08 tv[8]: LDPT_ADD_SYMBOLS func@0x1360c4 tv[9]: LDPT_GET_INPUT_FILE func@0x135c9c tv[10]: LDPT_GET_VIEW func@0x135ef4 tv[11]: LDPT_RELEASE_INPUT_FILE func@0x135c48 tv[12]: LDPT_GET_SYMBOLS func@0x1368d8 tv[13]: LDPT_GET_SYMBOLS_V2 func@0x1368cc tv[14]: LDPT_ADD_INPUT_FILE func@0x135e8c tv[15]: LDPT_ADD_INPUT_LIBRARY func@0x135e24 tv[16]: LDPT_SET_EXTRA_LIBRARY_PATH func@0x135dc8 tv[17]: LDPT_OPTION 'registerclaimfile' tv[18]: LDPT_OPTION 'claim:/vol/src/gnu/binutils/binutils/local/ld/testsuite/ld-plugin/func.c' tv[19]: LDPT_NULL value0x0 (0) hook called: claim_file tmpdir/main.o [@0/3100] not claimed hook called: claim_file /vol/src/gnu/binutils/binutils/local/ld/testsuite/ld-plugin/func.c [@0/248] CLAIMED /var/gcc/binutils/sparcv7/obj/binutils/ld/ld-new: BFD (GNU Binutils) 2.30.51.20180209 internal error, aborting at /vol/src/gnu/binutils/binutils/local/bfd/elf32-sparc.c:155 in elf32_sparc_final_write_processing /var/gcc/binutils/sparcv7/obj/binutils/ld/ld-new: Please report this bug. At this point, for some reason we have: arch = bfd_arch_unknown, mach = 0, arch_name = 0xef2e0 "unknown", However, when mach is first set, it looks perfectly reasonable: bfd_default_set_arch_mach (abfd=0x21a578, arch=bfd_arch_sparc, mach=1) The same tests all PASS on sparcv9-sun-solaris2.11, btw. 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
[Bug ld/22840] New: Several TLS tests FAIL on Solaris/SPARC
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
[Bug gas/25732] test-suite failures with i386-pc-solaris2.11
https://sourceware.org/bugzilla/show_bug.cgi?id=25732 Rainer Orth changed: What|Removed |Added Assignee|unassigned at sourceware dot org |ro at gcc dot gnu.org URL||https://sourceware.org/pipe ||rmail/binutils/2020-April/1 ||10483.html Status|WAITING |ASSIGNED --- Comment #16 from Rainer Orth --- Mine, patch posted. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25732] test-suite failures with i386-pc-solaris2.11
https://sourceware.org/bugzilla/show_bug.cgi?id=25732 Rainer Orth changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |2.35 Status|ASSIGNED|RESOLVED --- Comment #18 from Rainer Orth --- Fixed for binutils 2.35. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25802] New: Several 64-bit SPARC tests FAIL: relocation truncated to fit
https://sourceware.org/bugzilla/show_bug.cgi?id=25802 Bug ID: 25802 Summary: Several 64-bit SPARC tests FAIL: relocation truncated to fit Product: binutils Version: 2.35 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: ro at gcc dot gnu.org CC: davem at davemloft dot net, jose.marchesi at oracle dot com Target Milestone: --- Host: sparcv9-sun-solaris2.11 Target: sparcv9-sun-solaris2.11 Build: sparcv9-sun-solaris2.11 Several ld tests FAIL on 64-bit Solaris/SPARC, all with the same problem: FAIL: ld-elf/compress1a tmpdir/compress1.o:(.debug_info+0x10): relocation truncated to fit: R_SPARC_UA32 against `.text' tmpdir/compress1.o:(.debug_info+0x14): relocation truncated to fit: R_SPARC_UA32 against `.text' tmpdir/compress1.o:(.debug_info+0x40): relocation truncated to fit: R_SPARC_UA32 against `.text' tmpdir/compress1.o:(.debug_info+0x44): relocation truncated to fit: R_SPARC_UA32 against `.text' tmpdir/compress1.o:(.debug_line+0x30): relocation truncated to fit: R_SPARC_UA32 against `.text' tmpdir/compress1.o:(.debug_line+0x3b): relocation truncated to fit: R_SPARC_UA32 against `.text' FAIL: ld-elf/compressed1a same errors FAIL: ld-elf/eh5 tmpdir/eh5.o:(.eh_frame+0x3e): relocation truncated to fit: R_SPARC_UA32 against symbol `my_personality_v0' defined in .text section in tmpdir/eh5.o tmpdir/eh5.o:(.eh_frame+0x87): relocation truncated to fit: R_SPARC_UA32 against symbol `my_personality_v0' defined in .text section in tmpdir/eh5.o tmpdir/eh5a.o:(.eh_frame+0x3a): relocation truncated to fit: R_SPARC_UA32 against symbol `my_personality_v1' defined in .text section in tmpdir/eh5a.o tmpdir/eh5a.o:(.eh_frame+0x7f): relocation truncated to fit: R_SPARC_UA32 against symbol `my_personality_v1' defined in .text section in tmpdir/eh5a.o FAIL: --gc-sections with multiple debug sections for a function section tmpdir/all-debug-sections.o: in function `debug_info_main': (.debug_info.text.main+0x4): relocation truncated to fit: R_SPARC_32 against symbol `main' defined in .text.main section in tmpdir/all-debug-sections.o tmpdir/all-debug-sections.o: in function `debug_aranges_main': (.debug_aranges.text.main+0x4): relocation truncated to fit: R_SPARC_32 against symbol `main' defined in .text.main section in tmpdir/all-debug-sections.o tmpdir/all-debug-sections.o: in function `debug_line_main': (.debug_line.text.main+0x4): relocation truncated to fit: R_SPARC_32 against symbol `main' defined in .text.main section in tmpdir/all-debug-sections.o When using Solaris ld instead, all tests can be linked (modulo removal of -z norelo since Solaris doesn't support relro). 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. 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. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25802] Several 64-bit SPARC tests FAIL: relocation truncated to fit
https://sourceware.org/bugzilla/show_bug.cgi?id=25802 --- Comment #4 from Rainer Orth --- Created attachment 12617 --> https://sourceware.org/bugzilla/attachment.cgi?id=12617&action=edit ld-elf/eh5 elfdump -u output -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25802] Several 64-bit SPARC tests FAIL: relocation truncated to fit
https://sourceware.org/bugzilla/show_bug.cgi?id=25802 --- Comment #5 from Rainer Orth --- Created attachment 12618 --> https://sourceware.org/bugzilla/attachment.cgi?id=12618&action=edit ld-elf/eh5 readelf -wf output -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27666] New: ar doesn't create indices on Solaris/sparcv9
https://sourceware.org/bugzilla/show_bug.cgi?id=27666 Bug ID: 27666 Summary: ar doesn't create indices on Solaris/sparcv9 Product: binutils Version: 2.37 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: ro at gcc dot gnu.org CC: amodra at gmail dot com Target Milestone: --- Target: sparcv9-sun-solaris2.* On binutils master, quite a number of tests currently fail on Solaris/sparcv9. E.g. FAIL: ar thin archive and several more where the Archive index: section is missing from the nm --print-armap output. Likewise, several ld tests FAIL like this: ./ld-new: tmpdir/libpr25910.a: error adding symbols: archive has no index; run ranlib to add one failed with: <./ld-new: tmpdir/libpr25910.a: error adding symbols: archive has no index; run ranlib to add one>, no expected output FAIL: --export-dynamic-symbol foo archive And indeed, even with an explicit ar rs no index is created. This is not very easy to diagnose, it seems: I needed to use file to note the common issue of missing archive index. Looking back, this has worked in binutils 2.35, but was already broken in 2.36. Using side-by-side debugging with (working) Solaris/amd64 and (broken) Solaris/sparcv9, I found that in _bfd_write_archive_contents hasobjects remains 0 after the bfd_check_format call. In format.c (bfd_check_format_matches), the second call to BFD_SEND_FMT (abfd, _bfd_check_format, (abfd)) on l.343 matches only once on amd64 (for x86_64_elf64_sol2_vec), while it matches twice on sparcv9 (both for sparc_elf64_sol2_vec and sparc_elf64_vec). That sort of rang a bell and I found that https://sourceware.org/pipermail/binutils/2021-January/114778.html commit 3677b7296185e6abfe8327c00c460712151ade15 Author: Alan Modra Date: Wed Jan 6 12:01:10 2021 +1030 sparc-sun-solaris2 and sparc64-sun-solaris2 config had added the non-_sol2 vectors on Solaris/SPARC. Reverting the config.bfd part of the patch fixed the archive index issue. I believe that I had omitted the non-_sol2 vectors for a reason back in 2010: http://sourceware.org/ml/binutils/2010-10/msg00348.html There were similar ambiguities IIRC. On top of that, I believe the failing tests are better fixed differently: * You've already taken the first step in making the dump files both forms of the target names, with and without the _sol2 suffix. * The next step, I believe, would be to pass -m..._sol2 on Solaris (both sparc and x86). * The ugliest part is that due to differences in the Solaris ABI, the dumps differ from the Linux ones. Unfortunately, there's no way to represent conditional sections in the dumps and keeping separate copies almost guarantees that they diverge in the future. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27666] ar doesn't create indices on Solaris/sparcv9
https://sourceware.org/bugzilla/show_bug.cgi?id=27666 Rainer Orth changed: What|Removed |Added Target Milestone|--- |2.37 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32580] [2.44 regression] Non-bash shell breaks many default linker scripts
https://sourceware.org/bugzilla/show_bug.cgi?id=32580 --- Comment #2 from Rainer Orth --- Created attachment 15894 --> https://sourceware.org/bugzilla/attachment.cgi?id=15894&action=edit proposed patch (hack?) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32580] [2.44 regression] Non-bash shell breaks many default linker scripts
https://sourceware.org/bugzilla/show_bug.cgi?id=32580 Rainer Orth changed: What|Removed |Added Target Milestone|--- |2.44 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32580] New: [2.44 regression] Non-bash shell breaks many default linker scripts
https://sourceware.org/bugzilla/show_bug.cgi?id=32580
Bug ID: 32580
Summary: [2.44 regression] Non-bash shell breaks many default
linker scripts
Product: binutils
Version: 2.44
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: ro at gcc dot gnu.org
CC: nickc at redhat dot com
Target Milestone: ---
Target: *-*-solaris2.11
When trying the binutils 2.44 branch on Solaris, I found that roughly half the
ld test FAIL with
./ld-new:built in linker script:0: syntax error
While this error is as useless as it gets, it turns out that the same problem
happens with the default linker script files, too. In particular, a link with
gcc -shared fails as above, while without it it works.
Comparing the generated linker scripts between 2.43 and 2.44, I see that e.g
elf_i386_sol2.xs is heavily truncated, like
@@ -94,144 +94,3 @@
/* Adjust the address for the data segment. We want to adjust up to
the same address within the page on the next page up. */
. = DATA_SEGMENT_ALIGN (CONSTANT (MAXPAGESIZE), CONSTANT (COMMONPAGESIZE));
- /* Exception handling. */
- .eh_frame : ONLY_IF_RW { KEEP (*(.eh_frame)) *(.eh_frame.*) }
- .sframe : ONLY_IF_RW { *(.sframe) *(.sframe.*) }
[...]
As it turns out, this only happens when CONFIG_SHELL is /bin/ksh (or /bin/sh),
which is ksh93. With /bin/bash, the linker scripts are generated correctly.
This is a regression from 2.43.
I'm still trying to figure out what exactly caused this. So far I've found
that the the problem started with
commit fe217087a4b8aa214a221ca9f033c5fcdbcee90e
Author: Nick Clifton
Date: Wed Nov 27 11:23:38 2024 +
Tidy up the default ELF linker script
One thing I noticed is that in two places (emit_noinit, emit_persistent)
the cat <
[Bug gas/32579] [2.44 regression] Support for x86 Sun cmov syntax is incomplete
https://sourceware.org/bugzilla/show_bug.cgi?id=32579 Rainer Orth changed: What|Removed |Added Target Milestone|--- |2.44 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32579] New: [2.44 regression] Support for x86 Sun cmov syntax is incomplete
https://sourceware.org/bugzilla/show_bug.cgi?id=32579 Bug ID: 32579 Summary: [2.44 regression] Support for x86 Sun cmov syntax is incomplete Product: binutils Version: 2.44 Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: ro at gcc dot gnu.org CC: jbeulich at suse dot com Target Milestone: --- Target: i386-pc-solaris2.11, amd64-pc-solaris2.11 I just tried gcc trunk bootstraps with gas and gld from the binutils 2.44 branch. Unfortunately, bootstrap is broken, a regression from binutils 2.43: gcc/configure has this change -/* #undef HAVE_AS_IX86_CMOV_SUN_SYNTAX */ +#define HAVE_AS_IX86_CMOV_SUN_SYNTAX 1 but when building the stage 1 64-bit libgcc, gas chokes: /var/tmp//ccFX2LZa.s: Assembler messages: /var/tmp//ccFX2LZa.s:112: Error: no such instruction: `cmovq.s %rbx,%rax' That alternative cmov syntax support was introduced in commit 8a07ebae720c312aef3f19abf2070fbf4ba11187 Author: Jan Beulich Date: Fri Nov 29 09:37:13 2024 +0100 x86/Solaris: support Sun form of CMOVcc but is appparently incomplete, thus breaking bootstrap. It makes gas 2.44 useless on Solaris/x86. -- You are receiving this mail because: You are on the CC list for the bug.
