https://sourceware.org/bugzilla/show_bug.cgi?id=25295
--- Comment #12 from Fangrui Song <i at maskray dot me> --- (In reply to H.J. Lu from comment #11) > (In reply to Fangrui Song from comment #10) > > Thanks for CCing me. I'm interested on this topic. > > > > I expressed my feelings on > > https://sourceware.org/pipermail/binutils/2019-November/108784.html > > and https://sourceware.org/bugzilla/show_bug.cgi?id=23840 > > > > My idea is that we should treat `.symver foo, bar@V1` as "renaming foo to > > bar@V1" ( > > https://reviews.llvm.org/rL369233; This should be the same as Comment #3), > > just like what we do with the 3-@ variant `.symver foo, bar@@@V1` > > > > https://sourceware.org/pipermail/binutils/2019-November/108784.html(In reply > > to H.J. Lu from comment #8) > > > (In reply to hubicka from comment #5) > > > > > Where do you see "export foo and foo@VERS_1"? All I see is that the > > > > > alias gets > > > > > the same attributes as the original symbol, thus it will be external > > > > > iff the > > > > > original symbol is. > > > > Yes, but I want to implement only foo@VERS_1 in the unit, not foo, so I > > > > do not want to see foo in the symbol table, just foo@VERS_1 and this > > > > does not seem to be possible with current .symver > > > > (there is @@@ vairant that does that for default defs) > > > > > > > > Honza > > > > > > How abou > > > > > > .symver foo, foo@VERS_1, hidden > > > > > > It will mark foo as hidden. > > > > I would hope we just rename the symbol (i.e. drop foo). > > Rename won't work with: > > .symver foo, bar@V1 > .symver foo, baz@V2 This just means we cannot reuse `foo`. Each non-default version requires a fresh dummy name, e.g. .symver foo_V1, bar@V1 .symver foo_V2, bar@V2 The rename is postponed to a very late state. Very few (probably only 2) pieces of software actually depend on the behavior that the original name exists in the object file. -- You are receiving this mail because: You are on the CC list for the bug.
