[Bug ld/26978] Inconsistency for defined foo@v1 and foo@@v1
https://sourceware.org/bugzilla/show_bug.cgi?id=26978 --- Comment #12 from Sourceware Commits --- The binutils-2_42-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6224493e457e72b11818c87cdc112bdb0fee5f81 commit 6224493e457e72b11818c87cdc112bdb0fee5f81 Author: Alan Modra Date: Mon Apr 8 08:16:20 2024 +0930 Re: PR26978, Inconsistency for strong foo@v1 and weak foo@@v1 Commit 726d7d1ecf opened a hole that allowed a u.i.link loop to be created, resulting in _bfd_generic_link_add_one_symbol never returning. Fix that. Note that the MIND case handles two types of redefinition. For a new indirect symbol we'll have string non-NULL. For a new def, string will be NULL. So moving the string comparison earlier would work. However, we've already looked up inh in the first case so can dispense with name comparisons. Either way, for a new def we'll get to the defweak test and possibly cycle. Which is what we want here. PR 31615 PR 26978 * linker.c (_bfd_generic_link_add_one_symbol ): Test for exactly matching indirect symbols before cycling on a defweak. (cherry picked from commit 248b6326a49ed49e2f627d3bddbac514a074bac0) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26978] Inconsistency for defined foo@v1 and foo@@v1
https://sourceware.org/bugzilla/show_bug.cgi?id=26978 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26978] Inconsistency for defined foo@v1 and foo@@v1
https://sourceware.org/bugzilla/show_bug.cgi?id=26978 --- Comment #11 from Sourceware Commits --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=248b6326a49ed49e2f627d3bddbac514a074bac0 commit 248b6326a49ed49e2f627d3bddbac514a074bac0 Author: Alan Modra Date: Mon Apr 8 08:16:20 2024 +0930 Re: PR26978, Inconsistency for strong foo@v1 and weak foo@@v1 Commit 726d7d1ecf opened a hole that allowed a u.i.link loop to be created, resulting in _bfd_generic_link_add_one_symbol never returning. Fix that. Note that the MIND case handles two types of redefinition. For a new indirect symbol we'll have string non-NULL. For a new def, string will be NULL. So moving the string comparison earlier would work. However, we've already looked up inh in the first case so can dispense with name comparisons. Either way, for a new def we'll get to the defweak test and possibly cycle. Which is what we want here. PR 31615 PR 26978 * linker.c (_bfd_generic_link_add_one_symbol ): Test for exactly matching indirect symbols before cycling on a defweak. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26978] Inconsistency for defined foo@v1 and foo@@v1
https://sourceware.org/bugzilla/show_bug.cgi?id=26978 --- Comment #10 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=b05929a20efa7caa40415d2f069e44f7e76615e4 commit b05929a20efa7caa40415d2f069e44f7e76615e4 Author: Alan Modra Date: Thu Aug 26 12:19:35 2021 +0930 PR28264, ld.bfd crash on linking efivar with LTO PR 28264 PR 26978 * linker.c (_bfd_generic_link_add_one_symbol ): Check that string is non-NULL. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26978] Inconsistency for defined foo@v1 and foo@@v1
https://sourceware.org/bugzilla/show_bug.cgi?id=26978 H.J. Lu changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=28264 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26978] Inconsistency for defined foo@v1 and foo@@v1
https://sourceware.org/bugzilla/show_bug.cgi?id=26978 Alan Modra changed: What|Removed |Added Target Milestone|--- |2.36 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Alan Modra --- Fixed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26978] Inconsistency for defined foo@v1 and foo@@v1
https://sourceware.org/bugzilla/show_bug.cgi?id=26978 --- Comment #8 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=726d7d1ecfd1fc0966983e1d5e59b527b90cf7c5 commit 726d7d1ecfd1fc0966983e1d5e59b527b90cf7c5 Author: Alan Modra Date: Wed Dec 2 13:03:23 2020 +1030 PR26978, Inconsistency for strong foo@v1 and weak foo@@v1 Prior to this patch ld -shared --version-script=pr26979.ver pr26978a.o pr26978b.o results in ld: pr26978b.o: in function `foo_v1': (.text+0x0): multiple definition of `foo@v1' ld: pr26978b.o:(*IND*+0x0): multiple definition of `foo' while ld -shared --version-script=pr26979.ver pr26978b.o pr26978a.o results in no error, but some odd dynamic symbols. ... 0 NOTYPE GLOBAL DEFAULT7 foo@v1 ... 0 NOTYPE WEAK DEFAULT7 foo@@v1 When linking an undecorated reference to foo against such a shared library, ld complains about multiple definitions of foo@v1 while gold creates a dynamic reference to foo@v1. That results in foo@v1 being used at runtime. While we could error in both cases, it is reasonable to say foo@v1 and foo@@v1 are in fact the same symbol. (Same name, same version. The only real difference is that foo@@v1 satisfies a reference to plain foo, while foo@v1 does not.) Just as merging a weak undecorated sym with a strong sym results in the strong sym prevailing, so should the strong foo@v1 prevail. And since there is a definition that satisfies plain foo, the foo@@v1 variety of dynamic symbol should be emitted at the foo@v1 value. That makes the testcase that currently links continue to produce a shared library, and that shared library can now be used by both ld and gold with the same runtime behaviour as when using gold with the odd dynamic symbol library. bfd/ PR 26978 * elflink.c (_bfd_elf_add_default_symbol): Handle the case where a new weak sym@@ver should be overridden by an existing sym@ver. (elf_link_add_object_symbols): Don't _bfd_elf_add_default_symbol for a new weak sym@ver when sym@@ver already exists. * linker.c (link_action): Choose MIND for previous indirect, current def, rather than MDEF. (_bfd_generic_link_add_one_symbol ): Handle redefinition of weak indirect symbol. ld/ * testsuite/ld-elf/pr26978a.d, * testsuite/ld-elf/pr26978a.s, * testsuite/ld-elf/pr26978b.d, * testsuite/ld-elf/pr26978b.s: New tests. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26978] Inconsistency for defined foo@v1 and foo@@v1
https://sourceware.org/bugzilla/show_bug.cgi?id=26978 --- Comment #7 from H.J. Lu --- A patch is posted at https://sourceware.org/pipermail/binutils/2020-December/114357.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26978] Inconsistency for defined foo@v1 and foo@@v1
https://sourceware.org/bugzilla/show_bug.cgi?id=26978 --- Comment #6 from H.J. Lu --- (In reply to Alan Modra from comment #4) > I do think we have a problem here. > > ld.bfd -shared --version-script=ver hid1.o def1w.o > and > ld.bfd -shared --version-script=ver def1w.o hid1.o > > ought to give the same results. Both should fail to link. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26978] Inconsistency for defined foo@v1 and foo@@v1
https://sourceware.org/bugzilla/show_bug.cgi?id=26978 --- Comment #5 from Alan Modra --- Created attachment 13019 --> https://sourceware.org/bugzilla/attachment.cgi?id=13019=edit patch under test -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26978] Inconsistency for defined foo@v1 and foo@@v1
https://sourceware.org/bugzilla/show_bug.cgi?id=26978 Alan Modra changed: What|Removed |Added Status|REOPENED|ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26978] Inconsistency for defined foo@v1 and foo@@v1
https://sourceware.org/bugzilla/show_bug.cgi?id=26978 Alan Modra changed: What|Removed |Added Last reconfirmed||2020-12-02 Status|RESOLVED|REOPENED Assignee|unassigned at sourceware dot org |amodra at gmail dot com Resolution|NOTABUG |--- Ever confirmed|0 |1 --- Comment #4 from Alan Modra --- I do think we have a problem here. ld.bfd -shared --version-script=ver hid1.o def1w.o and ld.bfd -shared --version-script=ver def1w.o hid1.o ought to give the same results. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26978] Inconsistency for defined foo@v1 and foo@@v1
https://sourceware.org/bugzilla/show_bug.cgi?id=26978 --- Comment #3 from H.J. Lu --- (In reply to Fangrui Song from comment #2) > > Correct behavior. Otherwise, we will get > > This is a surprising behavior. Normally, STB_GLOBAL wins over STB_WEAK. Did > you argue that in the case of @ and @@ definitions, the rule "@@ wins over > @" taking precedence? > > I would think the two bits are independent. global foo@v1 + weak foo@@v1 => > global foo@@v1. If we allow this to link, weak foo@@v1 will be in .dynsym which overrides the non-weak foo@v1. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26978] Inconsistency for defined foo@v1 and foo@@v1
https://sourceware.org/bugzilla/show_bug.cgi?id=26978 Fangrui Song changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #2 from Fangrui Song --- > Correct behavior. Otherwise, we will get This is a surprising behavior. Normally, STB_GLOBAL wins over STB_WEAK. Did you argue that in the case of @ and @@ definitions, the rule "@@ wins over @" taking precedence? I would think the two bits are independent. global foo@v1 + weak foo@@v1 => global foo@@v1. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26978] Inconsistency for defined foo@v1 and foo@@v1
https://sourceware.org/bugzilla/show_bug.cgi?id=26978 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com Resolution|--- |NOTABUG Status|UNCONFIRMED |RESOLVED --- Comment #1 from H.J. Lu --- (In reply to Fangrui Song from comment #0) > > % ld.bfd -shared --version-script=ver def1.o hid1.o > ld.bfd: hid1.o: in function `foo_v1': > (.text+0x0): multiple definition of `foo@@v1'; def1.o:(.text+0x0): first > defined here > % ld.bfd -shared --version-script=ver def1w.o hid1.o > ld.bfd: hid1.o: in function `foo_v1': > (.text+0x0): multiple definition of `foo@v1' > ld.bfd: hid1.o:(*IND*+0x0): multiple definition of `foo' Correct behavior. Otherwise, we will get Symbol table '.dynsym' contains 4 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 1000 0 NOTYPE WEAK DEFAULT7 foo@@v1 2: 1002 0 NOTYPE GLOBAL DEFAULT7 foo_v1 3: 0 OBJECT GLOBAL DEFAULT ABS v1 and the weak foo@@v1 overrides the non-weak foo@v1. -- You are receiving this mail because: You are on the CC list for the bug.
