[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #21 from Fangrui Song --- I made a mistake in #comment 16. In GNU ld, the rule is probably: * it is linked at least once in `--no-as-needed` mode (i.e. `--as-needed a.so --no-as-needed a.so` => needed) * or it has a definition resolving a non-weak reference by a previous input file (it works similar to archive member selection) In gold, the rule is probably: * it is linked at least once in `--no-as-needed` mode (i.e. `--as-needed a.so --no-as-needed a.so` => needed) * or it has a definition resolving a non-weak reference In LLD, a shared object is needed, if one of the following conditions is true: * it is linked at least once in `--no-as-needed` mode (i.e. `--as-needed a.so --no-as-needed a.so` => needed) * or it has a definition resolving a non-weak reference from a live section (not discarded by `--gc-sections`) Yes, the GNU ld behavior matches its documentation. But gold and LLD's behaviors are probably more useful (less reliance on position dependent behaviors - the user has more freedom moving it around on the linker command line without changing symbol resolution) and can make implementation simpler (no need to handle --as-needed shared object similar to the tricky archive member selection) # a.s call foo # b.s .globl foo foo: ret gold --as-needed b.so a.o && readelf -d a.out ... 0x0001 (NEEDED) Shared library: [b.so] -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #20 from Michael Matz --- (In reply to Cary Coutant from comment #18) > > > My understanding of when a shared object is needed: > > > > > > * it is linked at least once in --no-as-needed mode (i.e. --as-needed a.so > > > --no-as-needed a.so => needed) > > > * or it has a non-weak definition resolving a reference from a live > > > section > > > (not discarded by --gc-sections) > > > > > > I think both LLD and gold's rules are like this. > > > > Then they both have the same bug (in the second item of your list). As Alan > > explains, as-needed behaviour intends to reflect behaviour of static > > archives > > (where that applies; here any difference in behaviour doesn't seem useful). > > > > The only thing about weak definitions is that there may be validly multiple > > ones > > without error (the first one or the single non-weak definition wins). > > This contradicts the ld manual: > ... > Note where it says "that at that point in the link satisfies a *non-weak* > undefined symbol reference from a regular object file or, if the library is > not found in the DT_NEEDED lists of other needed libraries, a *non-weak* > undefined symbol reference from another needed dynamic library." (emphasis > added) Right. This describes the static archive extraction rules. It talks about (non-weak i.e. strong) references, not about (weak) definitions. Weak (and strong) definitions do satisfy strong references, and hence invoke the above rules about archive member extraction (and therefore should then also cause the same behaviour for DT_NEEDED). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 Alan Modra changed: What|Removed |Added Target Milestone|--- |2.37 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #19 from Alan Modra --- Fixed on both mainline and 2.36 branch. (In reply to Fangrui Song from comment #16) > * or it has a non-weak definition resolving a reference No, the correct formulation is: "or it has a definition resolving a non-weak reference". I was confused about this too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 Cary Coutant changed: What|Removed |Added CC||ccoutant at gmail dot com --- Comment #18 from Cary Coutant --- > > My understanding of when a shared object is needed: > > > > * it is linked at least once in --no-as-needed mode (i.e. --as-needed a.so > > --no-as-needed a.so => needed) > > * or it has a non-weak definition resolving a reference from a live section > > (not discarded by --gc-sections) > > > > I think both LLD and gold's rules are like this. > > Then they both have the same bug (in the second item of your list). As Alan > explains, as-needed behaviour intends to reflect behaviour of static archives > (where that applies; here any difference in behaviour doesn't seem useful). > > The only thing about weak definitions is that there may be validly multiple > ones > without error (the first one or the single non-weak definition wins). This contradicts the ld manual: --as-needed --no-as-needed This option affects ELF DT_NEEDED tags for dynamic libraries mentioned on the command line after the --as-needed option. Normally the linker will add a DT_NEEDED tag for each dynamic library mentioned on the command line, regardless of whether the library is actually needed or not. --as-needed causes a DT_NEEDED tag to only be emitted for a library that at that point in the link satisfies a non-weak undefined symbol reference from a regular object file or, if the library is not found in the DT_NEEDED lists of other needed libraries, a non-weak undefined symbol reference from another needed dynamic library. Object files or libraries appearing on the command line after the library in question do not affect whether the library is seen as needed. This is similar to the rules for extraction of object files from archives. --no-as-needed restores the default behaviour. Note where it says "that at that point in the link satisfies a *non-weak* undefined symbol reference from a regular object file or, if the library is not found in the DT_NEEDED lists of other needed libraries, a *non-weak* undefined symbol reference from another needed dynamic library." (emphasis added) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #17 from Michael Matz --- (In reply to Fangrui Song from comment #16) > (In reply to Alan Modra from comment #12) > > (In reply to Michael Matz from comment #11) > > > Yes, I thought so as well, until I read ELF.txt again :) > > > > Huh, I can hardly believe I was making such a completely wrong assumption. > > How stupid is that? I just checked elflink.c plus archive.c code and ran a > > test to properly convince myself I was wrong. Yes, a weak definition does > > indeed cause an archive element to be extracted to satisfy a strong > > undefined reference. > > > > Testing the binding of the definition was just plain wrong. > > My understanding of when a shared object is needed: > > * it is linked at least once in --no-as-needed mode (i.e. --as-needed a.so > --no-as-needed a.so => needed) > * or it has a non-weak definition resolving a reference from a live section > (not discarded by --gc-sections) > > I think both LLD and gold's rules are like this. Then they both have the same bug (in the second item of your list). As Alan explains, as-needed behaviour intends to reflect behaviour of static archives (where that applies; here any difference in behaviour doesn't seem useful). The only thing about weak definitions is that there may be validly multiple ones without error (the first one or the single non-weak definition wins). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #16 from Fangrui Song --- (In reply to Alan Modra from comment #12) > (In reply to Michael Matz from comment #11) > > Yes, I thought so as well, until I read ELF.txt again :) > > Huh, I can hardly believe I was making such a completely wrong assumption. > How stupid is that? I just checked elflink.c plus archive.c code and ran a > test to properly convince myself I was wrong. Yes, a weak definition does > indeed cause an archive element to be extracted to satisfy a strong > undefined reference. > > Testing the binding of the definition was just plain wrong. My understanding of when a shared object is needed: * it is linked at least once in --no-as-needed mode (i.e. --as-needed a.so --no-as-needed a.so => needed) * or it has a non-weak definition resolving a reference from a live section (not discarded by --gc-sections) I think both LLD and gold's rules are like this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #15 from cvs-commit at gcc dot gnu.org --- The binutils-2_36-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e3316baf921523e884731f5c7b547bc9362039e5 commit e3316baf921523e884731f5c7b547bc9362039e5 Author: Alan Modra Date: Wed Feb 24 18:01:16 2021 +1030 PR27441, inconsistency in weak definitions This makes IR objects use the same logic as normal objects with respect to what sort of ref/def makes an as-needed library needed. Testing the binding of the definition is just plain wrong. What matters is the binding of the reference. PR 27441 * elf-bfd.h (struct elf_link_hash_entry): Add ref_ir_nonweak. * elflink.c (elf_link_add_object_symbols): Set ref_ir_nonweak and use when deciding an as-needed library should be loaded instead of using the binding of the library definition. (cherry picked from commit bbaddd4bbeba65200ee805d87c2e3a845842e3eb) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #14 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bfece7562d62f11782ca7089310b4063be526fb2 commit bfece7562d62f11782ca7089310b4063be526fb2 Author: Alan Modra Date: Fri Feb 26 13:26:19 2021 +1030 Add PR27441 testcase PR 27441 * testsuite/ld-plugin/pr27441a.c, * testsuite/ld-plugin/pr27441b.c, * testsuite/ld-plugin/pr27441c.c, * testsuite/ld-plugin/pr27441c.d: New test. * testsuite/ld-plugin/lto.exp: Run it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #13 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bbaddd4bbeba65200ee805d87c2e3a845842e3eb commit bbaddd4bbeba65200ee805d87c2e3a845842e3eb Author: Alan Modra Date: Wed Feb 24 18:01:16 2021 +1030 PR27441, inconsistency in weak definitions This makes IR objects use the same logic as normal objects with respect to what sort of ref/def makes an as-needed library needed. Testing the binding of the definition is just plain wrong. What matters is the binding of the reference. PR 27441 * elf-bfd.h (struct elf_link_hash_entry): Add ref_ir_nonweak. * elflink.c (elf_link_add_object_symbols): Set ref_ir_nonweak and use when deciding an as-needed library should be loaded instead of using the binding of the library definition. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #12 from Alan Modra --- (In reply to Michael Matz from comment #11) > Yes, I thought so as well, until I read ELF.txt again :) Huh, I can hardly believe I was making such a completely wrong assumption. How stupid is that? I just checked elflink.c plus archive.c code and ran a test to properly convince myself I was wrong. Yes, a weak definition does indeed cause an archive element to be extracted to satisfy a strong undefined reference. Testing the binding of the definition was just plain wrong. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #11 from Michael Matz --- (In reply to Alan Modra from comment #8) > (In reply to Michael Matz from comment #3) > > % gcc -fPIC -Wl,--as-needed -fno-lto -shared -o good.so bad4.c -L. -l2 -l1 > > % readelf-dW good.so | grep lib > > 0x0001 (NEEDED) Shared library: [lib2.so] > > 0x0001 (NEEDED) Shared library: [lib1.so] > > I'd actually like to fix the above to *not* have DT_NEEDED lib2.so. The > reason is that as-needed was supposed to be modeled on the way archive > entries are treated, and if you were using static libraries you'd find the > weak func1 in lib2.a would not be enough to cause lib2.o to be extracted.. Yes, I thought so as well, until I read ELF.txt again :) : * When the link editor searches archive libraries, it extracts archive members that contain definitions of undefined global symbols. The member's definition may be either a global or a weak symbol. The link editor does not extract archive members to resolve undefined weak symbols. Unresolved weak symbols have a zero value. "may be either a global or a weak symbol". It's weak undefs that don't cause things to be pulled in, but a strong ref should pull in a weak def. Independend of that I considered the current (non-LTO) behaviour more useful. > Unfortunately I can't do that, libm.so.6 for instance is full of weak > dynamic symbols. (huh, I never noticed that; indeed) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #10 from Alan Modra --- Created attachment 13259 --> https://sourceware.org/bugzilla/attachment.cgi?id=13259=edit patch under test -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener --- Note with -flto it is difficult to argue about the order of "source" objects and library references with -l, say you'd have gcc t.c -lpthread t2.c -flto gcc can then, via -flto, happily produce only a single "real" ltrans object. Of course via the plugin it should get the original refs of t.c and t2.c in the correct order but my understanding is that BFD re-scans objects (because GCC is also prone to introduce new refs, for example to memcpy, libm functions or libgcc provided functions). But "placement" of the generated ltrans object on the linker command-line is not well-defined since the plugin merely provides LD with extra objects it should link. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |amodra at gmail dot com --- Comment #8 from Alan Modra --- (In reply to Michael Matz from comment #3) > % gcc -fPIC -Wl,--as-needed -fno-lto -shared -o good.so bad4.c -L. -l2 -l1 > % readelf-dW good.so | grep lib > 0x0001 (NEEDED) Shared library: [lib2.so] > 0x0001 (NEEDED) Shared library: [lib1.so] I'd actually like to fix the above to *not* have DT_NEEDED lib2.so. The reason is that as-needed was supposed to be modeled on the way archive entries are treated, and if you were using static libraries you'd find the weak func1 in lib2.a would not be enough to cause lib2.o to be extracted.. Unfortunately I can't do that, libm.so.6 for instance is full of weak dynamic symbols. So for as-needed shared libraries we instead say the library is needed whenever a non-weak undefined reference is satisfied by the library regardless of whether the definition is strong or weak. I guess I need to do the same for plugins. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-23 Status|UNCONFIRMED |NEW --- Comment #7 from H.J. Lu --- Please try users/hjl/pr26530/master branch: https://gitlab.com/x86-binutils/binutils-gdb/-/commits/users/hjl/pr26530/master -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #6 from Michael Matz --- Probably just one more corner case (the last one!) ;-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #5 from Martin Liska --- The issue started with: commit b1a92c635c1ec10fd703302ce1fc4ab3a8515a04 Author: Alan Modra Date: Fri Oct 30 14:56:35 2020 +1030 PR26806, Suspected linker bug with LTO This patch reverts most of git commit 1e3b96fd6cf, so IR symbols are again not marked def_regular or ref_regular. That should be enough to stop IR symbols from becoming dynamic. To mark as-needed shared libraries referenced by IR symbols, use the referencing BFD rather than the ref flags. bfd/ PR 15146 PR 26314 PR 26530 PR 26806 * elflink.c (elf_link_add_object_symbols): Don't set def/ref flags for plugin syms. Do allow plugin syms to mark as-needed libs. ld/ PR 26806 * testsuite/ld-plugin/lto-19.h, * testsuite/ld-plugin/lto-19a.c, * testsuite/ld-plugin/lto-19b.c, * testsuite/ld-plugin/lto-19c.c: New test. * testsuite/ld-plugin/pr26806.c, * testsuite/ld-plugin/pr26806.d: New test. * testsuite/ld-plugin/lto.exp: Run them. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 --- Comment #4 from Michael Matz --- (I've now verified that it doesn't happen with older binutils (2.26 :) ) but does with 2.36, with otherwise same toolchain (some random gcc-9 compiler), so it's not any gcc component) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441
Michael Matz changed:
What|Removed |Added
Assignee|ccoutant at gmail dot com |unassigned at
sourceware dot org
Component|gold|ld
--- Comment #3 from Michael Matz ---
So, like this:
% cat lib1.c
int func1(void) { return 1; }
int func2(void) { return 2; }
% cat lib2.c
int __attribute__((weak)) func1(void) { return 3; }
% cat bad4.c
extern int func1(void);
extern int func2(void);
int callthem(void)
{
return func1() + func2();
}
% gcc -fPIC -shared -o lib1.so lib1.c
% gcc -fPIC -shared -o lib2.so lib2.c
% gcc -fPIC -Wl,--as-needed -fno-lto -shared -o good.so bad4.c -L. -l2 -l1
% readelf-dW good.so | grep lib
0x0001 (NEEDED) Shared library: [lib2.so]
0x0001 (NEEDED) Shared library: [lib1.so]
% gcc -fPIC -Wl,--as-needed -flto -shared -o bad.so bad4.c -L. -l2 -l1
% readelf -dW bad.so | grep lib
0x0001 (NEEDED) Shared library: [lib1.so]
(I'm resetting component to ld again, as I think the above shows the problem
clearly enough. It's still possible that it's the gcc LTO plugin at fault,
though)
--
You are receiving this mail because:
You are on the CC list for the bug.
