[Bug gas/25295] Gas should have way to define symbol version without exporting its target
https://sourceware.org/bugzilla/show_bug.cgi?id=25295 Martin Liška changed: What|Removed |Added CC|marxin.liska at gmail dot com | -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25295] Gas should have way to define symbol version without exporting its target
https://sourceware.org/bugzilla/show_bug.cgi?id=25295 Martin Liška changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25295] Gas should have way to define symbol version without exporting its target
https://sourceware.org/bugzilla/show_bug.cgi?id=25295 Martin Liška changed: What|Removed |Added CC||marxin.liska at gmail dot com --- Comment #2 from Martin Liška --- (In reply to Jan Hubicka from comment #0) > GCC now support symver attribute. However in order to make > > .symver sym, name@nodename > > to work, sym needs to be declared as .globl (already .hidden break things). > In order to produce symbol version one thus need to export also SYM and if > that is not part of DSO API the mapfile needs to hide it. This is in > conflict with -fvisiblity=hidden and other GCC features. Are you talking about GAS rejecting such assembly? Or is it a run-time error where a DSO has broken symbol versions? Anyway, please provide a self-contained test-case. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25737] New: Document which readelf and binutils options support debuginfod
https://sourceware.org/bugzilla/show_bug.cgi?id=25737 Bug ID: 25737 Summary: Document which readelf and binutils options support debuginfod Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com Target Milestone: --- I have a few comments about debuginfod support: 1) it's not easy to identify which options do support debuginfod client support: ./binutils/objdump -W `which openssl` - this support debuginfod ./binutils/objdump --dwarf=info `which openssl` - this not I would like to see that documented. 2) I would welcome objdump/readelf -V would print if debuginfod is supported or not -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25640] nm shows symbol as 'U' while showed as 'T'
https://sourceware.org/bugzilla/show_bug.cgi?id=25640 --- Comment #9 from Martin Liška --- (In reply to H.J. Lu from comment #8) > (In reply to Martin Liška from comment #7) > > (In reply to H.J. Lu from comment #4) > > > Created attachment 12355 [details] > > > Pass -flto-partition=none to GCC > > > > The patch does not work, very likely due to: > > > > lto-wrapper.c:608: > > > >604 /* Drop arguments that we want to take from the link line. > > */ > >605 case OPT_flto_: > >606 case OPT_flto: > >607 case OPT_flto_partition_: > >608continue; > > But it works on your testcase. Are you sure? I tried that by adding the patch to package and also locally and it didn't work. Can you please paste output of: strace -f -s512 nm -B x.o 2>&1 | grep execv -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25640] nm shows symbol as 'U' while showed as 'T'
https://sourceware.org/bugzilla/show_bug.cgi?id=25640 --- Comment #7 from Martin Liška --- (In reply to H.J. Lu from comment #4) > Created attachment 12355 [details] > Pass -flto-partition=none to GCC The patch does not work, very likely due to: lto-wrapper.c:608: 604 /* Drop arguments that we want to take from the link line. */ 605 case OPT_flto_: 606 case OPT_flto: 607 case OPT_flto_partition_: 608continue; -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25640] nm shows symbol as 'U' while showed as 'T'
https://sourceware.org/bugzilla/show_bug.cgi?id=25640 --- Comment #5 from Martin Liška --- (In reply to H.J. Lu from comment #4) > Created attachment 12355 [details] > Pass -flto-partition=none to GCC This seems right to me. Anyway, can't we built on something like: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/lto-plugin-symbol-type There should be extra space at the end of struct ld_plugin_symbol which can make it backward compatible.. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25640] nm shows symbol as 'U' while showed as 'T'
https://sourceware.org/bugzilla/show_bug.cgi?id=25640 --- Comment #2 from Martin Liška --- Heh. Then we should use -flto-partition=none or one. Anyway, to be honest, I'm still not fully convinced about the selected approach (of using LTO for nm). There's still a possibility to extend lto plugin to provide information about a symbol whether it's a function of a global variable. That would need plugin extension and GCC change in streaming of LTO call graph section. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25640] nm shows symbol as 'U' while showed as 'T'
https://sourceware.org/bugzilla/show_bug.cgi?id=25640 Martin Liška changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25640] New: nm shows symbol as 'U' while showed as 'T'
https://sourceware.org/bugzilla/show_bug.cgi?id=25640 Bug ID: 25640 Summary: nm shows symbol as 'U' while showed as 'T' Product: binutils Version: 2.34 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com Target Milestone: --- Created attachment 12352 --> https://sourceware.org/bugzilla/attachment.cgi?id=12352=edit test-case Using latest release I see: $ gcc connection.i -O2 -c -flto -c -o x.o $ nm -B x.o | grep 'U tp_connection_get_type\>' U tp_connection_get_type while previous release 2.33 showed: $ /home/marxin/Programming/binutils/objdir/binutils/nm-new --plugin /usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0 x.o $ /home/marxin/Programming/binutils/objdir/binutils/nm-new --plugin /usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0 x.o | grep tp_connection_get_type T tp_connection_get_type -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25584] ar and ranlib should not call lto-wrapper for LTO bytecode
https://sourceware.org/bugzilla/show_bug.cgi?id=25584 --- Comment #4 from Martin Liška --- Yes, I used the updated binutils to build a LTO project. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25584] ar and ranlib should not call lto-wrapper for LTO bytecode
https://sourceware.org/bugzilla/show_bug.cgi?id=25584 --- Comment #2 from Martin Liška --- I can confirm the patch works. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25584] ar and ranlib should not call lto-wrapper for LTO bytecode
https://sourceware.org/bugzilla/show_bug.cgi?id=25584 Martin Liška changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=25355 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #65 from Martin Liška --- > > Please open a new bug. Sure: https://sourceware.org/bugzilla/show_bug.cgi?id=25584 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25584] New: ar and ranlib should not call lto-wrapper for LTO bytecode
https://sourceware.org/bugzilla/show_bug.cgi?id=25584 Bug ID: 25584 Summary: ar and ranlib should not call lto-wrapper for LTO bytecode Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com Target Milestone: --- It's a follow up of PR25355: https://sourceware.org/bugzilla/show_bug.cgi?id=25355#c63 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=25584 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #63 from Martin Liška --- I have one more question about the lto-wrapper usage: is there any reason why 'ar' and 'ranlib' also use it? It makes building of some packages significantly slower. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #60 from Martin Liška --- (In reply to H.J. Lu from comment #59) > Fixed on master branch. Good. Please pull the revision to the 2.34 branch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #57 from Martin Liška --- > Try the latest one. I can confirm it works. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #54 from Martin Liška --- However, I see one another segfault: $ cat 1.i int a; $ cat 2.i [empty file] $ gcc -flto=auto -O2 -fPIC 1.i -c $ gcc -flto=auto -O2 -fPIC 2.i -c $ ar cru x.a 1.o 2.o $ ranlib x.a Segmentation fault (core dumped) $ valgrind ranlib x.a ==423== Memcheck, a memory error detector ==423== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==423== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==423== Command: ranlib x.a ==423== ==423== Invalid read of size 1 ==423==at 0x498CDF1: bfd_close (opncls.c:753) ==423==by 0x4B5D76D: bfd_plugin_close_and_cleanup (plugin.c:1074) ==423==by 0x498CD2A: bfd_close_all_done (opncls.c:789) ==423==by 0x497C31F: archive_close_worker (archive.c:2788) ==423==by 0x4B6F38E: htab_traverse_noresize (hashtab.c:775) ==423==by 0x497F9A4: _bfd_archive_close_and_cleanup (archive.c:2835) ==423==by 0x498CD2A: bfd_close_all_done (opncls.c:789) ==423==by 0x10CA11: write_archive (ar.c:1247) ==423==by 0x10DBA1: ranlib_only.part.0 (ar.c:1498) ==423==by 0x10BCF1: ranlib_only (ar.c:1492) ==423==by 0x10BCF1: ranlib_main (ar.c:695) ==423==by 0x10BCF1: main (ar.c:759) ==423== Address 0x4f57644 is 68 bytes inside a block of size 280 free'd ==423==at 0x48389AB: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==423==by 0x498CD4E: bfd_close_all_done (opncls.c:797) ==423==by 0x498CD4E: bfd_close_all_done (opncls.c:785) ==423==by 0x4B5D76D: bfd_plugin_close_and_cleanup (plugin.c:1074) ==423==by 0x498CD2A: bfd_close_all_done (opncls.c:789) ==423==by 0x497C31F: archive_close_worker (archive.c:2788) ==423==by 0x4B6F38E: htab_traverse_noresize (hashtab.c:775) ==423==by 0x497F9A4: _bfd_archive_close_and_cleanup (archive.c:2835) ==423==by 0x498CD2A: bfd_close_all_done (opncls.c:789) ==423==by 0x10CA11: write_archive (ar.c:1247) ==423==by 0x10DBA1: ranlib_only.part.0 (ar.c:1498) ==423==by 0x10BCF1: ranlib_only (ar.c:1492) ==423==by 0x10BCF1: ranlib_main (ar.c:695) ==423==by 0x10BCF1: main (ar.c:759) ==423== Block was alloc'd at ==423==at 0x483777F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==423==by 0x4986A41: bfd_malloc (libbfd.c:275) ==423==by 0x4986BD9: bfd_zmalloc (libbfd.c:360) ==423==by 0x498C72B: _bfd_new_bfd (opncls.c:62) ==423==by 0x498C917: bfd_fopen (opncls.c:200) ==423==by 0x4B5D7B4: add_input_file (plugin.c:389) ==423==by 0x52E01D1: ??? ==423==by 0x4B5E3C3: try_claim (plugin.c:564) ==423==by 0x4B5E3C3: try_load_plugin (plugin.c:710) ==423==by 0x4B5E8EB: load_plugin (plugin.c:848) ==423==by 0x4B5E8EB: bfd_plugin_object_p (plugin.c:861) ==423==by 0x49857F5: bfd_check_format_matches (format.c:261) ==423==by 0x497EA17: _bfd_write_archive_contents (archive.c:2127) ==423==by 0x498CE09: bfd_close (opncls.c:755) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #53 from Martin Liška --- (In reply to H.J. Lu from comment #52) > Created attachment 12297 [details] > A new patch The patch works for me! Thank you. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #49 from Martin Liška --- If I revert backport of 99845b3b77ed1248b6fb94707f88868bde358ccc, then it's fine. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #48 from Martin Liška --- Ok, I've just packaged the 2.34 release branch with the backport of this issue. However, I see the following Invalid free: $ touch a.c && gcc -c -flto a.c -o a.o $ touch a.c && gcc -c -flto a.c -o b.o $ ar r libconsole.a a.o b.o ar: creating libconsole.a bfd plugin: could not unlink output file free(): invalid pointer Aborted (core dumped) $ valgrind ar r libconsole.a a.o b.o ==17300== Memcheck, a memory error detector ==17300== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==17300== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==17300== Command: ar r libconsole.a a.o b.o ==17300== ==17300== Invalid free() / delete / delete[] / realloc() ==17300==at 0x4839D7B: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==17300==by 0x4B71929: xrealloc (xmalloc.c:179) ==17300==by 0x485B1B2: ??? (in /usr/lib64/gcc/x86_64-suse-linux/9/liblto_plugin.so.0.0.0) ==17300==by 0x4B5E338: try_claim (plugin.c:565) ==17300==by 0x4B5E338: try_load_plugin (plugin.c:723) ==17300==by 0x4B5E91B: load_plugin (plugin.c:855) ==17300==by 0x4B5E91B: bfd_plugin_object_p (plugin.c:868) ==17300==by 0x49857F5: bfd_check_format_matches (format.c:261) ==17300==by 0x497E5FC: _bfd_compute_and_write_armap (archive.c:2283) ==17300==by 0x497EF0B: _bfd_write_archive_contents (archive.c:2147) ==17300==by 0x498CE09: bfd_close (opncls.c:755) ==17300==by 0x10E45F: write_archive (ar.c:1240) ==17300==by 0x10F0CB: replace_members (ar.c:1482) ==17300==by 0x10BF4C: main (ar.c:887) ==17300== Address 0x4f568b0 is 0 bytes inside a block of size 8 free'd ==17300==at 0x48389AB: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==17300==by 0x485ABC3: ??? (in /usr/lib64/gcc/x86_64-suse-linux/9/liblto_plugin.so.0.0.0) ==17300==by 0x4B5E362: try_claim (plugin.c:574) ==17300==by 0x4B5E362: try_load_plugin (plugin.c:723) ==17300==by 0x4B5E91B: load_plugin (plugin.c:855) ==17300==by 0x4B5E91B: bfd_plugin_object_p (plugin.c:868) ==17300==by 0x49857F5: bfd_check_format_matches (format.c:261) ==17300==by 0x497EA17: _bfd_write_archive_contents (archive.c:2127) ==17300==by 0x498CE09: bfd_close (opncls.c:755) ==17300==by 0x10E45F: write_archive (ar.c:1240) ==17300==by 0x10F0CB: replace_members (ar.c:1482) ==17300==by 0x10BF4C: main (ar.c:887) ==17300== Block was alloc'd at ==17300==at 0x483777F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==17300==by 0x4B7193F: xrealloc (xmalloc.c:177) ==17300==by 0x485B1B2: ??? (in /usr/lib64/gcc/x86_64-suse-linux/9/liblto_plugin.so.0.0.0) ==17300==by 0x4B5E338: try_claim (plugin.c:565) ==17300==by 0x4B5E338: try_load_plugin (plugin.c:723) ==17300==by 0x4B5E91B: load_plugin (plugin.c:855) ==17300==by 0x4B5E91B: bfd_plugin_object_p (plugin.c:868) ==17300==by 0x49857F5: bfd_check_format_matches (format.c:261) ==17300==by 0x497EA17: _bfd_write_archive_contents (archive.c:2127) ==17300==by 0x498CE09: bfd_close (opncls.c:755) ==17300==by 0x10E45F: write_archive (ar.c:1240) ==17300==by 0x10F0CB: replace_members (ar.c:1482) ==17300==by 0x10BF4C: main (ar.c:887) ==17300== ar: out of memory allocating 16 bytes after a total of 0 bytes -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #41 from Martin Liška --- Closing again. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #40 from Martin Liška --- I will have to start using AR=gcc-ar, ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #39 from Martin Liška --- > > What is wrong to use the matching lto-wrapper for the plugin being used? It's probably fine. I'm just wondering how to use a locally install GCC to cooperate fine with binutils. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
--- Comment #37 from Martin Liška ---
>
> Which liblto_plugin.so did nm load? Which liblto_plugin.so should nm load?
It loads the following plugin:
stat("/usr/bin/../lib64/bfd-plugins", 0x7fffd980) = -1 ENOENT (No such file
or directory)
stat("/usr/bin/../bin/../lib/bfd-plugins", {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
openat(AT_FDCWD, "/usr/bin/../bin/../lib/bfd-plugins",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
stat("/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0",
{st_mode=S_IFREG|0755, st_size=84904, ...}) = 0
The plugins are very stable and the plugin works fine with current GCC master.
Problem is that we need to find a corresponding lto-wrapper. It's more
challenging..
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #35 from Martin Liška --- Reopening as it's quite fragile now.. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
--- Comment #34 from Martin Liška ---
I have one more question. It's a quite common case for me that that I do
testing of the built GCC :
$ export PATH=/home/marxin/bin/gcc/bin/:$PATH && export
LD_LIBRARY_PATH=/home/marxin/bin/gcc/lib64/:$LD_LIBRARY_PATH
...
but the search path of gcc/lto-wrapper ends up for a location where I have a
system compiler:
$ strace -f -s512 nm quotes.o 2>&1 | grep execv
execve("/usr/bin/nm", ["nm", "quotes.o"], 0x7fffdcf8 /* 88 vars */) = 0
[pid 7064] execve("/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper",
["/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper", "@/tmp/ccTEcaUg"],
0x55567980 /* 90 vars */
which ends badly :/
Any solution for this scenario?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #31 from Martin Liška --- (In reply to H.J. Lu from comment #30) > Created attachment 12287 [details] > Try this I can confirm that patch works. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
--- Comment #27 from Martin Liška ---
>
> Works for me on master branch. Please try master branch to see if
> it works for you.
It looks one needs a system setup to have multiple plug-in which cause that:
$ ls /usr/bin/../bin/../lib/bfd-plugins
liblto_plugin.so.0.0.0 LLVMgold.so
Now I put breakpoint here: try_load_plugin
and I see:
Breakpoint 2, try_load_plugin (pname=pname@entry=0x555653f0
"/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0",
abfd=abfd@entry=0x55564a70, has_plugin_p=has_plugin_p@entry=0x7fffd97c)
at ../../bfd/plugin.c:593
593 {
(gdb) fin
Run till exit from #0 try_load_plugin (pname=pname@entry=0x555653f0
"/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0",
abfd=abfd@entry=0x55564a70, has_plugin_p=has_plugin_p@entry=0x7fffd97c)
at ../../bfd/plugin.c:593
load_plugin (abfd=0x55564a70) at ../../bfd/plugin.c:844
844 if (has_plugin <= 0)
Value returned is $15 = 0
(gdb) list
839 if (stat (full_name, ) == 0 && S_ISREG
(st.st_mode))
840 {
841 int valid_plugin;
842
843 found = try_load_plugin (full_name, abfd,
_plugin);
844 if (has_plugin <= 0)
845 has_plugin = valid_plugin;
846 }
847 free (full_name);
848 if (found)
(gdb) n
845 has_plugin = valid_plugin;
(gdb)
847 free (full_name);
(gdb) p full_name
$16 = 0x555653f0
"/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0"
(gdb) p current_plugin->plugin_name
$17 = 0x555653f0
"/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0"
So the free for full_name is called, but the pointer is stored in
current_plugin->plugin_name. And later compared with..
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #28 from Martin Liška --- Created attachment 12286 --> https://sourceware.org/bugzilla/attachment.cgi?id=12286=edit libiberty archive -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #24 from Martin Liška --- Ok, I've got one another problem with the 2 commits (de66c68d899600286b0d054508a2ed7beee64870 and 39f2b43be6ccc3acb29ab84dee48180b6a8fcba5) applied on top of the bintuils 2.34 release. I built a openSUSE package and now I see: $ nm ./libiberty.a regex.o: U abort 01c0 t byte_alt_match_null_string_p 00d0 t byte_common_op_match_null_string_p t byte_compile_range 0240 t byte_group_match_null_string_p 03a0 t byte_re_compile_fastmap t byte_re_compile_fastmap.cold 2c10 t byte_regex_compile 0060 b byte_reg_unset_dummy 0760 t byte_re_match_2_internal 0005 t byte_re_match_2_internal.cold 28d0 t byte_re_search_2 U __ctype_b_loc U __ctype_tolower_loc b done.3131 U free U malloc U memcmp U memcpy U realloc 0020 b re_comp_buf 0840 r re_error_msgid 0080 b re_syntax_table U strcmp U strlen 5cd0 T xre_comp 5be0 T xre_compile_fastmap 5c90 T xre_compile_pattern 5d80 T xre_exec 5dc0 T xregcomp 6100 T xregerror 000a t xregerror.cold 5f50 T xregexec 6180 T xregfree 5c60 T xre_match 5c80 T xre_match_2 D xre_max_failures 5c30 T xre_search 5c50 T xre_search_2 5bf0 T xre_set_registers 5bd0 T xre_set_syntax 0008 C xre_syntax_options cplus-dem.o: 0090 T ada_demangle 0600 T cplus_demangle 0040 T cplus_demangle_name_to_style T cplus_demangle_set_style U cplus_demangle_v3 D current_demangling_style U dlang_demangle U free U java_demangle_v3 01a0 R libiberty_demanglers U memcpy 0060 r operators.3980 U rust_demangle U _sch_istable r special.4008 U sprintf U strcmp U strcpy U strlen U strncmp U xmalloc U xstrdup free(): double free detected in tcache 2 Aborted (core dumped) $ valgrind nm ./libiberty.a ==26662== Memcheck, a memory error detector ==26662== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==26662== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==26662== Command: nm ./libiberty.a ==26662== ==26662== Invalid read of size 1 ==26662==at 0x4DF3DC0: __strcmp_avx2 (strcmp-avx2.S:92) ==26662==by 0x4B1FFF9: try_load_plugin (plugin.c:608) ==26662==by 0x4B20996: load_plugin (plugin.c:843) ==26662==by 0x4B20996: bfd_plugin_object_p (plugin.c:869) ==26662==by 0x49477F5: bfd_check_format_matches (format.c:261) ==26662==by 0x10D2A1: display_archive (nm.c:1314) ==26662==by 0x10D2A1: display_file (nm.c:1373) ==26662==by 0x10B9BF: main (nm.c:1860) ==26662== Address 0x4ea7fc0 is 0 bytes inside a block of size 58 free'd ==26662==at 0x48389AB: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==26662==by 0x4B209B6: load_plugin (plugin.c:847) ==26662==by 0x4B209B6: bfd_plugin_object_p (plugin.c:869) ==26662==by 0x49477F5: bfd_check_format_matches (format.c:261) ==26662==by 0x10D2A1: display_archive (nm.c:1314) ==26662==by 0x10D2A1: display_file (nm.c:1373) ==26662==by 0x10B9BF: main (nm.c:1860) ==26662== Block was alloc'd at ==26662==at 0x483777F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==26662==by 0x4B338C4: xmalloc (xmalloc.c:147) ==26662==by 0x4B2DE79: concat (concat.c:147) ==26662==by 0x4B2095F: load_plugin (plugin.c:838) ==26662==by 0x4B2095F: bfd_plugin_object_p (plugin.c:869) ==26662==by 0x49477F5: bfd_check_format_matches (format.c:261) ==26662==by 0x10D2A1: display_archive (nm.c:1314) ==26662==by 0x10D2A1: display_file (nm.c:1373) ==26662==by 0x10B9BF: main (nm.c:1860) ==26662== ==26662== Invalid read of size 1 ==26662==at 0x483BBA8: strcmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==26662==by 0x4B1FFF9: try_load_plugin (plugin.c:608) ==26662==by 0x4B20996: load_plugin (plugin.c:843) ==26662==by 0x4B20996: bfd_plugin_object_p (plugin.c:869) ==26662==by 0x49477F5: bfd_check_format_matches (format.c:261) ==26662==by 0x10D2A1: display_archive (nm.c:1314) ==26662==by 0x10D2A1: display_file (nm.c:1373) ==26662==by 0x10B9BF: main (nm.c:1860) ==26662== Address 0x4ea7fc1 is 1 bytes inside a block of size 58 free'd
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #23 from Martin Liška --- > > It looks like you were using one of my old patches. Line 860 in plugin.c > doesn't do anything on master branch. You are right, sorry for the noise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #20 from Martin Liška --- Created attachment 12283 --> https://sourceware.org/bugzilla/attachment.cgi?id=12283=edit valgrind log file -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #19 from Martin Liška --- Thank you H.J. but I see the following memory corruption with the patch applied: $ valgrind ~/bin/binutils/bin/nm --plugin /usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0 x.o ... ==28080== Invalid read of size 8 ==28080==at 0x48A55D: bfd_plugin_canonicalize_symtab (plugin.c:860) ==28080==by 0x4123C4: _bfd_generic_read_minisymbols (syms.c:826) ==28080==by 0x4039A9: display_rel_file (nm.c:1112) ==28080==by 0x4043DA: display_file (nm.c:1379) ==28080==by 0x402B64: main (nm.c:1860) ==28080== Address 0x4a81498 is 1,704 bytes inside a block of size 4,064 free'd ==28080==at 0x48389AB: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==28080==by 0x4ACCF2: objalloc_free (objalloc.c:187) ==28080==by 0x40FAB2: _bfd_delete_bfd (opncls.c:126) ==28080==by 0x41067B: bfd_close_all_done (opncls.c:797) ==28080==by 0x41067B: bfd_close_all_done (opncls.c:785) ==28080==by 0x48A236: add_input_file (plugin.c:315) ==28080==by 0x485B1D1: ??? (in /usr/lib64/gcc/x86_64-suse-linux/9/liblto_plugin.so.0.0.0) ==28080==by 0x48A8FB: try_claim (plugin.c:417) ==28080==by 0x48A8FB: try_load_plugin (plugin.c:562) ==28080==by 0x48AF4C: load_plugin (plugin.c:637) ==28080==by 0x48AF4C: bfd_plugin_object_p (plugin.c:704) ==28080==by 0x40DE35: bfd_check_format_matches (format.c:261) ==28080==by 0x4043B1: display_file (nm.c:1375) ==28080==by 0x402B64: main (nm.c:1860) ==28080== Block was alloc'd at ==28080==at 0x483777F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==28080==by 0x4ACC2B: _objalloc_alloc (objalloc.c:159) ==28080==by 0x410990: bfd_alloc (opncls.c:978) ==28080==by 0x410E29: bfd_zalloc (opncls.c:1027) ==28080==by 0x42C679: _bfd_elf_new_section_hook (elf.c:2902) ==28080==by 0x41148E: bfd_section_init (section.c:825) ==28080==by 0x42B46B: _bfd_elf_make_section_from_shdr (elf.c:1035) ==28080==by 0x42B46B: _bfd_elf_make_section_from_shdr (elf.c:1023) ==28080==by 0x42A9A0: bfd_section_from_shdr (elf.c:2586) ==28080==by 0x4261DB: bfd_elf64_object_p (elfcode.h:815) ==28080==by 0x40DC89: bfd_check_format_matches (format.c:328) ==28080==by 0x48A1E3: add_input_file (plugin.c:300) ==28080==by 0x485B1D1: ??? (in /usr/lib64/gcc/x86_64-suse-linux/9/liblto_plugin.so.0.0.0) ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
--- Comment #15 from Martin Liška ---
Thank you H.J. I can confirm the patch works:
Before:
$ cat x.c
int nm_test_var;
int nm_test_var2 = 1234;
extern int foo (void);
int
main ()
{
return foo ();
}
$ gcc-9 -fno-common x.c -c -flto && nm x.o
U foo
T main
T nm_test_var
T nm_test_var2
After:
$ ~/bin/binutils/bin/nm --plugin
/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0 x.o
U foo
T main
B nm_test_var
D nm_test_var2
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #9 from Martin Liška --- > > Amusingly, "nm" is also busted on objects using this trick with -flto, > showing a_ as an undefined symbol which is not the case. But that > shouldn't cause any issue for libtool's uses of nm. Hello Nick. Have you made a progress about the upstreaming of the workaround? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added CC||bfriesen at simple dot dallas.tx.u ||s -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
--- Comment #4 from Martin Liška ---
(In reply to Nick Bowler from comment #2)
> Summary of the issue in libtool:
>
> libtool needs to produce C declarations for arbitrary symbols based on nm
> output, in order to implement various features such as dlpreopen which
> depend on putting symbol values into C data structures.
>
> Some linkers (apparently this the case on HP-UX) are strict and won't let
> function declarations refer to variables and vice versa. So the nm symbol
> type is used to produce either a function or variable declaration, as
> appropriate.
>
> Unfortunately, with LTO enabled the GNU linker (or does GCC do everything in
> this case?) seems to also have this restriction: it is an error for a
> function declaration to refer to a variable or vice versa.
Yes, it's critical for the compiler to not mix different symbol types (fn, var)
with the same name
> So libtool uses
> the symbol type reported by nm to produce function declarations for
> functions, and variable declarations for variables.
>
> Unfortunately, with LTO enabled then GNU nm does not distinguish between
> functions and variables (however, clang and llvm-nm seems to be fine in this
> regard).
That's true, but it's only related to .o files (LTO bytecode). If you link
a final executable (or a shared library), you'll get proper type information:
$ cat conftest.c
int foo;
int main() { return foo; }
$ gcc conftest.c -flto -fno-common
$ nm a.out | grep ' main'
004010f2 T main
$ nm a.out | grep foo
0040402c b foo
Would it be possible to libtool to make the detection on a binary executable
or a shared library?
>
> There is no obvious way to work around the LTO function/data declaration
> issue in C code. It seems libtool has to know, in advance, whether any
> given symbol is code or data in order to produce a declaration that will
> link successfully.
>
> I see several options that would work to resolve the libtool problem:
>
> - Fix GNU nm to report functions and variables differently (best).
> - Fix GNU ld (or GCC?) so that it is not a hard error to refer to
> variables with function declarations or vice versa, so the nm issue does not
> matter.
> - Figure out another way to get the value of a symbol in C code without
> knowing anything other than its name.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/25355] New: nm reports a variable as "T" with -flto and -fno-common
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Bug ID: 25355 Summary: nm reports a variable as "T" with -flto and -fno-common Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com Target Milestone: --- As being discussed here: https://lists.gnu.org/archive/html/libtool/2020-01/msg00022.html nm reports misleadingly a global variable: $ cat nm.c char nm_test_var; $ gcc-9 nm.c -c -fno-common $ nm nm.o B nm_test_var $ gcc-9 nm.c -c -fno-common -flto $ nm nm.o T nm_test_var So the issue is that I would expect "B" from the last nm invocation. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/24123] incremental_copy_test failure when building with gcc-9
https://sourceware.org/bugzilla/show_bug.cgi?id=24123 Martin Liška changed: What|Removed |Added CC||marxin.liska at gmail 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/24912] g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://sourceware.org/bugzilla/show_bug.cgi?id=24912 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Liška --- Fixed. -- 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/24912] New: g++.dg/lto/pr90990 FAILs with gld 2.32.51
https://sourceware.org/bugzilla/show_bug.cgi?id=24912 Bug ID: 24912 Summary: g++.dg/lto/pr90990 FAILs with gld 2.32.51 Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com Target Milestone: --- Copy from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376: 've just tried Solaris/SPARC and x86 bootstraps with gas and gld from binutils master. Doing so revealed a failure not present when using gas/gld 2.32: +FAIL: g++.dg/lto/pr90990 cp_lto_pr90990_0.o-cp_lto_pr90990_0.o link, -O0 -flto -flto-partition=none -fuse-linker-plugin +FAIL: g++.dg/lto/pr90990 cp_lto_pr90990_0.o-cp_lto_pr90990_0.o link, -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects +FAIL: g++.dg/lto/pr90990 cp_lto_pr90990_0.o-cp_lto_pr90990_0.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects +FAIL: g++.dg/lto/pr90990 cp_lto_pr90990_0.o-cp_lto_pr90990_0.o link, -O2 -flto -fuse-linker-plugin The tests FAIL with /vol/gcc/bin/gld-2.32.51: g++-dg-lto-pr90990-01.exe.lto.o: plugin needed to handle lto object Just replacing gld-2.32.51 with gld-2.32 makes the failure go away. I don't believe that this is a traget issue, though, because on gcc-testresults there are reports of the same failure on Linux/ia64, Linux/powerpc64le, and PRU. It would be good to have this fixed before binutils 2.33 hit the streets. -- 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/24768] Stop using __gnu_lto_slim symbol as a detection of a slim LTO object
https://sourceware.org/bugzilla/show_bug.cgi?id=24768 --- Comment #5 from Martin Liška --- Should be implemented now. Let's keep this issue to remove later the usage of __gnu_lto_slim. -- 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/24768] Stop using __gnu_lto_slim symbol as a detection of a slim LTO object
https://sourceware.org/bugzilla/show_bug.cgi?id=24768 --- Comment #3 from Martin Liška --- > > The layout of this struct depends on the host compiler. Won't that cause > problems in object file portability? You are right, I will change streaming of the structure to be always LE in a ELF file. I'll then send patches to binutils mailing list. -- 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/24768] Stop using __gnu_lto_slim symbol as a detection of a slim LTO object
https://sourceware.org/bugzilla/show_bug.cgi?id=24768 --- Comment #1 from Martin Liška --- Created attachment 11883 --> https://sourceware.org/bugzilla/attachment.cgi?id=11883=edit Patch candidate I would appreciate feedback about the patch before I'll send it to the mailing list. -- 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/24464] rx: Fatal error: Infinite loop encountered whilst attempting to compute the addresses of symbols in section P
https://sourceware.org/bugzilla/show_bug.cgi?id=24464 Martin Liška changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||ysato at users dot sourceforge.jp -- 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/24464] New: rx: Fatal error: Infinite loop encountered whilst attempting to compute the addresses of symbols in section P
https://sourceware.org/bugzilla/show_bug.cgi?id=24464 Bug ID: 24464 Summary: rx: Fatal error: Infinite loop encountered whilst attempting to compute the addresses of symbols in section P Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com Target Milestone: --- Using rx cross gas I see: $ cat pr90045.s .file "pr90045.c" .section P,"ax" .global _copy .type _copy, @function _copy: mov.L r2, r14 cmp #0, r14 mov.L r1, r2 bne .L7 rts .balign 2 .L7: mov.L r3, r1 mov.L r14, r3 smovf rts .size _copy, .-_copy .ident "GCC: (GNU) 9.0.0 20180717 (experimental)" $ ./as -m32bit-doubles -mrx-abi -o pr90045.o pr90045.s pr90045.s: Assembler messages: pr90045.s: Fatal error: Infinite loop encountered whilst attempting to compute the addresses of symbols in section P $ ./as --version GNU assembler (GNU Binutils; openSUSE Tumbleweed) 2.32 -- 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/24434] Missing testsuite coverage for AVX512F gathers (and scatters?) with no base register
https://sourceware.org/bugzilla/show_bug.cgi?id=24434 --- Comment #3 from Martin Liška --- (In reply to Jan Beulich from comment #2) > (In reply to Martin Liška from comment #1) > > Fixed in bintuils with: > > > > commit 629cfaf1b0fbb32a985607c774bd8e7870b9fa94 (HEAD, refs/bisect/bad) > > Author: Jan Beulich > > Date: Mon Jul 30 17:25:05 2018 +0200 > > > > x86: don't mistakenly scale non-8-bit displacements > > I don't understand this comment: Said commit does not add any S/G test > case(s) o the testsuite. I don't think you should have copied the respective > gcc bug comment here. Yes, I should have mentioned that the commit fixes the problem and that it would be nice to add the assembly snippet to test suite. -- 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/24434] Missing testsuite coverage for AVX512F gathers (and scatters?) with no base register
https://sourceware.org/bugzilla/show_bug.cgi?id=24434 Martin Liška changed: What|Removed |Added CC||jbeulich at novell 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 gas/24434] Missing testsuite coverage for AVX512F gathers (and scatters?) with no base register
https://sourceware.org/bugzilla/show_bug.cgi?id=24434
Martin Liška changed:
What|Removed |Added
CC||marxin.liska at gmail dot com
--- Comment #1 from Martin Liška ---
Fixed in bintuils with:
commit 629cfaf1b0fbb32a985607c774bd8e7870b9fa94 (HEAD, refs/bisect/bad)
Author: Jan Beulich
Date: Mon Jul 30 17:25:05 2018 +0200
x86: don't mistakenly scale non-8-bit displacements
In commit b5014f7af2 I've removed (instead of replaced) a conditional,
resulting in addressing forms not allowing 8-bit displacements to now
get their displacements scaled under certain circumstances. Re-add the
missing conditional.
Minimal reproducer:
$ cat min.s
.text
foo:
vpgatherqq 8(,%ymm1,1), %ymm0{%k2}
$ ./gas/as-new --64 min.s -o avx512.o && ./binutils/objdump -S avx512.o
avx512.o: file format elf64-x86-64
Disassembly of section .text:
:
0: 62 f2 fd 2a 91 04 0dvpgatherqq 0x1(,%ymm1,1),%ymm0{%k2}
7: 01 00 00 00
--
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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #26 from Martin Liška --- (In reply to H.J. Lu from comment #25) > Created attachment 11681 [details] > A patch > > Please try this. Good job H.J. I can confirm it works for a simple test-case and I see: 737 54db81cc670131ad PREVAILING_DEF _ZNKSt5ctypeIcE8do_widenEc 740 54db81cc670131ad PREVAILING_DEF main which is good. I'm going to ask Godot engine guy who use it for much bigger code base. -- 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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #23 from Martin Liška --- (In reply to H.J. Lu from comment #22) > Works for me with binutils 2.32: > Have you tried to run the binary with wine? You'll probably see something like: wine: Unhandled page fault on read access to 0x at address 0x4a39fe (thread 002a), starting debugger... Issue is that the linker claims that all is fine, but final binary is missing the symbol. -- 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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #21 from Martin Liška --- (In reply to H.J. Lu from comment #20) > (In reply to Martin Liška from comment #19) > > H.J. : Can you please help me how to find a place which makes a real > > decision about which BFD (object) will be used for each symbol? > > Is there a way to easily reproduce it on Fedora 29? I guess so, you'll need to install cross compiler, linker, etc.: https://fedoraproject.org/wiki/MinGW/Tutorial https://fedora.pkgs.org/27/fedora-x86_64/mingw64-gcc-7.2.0-1.fc27.x86_64.rpm.html -- 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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #19 from Martin Liška --- H.J. : Can you please help me how to find a place which makes a real decision about which BFD (object) will be used for each symbol? -- 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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #18 from Martin Liška --- > I meant it must be PREVAILING_DEF and can't be PREVAILING_DEF_IRONLY. Yes, PREVAILING_DEF would be fine as well for COFF. -- 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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #15 from Martin Liška --- Yes, both return: ... 262 545ca41eb4de6c9c PREVAILING_DEF _ZNKSt5ctypeIcE8do_widenEc -- 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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #13 from Martin Liška --- > > What do ELF linkers (gold and bfd) get? We get: (gdb) p owner_sec->owner->filename $5 = 0x69ae80 "main.o (symbol from plugin)" -- 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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267
--- Comment #11 from Martin Liška ---
I've got a patch candidate that can solve it:
diff --git a/bfd/coffgen.c b/bfd/coffgen.c
index 309e1249ac..1d200b066b 100644
--- a/bfd/coffgen.c
+++ b/bfd/coffgen.c
@@ -2678,9 +2678,9 @@ _bfd_coff_section_already_linked (bfd *abfd,
and match any comdat section with comdat name of , and
any linkonce section with the same suffix, ie.
.gnu.linkonce.*.. */
- if (((s_comdat != NULL) == (l_comdat != NULL)
- && strcmp (name, l->sec->name) == 0)
- || (l->sec->owner->flags & BFD_PLUGIN) != 0)
+ if (((s_comdat != NULL) == (l_comdat != NULL))
+ && ((strcmp (name, l->sec->name) == 0)
+|| (l->sec->owner->flags & BFD_PLUGIN) != 0))
{
/* The section has already been linked. See if we should
issue a warning. */
However, Honza is still thinking that LDPR_PREVAILING_DEF_IRONLY should be used
for the symbol. If I see correctly it's set in ld/plugin.c base on
else if (owner_sec->owner == abfd).
Can you please help me where sections are set for each symbol? Is it a COFF
specific code?
--
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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #10 from Martin Liška --- > I don't understand much the details but I think what H.J. Lu was trying to > say is that maybe was fixed for ELF but not for PE/COFF so to have a look at > the mentioned PRs. > I cannot suggest any of them, PR 0 refers to PREVAILING_DEF_IRONLY but > the issue seems the opposite. I know, I filtered these PRs: PR23958 - elf-related change, but related to symbol versioning PR23818 - likewise PR23309 - changes only in generic code PR22983 - related to dynamic-list only PR22751 - changes only in generic code PR22502 - elf-related change, might by a candidate for COFF PR20321 - a segfault, changes in generic code PR20267 - llvm-related crash PR18250 - likewise PR21382 - elf-related change, might by a candidate for COFF PR0 - elf-related change, might by a candidate for COFF, but's symbol versioning related I'll investigate PR22502 and PR21382 -- 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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 Martin Liška changed: What|Removed |Added CC||eliz at gnu dot org -- 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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 Martin Liška changed: What|Removed |Added CC||eliz at gnu dot org -- 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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #8 from Martin Liška --- (In reply to H.J. Lu from comment #7) > (In reply to Martin Liška from comment #6) > > > > > > Not regression. They are LTO bug fixes. > > > > Can you be please more concrete? > > Check PR 23958, PR 23818, PR 23309, PR 22983, PR 22751, PR 22502, > PR 0, PR 21382, PR 18250, PR 20267, PR 20321. I would like to mention that I also tested binutils 2.32 and it's affected. Let me know if you'll need any help with this? -- 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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 Martin Liška changed: What|Removed |Added CC||dave.korn.cygwin at gmail dot com, ||dj at redhat dot com --- Comment #6 from Martin Liška --- (In reply to H.J. Lu from comment #5) > (In reply to Martin Liška from comment #4) > > (In reply to H.J. Lu from comment #3) > > > (In reply to Martin Liška from comment #2) > > > > (In reply to H.J. Lu from comment #1) > > > > > Does it happen on Linux? > > > > > > > > No, it's specific to w64-mingw32 target. I'm testing that on Linux > > > > where I > > > > use cross compiler + wine: > > > > > > Some LTO fixes are ELF specific. Someone needs to take a look at > > > them to see if COFF needs similar fixes. > > > > Are you talking about any recent regression that were just fixed for ELF? > > Not regression. They are LTO bug fixes. Can you be please more concrete? > > > Btw. do you have a COFF specific maintainer or a person who can help us? > > DJ Delorie and Dave Korn are > COFF maintainers. Good, I'm adding them. -- 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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #4 from Martin Liška --- (In reply to H.J. Lu from comment #3) > (In reply to Martin Liška from comment #2) > > (In reply to H.J. Lu from comment #1) > > > Does it happen on Linux? > > > > No, it's specific to w64-mingw32 target. I'm testing that on Linux where I > > use cross compiler + wine: > > Some LTO fixes are ELF specific. Someone needs to take a look at > them to see if COFF needs similar fixes. Are you talking about any recent regression that were just fixed for ELF? Btw. do you have a COFF specific maintainer or a person who can help us? -- 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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #2 from Martin Liška --- (In reply to H.J. Lu from comment #1) > Does it happen on Linux? No, it's specific to w64-mingw32 target. I'm testing that on Linux where I use cross compiler + wine: $ wine --version wine-4.1 -- 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/24267] ld discards a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 Martin Liška changed: What|Removed |Added Summary|ld discard a symbol with|ld discards a symbol with |-flto and -static |-flto and -static -- 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/24267] ld discard a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 Martin Liška changed: What|Removed |Added CC||amodra at gmail 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/24267] New: ld discard a symbol with -flto and -static
https://sourceware.org/bugzilla/show_bug.cgi?id=24267
Bug ID: 24267
Summary: ld discard a symbol with -flto and -static
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: marxin.liska at gmail dot com
Target Milestone: ---
This is follow up of:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81879
$ cat simpler.ii
namespace std {
template struct char_traits;
template > class basic_ostream;
typedef basic_ostream b;
class ios_base {
public:
class Init {
public:
Init();
};
};
template class ctype {
virtual char do_widen(char c) const { return c; }
};
class d {
ctype e;
};
template class basic_ostream : d {};
template
basic_ostream <<(basic_ostream &, const char *);
b cout;
ios_base::Init g;
} // namespace std
int main() { std::cout << "ok"; }
When compiler with:
$ x86_64-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-w64-mingw32/8.2.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin
--includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib64
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--build=x86_64-suse-linux-gnu --host=x86_64-suse-linux-gnu
--target=x86_64-w64-mingw32 --with-gnu-as --with-gnu-ld --verbose
--without-newlib --disable-multilib --enable-shared --disable-plugin
--with-system-zlib --disable-nls --without-included-gettext
--disable-win32-registry --enable-threads=posix
--enable-version-specific-runtime-libs
--with-sysroot=/usr/x86_64-w64-mingw32/sys-root
--enable-languages=c,c++,fortran,objc,obj-c++ --without-x
--enable-hash-synchronization --enable-fully-dynamic-string --enable-libgomp
--enable-linker-build-id --disable-vtable-verify --with-pkgversion='SUSE Linux'
Thread model: posix
gcc version 8.2.0 (SUSE Linux)
$ x86_64-w64-mingw32-g++ simpler.ii -flto -O2 -static --save-temps --verbose
...
$ cat simpler.res
1
simpler.o 10
257 4b7905b9947ad39f PREEMPTED_REG _ZNKSt5ctypeIcE8do_widenEc
260 4b7905b9947ad39f PREVAILING_DEF main
279 4b7905b9947ad39f PREEMPTED_REG _ZSt4cout
282 4b7905b9947ad39f PREVAILING_DEF_IRONLY _ZSt1g
291 4b7905b9947ad39f PREEMPTED_REG _ZTSSt5ctypeIcE
305 4b7905b9947ad39f PREEMPTED_REG _ZTISt5ctypeIcE
207 4b7905b9947ad39f PREEMPTED_REG _ZTVSt5ctypeIcE
316 4b7905b9947ad39f RESOLVED_EXEC _ZTVN10__cxxabiv117__class_type_infoE
271 4b7905b9947ad39f RESOLVED_EXEC
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
276 4b7905b9947ad39f RESOLVED_EXEC _ZNSt8ios_base4InitC1Ev
as seen _ZNKSt5ctypeIcE8do_widenEc is both defined in the static libstdc++ and
simpler.ii. Linker tells to not to emit assembly for the symbol. However we
then end up with a binary where the symbol is missing:
$ x86_64-w64-mingw32-nm a.exe | grep _ZNKSt5ctypeIcE8do_widenEc
00acda70 N .debug_frame$_ZNKSt5ctypeIcE8do_widenEc
004b9150 p .pdata$_ZNKSt5ctypeIcE8do_widenEc
004c51b4 r .xdata$_ZNKSt5ctypeIcE8do_widenEc
U _ZNKSt5ctypeIcE8do_widenEc
U _ZNKSt5ctypeIcE8do_widenEc
U _ZNKSt5ctypeIcE8do_widenEc
U _ZNKSt5ctypeIcE8do_widenEc
U _ZNKSt5ctypeIcE8do_widenEc
U _ZNKSt5ctypeIcE8do_widenEc
U _ZNKSt5ctypeIcE8do_widenEc
Which is causing wine crash:
wine a.exe
wine: Unhandled page fault on read access to 0x at address 0x4a3a2e
(thread 002b), starting debugger...
So I suspect ld.bfd for not copying the _ZNKSt5ctypeIcE8do_widenEc from static
libstdc++:
$ x86_64-w64-mingw32-nm /usr/lib64/gcc/x86_64-w64-mingw32/8.2.0/libstdc++.dll.a
| grep _ZNKSt5ctypeIcE8do_widenEc
I __imp__ZNKSt5ctypeIcE8do_widenEc
T _ZNKSt5ctypeIcE8do_widenEc
If needed I can upload somewhere libstdc++.dll.a 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 gas/24165] fivefold time and memory usage since commit 3ae729d5 on large files generated by lto
https://sourceware.org/bugzilla/show_bug.cgi?id=24165 Martin Liška changed: What|Removed |Added CC||marxin.liska at gmail dot com --- Comment #2 from Martin Liška --- And the original test-case can be found here: https://drive.google.com/file/d/1_63e0GbykhVAr_ZubOP4YuiZOW2ThoGl/view?usp=sharing -- 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 gold/15660] out of file descriptors and couldn't close any
https://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #11 from Martin Liška marxin.liska at gmail dot com --- There's my out/Release build folder: https://drive.google.com/file/d/0B0pisUJ80pO1UzFGNGJhaW1xbVE/edit?usp=sha ring It's ~3.4GB tar with bzip2 (~6GB extracted). ld --version: GNU gold (GNU Binutils 2.24.51.20140304) 1.11 liblto plugin and command line argument for ld are attached in the tar I wi ll upload. -- 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 gold/15660] out of file descriptors and couldn't close any
https://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #12 from Martin Liška marxin.liska at gmail dot com --- Created attachment 7476 -- https://sourceware.org/bugzilla/attachment.cgi?id=7476action=edit ld args and liblto plugin -- 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 gold/15660] New: out of file descriptors and couldn't close any
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 Bug ID: 15660 Summary: out of file descriptors and couldn't close any Product: binutils Version: 2.23 Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ian at airs dot com Reporter: marxin.liska at gmail dot com CC: ccoutant at google dot com I've encountered similar bug to: http://sourceware.org/bugzilla/show_bug.cgi?id=10708 during linking of chromium binary. ld --version GNU gold (GNU Binutils 2.23.52.20130526) 1.11 Command line: FAILED: flock linker.lock g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -pie -L. -flto=9 -fno-fat-lto-objects -O2 --param lto-partitions=64 -o chrome -Wl,--start-group obj/chrome/app/chrome.chrome_exe_main_gtk.o obj/chrome/app/chrome.chrome_main.o obj/chrome/app/chrome.chrome_main_delegate.o obj/chrome/libinstaller_util.a obj/media/libmedia_sse.a obj/third_party/icu/libicuuc.a obj/third_party/libjingle/libjingle.a obj/skia/libskia_opts.a obj/third_party/icu/libicudata.a obj/device/libdevice_media_transfer_protocol.a obj/native_client/src/trusted/service_runtime/arch/x86/libservice_runtime_x86_common.a obj/chrome/libservice.a obj/chrome/librenderer.a obj/webkit/support/libglue.a obj/content/libcontent_worker.a obj/third_party/libwebp/libwebp_utils.a obj/third_party/zlib/libminizip.a obj/chrome/browser/performance_monitor/libperformance_monitor.a obj/third_party/leveldatabase/libleveldatabase.a obj/native_client/src/trusted/service_runtime/libenv_cleanser.a obj/sandbox/libc_urandom_override.a obj/chrome/libbrowser.a obj/ppapi/libppapi_host.a obj/sync/libsync_core.a obj/gpu/libgles2_cmd_helper.a obj/third_party/smhasher/libcityhash.a obj/third_party/libphonenumber/libphonenumber.a obj/chrome/app/policy/libpolicy.a obj/webkit/support/libplugins_common.a obj/native_client/src/trusted/validator_x86/libnccopy_x86_64.a obj/webkit/support/libglue_common.a obj/webkit/renderer/compositor_bindings/libwebkit_compositor_support.a obj/third_party/smhasher/libmurmurhash3.a obj/content/libcontent_gpu.a obj/native_client/src/trusted/threading/libthread_interface.a obj/media/libmedia_mmx.a obj/ipc/libipc.a obj/third_party/libxslt/libxslt.a obj/remoting/libremoting_client.a obj/third_party/ots/libots.a obj/base/libsymbolize.a obj/native_client/src/trusted/validator/libvalidators.a obj/chrome/libbrowser_extensions.a obj/skia/libskia_opts_ssse3.a obj/third_party/protobuf/libprotobuf_lite.a obj/third_party/WebKit/Source/core/core.gyp/libwebcore_platform.a obj/ui/surface/libsurface.a obj/third_party/WebKit/Source/WebKit/chromium/libwebkit.a obj/native_client/src/trusted/validator/x86/64/libncvalidate_x86_64.a obj/third_party/jsoncpp/libjsoncpp.a obj/google_apis/libgoogle_apis.a obj/chrome/libnacl.a obj/third_party/libphonenumber/libphonenumber_without_metadata.a obj/chrome/libdebugger.a obj/v8/tools/gyp/libv8_snapshot.a obj/ui/native_theme/libnative_theme.a obj/third_party/libusb/libusb.a obj/content/libcontent_common_child.a obj/native_client/src/trusted/nacl_base/libnacl_base.a obj/base/libbase_static.a obj/native_client/src/shared/imc/libimc.a obj/chrome/libfeedback_proto.a obj/components/libbrowser_context_keyed_service.a obj/components/libweb_modal.a obj/chrome/libapps.a obj/third_party/WebKit/Source/core/core.gyp/libwebcore_platform_geometry.a obj/components/libuser_prefs.a obj/content/libcontent_utility.a obj/third_party/libevent/libevent.a obj/sandbox/libseccomp_bpf.a obj/build/linux/libpci.a obj/ui/gl/libgl_wrapper.a obj/third_party/mt19937ar/libmt19937ar.a obj/third_party/angle/src/libtranslator_common.a obj/ui/message_center/libmessage_center.a obj/third_party/libpng/libpng.a obj/components/libwebdata_common.a obj/third_party/opus/libopus.a obj/sync/libsync_notifier.a obj/ui/snapshot/libsnapshot.a obj/native_client/src/trusted/validator/x86/libncval_base_x86_64.a obj/webkit/support/libwebkit_media.a obj/third_party/libwebp/libwebp_dsp.a obj/third_party/harfbuzz-ng/libharfbuzz-ng.a obj/chrome/app/policy/libcloud_policy_proto_generated_compile.a obj/base/allocator/liballocator_extension_thunks.a obj/remoting/libremoting_jingle_glue.a obj/native_client/src/trusted/service_runtime/libnacl_error_code.a obj/third_party/snappy/libsnappy.a obj/cc/libcc.a obj/third_party/libjingle/libjingle_p2p_constants.a obj/third_party/cld/libcld.a obj/third_party/libxml/libxml2.a obj/webkit/support/libplugins.a obj/chrome/libvariations_seed_proto.a obj/remoting/proto/libchromotocol_proto_lib.a obj/native_client/src/trusted/simple_service/libsimple_service.a obj/chrome/libsync_file_system_proto.a obj/gpu/libdisk_cache_proto.a obj/third_party/WebKit/Source/core/core.gyp/libwebcore_html.a obj/native_client/src/trusted/interval_multiset/libnacl_interval.a obj/build/linux/libspeechd.a obj/sync/libsync_internal_api.a obj/third_party/hunspell/libhunspell.a obj/chrome/libplugin.a obj/ui/compositor
[Bug gold/15660] out of file descriptors and couldn't close any
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #3 from Martin Liška marxin.liska at gmail dot com --- ulimit -n 1024 I tried same command line without --start-group/--end-group, but didn't hel p. Next step was to create one large archive, so: ar r [list of all *.a] /tmp/lib.a g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -pie -L. -flt o=9 -fno-fat-lto-objects -O2 --param lto-partitions=64 -o chrome obj/chrome/app/chrome.chrome_exe_main_gtk.o obj/chrome/app/chrome.chrome_ma in.o obj/chrome/app/chrome.chrome_main_delegate.o /tmp/lib.a -lX11 -lXcursor -lXrandr -lXrender -lXss -lXext -lrt -ldl -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lXtst -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio -2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfree type -lfontconfig -lXi -lsmime3 -lnssutil3 -lnss3 -lplds4 -lplc4 -lnspr4 -lgconf -2 -lresolv -lXcomposite -lasound -lXdamage -lXfixes -lcups -lgnutls -lgcrypt -lgpg-error -lz -lpthread -lcrypt -lm -L/usr/lib64 -lexpat -ldbus-1 -ludev I was shown big amount of undefined symbols, did I use the correct way how to create the archive? Thanks, Martin -- 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 gold/15660] out of file descriptors and couldn't close any
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #5 from Martin Liška marxin.liska at gmail dot com --- I did so, thin library was created, but linker is still complaining about f ile descriptors: g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -pie -L. -flt o=9 -fno-fat-lto-objects -O2 --param lto-partitions=64 -o chrome obj/chrome/app/chrome.chrome_exe_main_gtk.o obj/chrome/app/chrome.chrome_ma in.o obj/chrome/app/chrome.chrome_main_delegate.o lib.a -lX11 -lXcursor -lXrandr -lXrender -lXss -lXext -lrt -ldl -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lXtst -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfree type -lfontconfig -lXi -lsmime3 -lnssutil3 -lnss3 -lplds4 -lplc4 -lnspr4 -lgconf -2 -lresolv -lXcomposite -lasound -lXdamage -lXfixes -lcups -lgnutls -lgcrypt -lgpg-error -lz -lpthread -lcrypt -lm -L/usr/lib64 -lexpat -ldbus-1 -ludev -- 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 gold/15660] out of file descriptors and couldn't close any
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #7 from Martin Liška marxin.liska at gmail dot com --- I'll try to link it without -flto, but I used -fno-fat-lto-objects. It will take me some time to recompile chromium. Weird is that ld.bfd is able to link the binary with -flto (aside gcc relat ed errors). -- 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/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.
http://sourceware.org/bugzilla/show_bug.cgi?id=15516 --- Comment #11 from Martin Liška marxin.liska at gmail dot com --- So the bug is really present in binutils trunk (May 24 2013). ld --version: GNU ld (GNU Binutils) 2.23.52.20130524 gcc --version: gcc (GCC) 4.9.0 20130517 (experimental) Compilation error: S=/home/marxin/Programming/libreoffice-lto-test O=$S/solver/unxlngx6 .pro W=$S/workdir/unxlngx6.pro mkdir -p $W/LinkTarget/Executable/ g++ -flto -fno-fat-lto-objects -fuse-linker-plugin -O2 -Wl,-z,origin '-Wl,-rpath,$ORIGIN/../lib:$ORIGIN' -Wl,-rpath-link,$O/lib -Wl,-z,defs -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -L$O/lib -Wl,--hash-style =gnu -Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo -Wl,-Bsymbolic-functions -Wl,-O1 -Wl,-S $W/CxxObject/i18npool/source/localedata/LocaleNode.o $W/CxxObject/i18npool/source/localedata/filewriter.o $W/CxxObject/i18npool/source/localedata/saxparser.o -Wl,--start-group -Wl,--end-group -Wl,--no-as-needed -luno_cppu -luno_cppuhelpergcc3 -luno_ sal -o $W/LinkTarget/Executable/saxparser /home/marxin/Programming/libreoffice-lto-test/workdir/unxlngx6.pro/CxxObjec t/i18npool/source/localedata/saxparser.o (symbol from plugin): undefined reference to `typeinfo for com::sun::star::uno::Exception' /home/marxin/Programming/libreoffice-lto-test/workdir/unxlngx6.pro/CxxObjec t/i18npool/source/localedata/saxparser.o (symbol from plugin): undefined reference to `typeinfo name for com::sun::star::uno::RuntimeException' /home/marxin/Programming/libreoffice-lto-test/workdir/unxlngx6.pro/CxxObjec t/i18npool/source/localedata/saxparser.o (symbol from plugin): undefined reference to `typeinfo for com::sun::star::uno::RuntimeException' /home/marxin/Programming/libreoffice-lto-test/workdir/unxlngx6.pro/CxxObjec t/i18npool/source/localedata/saxparser.o (symbol from plugin): undefined reference to `typeinfo name for com::sun::star::uno::Exception' collect2: error: ld returned 1 exit status All 3 object files are added as an attachment. Thanks, Martin -- 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/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.
http://sourceware.org/bugzilla/show_bug.cgi?id=15516 --- Comment #12 from Martin Liška marxin.liska at gmail dot com --- Created attachment 7054 -- http://sourceware.org/bugzilla/attachment.cgi?id=7054action=edit Libreoffice saxparser object files -- 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/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.
http://sourceware.org/bugzilla/show_bug.cgi?id=15516 Martin Liška marxin.liska at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- --- Comment #13 from Martin Liška marxin.liska at gmail dot com --- Test case was introduced. -- 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/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.
http://sourceware.org/bugzilla/show_bug.cgi?id=15516 Martin Liška marxin.liska at gmail dot com changed: What|Removed |Added CC||marxin.liska at gmail dot ||com --- Comment #5 from Martin Liška marxin.liska at gmail dot com 2013- 05-24 12:36:57 UTC --- Hello, I've just tried to build libreoffice with GNU ld (Linux/GNU Binutils) 2.23.52.0.2.20130423, latest version I am able to install on my gentoo mach ine, and the problem was reached. If it helps, I will checkout mainline bintuils and try it. Martin -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.
MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable html head base href=3Dhttp://sourceware.org/bugzilla/; / /head body p div ba class=3Dbz_bug_link=20 bz_status_RESOLVED bz_closed title=3DRESOLVED WORKSFORME - GNU LD is confused when linker plugin tur= ns COMDAT symbol into static w/o renaming. href=3Dhttp://sourceware.org/bugzilla/show_bug.cgi?id=3D15516#c8;Comme= nt # 8/a on a class=3Dbz_bug_link=20 bz_status_RESOLVED bz_closed title=3DRESOLVED WORKSFORME - GNU LD is confused when linker plugin tur= ns COMDAT symbol into static w/o renaming. href=3Dhttp://sourceware.org/bugzilla/show_bug.cgi?id=3D15516;bug 1551= 6/a from span class=3Dvcardspan class=3DfnMartin Li=C5=A1= ka/span /span/b preI've got a good news, mainline ld does not report the problem. The bug could be closed. Martin/pre /div /p hr spanYou are receiving this mail because:/span =20=20=20=20=20=20 ul liYou are on the CC list for the bug./li /ul /body /html ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
