.hidden for _ZTS.*? (was Re: RFC: .gnu.linkonce.* and shared libraries)

[Jakub Jelinek <jakub at redhat dot com>]

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