[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 #9 from Evangelos Foutras --- Created attachment 13973 --> https://sourceware.org/bugzilla/attachment.cgi?id=13973&action=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/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&action=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 #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 --- 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] New: [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 Bug ID: 28879 Summary: [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors Product: binutils Version: 2.39 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: evangelos at foutrelis dot com Target Milestone: --- Created attachment 13969 --> https://sourceware.org/bugzilla/attachment.cgi?id=13969&action=edit Small example with pre-built objects The attached tarball contains a small example of an issue I'm seeing on Arch Linux after upgrading to binutils 2.38. It's a trimmed down version of the linking errors I get when trying to build libheif [1] with CXXFLAGS="-flto -Wp,-D_GLIBCXX_ASSERTIONS" LDFLAGS="-Wl,--as-needed". I was unable to repro with a few minimal examples I tried, so please excuse the binary test case. Bisect pointed to commit 7de7786bb7db [2] as the first revision that exhibits linking failures when building libheif with LTO. Adding "libx265.so.199" to end of the g++ line in repro.sh allows it to link, so there appears to be some issue with looking up some libstdc++ symbols used by libx265 when it's linked indirectly through libheif.so. (Please note that libheif and libx265 are used as an example here; they were just the first packages that showed this issue after upgrading the toolchain to gcc 11.2, glibc 2.35 and binutils 2.38.) FWIW, searching for the first symbol in the attached object files I see: --- heif_info-heif_info.o (readelf --lto-syms): _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERmm WEAKDEF DEFAULT libheif.so (readelf -Ws): FUNCLOCAL DEFAULT 13 _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERmm libx265.so.199 (readelf -Ws): GLOBAL DEFAULT UND _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERmm@GLIBCXX_3.4.21 --- My linker knowledge is limited, but perhaps you might be able to make sense of all this. :) [1] https://github.com/strukturag/libheif [2] https://github.com/bminor/binutils-gdb/commit/7de7786bb7db == $ cat repro.sh #!/bin/bash # objects below built w/ CXXFLAGS="-flto -Wp,-D_GLIBCXX_ASSERTIONS" LDFLAGS="-Wl,--as-needed" LD_LIBRARY_PATH=$PWD g++ heif_info-heif_info.o libheif.so $ ./repro.sh /usr/bin/ld: /../heif-link-failure/libx265.so.199: undefined reference to `std::__cxx11::basic_string, std::allocator >::_M_create(unsigned long&, unsigned long)@GLIBCXX_3.4.21' /usr/bin/ld: /../heif-link-failure/libx265.so.199: undefined reference to `std::__cxx11::basic_string, std::allocator >::_M_mutate(unsigned long, unsigned long, char const*, unsigned long)@GLIBCXX_3.4.21' /usr/bin/ld: /../heif-link-failure/libx265.so.199: undefined reference to `std::__cxx11::basic_string, std::allocator >::~basic_string()@GLIBCXX_3.4.21' /usr/bin/ld: /../heif-link-failure/libx265.so.199: undefined reference to `std::__cxx11::basic_string, std::allocator >::_M_replace(unsigned long, unsigned long, char const*, unsigned long)@GLIBCXX_3.4.21' == -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/23460] regression: ar can not create archive containing many (>1024) lto object files
https://sourceware.org/bugzilla/show_bug.cgi?id=23460 --- Comment #19 from Evangelos Foutras --- I believe it's safe to remove the call to dlclose() which, as far as I can tell, would restore the previous behavior of the plugin loader. I will do a Chromium build to verify that the patch from comment #17 works with unpatched LLVM. (I'm 99% sure it won't fail though.) (Bellow excerpts are for reference.) dlopen(3) / glibc says: If the same shared object is loaded again with dlopen(), the same object handle is returned. The dynamic linker maintains reference counts for object handles, so a dynamically loaded shared object is not deallocated until dlclose() has been called on it as many times as dlopen() has succeeded on it. dlopen(3p) / POSIX also touches on this: Only a single copy of an executable object file shall be brought into the address space, even if dlopen() is invoked multiple times in reference to the executable object file, and even if different pathnames are used to reference the executable object file. -- 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/23460] regression: ar can not create archive containing many (>1024) lto object files
https://sourceware.org/bugzilla/show_bug.cgi?id=23460 --- Comment #16 from Evangelos Foutras --- (In reply to zenith432 from comment #15) > = begin patch > diff --git a/bfd/plugin.c b/bfd/plugin.c > index d9b9e2f1..3b738c38 100644 > --- a/bfd/plugin.c > +++ b/bfd/plugin.c > @@ -274,7 +274,7 @@ have_claim_file: > goto err; > >if (!try_claim (abfd)) > -goto err; > +return 0; > >abfd->plugin_format = bfd_plugin_yes; > > = end patch The above didn't allow a ThinLTO Chromium build to finish; there were missing symbols during the final linking of the main binary. Chromium built successfully with the following change (and unpatched LLVM): == diff --git a/bfd/plugin.c b/bfd/plugin.c index d9b9e2f174..e12f37d36a 100644 --- a/bfd/plugin.c +++ b/bfd/plugin.c @@ -274,7 +274,7 @@ have_claim_file: goto err; if (!try_claim (abfd)) -goto err; +goto err_no_dlclose; abfd->plugin_format = bfd_plugin_yes; @@ -283,6 +283,7 @@ have_claim_file: err: if (plugin_handle) dlclose (plugin_handle); + err_no_dlclose: register_claim_file (NULL); return 0; } == The proposed approach seems to skip dlclose for most (all?) plugins. To my untrained eye, it looks preferable to just do away with dlclose() altogether instead of selectively skipping it. The workaround on the LLVM side that builds LLVMgold.so with -Wl,-z,nodelete has been tentatively merged. [1] Assuming it doesn't cause any regressions, the use of dlclose() shouldn't be an issue anymore. Finally, I will say that I don't understand the need to dlclose() plugins if they don't claim a specific file. Doesn't this create unnecessary overhead of opening and closing plugins for each member added to an archive (in the case of ar)? Since previous binutils versions worked fine, I would think that the problem was with file handles to object files being left open, and not plugins that remained loaded. [1] https://reviews.llvm.org/D50416 -- 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/23460] regression: ar can not create archive containing many (>1024) lto object files
https://sourceware.org/bugzilla/show_bug.cgi?id=23460 --- Comment #14 from Evangelos Foutras --- (In reply to Nick Clifton from comment #11) > I just do not like the idea of not tidying up after ourselves. Mind you it > is only linker plugins that call dlclose. Plugins for other tools (eg ar, > nm, etc) do not bother with the call. Plus the linker only calls dlclose > when it is closing *all* plugins as part of its exit sequence. So I am not > sure if there really is a problem (for the binutils) here. (To reproduce the following on Fedora Rawhide, rebuild binutils with the patch from comment #7 and pass "--plugin /usr/lib64/LLVMgold.so" to ar/nm. The examples below are without the --plugin option, because LLVMgold.so is symlinked from /usr/lib/bfd-plugins on Arch.) The main issue seems to be with ar and nm: $ touch a.c b.c $ gcc -c a.c b.c $ ar r ab.a a.o b.o ar: creating ab.a : CommandLine Error: Option 'asm-instrumentation' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options $ nm a.o b.o a.o: : CommandLine Error: Option 'asm-instrumentation' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options I believe the above error is caused by a sequence of "dlopen -> dlclose -> dlopen" on LLVMgold.so. (liblto_plugin.so doesn't seem to mind being unloaded and loaded again.) Is the repeated dlopen expected here? -- 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/23428] ld does not put program headers in a code-only load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=23428 --- Comment #19 from Evangelos Foutras --- (In reply to H.J. Lu from comment #18) > (In reply to Evangelos Foutras from comment #16) > > The test case from comment #14 is still reproducible for me with both > > binutils master (1dc9e2d6) and binutils-2_31-branch (6ee91b1e). No change at > > all in the resulting binary, compared to just the patch from comment #4. > > Please try master branch again. Your latest commit fixes the issue I was experiencing. Thanks! -- 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/23428] ld does not put program headers in a code-only load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=23428 --- Comment #16 from Evangelos Foutras --- The test case from comment #14 is still reproducible for me with both binutils master (1dc9e2d6) and binutils-2_31-branch (6ee91b1e). No change at all in the resulting binary, compared to just the patch from comment #4. -- 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/23428] ld does not put program headers in a code-only load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=23428
--- Comment #13 from Evangelos Foutras ---
Created attachment 11177
--> https://sourceware.org/bugzilla/attachment.cgi?id=11177&action=edit
libgcc-8-dev rebuilt with --enable-cet=auto (for Debian testing)
(In reply to H.J. Lu from comment #12)
> Please provide a small and host-independent testcase.
I have not been able to further reduce my findings from comment #11. I was
hoping someone else might be able to figure out what's going on.
--
@Szabolcs: If you rebuild gcc-8 on Debian testing with "--enable-cet=auto"
added to CONFARGS in debian/rules2, then you should be able to reproduce the
musl-gcc crash (after removing the --build-id workaround from musl-gcc.specs!).
(It appears that "--enable-cet=auto" is the important difference between Arch's
and Debian's GCC packages.)
Since gcc-8 takes several hours to build, I have attached libgcc-8-dev which
contains the relevant crt{begin,end}.o files. With this I'm able to reproduce
the crash in a new Debian testing VM as follows:
# apt install ./libgcc-8-dev_8.2.0-3_amd64.deb
# sed -i 's/--build-id //' /usr/lib/x86_64-linux-musl/musl-gcc.specs
$ musl-gcc -static -xc - <<<"int main() { return 0; }"
$ gdb -q --batch -ex run -ex bt ./a.out
Program received signal SIGSEGV, Segmentation fault.
0x0040158d in static_init_tls ()
#0 0x0040158d in static_init_tls ()
#1 0x in ?? ()
--
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/23428] ld does not put program headers in a code-only load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=23428
--- Comment #11 from Evangelos Foutras ---
Created attachment 11174
--> https://sourceware.org/bugzilla/attachment.cgi?id=11174&action=edit
Test case with Arch's and Debian's GCC-provided crt{begin,end}.o
(In reply to nsz from comment #10)
> i'd try to verify that the right ld is used (e.g. strace -f -e execve
> musl-gcc ...)
> then i'd try to reproduce the issue outside of musl-gcc (e.g. manually
> invoking
> ld with the options seen in the strace and look for the NOTE program header)
Thanks for the suggestion. I was able to reduce my test case to something that
is reproducible on both Arch and Debian.
The attached test case indicates that it's some difference between Debian's and
Arch's crt{begin,end}.o (as provided by GCC) that's causing ld to add the NOTE
program header and .note.gnu.property section to the produced binary.
Comparing them using 'objdump -h', I notice that Arch's crt{begin,end}.o have a
.note.gnu.property section and Debian's don't. If I use 'objcopy -R
.note.gnu.property' on the Arch ones, then those produce a working executable
too!
Does the above indicate that the fix to binutils needs to be tweaked?
=
[pr23428-test]$ make
cc-c -o test.o test.c
ld -static -o test-arch arch-crts/* arch-musl/* test.o
ld -static -o test-debian debian-crts/* arch-musl/* test.o
pr23428-test$ grep gnu.property test-*
Binary file test-debian matches
[pr23428-test]$ ./test-debian
[pr23428-test]$ ./test-arch
Segmentation fault (core dumped)
[pr23428-test]$ objcopy -R .note.gnu.property arch-crts/crtbegin.o
[pr23428-test]$ objcopy -R .note.gnu.property arch-crts/crtend.o
[pr23428-test]$ make -Bs test-arch
[pr23428-test]$ gdb -q -ex run ./test-arch
Reading symbols from ./test-arch...(no debugging symbols found)...done.
Starting program: /home/../desktop/pr23428-test/test-arch
[Inferior 1 (process 17284) exited normally]
=
--
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/23428] ld does not put program headers in a code-only load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=23428 --- Comment #9 from Evangelos Foutras --- (In reply to nsz from comment #8) > it works for me, please post the readelf -aW ./a.out somewhere (e.g. musl > list) https://paste.xinu.at/igNNdz/ -- but as mentioned below, it's the same as unpatched binutils. > (you should see a .note.gnu.property section and an appropriate NOTE program > header.) This is really weird and I'm not sure what's going on: The output from 'readelf -aW' is exactly the same with both patched and unpatched binutils 2.31 when using the musl-gcc example. However, it does change when using your original example of linking t.o; with patched binutils I see a .note.gnu.property section and a NOTE program header. I also checked on Debian testing and the musl-gcc command produces a working binary there (even after removing the --build-id workaround from musl-gcc.specs). For some weird reason though, it still segfaults on Arch with patched binutils. :| -- 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/23428] ld does not put program headers in a code-only load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=23428
Evangelos Foutras changed:
What|Removed |Added
CC||evangelos at foutrelis dot com
--- Comment #7 from Evangelos Foutras ---
@Szabolcs, Rich: Is the musl-gcc issue fixed for you guys? [1]
I'm still getting a segfault with current binutils master (6404ab9937):
$ ld -v
GNU ld (GNU Binutils) 2.31.51.20180809
$ musl-gcc -ggdb3 -O0 -static -xc - <<<"int main() { return 0; }"
$ gdb -q --batch -ex run -ex bt ./a.out
Program received signal SIGSEGV, Segmentation fault.
0x0040140f in static_init_tls ()
#0 0x0040140f in static_init_tls ()
#1 0x in ?? ()
[1] http://www.openwall.com/lists/musl/2018/07/18/5
--
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/23486] GNU_PROPERTY_X86_ISA_1_USED isn't merged properly
https://sourceware.org/bugzilla/show_bug.cgi?id=23486 Evangelos Foutras changed: What|Removed |Added CC||evangelos at foutrelis dot com -- 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/23460] regression: ar can not create archive containing many (>1024) lto object files
https://sourceware.org/bugzilla/show_bug.cgi?id=23460 Evangelos Foutras changed: What|Removed |Added CC||evangelos at foutrelis dot com --- Comment #10 from Evangelos Foutras --- Is it possible to avoid calling dlclose() on the plugin handle? I'm asking because the LLVM gold plugin (LLVMgold.so) will throw the following error when loaded more than once: > CommandLine Error: Option 'asm-instrumentation' registered more than once! libLLVM.so used to have the same problem, but it's worked around using NODELETE (https://reviews.llvm.org/D40459). However, LLVMgold.so is considered a module and not a shared library. As such, it's not linked with "-z nodelete". Perhaps an fix on LLVM's side would be to specify nodelete for LLVMgold.so; I have uploaded a tentative patch doing that here: https://reviews.llvm.org/D50416 In any case, I thought I'd also ask here if it might make sense to remove dlclose() from bfd's plugin loader. -- 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/16457] Weak reference leads to bogus entry in .gnu.version_r section
https://sourceware.org/bugzilla/show_bug.cgi?id=16457 Evangelos Foutras changed: What|Removed |Added CC||evangelos at foutrelis dot com -- 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/16452] ELF executable with weak reference linked with ld causes assertion in ld.so
https://sourceware.org/bugzilla/show_bug.cgi?id=16452 Evangelos Foutras changed: What|Removed |Added CC||evangelos at foutrelis dot com -- 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
