Re: gcc visibility used by moz

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Geoffrey Keating <geoffk@apple.com> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| > Jason Merrill <jason@redhat.com> writes:
| > 
| > [...]
| > 
| > | > | - I don't recall suggesting that
| > | > | multiple types with the same name should be able to exist.
| > | > then you have to consider that suggestion and come with an answer.
| > | 
| > | I don't see why.  The point is that visibility is orthogonal to
| > | linkage; a class S with external linkage is still required by the ODR
| > | to be unique across multiple shared objects even if some of the
| > | symbols that refer to it can't be referenced from outside their
| > | defining object.  The visibility restrictions place practical limits
| > | on how other objects can use the type, but that doesn't mean it isn't
| > | the same type.
| > 
| > So, -concretely- what happens to a class S (e.g. associated type info object
| > address, address of member functions, etc.) with external linkage,
| > defined in multiple translation units, with say hidden visibility?
| 
| Under the current definition, this is impossible.  If you have a class
| S defined in one object with hidden visibility, and you try to define
| it in a different object, you get a different class named S, just as if
| you'd defined it in a different namespace or similar.
| 
| Thus, the type info objects are different, the member functions have
| different addresses, and so on.
| 
| This is achived by giving the various pieces hidden visibility.

On platfoms where __GXX_MERGED_TYPEINFO_NAMES is not defined, before()
is defined in terms of the mangled names of the types.  I'm unable to
find the mangled names are different.

-- Gaby