[Bug ld/31489] --as-needed doesn't work with references to builtin functions
https://sourceware.org/bugzilla/show_bug.cgi?id=31489 --- Comment #4 from Sourceware Commits --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e7e05a9dd0c93038fdd5ed1904ca660e52beabdc commit e7e05a9dd0c93038fdd5ed1904ca660e52beabdc Author: Alan Modra Date: Sat Apr 6 15:49:44 2024 +1030 Don't have first_hash entries of strings that can be freed. Seen running "LTO 1" under valgrind. ==1443263== Invalid read of size 1 ==1443263==at 0x484CFE4: strcmp (vg_replace_strmem.c:939) ==1443263==by 0x56E16C: bfd_hash_lookup (hash.c:564) ==1443263==by 0x5A3C8F: elf_link_add_to_first_hash (elflink.c:4316) ==1443263==by 0x5AE60F: elf_link_add_object_symbols (elflink.c:5663) ==1443263==by 0x5B0672: bfd_elf_link_add_symbols (elflink.c:6333) ==1443263==by 0x41448F: load_symbols (ldlang.c:3129) ==1443263==by 0x4149D8: open_input_bfds (ldlang.c:3621) ==1443263==by 0x414968: open_input_bfds (ldlang.c:3569) ==1443263==by 0x4166A2: lang_process (ldlang.c:8162) ==1443263==by 0x4194D5: main (ldmain.c:504) ==1443263== Address 0x525e230 is 192 bytes inside a block of size 4,064 free'd ==1443263==at 0x484810F: free (vg_replace_malloc.c:974) ==1443263==by 0x8D4D87: objalloc_free_block (objalloc.c:248) ==1443263==by 0x5AEACC: elf_link_add_object_symbols (elflink.c:5790) ==1443263==by 0x5B0672: bfd_elf_link_add_symbols (elflink.c:6333) ==1443263==by 0x41448F: load_symbols (ldlang.c:3129) ==1443263==by 0x4149D8: open_input_bfds (ldlang.c:3621) ==1443263==by 0x414968: open_input_bfds (ldlang.c:3569) ==1443263==by 0x4166A2: lang_process (ldlang.c:8162) ==1443263==by 0x4194D5: main (ldmain.c:504) PR ld/31482 PR ld/31489 * elflink.c (elf_link_add_to_first_hash): Add "copy" param. (elf_link_add_object_symbols): Flag that name must be copied when appending version string to symbol name. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31482] The first definition in shared object and archive is ignored
https://sourceware.org/bugzilla/show_bug.cgi?id=31482 --- Comment #12 from Sourceware Commits --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e7e05a9dd0c93038fdd5ed1904ca660e52beabdc commit e7e05a9dd0c93038fdd5ed1904ca660e52beabdc Author: Alan Modra Date: Sat Apr 6 15:49:44 2024 +1030 Don't have first_hash entries of strings that can be freed. Seen running "LTO 1" under valgrind. ==1443263== Invalid read of size 1 ==1443263==at 0x484CFE4: strcmp (vg_replace_strmem.c:939) ==1443263==by 0x56E16C: bfd_hash_lookup (hash.c:564) ==1443263==by 0x5A3C8F: elf_link_add_to_first_hash (elflink.c:4316) ==1443263==by 0x5AE60F: elf_link_add_object_symbols (elflink.c:5663) ==1443263==by 0x5B0672: bfd_elf_link_add_symbols (elflink.c:6333) ==1443263==by 0x41448F: load_symbols (ldlang.c:3129) ==1443263==by 0x4149D8: open_input_bfds (ldlang.c:3621) ==1443263==by 0x414968: open_input_bfds (ldlang.c:3569) ==1443263==by 0x4166A2: lang_process (ldlang.c:8162) ==1443263==by 0x4194D5: main (ldmain.c:504) ==1443263== Address 0x525e230 is 192 bytes inside a block of size 4,064 free'd ==1443263==at 0x484810F: free (vg_replace_malloc.c:974) ==1443263==by 0x8D4D87: objalloc_free_block (objalloc.c:248) ==1443263==by 0x5AEACC: elf_link_add_object_symbols (elflink.c:5790) ==1443263==by 0x5B0672: bfd_elf_link_add_symbols (elflink.c:6333) ==1443263==by 0x41448F: load_symbols (ldlang.c:3129) ==1443263==by 0x4149D8: open_input_bfds (ldlang.c:3621) ==1443263==by 0x414968: open_input_bfds (ldlang.c:3569) ==1443263==by 0x4166A2: lang_process (ldlang.c:8162) ==1443263==by 0x4194D5: main (ldmain.c:504) PR ld/31482 PR ld/31489 * elflink.c (elf_link_add_to_first_hash): Add "copy" param. (elf_link_add_object_symbols): Flag that name must be copied when appending version string to symbol name. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31614] New: [2.40 Regression] LD fails to link thin archive
https://sourceware.org/bugzilla/show_bug.cgi?id=31614
Bug ID: 31614
Summary: [2.40 Regression] LD fails to link thin archive
Product: binutils
Version: 2.40
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: timo.kreuzer at reactos dot org
Target Milestone: ---
Since version 2.40 LD fails to link (certain?) archives in thin format.
Test case:
1. Create the following file as oldnames.def:
LIBRARY msvcrt.dll
EXPORTS
eof==_eof
2. Create an import lib with the command "dlltool.exe --def oldnames.def
--output-lib=oldnames.a -t oldnames"
3. Convert the import lib to thin format with the command "ar.exe crT
liboldnames.a oldnames.a"
4. Create the following file as bug.c:
extern int eof(int fd);
int main() {
return eof(0);
}
5. Compile bug.c with "gcc -o bug.obj -c bug.c"
6. Link bug.exe with "gcc bug.obj liboldnames.a -o bug.exe"
Expected behavior: It links the executable.
Observed behavior (with ld 2.40, 2.41, 2.42): ld fails with an error:
"collect2.exe: error: ld returned 5 exit status"
Using binutils 2.42 and only replacing ld.exe with version 2.39 fixes the
issue.
Please note that the process above is a simple example for an integral part of
the ReactOS build process and suggestions like "just don't convert the import
lib to thin format" are not helpful.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/31606] [2.43 Regression] "shld %rsi,%rdx,%rax" no longer works
https://sourceware.org/bugzilla/show_bug.cgi?id=31606 --- Comment #3 from Sourceware Commits --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=cca46dea4d09fc9d9896e952242b3e8f5baa506a commit cca46dea4d09fc9d9896e952242b3e8f5baa506a Author: H.J. Lu Date: Sat Apr 6 05:02:56 2024 -0700 Revert "x86: Restore APX shift-double instructions with omitted shift count" This reverts commit c2d698fe03a6092d58a07de96068b87836daced0. GCC 14 has been changed to use explicit shift count in shift-double instructions by the commit: 06a7e7514af x86: Use explicit shift count in double-precision shifts gas/ PR gas/31606 * testsuite/gas/i386/x86-64-apx-ndd-wig.d: Updated. * testsuite/gas/i386/x86-64-apx-ndd.d: Likewise. * testsuite/gas/i386/x86-64-apx-ndd.s: Remove tests for APX shift-double instructions with omitted shift count. opcodes/ PR gas/31606 * i386-opc.tbl: Remove APX shift-double instructions with omitted shift count. * i386-tbl.h: Regenerated. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31614] [2.40 Regression] LD fails to link thin archive
https://sourceware.org/bugzilla/show_bug.cgi?id=31614 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING CC||hjl.tools at gmail dot com Ever confirmed|0 |1 Last reconfirmed||2024-04-06 --- Comment #1 from H.J. Lu --- Does it happen on Linux? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31615] New: Hang when linking vorbis-tools
https://sourceware.org/bugzilla/show_bug.cgi?id=31615 Bug ID: 31615 Summary: Hang when linking vorbis-tools Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: sam at gentoo dot org CC: hjl.tools at gmail dot com Target Milestone: --- I noticed that building vorbis-tools-1.4.2 hangs and took > 10 minutes before I killed it. During the build, the hanging command is: ``` x86_64-pc-linux-gnu-gcc -O2 -Wall -ffast-math -fsigned-char -O3 -march=native -mtls-dialect=gnu2 -flto=jobserver -fno-semantic-interposition -pipe -fcf-protection=none -fdiagnostics-color=always -fdiagnostics-urls=never -frecord-gcc-switches -Wa,-O2 -Wa,-mtune=znver2 -Wstrict-aliasing -Wfree-nonheap-object -Werror=lto-type-mismatch -Werror=strict-aliasing -Werror=odr -Wstrict-aliasing -Wfree-nonheap-object -Werror=lto-type-mismatch -Werror=strict-aliasing -Werror=odr -Wbuiltin-declaration-mismatch -ggdb3 -Wformat -Wformat-security -Waddress -Warray-bounds -Wfree-nonheap-object -Wint-to-pointer-cast -Wmain -Wnonnull -Wodr -Wreturn-type -Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstring-compare -Wuninitialized -Wvarargs -Wl,-O1 -Wl,-z -Wl,pack-relative-relocs -flto=jobserver -Wl,--defsym=__gentoo_check_ldflags__=0 -ggdb3 -o oggenc flac.o easyflac.o oggenc.o audio.o encode.o platform.o resample.o skeleton.o -Wl,--as-needed ../share/libutf8.a ../share/libgetopt.a -lvorbisenc -lvorbis -lFLAC -logg -lm ``` Reduced is: ``` gcc -o oggenc flac.o easyflac.o oggenc.o audio.o encode.o platform.o resample.o skeleton.o -Wl,--as-needed libutf8.a libgetopt.a libvorbisenc.so.2.0.12 libvorbis.so.0.4.9 libFLAC.so.12.1.0 libogg.so.0.8.5 -lm ``` * Appending -fuse-ld=mold makes it complete (I used mold as I used LTO so needed the plugin support which lld didn't have here.) * Dropping -Wl,--as-needed makes it complete. gdb says: ``` 0x7fce71af2674 in _bfd_generic_link_add_one_symbol (info=0x5630c7418ea0 , abfd=0x5630c86a12e0, name=0x5630c9014ef8 "ldexp", flags=, section=0x7fce72114388 <_bfd_std_section+840>, value=0, string=0x5630c9014ee0 "ldexp@@GLIBC_2.2.5", copy=false, collect=false, hashp=0x7ffdfb92ea80) at /usr/src/debug/sys-devel/binutils-/binutils/bfd/linker.c:1477 1477 action = link_action[(int) row][prev]; (gdb) bt #0 0x7fce71af2674 in _bfd_generic_link_add_one_symbol (info=0x5630c7418ea0 , abfd=0x5630c86a12e0, name=0x5630c9014ef8 "ldexp", flags=, section=0x7fce72114388 <_bfd_std_section+840>, value=0, string=0x5630c9014ee0 "ldexp@@GLIBC_2.2.5", copy=false, collect=false, hashp=0x7ffdfb92ea80) at /usr/src/debug/sys-devel/binutils-/binutils/bfd/linker.c:1477 #1 0x7fce71b3bfe2 in _bfd_elf_add_default_symbol (abfd=, info=, h=0x5630c88fcc30, name=, sym=0x5630c8e01400, sec=0x7fce72114158 <_bfd_std_section+280>, value=, poldbfd=0x7ffdfb92ea68, dynsym=) at /usr/src/debug/sys-devel/binutils-/binutils/bfd/elflink.c:2023 #2 elf_link_add_object_symbols (abfd=, info=) at /usr/src/debug/sys-devel/binutils-/binutils/bfd/elflink.c:5419 #3 bfd_elf_link_add_symbols (abfd=, info=) at /usr/src/debug/sys-devel/binutils-/binutils/bfd/elflink.c:6339 #4 0x5630c72b5f9a in load_symbols (entry=entry@entry=0x5630c84d8370, place=place@entry=0x7ffdfb92eb70) at /usr/src/debug/sys-devel/binutils-/binutils/ld/ldlang.c:3129 #5 0x5630c72a89a0 in open_input_bfds (s=0x5630c84d8370, os=, mode=(OPEN_BFD_FORCE | OPEN_BFD_RESCAN)) at /usr/src/debug/sys-devel/binutils-/binutils/ld/ldlang.c:3621 #6 0x5630c72a8941 in open_input_bfds (s=0x5630c84d8350, os=, mode=OPEN_BFD_RESCAN) at /usr/src/debug/sys-devel/binutils-/binutils/ld/ldlang.c:3569 #7 0x5630c72a7932 in lang_process () at /usr/src/debug/sys-devel/binutils-/binutils/ld/ldlang.c:8248 #8 0x5630c72afcb8 in main (argc=63, argv=) at /usr/src/debug/sys-devel/binutils-/binutils/ld/ldmain.c:511 ``` perf but perhaps not so insightful ;) says: `` 100.00% ld libbfd-2.42.50.20240406.gentoo-sys-devel-binutils-mt.so [.] _bfd_generic_link_add_one_symbol 0.00% ld [kernel.kallsyms] [k] stackleak_erase 0.00% ld [kernel.kallsyms] [k] arch_perf_update_userpage 0.00% ld [kernel.kallsyms] [k] perf_ibs_handle_irq 0.00% ld [kernel.kallsyms] [k] perf_ibs_start ``` ``` $ ld --version | head -1 GNU ld (Gentoo p1) 2.42.50.20240406 ``` I can try reduce it to C if needed but it will take more time. I have attached a reproducible tarball with object files. Tell me if need to do anything else. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31615] Hang when linking vorbis-tools
https://sourceware.org/bugzilla/show_bug.cgi?id=31615 --- Comment #1 from Sam James --- Tarball of objects: https://dev.gentoo.org/~sam/bugs/sourceware/31615/binutils-PR31615.tar.xz. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31615] Hang when linking vorbis-tools
https://sourceware.org/bugzilla/show_bug.cgi?id=31615 --- Comment #2 from Sam James --- My guess is the recent LTO rescan fixes but I did not bisect yet. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31615] Hang when linking vorbis-tools
https://sourceware.org/bugzilla/show_bug.cgi?id=31615 --- Comment #3 from Sam James --- Given LTO is involved, you may need matching GCC version: gcc version 14.0.1 20240405 (experimental) 4b02dd48f531ea88587edd2b75b6e5243b4389e8 (Gentoo Hardened 14.0. p, commit 7bbfb01a32b73842f8908de028703510a0e12057). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31252] gprofng causes testsuite parallel jobs fail (again)
https://sourceware.org/bugzilla/show_bug.cgi?id=31252 --- Comment #6 from Sam James --- (In reply to Radu Hociung from comment #5) > Created attachment 15451 [details] > fixes failure due to hardcoded bash path Can you send to the ML? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31614] [2.40 Regression] LD fails to link thin archive
https://sourceware.org/bugzilla/show_bug.cgi?id=31614 --- Comment #2 from Timo Kreuzer --- No, it doesn't happen on linux (tested with bnutils 2.40 on Debian) The Windows binaries it happens with are from winlibs (https://winlibs.com/) and also self-built. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31615] Hang when linking vorbis-tools
https://sourceware.org/bugzilla/show_bug.cgi?id=31615 H.J. Lu changed: What|Removed |Added CC||amodra at gmail dot com Target Milestone|--- |2.43 Version|unspecified |2.43 (HEAD) --- Comment #4 from H.J. Lu --- It is caused by commit e7e05a9dd0c93038fdd5ed1904ca660e52beabdc Author: Alan Modra Date: Sat Apr 6 15:49:44 2024 +1030 Don't have first_hash entries of strings that can be freed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31615] Hang when linking vorbis-tools
https://sourceware.org/bugzilla/show_bug.cgi?id=31615 --- Comment #5 from H.J. Lu --- #0 0x0043c171 in _bfd_generic_link_add_one_symbol ( info=0x61ef80 , abfd=0x7f7d80, name=0xeb69a8 "ldexp", flags=, section=0x61e008 <_bfd_std_section+840>, value=0, string=0xeb6990 "ldexp@@GLIBC_2.2.5", copy=false, collect=false, hashp=0x7fffc770) became an infinite loop. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31615] Hang when linking vorbis-tools
https://sourceware.org/bugzilla/show_bug.cgi?id=31615 --- Comment #6 from Alan Modra --- (In reply to H.J. Lu from comment #4) > It is caused by > > commit e7e05a9dd0c93038fdd5ed1904ca660e52beabdc Not possible. The real cause must be something else. At most, this patch exposed another bug that was hidden due to first_hash entries pointing to freed memory. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31615] Hang when linking vorbis-tools
https://sourceware.org/bugzilla/show_bug.cgi?id=31615
--- Comment #7 from Alan Modra ---
/* gcc -O3 -flto -c xxx.c; gcc -o xxx xxx.o -lm */
#include
#include
#include
int
main (int argc, char **argv)
{
double x = 1.0;
long y = 0;
if (--argc > 0)
x = strtod (*++argv, NULL);
if (--argc > 0)
y = strtol (*++argv, NULL, 0);
printf ("%f\n", ldexp (x, y));
return 0;
}
The above simpler testcase shows the problem. Prior to my commit e7e05a9dd0,
lookup of "ldexp@@GLIBC_2.2.5" (which I verified is put in first_hash) returns
NULL due to the string pointing into freed and reused memory.
0x558a66b3 in bfd_hash_lookup (table=0x55ffe5f0,
string=0x563f72c8 "ldexp@@GLIBC_2.2.5", create=create@entry=false,
copy=copy@entry=false) at /home/alan/src/binutils-gdb/bfd/hash.c:564
564 && strcmp (hashp->string, string) == 0)
(gdb) p *hashp
$5 = {next = 0x0, string = 0x561113f0 "", hash = 337613448}
This results in no reload of libm.so.6. If libm.so.6 is reloaded (post
e7e05a9dd0) ldexp is already an indirect symbol to a defweak versioned sym from
libc.so.6, and attempting to mash in the duplicated libm.so ldexp results in a
u.i.link loop back to itself. We don't normally try to override symbols like
that, but you could argue it is a long-standing bug in
_bfd_generic_link_add_one_symbol that case is not handled gracefully.
--
You are receiving this mail because:
You are on the CC list for the bug.
