This is the mail archive of the
mailing list for the GCC project.
Re: gcc visibility used by moz
Geoffrey Keating <firstname.lastname@example.org> writes:
| Gabriel Dos Reis <email@example.com> writes:
| > Jason Merrill <firstname.lastname@example.org> 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.