[Bug ld/28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 --- Comment #12 from Evangelos Foutras --- (In reply to H.J. Lu from comment #11) > A patch is posted at > > https://sourceware.org/pipermail/binutils/2022-February/119740.html Works great, thanks! :) (Gave it a quick test by rebuilding the libheif and nextcloud-client packages on Arch.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 --- Comment #11 from H.J. Lu --- A patch is posted at https://sourceware.org/pipermail/binutils/2022-February/119740.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 H.J. Lu changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at sourceware dot org |hjl.tools at gmail dot com --- Comment #10 from H.J. Lu --- Created attachment 13974 --> https://sourceware.org/bugzilla/attachment.cgi?id=13974=edit A testcase [hjl@gnu-tgl-3 pr28879]$ make g++ -D_GLIBCXX_ASSERTIONS -flto -c -o pr28879c.o pr28879c.cc g++ -fPIC -c -o pr28879b.o pr28879b.cc g++ -fPIC -c -o pr28879a.o pr28879a.cc g++ -Wl,--no-demangle -shared -o libpr28879a.so pr28879a.o g++ -Wl,--no-demangle -shared -o libpr28879b.so pr28879b.o libpr28879a.so g++ -Wl,--no-demangle -o x pr28879c.o libpr28879b.so -Wl,-R,. /usr/local/bin/ld: ./libpr28879a.so: undefined reference to `_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev@GLIBCXX_3.4.21' collect2: error: ld returned 1 exit status make: *** [Makefile:25: x] Error 1 [hjl@gnu-tgl-3 pr28879]$ -- You are receiving this mail because: You are on the CC list for the bug.
Issue 40967 in oss-fuzz: binutils:fuzz_addr2line: Heap-buffer-overflow in bfd_getl16
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #4 on issue 40967 by sheriffbot: binutils:fuzz_addr2line: Heap-buffer-overflow in bfd_getl16 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40967#c4 This bug has exceeded our disclosure deadline. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 40993 in oss-fuzz: binutils:fuzz_objdump_safe: Null-dereference READ in mips_gprel_reloc
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #4 on issue 40993 by sheriffbot: binutils:fuzz_objdump_safe: Null-dereference READ in mips_gprel_reloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40993#c4 This bug has exceeded our disclosure deadline. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 40987 in oss-fuzz: binutils:fuzz_objdump_safe: Direct-leak in xrealloc
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #3 on issue 40987 by sheriffbot: binutils:fuzz_objdump_safe: Direct-leak in xrealloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40987#c3 This bug has exceeded our disclosure deadline. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 40970 in oss-fuzz: binutils:fuzz_nm: Crash in filter_symbols
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #4 on issue 40970 by sheriffbot: binutils:fuzz_nm: Crash in filter_symbols https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40970#c4 This bug has exceeded our disclosure deadline. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug ld/28875] ld should warn or error out about creating copy relocs & direct external references for protected symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=28875 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from H.J. Lu --- Fixed for 2.39 and 2.38 branch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28875] ld should warn or error out about creating copy relocs & direct external references for protected symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=28875 --- Comment #7 from cvs-commit at gcc dot gnu.org --- The binutils-2_38-branch branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=caa6172de4b5100c9b45fd03eae714167a6085c1 commit caa6172de4b5100c9b45fd03eae714167a6085c1 Author: H.J. Lu Date: Wed Feb 9 15:51:22 2022 -0800 x86: Disallow invalid relocation against protected symbol I am checking this into master and will backport it to 2.38 branch. H.J On x86, GCC 12 supports -mno-direct-extern-access to enable canonical reference to protected function and disable copy relocation. With -mno-direct-extern-access, the canonical protected function symbols must be accessed via canonical reference and the protected data symbols in shared libraries are non-copyable. Under glibc 2.35, non-canonical reference to the canonical protected function will get the run-time error: ./y: internal_f: ./libfoo.so: non-canonical reference to canonical protected function and copy relocations against the non-copyable protected symbols will get the run-time error: ./x: internal_i: ./libfoo.so: copy relocation against non-copyable protected symbol Update x86 linker to disallow non-canonical reference to the canonical protected function: ld: plt.o: non-canonical reference to canonical protected function `internal_f' in libfoo.so ld: failed to set dynamic section sizes: bad value and copy relocation against the non-copyable protected symbol: ld: main.o: copy relocation against non-copyable protected symbol `internal_i' in libfoo.so at link-time. bfd/ PR ld/28875 * elf-properties.c (_bfd_elf_parse_gnu_properties): Don't skip shared libraries for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS. * elf32-i386.c (elf_i386_scan_relocs): Disallow non-canonical reference to canonical protected function. * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. * elfxx-x86.c (elf_x86_allocate_dynrelocs): Don't allow copy relocation against non-copyable protected symbol. ld/ PR ld/28875 * testsuite/ld-i386/i386.exp: Check non-canonical reference to canonical protected function and check copy relocation against non-copyable protected symbol. * testsuite/ld-i386/pr21997-1.err: New file. * testsuite/ld-i386/pr28875.err: Likewise. * testsuite/ld-i386/pr28875a.c: Likewise. * testsuite/ld-i386/pr28875b.c: Likewise. * testsuite/ld-x86-64/pr21997-1a.err: Updated. * testsuite/ld-x86-64/pr21997-1b.err: Likewise. * testsuite/ld-x86-64/pr28875-data.err: New file. * testsuite/ld-x86-64/pr28875-func.err: Likewise. * testsuite/ld-x86-64/x86-64.exp: Check non-canonical reference to canonical protected function and check copy relocation against non-copyable protected symbol. (cherry picked from commit ebb191adac4ab45498dec0bfaac62f0a33537ba4) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28875] ld should warn or error out about creating copy relocs & direct external references for protected symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=28875 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ebb191adac4ab45498dec0bfaac62f0a33537ba4 commit ebb191adac4ab45498dec0bfaac62f0a33537ba4 Author: H.J. Lu Date: Wed Feb 9 15:51:22 2022 -0800 x86: Disallow invalid relocation against protected symbol I am checking this into master and will backport it to 2.38 branch. H.J On x86, GCC 12 supports -mno-direct-extern-access to enable canonical reference to protected function and disable copy relocation. With -mno-direct-extern-access, the canonical protected function symbols must be accessed via canonical reference and the protected data symbols in shared libraries are non-copyable. Under glibc 2.35, non-canonical reference to the canonical protected function will get the run-time error: ./y: internal_f: ./libfoo.so: non-canonical reference to canonical protected function and copy relocations against the non-copyable protected symbols will get the run-time error: ./x: internal_i: ./libfoo.so: copy relocation against non-copyable protected symbol Update x86 linker to disallow non-canonical reference to the canonical protected function: ld: plt.o: non-canonical reference to canonical protected function `internal_f' in libfoo.so ld: failed to set dynamic section sizes: bad value and copy relocation against the non-copyable protected symbol: ld: main.o: copy relocation against non-copyable protected symbol `internal_i' in libfoo.so at link-time. bfd/ PR ld/28875 * elf-properties.c (_bfd_elf_parse_gnu_properties): Don't skip shared libraries for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS. * elf32-i386.c (elf_i386_scan_relocs): Disallow non-canonical reference to canonical protected function. * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. * elfxx-x86.c (elf_x86_allocate_dynrelocs): Don't allow copy relocation against non-copyable protected symbol. ld/ PR ld/28875 * testsuite/ld-i386/i386.exp: Check non-canonical reference to canonical protected function and check copy relocation against non-copyable protected symbol. * testsuite/ld-i386/pr21997-1.err: New file. * testsuite/ld-i386/pr28875.err: Likewise. * testsuite/ld-i386/pr28875a.c: Likewise. * testsuite/ld-i386/pr28875b.c: Likewise. * testsuite/ld-x86-64/pr21997-1a.err: Updated. * testsuite/ld-x86-64/pr21997-1b.err: Likewise. * testsuite/ld-x86-64/pr28875-data.err: New file. * testsuite/ld-x86-64/pr28875-func.err: Likewise. * testsuite/ld-x86-64/x86-64.exp: Check non-canonical reference to canonical protected function and check copy relocation against non-copyable protected symbol. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 freswa changed: What|Removed |Added CC||freswa at archlinux dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28882] New: build failure in readelf.c with gcc-4.2 due to use of 0b literals
https://sourceware.org/bugzilla/show_bug.cgi?id=28882 Bug ID: 28882 Summary: build failure in readelf.c with gcc-4.2 due to use of 0b literals Product: binutils Version: 2.38 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: mikpelinux at gmail dot com Target Milestone: --- Attempting to build binutils-2.38 with gcc-4.2 or older fails with: /tmp/binutils-2.38/binutils/readelf.c:4239:37: error: invalid suffix "b11" on integer constant /tmp/binutils-2.38/binutils/readelf.c:4239:37: error: invalid suffix "b11" on integer constant /tmp/binutils-2.38/binutils/readelf.c:4241:43: error: invalid suffix "b11" on integer constant /tmp/binutils-2.38/binutils/readelf.c:4241:43: error: invalid suffix "b01" on integer constant /tmp/binutils-2.38/binutils/readelf.c:4244:43: error: invalid suffix "b00" on integer constant /tmp/binutils-2.38/binutils/readelf.c:4244:43: error: invalid suffix "b001100" on integer constant /tmp/binutils-2.38/binutils/readelf.c:4246:50: error: invalid suffix "b00" on integer constant /tmp/binutils-2.38/binutils/readelf.c:4246:50: error: invalid suffix "b001000" on integer constant /tmp/binutils-2.38/binutils/readelf.c:4248:50: error: invalid suffix "b00" on integer constant /tmp/binutils-2.38/binutils/readelf.c:4248:50: error: invalid suffix "b00" on integer constant Building just that file with gcc-11 -std=c17 -Wpedantic shows: /tmp/binutils-2.38/binutils/readelf.c: In function 'get_machine_flags': /tmp/binutils-2.38/binutils/readelf.c:4239:27: warning: binary constants are a C2X feature or GCC extension 4239 | if (EF_LOONGARCH_IS_LP64 (e_flags)) | ^~~~ ... So the issue comes from include/elf/loongarch.h's use of 0b literals which are a GNU C extension since gcc-4.3 but are not in any ANSI or ISO C standard. I can work around this issue, but the question is whether GNU binutils wants to require host compiler support for this non-standard feature or not? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 --- Comment #9 from Evangelos Foutras --- Created attachment 13973 --> https://sourceware.org/bugzilla/attachment.cgi?id=13973=edit Build log from the source build of libheif -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28875] ld should warn or error out about creating copy relocs & direct external references for protected symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=28875 --- Comment #5 from Thiago Macieira --- (In reply to H.J. Lu from comment #4) > Created attachment 13971 [details] > The v2 patch > > I got > > /usr/gcc-12.0.1-x32/bin/gcc -B./ -o x main.o libfoo.so -Wl,-R,. > ./ld: main.o: non-canonical reference to canonical protected function > `internal_f' in libfoo.so > ./ld: failed to set dynamic section sizes: bad value > collect2: error: ld returned 1 exit status Confirmed: $ gcc main.cpp libb.so /home/tjmaciei/dev/gcc/lib/gcc/x86_64-pc-linux-gnu/12.0.1/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccTtYFXS.o: non-canonical reference to canonical protected function `_Z10internal_fv' in libb.so collect2: error: ld returned 1 exit status Uploading my Qt patch to make use of this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 --- Comment #8 from Evangelos Foutras --- Created attachment 13972 --> https://sourceware.org/bugzilla/attachment.cgi?id=13972=edit Reproducer with source build Sorry this took a while, I tried to make it use the bundled x265 library which I know reproduces the issue. Hopefully it repros on your system too. :) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 --- Comment #7 from H.J. Lu --- (In reply to Evangelos Foutras from comment #6) > > However, I can provide a repro.sh that builds libheif from source and > reproduces the undefined references on GCC 11.2 + binutils 2.38; would that > help? Yes. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 --- Comment #6 from Evangelos Foutras --- (In reply to H.J. Lu from comment #5) > It may be a GCC 11.1 bug. Are you referring to the error about _ZTI11QSharedData@Qt_5 in my last comment, or the original issue? The system libQt5Gui was indeed built with GCC 11.1 but the error came from building nextcloud-client with GCC 11.2 and binutils 2.38. It also went away after applying your earlier diff. If you meant the original issue: I'm using GCC 11.2. I grabbed heif_info-heif_info.o from the failed libheif build so generating its proproccessed source counterpart isn't very straightforward for me. However, I can provide a repro.sh that builds libheif from source and reproduces the undefined references on GCC 11.2 + binutils 2.38; would that help? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from H.J. Lu --- It may be a GCC 11.1 bug. Please upload the preprocessed heif_info-heif_info.cc with the command-line options used to compile heif_info-heif_info.o. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 --- Comment #4 from Evangelos Foutras --- Thank you for looking into this. :) I applied your diff on top of binutils 2.38 and was able to successfully build libheif and nextcloud-client with it. Previously, these two Arch Linux packages (and probably a lot more) would fail to link to several system libraries (x265, de265, snappy). PS: Not sure if this is of any importance, but I also noticed the following linker error when building nextcloud-client with unpatched binutils 2.38 (likely has the same root cause and fix as the undefined references seen earlier, and this error is gone as well after applying your patch): /usr/bin/ld: /usr/lib/libQt5Gui.so.5.15.2: unexpected redefinition of indirect versioned symbol `_ZTI11QSharedData@Qt_5' -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 --- Comment #3 from H.J. Lu --- I am testing this: diff --git a/bfd/elflink.c b/bfd/elflink.c index 6fa18d92007..a231bdabd28 100644 --- a/bfd/elflink.c +++ b/bfd/elflink.c @@ -1295,7 +1295,9 @@ _bfd_elf_merge_symbol (bfd *abfd, hi->root.non_ir_ref_dynamic = true; } - if ((oldbfd->flags & BFD_PLUGIN) != 0 + if (!h->root.non_ir_ref_dynamic +&& !h->root.non_ir_ref_regular +&& (oldbfd->flags & BFD_PLUGIN) != 0 && hi->root.type == bfd_link_hash_indirect) { /* Change indirect symbol from IR to undefined. */ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28264] [2.37 Regression] ld.bfd crashes on linking efivar with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=28264 H.J. Lu changed: What|Removed |Added Depends on||28879 Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=28879 [Bug 28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 H.J. Lu changed: What|Removed |Added Status|WAITING |NEW Blocks||28264 --- Comment #2 from H.J. Lu --- This is caused by 7de7786bb7db5159fc8a7bfa3df72381ff16a38c is the first bad commit commit 7de7786bb7db5159fc8a7bfa3df72381ff16a38c Author: H.J. Lu Date: Thu Aug 26 07:43:23 2021 -0700 ld: Change indirect symbol from IR to undefined Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=28264 [Bug 28264] [2.37 Regression] ld.bfd crashes on linking efivar with LTO -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28848] [2.38 Regression] ld assertion fail ../../bfd/elf32-arm.c:14807
https://sourceware.org/bugzilla/show_bug.cgi?id=28848 Matthias Klose changed: What|Removed |Added CC||michael.hudson at canonical dot co ||m -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2022-02-11 --- Comment #1 from H.J. Lu --- I am using GCC 11.2 and got g++ -o x heif_info-heif_info.o libheif.so -Wl,-R,. lto1: fatal error: bytecode stream in file ‘heif_info-heif_info.o’ generated with LTO version 11.0 instead of the expected 11.2 compilation terminated. lto-wrapper: fatal error: g++ returned 1 exit status Please compile heif_info-heif_info.o with GCC 11.2. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28848] [2.38 Regression] ld assertion fail ../../bfd/elf32-arm.c:14807
https://sourceware.org/bugzilla/show_bug.cgi?id=28848 --- Comment #8 from Matthias Klose --- that patch is https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/arm/local-vfp-sysdeps.diff Michael just confirmed that fpc still fails to build without this patch (and builds with the updated patch as suggested by Richard). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 Allan McRae changed: What|Removed |Added CC||allan at archlinux dot org -- You are receiving this mail because: You are on the CC list for the bug.