[Bug binutils/29566] objdump -p considers an empty .gnu.version_r invalid
https://sourceware.org/bugzilla/show_bug.cgi?id=29566 --- Comment #1 from Alan Modra --- Is there any point in allowing an empty .gnu.version_r section? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29566] objdump -p considers an empty .gnu.version_r invalid
https://sourceware.org/bugzilla/show_bug.cgi?id=29566 --- Comment #2 from Fangrui Song --- The spec (https://sourceware.org/gnu-gabi/program-loading-and-dynamic-linking.txt) doesn't reject it. For a section whose content is a concatenated N items, the ELF spirits typically allows N==0, as otherwise it needs an additional sentence to disallow the case, which is unnecessary. It seems that the reference implementation of Go may generate .gnu.version_r at least in some cases: https://github.com/llvm/llvm-project/issues/57707 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29149] spidermonkey-91 fails to link with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
https://sourceware.org/bugzilla/show_bug.cgi?id=29149 tt_1 changed: What|Removed |Added URL||https://bugzilla.mozilla.or ||g/show_bug.cgi?id=1786621 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29594] New: [ld, feature request] Add --ctf-functions
https://sourceware.org/bugzilla/show_bug.cgi?id=29594 Bug ID: 29594 Summary: [ld, feature request] Add --ctf-functions Product: binutils Version: 2.40 (HEAD) Status: NEW Severity: enhancement Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org Target Milestone: --- Normally, when using gcc -gctf, gcc produces info for various things: ... Contents of CTF section .ctf: Header: Magic number: 0xdff2 Version: 4 (CTF_VERSION_3) Flags: 0x2 (CTF_F_NEWFUNCINFO) Compilation unit name: gdb/testsuite/gdb.base/ctf-constvars.c Data object section:0x0 -- 0xcb (0xcc bytes) Function info section: 0xcc -- 0xcf (0x4 bytes) Object index section: 0xd0 -- 0x19b (0xcc bytes) Function index section: 0x19c -- 0x19f (0x4 bytes) Variable section: 0x1a0 -- 0x337 (0x198 bytes) Type section: 0x338 -- 0x7ab (0x474 bytes) String section: 0x7ac -- 0x9dc (0x231 bytes) ... but after linking, both functions and variables are dropped: ... Header: Magic number: 0xdff2 Version: 4 (CTF_VERSION_3) Flags: 0xe (CTF_F_NEWFUNCINFO, CTF_F_IDXSORTED, CTF_F_DYNSTR) Compilation unit name: gdb/testsuite/gdb.base/ctf-constvars.c Type section: 0x0 -- 0x473 (0x474 bytes) String section: 0x474 -- 0x51b (0xa8 bytes) ... There's a linker flag: -Wl,--ctf-variables that makes ld pass variable info to the exec, such that we have: ... Contents of CTF section .ctf: Header: Magic number: 0xdff2 Version: 4 (CTF_VERSION_3) Flags: 0xe (CTF_F_NEWFUNCINFO, CTF_F_IDXSORTED, CTF_F_DYNSTR) Compilation unit name: gdb/testsuite/gdb.base/ctf-constvars.c Variable section: 0x0 -- 0x19f (0x1a0 bytes) Type section: 0x1a0 -- 0x613 (0x474 bytes) String section: 0x614 -- 0x844 (0x231 bytes) ... But there's no equivalent for functions, so these still go missing. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29566] objdump -p considers an empty .gnu.version_r invalid
https://sourceware.org/bugzilla/show_bug.cgi?id=29566 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |amodra at gmail dot com --- Comment #3 from Alan Modra --- OK, so if we have linkers that produce them, I suppose they ought to be allowed. Easily done. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29592] [2.39 Regression][bisected] Exec stack warning causes go programs with cgo to fail to link on mips
https://sourceware.org/bugzilla/show_bug.cgi?id=29592 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to matoro from comment #0) Hi Matoro, > On mips, since this commit, all linking prints the following warning: > > /usr/lib/gcc/mips64-unknown-linux-gnu/12.2.0/../../../../mips64-unknown- > linux-gnu/bin/ld: warning: > /usr/lib/gcc/mips64-unknown-linux-gnu/12.2.0/../../../../lib64/Scrt1.o: > requires executable stack (because the .note.GNU-stack section is executable) This was supposed to have been fixed by commit ed1c7ad8e31a2cfca1d8c8c898ee7cde6ae340ca Do you have that commit in your sources ? > /var/tmp/portage/dev-lang/go-1.19.1/temp/go-link-3757955373/go.o: in > function `internal/cpu.Initialize': > /usr/lib/go/src/internal/cpu/cpu.go:123:(.text+0x14): relocation R_MIPS_26 > against `a local symbol' cannot be used when making a shared object; > recompile with -fPIC Are you sure that it was that commit which triggered this problem ? The commit only added code to generate the new warning messages, it did not - or at least should not - affect the linking process in any other way. Also - is the warning correct ? Is the -fPIC option missing from the compilation command line ? Or is the linker mistaken when it complains about attempting to create a shared object ? (IE is it supposed to be creating a static executable rather than a dynamic executable ?) Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29547] binutils-2.39: fails to build against cctools nm (no '-B' option support)
https://sourceware.org/bugzilla/show_bug.cgi?id=29547 --- Comment #9 from Nick Alcock --- On 20 Sep 2022, slyich at gmail dot com spake thusly: > Seems to build binutils just fine! Detected `nm -p` command option. Great! It'll go in the next tranche, and probably be backported to 2.39. (But that's a week or so off -- long test runs plus a bunch of other stuff I want to get in at the same time, courtesy of feature requests at LPC. :) ) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29547] binutils-2.39: fails to build against cctools nm (no '-B' option support)
https://sourceware.org/bugzilla/show_bug.cgi?id=29547 Nick Alcock changed: What|Removed |Added Status|WAITING |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29566] objdump -p considers an empty .gnu.version_r invalid
https://sourceware.org/bugzilla/show_bug.cgi?id=29566 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |2.40 --- Comment #5 from Alan Modra --- Fixed for 2.40 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29566] objdump -p considers an empty .gnu.version_r invalid
https://sourceware.org/bugzilla/show_bug.cgi?id=29566 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f9a59eea78428159a9522bd64ec354a872f1dc31 commit f9a59eea78428159a9522bd64ec354a872f1dc31 Author: Alan Modra Date: Wed Sep 21 19:34:08 2022 +0930 PR29566, objdump -p considers an empty .gnu.version_r invalid Allow and ignore an empty section. PR 29566 * elf.c (bfd_section_from_shdr): Don't set elf_dynverdef or elf_dynverref for empty sections. (_bfd_elf_slurp_version_tables): Remove now redundant tests. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29592] [2.39 Regression][bisected] Exec stack warning causes go programs with cgo to fail to link on mips
https://sourceware.org/bugzilla/show_bug.cgi?id=29592 --- Comment #2 from matoro --- (In reply to Nick Clifton from comment #1) > (In reply to matoro from comment #0) > Hi Matoro, > > > On mips, since this commit, all linking prints the following warning: > > > > /usr/lib/gcc/mips64-unknown-linux-gnu/12.2.0/../../../../mips64-unknown- > > linux-gnu/bin/ld: warning: > > /usr/lib/gcc/mips64-unknown-linux-gnu/12.2.0/../../../../lib64/Scrt1.o: > > requires executable stack (because the .note.GNU-stack section is > > executable) > > This was supposed to have been fixed by commit > ed1c7ad8e31a2cfca1d8c8c898ee7cde6ae340ca > Do you have that commit in your sources ? > > > > > /var/tmp/portage/dev-lang/go-1.19.1/temp/go-link-3757955373/go.o: in > > function `internal/cpu.Initialize': > > /usr/lib/go/src/internal/cpu/cpu.go:123:(.text+0x14): relocation R_MIPS_26 > > against `a local symbol' cannot be used when making a shared object; > > recompile with -fPIC > > Are you sure that it was that commit which triggered this problem ? > > The commit only added code to generate the new warning messages, it did not > - or at least should not - affect the linking process in any other way. > > Also - is the warning correct ? Is the -fPIC option missing from the > compilation command line ? Or is the linker mistaken when it complains > about attempting to create a shared object ? (IE is it supposed to be > creating a static executable rather than a dynamic executable ?) > > Cheers > Nick Hi Nick, thank you for taking a look at this. I checked and found that the distro (Gentoo) is actually explicitly passing --enable-warn-execstack, so any change to the defaults doesn't help: https://github.com/gentoo/gentoo/blob/master/sys-devel/binutils/binutils-.ebuild#L251 I tested at that commit and when --enable-warn-execstack is passed, the issue is still present. What I don't understand is why toggling this warning on or off changes the behavior of the linker - shouldn't it just be a purely informational warning? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29592] [2.39 Regression][bisected] Exec stack warning causes go programs with cgo to fail to link on mips
https://sourceware.org/bugzilla/show_bug.cgi?id=29592 --- Comment #3 from matoro --- The warning itself is correct. In golang, CGO_ENABLED=1 (the default) creates a dynamic exe, while CGO_ENABLED=0 produces a static one. However the -fPIC part is not accurate. Golang has its own assembly emitter, it doesn't use gcc or any compiler for codegen. It only uses ld for linking. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29592] [2.39 Regression][bisected] Exec stack warning causes go programs with cgo to fail to link on mips
https://sourceware.org/bugzilla/show_bug.cgi?id=29592 --- Comment #4 from matoro --- OK, just tested, removing --enable-warn-execstack does resolve the problem. But that also confirms that toggling that flag is not purely informational, it has an effect on the linker behavior and causes previously-working scenarios to stop working. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29435] Building openblas with binutils 2.38 leads to "ELF load command address/offset not properly aligned"
https://sourceware.org/bugzilla/show_bug.cgi?id=29435 --- Comment #9 from cvs-commit at gcc dot gnu.org --- The binutils-2_39-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a98316d5cf970cbc99689797d84c2ea832bcdcbb commit a98316d5cf970cbc99689797d84c2ea832bcdcbb Author: H.J. Lu Date: Mon Aug 1 16:02:39 2022 -0700 elf: Reset alignment for each PT_LOAD segment Reset alignment for each PT_LOAD segment to avoid using alignment from the previous PT_LOAD segment. bfd/ PR ld/29435 * elf.c (assign_file_positions_for_load_sections): Reset alignment for each PT_LOAD segment. ld/ PR ld/29435 * testsuite/ld-elf/pr29435.d: New file. * testsuite/ld-elf/pr29435.s: Likewise. (cherry picked from commit 59f214544c50ec7ebbca285ff2b4949f48671690) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29435] Building openblas with binutils 2.38 leads to "ELF load command address/offset not properly aligned"
https://sourceware.org/bugzilla/show_bug.cgi?id=29435 --- Comment #10 from cvs-commit at gcc dot gnu.org --- The binutils-2_38-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=dc2474e7d204c124ab5a21b4490aa46eb7e1d4c3 commit dc2474e7d204c124ab5a21b4490aa46eb7e1d4c3 Author: H.J. Lu Date: Mon Aug 1 16:02:39 2022 -0700 elf: Reset alignment for each PT_LOAD segment Reset alignment for each PT_LOAD segment to avoid using alignment from the previous PT_LOAD segment. bfd/ PR ld/29435 * elf.c (assign_file_positions_for_load_sections): Reset alignment for each PT_LOAD segment. ld/ PR ld/29435 * testsuite/ld-elf/pr29435.d: New file. * testsuite/ld-elf/pr29435.s: Likewise. (cherry picked from commit 59f214544c50ec7ebbca285ff2b4949f48671690) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29435] Building openblas with binutils 2.38 leads to "ELF load command address/offset not properly aligned"
https://sourceware.org/bugzilla/show_bug.cgi?id=29435 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Alan Modra --- Fixed everywhere -- You are receiving this mail because: You are on the CC list for the bug.
