This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
.hidden for _ZTS.*? (was Re: RFC: .gnu.linkonce.* and shared libraries)
On Thu, Jul 12, 2001 at 12:35:22AM +0100, Jason Merrill wrote:
> >>>>> "Jakub" == Jakub Jelinek <jakub@redhat.com> writes:
>
> > On Wed, Jul 11, 2001 at 02:11:06PM -0700, Ian Lance Taylor wrote:
> >> Jakub Jelinek <jakub@redhat.com> writes:
> >>
> >> > I perhaps have not written it clearly.
> >> > All of 1)-4) would be done in the static linker, not dynamic linker.
> >>
> >> Sorry, I misunderstood.
> >>
> >> The only relevant issue then is that your scheme is robust in the face
> >> of running against a dynamic library which is not the specific one
> >> which was linked against.
>
> > That's why the compiler/programmer has to ask for it explicitely.
> > As far as I understand C++, having e.g. different vtables in a program would
> > make it non-conforming.
>
> Considering the entire program, perhaps. The problem comes when the stuff
> in .gnu.linkonce.foo is not part of the intended API of the library, but a
> side effect of the implementation. If the implementation changes (say, to
> use list<T> instead of vector<T>), the instantiations present in the
> library change, so if the linker had decided the executable could just use
> the vector<int> code in the library things break.
Bad. It would be good if C++ libraries clearly marked what they consider
exported interface and what not.
Anyway, I killed some conflicts at least by using knowledge about C++
virtual tables and typeinfo stuff (mainly that they are only referenced by
the associated _ZTV resp. _ZTI symbol, there is nothing like:
.weak _ZTV1B
.section .gnu.linkonce.d._ZTV1B,"aw",@progbits
.align 8
.type _ZTV1B,@object
.size _ZTV1B,16
_ZTV1B:
.L257: # <- This cannot happen
.long 0
.long _ZTI1B
.long _ZN1BD1Ev
.L258: # <- Neither this
.long _ZN1BD0Ev
). That means I can kill conflicts for virtual tables/typeinfo which will
not be referenced anyway, because there is a conflict for the containing
_ZTV resp. _ZTI symbol too.
Now, related question:
Shouldn't G++ 3.0+ emit
.weak _ZTS1A
.hidden _ZTS1A # <- This
.section .gnu.linkonce.r._ZTS1A,"a",@progbits
.type _ZTS1A,@object
.size _ZTS1A,3
_ZTS1A:
.string "1A"
?
>From my reading of rtti and
http://reality.sgi.com/dehnert_engr/cxx/abi.html#vague (5.2.4)
a _ZTS.* object is only ever referenced from the corresponding _ZTI object.
But that means _ZTS comes always with _ZTI together, so if symbol lookup
from _ZTI winds in ELF object XYZ, symbol oookup for _ZTS will wind that
too. So, if _ZTS.* are STV_HIDDEN inside of each objects, it should have no
influence on program behaviour and should save quite a few
a) relocations
b) symbol lookups
c) DYNSYM symbols
If you agree, I'll try to cook up a patch...
Jakub