Bug 15516 - GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.
Summary: GNU LD is confused when linker plugin turns COMDAT symbol into static w/o ren...
Status: RESOLVED OBSOLETE
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-22 14:42 UTC by Jan Hubicka
Modified: 2023-04-16 02:38 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Libreoffice saxparser object files (493.85 KB, application/x-bzip)
2013-06-02 17:13 UTC, Martin Liška
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Hubicka 2013-05-22 14:42:46 UTC
Current libreoffice fails to build with the current GCC because of bogus error:


S=/home/marxin/libreoffice && 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/libreoffice/workdir/unxlngx6.pro/CxxObject/i18npool/source/localedata/saxparser.o (symbol from plugin): undefined reference to `typeinfo for com::sun::star::uno::Exception'
/home/marxin/libreoffice/workdir/unxlngx6.pro/CxxObject/i18npool/source/localedata/saxparser.o (symbol from plugin): undefined reference to `typeinfo name for com::sun::star::uno::RuntimeException'
/home/marxin/libreoffice/workdir/unxlngx6.pro/CxxObject/i18npool/source/localedata/saxparser.o (symbol from plugin): undefined reference to `typeinfo for com::sun::star::uno::RuntimeException'
/home/marxin/libreoffice/workdir/unxlngx6.pro/CxxObject/i18npool/source/localedata/saxparser.o (symbol from plugin): undefined reference to `typeinfo name for com::sun::star::uno::Exception'

The typeinfo is a COMDAT symbol that is turned into static and somehow GNU LD still mixes it up with the original symbol definition.

Sadly we have no self contained testcase....
Comment 1 Alan Modra 2013-05-22 16:24:05 UTC
By "turned into static" do you mean that the typeinfo symbol in the real object is STB_LOCAL?
Comment 2 hubicka 2013-05-22 16:44:43 UTC
> --- Comment #1 from Alan Modra <amodra at gmail dot com> 2013-05-22 16:24:05 UTC ---
> By "turned into static" do you mean that the typeinfo symbol in the real object
> is STB_LOCAL?

typeinfo itself is not changed, just the symbol was previously common 
GCC localized it to static guided by RESOLVED_DEF_IRONLY resolution.
For some reason this seem to break with the message above (that seems bogus,
since it speaks of reference from plugin section)

Honza
Comment 3 Alan Modra 2013-05-24 09:54:14 UTC
I could not reproduce this with current mainline binutils.  The following extract from a debug session shows one of the typeinfo symbols hitting _bfd_exf_export_symbol.  We get there due to -Wl,--dynamic-list-cpp-typeinfo. Notice the plugin sym doesn't have def_regular or ref_regular set, so is not exported dynamic.  The second sym showed me what Jan meant by "turned into static", and is some evidence that ld is being exercised in a way that would trigger the bug if it still existed.  I suspect the bug was fixed along with PR15270, or one of my other patches in late March.

Jan if you can reproduce with mainline ld, please attach at set of objects that reproduce the problem, and reopen the bug.

Breakpoint 2, _bfd_elf_export_symbol (h=0x114a2c0, data=0x7fffffffd1e0) at /src/binutils-current/bfd/elflink.c:1813
(gdb) p *h
$28 = {root = {root = {next = 0x0, string = 0x11555fc "_ZTIN3com3sun4star3uno9ExceptionE", hash = 474875173}, type = bfd_link_hash_defweak, non_ir_ref = 1, u = {undef = {next = 0x114a2c0, abfd = 0x1135198}, def = {next = 0x114a2c0, section = 0x1135198, value = 0}, i = {next = 0x114a2c0, link = 0x1135198, warning = 0x0}, c = {next = 0x114a2c0, p = 0x1135198, size = 0}}}, indx = -1, dynindx = -1, got = {refcount = 0, offset = 0, glist = 0x0, plist = 0x0}, plt = {refcount = 0, offset = 0, glist = 0x0, plist = 0x0}, size = 16, type = 1, other = 0, target_internal = 0, ref_regular = 0, def_regular = 0, ref_dynamic = 1, def_dynamic = 0, ref_regular_nonweak = 0, dynamic_adjusted = 0, needs_copy = 0, needs_plt = 0, non_elf = 0, hidden = 0, forced_local = 0, dynamic = 1, mark = 0, non_got_ref = 0, dynamic_def = 1, ref_dynamic_nonweak = 0, pointer_equality_needed = 0, unique_global = 0, dynstr_index = 0, u = {weakdef = 0x0, elf_hash_value = 0}, verinfo = {verdef = 0x0, vertree = 0x0}, vtable = 0x0}
(gdb) p h->root.u.def.section->owner->filename
$29 = 0x1094ee0 "/home/alan/build/libreoffice/workdir/unxlngx6.pro/CxxObject/i18npool/source/localedata/saxparser.o (symbol from plugin)"
(gdb) c
Continuing.

Breakpoint 2, _bfd_elf_export_symbol (h=0x16657d8, data=0x7fffffffd1e0) at /src/binutils-current/bfd/elflink.c:1813
(gdb) p *h
$30 = {root = {root = {next = 0x0, string = 0x168264d "_ZTIN3com3sun4star3uno9ExceptionE.lto_priv.27", hash = 1034143234}, type = bfd_link_hash_defined, non_ir_ref = 1, u = {undef = {next = 0x0, abfd = 0x1680b88}, def = {next = 0x0, section = 0x1680b88, value = 1232}, i = {next = 0x0, link = 0x1680b88, warning = 0x4d0 <Address 0x4d0 out of bounds>}, c = {next = 0x0, p = 0x1680b88, size = 1232}}}, indx = -1, dynindx = -1, got = {refcount = 0, offset = 0, glist = 0x0, plist = 0x0}, plt = {refcount = 3, offset = 3, glist = 0x3, plist = 0x3}, size = 16, type = 1, other = 2, target_internal = 0, ref_regular = 1, def_regular = 1, ref_dynamic = 0, def_dynamic = 0, ref_regular_nonweak = 0, dynamic_adjusted = 0, needs_copy = 0, needs_plt = 0, non_elf = 0, hidden = 0, forced_local = 0, dynamic = 1, mark = 0, non_got_ref = 1, dynamic_def = 0, ref_dynamic_nonweak = 0, pointer_equality_needed = 1, unique_global = 0, dynstr_index = 0, u = {weakdef = 0x0, elf_hash_value = 0}, verinfo = {verdef = 0x0, vertree = 0x0}, vtable = 0x0}
(gdb) p h->root.u.def.section->owner->filename
$31 = 0x110e8c0 "saxparser.ltrans1.ltrans.o"
(gdb) c
Continuing.
[Inferior 1 (process 21141) exited normally]
(gdb)
Comment 4 hubicka 2013-05-24 11:42:48 UTC
> I could not reproduce this with current mainline binutils.  The following
> extract from a debug session shows one of the typeinfo symbols hitting
> _bfd_exf_export_symbol.  We get there due to -Wl,--dynamic-list-cpp-typeinfo.

Martin,
do you think you can double check if the mainline binutils triggers the bug or not?
The error sadly happens during libreoffice build that is bit hard to turn into
resoable testcase (the module is small though).

I was surprised that the bug does not trigger more often, since mainline GCC since
2013-05-15  Jan Hubicka  <jh@suse.cz>

        PR lto/57038
        PR lto/47375
        * lto-partition.c (get_symbol_class): Fix weakrefs.
        (lto_balanced_map): Fix weakrefs.
        (privatize_symbol_name): Remove unnecesary label.
        (rename_statics): Handle weakrefs as statics.

produces quite a lot of such changes (previously GCC always renamed the symbol
but people complained it makes debugging harder).

Honza
> Notice the plugin sym doesn't have def_regular or ref_regular set, so is not
> exported dynamic.  The second sym showed me what Jan meant by "turned into
> static", and is some evidence that ld is being exercised in a way that would
> trigger the bug if it still existed.  I suspect the bug was fixed along with
> PR15270, or one of my other patches in late March.
> 
> Jan if you can reproduce with mainline ld, please attach at set of objects that
> reproduce the problem, and reopen the bug.
> 
> Breakpoint 2, _bfd_elf_export_symbol (h=0x114a2c0, data=0x7fffffffd1e0) at
> /src/binutils-current/bfd/elflink.c:1813
> (gdb) p *h
> $28 = {root = {root = {next = 0x0, string = 0x11555fc
> "_ZTIN3com3sun4star3uno9ExceptionE", hash = 474875173}, type =
> bfd_link_hash_defweak, non_ir_ref = 1, u = {undef = {next = 0x114a2c0, abfd =
> 0x1135198}, def = {next = 0x114a2c0, section = 0x1135198, value = 0}, i = {next
> = 0x114a2c0, link = 0x1135198, warning = 0x0}, c = {next = 0x114a2c0, p =
> 0x1135198, size = 0}}}, indx = -1, dynindx = -1, got = {refcount = 0, offset =
> 0, glist = 0x0, plist = 0x0}, plt = {refcount = 0, offset = 0, glist = 0x0,
> plist = 0x0}, size = 16, type = 1, other = 0, target_internal = 0, ref_regular
> = 0, def_regular = 0, ref_dynamic = 1, def_dynamic = 0, ref_regular_nonweak =
> 0, dynamic_adjusted = 0, needs_copy = 0, needs_plt = 0, non_elf = 0, hidden =
> 0, forced_local = 0, dynamic = 1, mark = 0, non_got_ref = 0, dynamic_def = 1,
> ref_dynamic_nonweak = 0, pointer_equality_needed = 0, unique_global = 0,
> dynstr_index = 0, u = {weakdef = 0x0, elf_hash_value = 0}, verinfo = {verdef =
> 0x0, vertree = 0x0}, vtable = 0x0}
> (gdb) p h->root.u.def.section->owner->filename
> $29 = 0x1094ee0
> "/home/alan/build/libreoffice/workdir/unxlngx6.pro/CxxObject/i18npool/source/localedata/saxparser.o
> (symbol from plugin)"
> (gdb) c
> Continuing.
> 
> Breakpoint 2, _bfd_elf_export_symbol (h=0x16657d8, data=0x7fffffffd1e0) at
> /src/binutils-current/bfd/elflink.c:1813
> (gdb) p *h
> $30 = {root = {root = {next = 0x0, string = 0x168264d
> "_ZTIN3com3sun4star3uno9ExceptionE.lto_priv.27", hash = 1034143234}, type =
> bfd_link_hash_defined, non_ir_ref = 1, u = {undef = {next = 0x0, abfd =
> 0x1680b88}, def = {next = 0x0, section = 0x1680b88, value = 1232}, i = {next =
> 0x0, link = 0x1680b88, warning = 0x4d0 <Address 0x4d0 out of bounds>}, c =
> {next = 0x0, p = 0x1680b88, size = 1232}}}, indx = -1, dynindx = -1, got =
> {refcount = 0, offset = 0, glist = 0x0, plist = 0x0}, plt = {refcount = 3,
> offset = 3, glist = 0x3, plist = 0x3}, size = 16, type = 1, other = 2,
> target_internal = 0, ref_regular = 1, def_regular = 1, ref_dynamic = 0,
> def_dynamic = 0, ref_regular_nonweak = 0, dynamic_adjusted = 0, needs_copy = 0,
> needs_plt = 0, non_elf = 0, hidden = 0, forced_local = 0, dynamic = 1, mark =
> 0, non_got_ref = 1, dynamic_def = 0, ref_dynamic_nonweak = 0,
> pointer_equality_needed = 1, unique_global = 0, dynstr_index = 0, u = {weakdef
> = 0x0, elf_hash_value = 0}, verinfo = {verdef = 0x0, vertree = 0x0}, vtable =
> 0x0}
> (gdb) p h->root.u.def.section->owner->filename
> $31 = 0x110e8c0 "saxparser.ltrans1.ltrans.o"
> (gdb) c
> Continuing.
> [Inferior 1 (process 21141) exited normally]
> (gdb)
> 
> -- 
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
Comment 5 Martin Liška 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 machine, and the problem was reached.

If it helps, I will checkout mainline bintuils and try it.

Martin
Comment 6 hubicka 2013-05-24 12:50:04 UTC
> --- 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 machine,
> and the problem was reached.
> 
> If it helps, I will checkout mainline bintuils and try it.

Yes, please checkout the mainline binutils and if the problem is there try to produce preprocessed files
to reproduce the bug.

Thanks,
Honza
Comment 7 Alan Modra 2013-05-24 14:37:29 UTC
Not preprocessed files, object files please.  If this is a linker bug, I want the inputs to the linker, including its invocation which you can see by adding -v to the g++ command line.
Comment 8 Martin Liška 2013-05-24 15:38:31 UTC
I've got a good news, mainline ld does not report the problem.

The bug could be closed.

Martin
Comment 9 hubicka 2013-05-24 15:39:49 UTC
> --- Comment #7 from Alan Modra <amodra at gmail dot com> 2013-05-24 14:37:29 UTC ---
> Not preprocessed files, object files please.  If this is a linker bug, I want
> the inputs to the linker, including its invocation which you can see by adding
> -v to the g++ command line.

Catch with object files and LTO is that they are GCC configuration specific.  But lets
try to get around with those.

Honza
Comment 10 H.J. Lu 2013-05-24 17:50:09 UTC
(In reply to Martin Liška from comment #8)
> I've got a good news, mainline ld does not report the problem.
> 
> The bug could be closed.
> 
> Martin

Can you also checkout hjl/lto/master branch at

http://git.kernel.org/cgit/linux/kernel/git/hjl/binutils.git

Thanks.
Comment 11 Martin Liška 2013-06-02 17:11:49 UTC
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/CxxObject/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/CxxObject/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/CxxObject/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/CxxObject/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
Comment 12 Martin Liška 2013-06-02 17:13:01 UTC
Created attachment 7054 [details]
Libreoffice saxparser object files
Comment 13 Martin Liška 2013-06-02 17:38:47 UTC
Test case was introduced.
Comment 14 Alan Modra 2013-06-03 00:44:09 UTC
I suspect you're picking up some older ld.  Note addition of -Wl,-v to show versions in the following:

alan@bubble:~/build/libreoffice$ B=/home/alan/build/libreoffice && O=$B/solver/unxlngx6.pro && W=$B/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 $B/libreoffice-object-files/LocaleNode.o $B/libreoffice-object-files/filewriter.o $B/libreoffice-object-files/saxparser.o -Wl,--start-group -Wl,--end-group -Wl,--no-as-needed -luno_cppu -luno_cppuhelpergcc3 -luno_sal -o $W/LinkTarget/Executable/saxparser -Wl,-v
collect2 version 4.9.0 20130522 (experimental)
/usr/local/lib/gcc/x86_64-linux/4.9.0/../../../../x86_64-linux/bin/ld -plugin /usr/local/libexec/gcc/x86_64-linux/4.9.0/liblto_plugin.so -plugin-opt=/usr/local/libexec/gcc/x86_64-linux/4.9.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccbxEkZk.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /home/alan/build/libreoffice/workdir/unxlngx6.pro/LinkTarget/Executable/saxparser /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o /usr/local/lib/gcc/x86_64-linux/4.9.0/crtbegin.o -L/home/alan/build/libreoffice/solver/unxlngx6.pro/lib -L/usr/local/lib/gcc/x86_64-linux/4.9.0 -L/usr/local/lib/gcc/x86_64-linux/4.9.0/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/local/lib/gcc/x86_64-linux/4.9.0/../../../../x86_64-linux/lib -L/usr/local/lib/gcc/x86_64-linux/4.9.0/../../.. -z origin -rpath $ORIGIN/../lib:$ORIGIN -rpath-link /home/alan/build/libreoffice/solver/unxlngx6.pro/lib -z defs -rpath-link /lib:/usr/lib -z combreloc --hash-style=gnu --dynamic-list-cpp-new --dynamic-list-cpp-typeinfo -Bsymbolic-functions -O1 -S /home/alan/build/libreoffice/libreoffice-object-files/LocaleNode.o /home/alan/build/libreoffice/libreoffice-object-files/filewriter.o /home/alan/build/libreoffice/libreoffice-object-files/saxparser.o --start-group --end-group --no-as-needed -luno_cppu -luno_cppuhelpergcc3 -luno_sal -v -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/lib/gcc/x86_64-linux/4.9.0/crtend.o /usr/lib/x86_64-linux-gnu/crtn.o
GNU ld (GNU Binutils) 2.23.52.20130524
alan@bubble:~/build/libreoffice$ 

The other possibility is that my shared libraries are masking the problem somehow.  If you are running the version of ld you think you are, please attach the following shared libs:
-luno_cppu (/home/alan/build/libreoffice/solver/unxlngx6.pro/lib/libuno_cppu.so)
-luno_cppuhelpergcc3 (/home/alan/build/libreoffice/solver/unxlngx6.pro/lib/libuno_cppuhelpergcc3.so)
-luno_sal (/home/alan/build/libreoffice/solver/unxlngx6.pro/lib/libuno_sal.so)
Comment 15 Alan Modra 2022-07-29 05:53:32 UTC
I'm not sure if this was fixed or not, but a 9 year old lto related bug is surely obsolete.