This is the mail archive of the
mailing list for the GCC project.
Re: gcc visibility used by moz
First of all, thank you for "seeing" the problem I was trying to
Geoffrey Keating <firstname.lastname@example.org> writes:
| Joe Buck <Joe.Buck@synopsys.COM> writes:
| > I wrote [for two classes S with visibility == hidden ]
| > > | > | We can have two distinct
| > > | > | classes named S, and no one can tell. Each bit of code will see one
| > > | > | definition of S.
| > Jason Merrill <email@example.com> writes:
| > > | I think that Joe's point is that IF you have two classes named S, then
| > > | they're hidden away in separate shared libraries and you can't compare
| > > | them, because no piece of code knows about both of them.
| > Yes. It is sometimes necessary with very large software systems to
| > use tricks like this because someone was sloppy about naming (particularly
| > in older code that comes from times before namespaces were universally
| > available, and many of us do have to deal with 7-10 year old code on
| > occasion).
| I don't think you can say 'no piece of code knows about both of them'.
| What you can say is that these two classes are both named S but
| they're different, just as if they were in different namespaces.
That would mirror how C++ handles classes in unnamed namspaces. In
other words, the visibility would have to be part of the mangled name.
| > On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
| > > I'm not clear about "you can't compare them".
| > >
| > > Surely, I can take the address of typeid(S) and pass it around to
| > > a function in another translation unit. I can do
| > > typeinfo1->before(*typeinfo2), where typeinfo1 and typeinfo2 comes
| > > from two such different translation units.
| > >
| > > How the current visibility framework prevent that from happening?
| > By a note in the documentation telling the user "don't do that".
| No, there's no such note. The answer is that the two typeids have
| different addresses, so one will be before the other, depending on
| where the shared libraries got loaded, just as if the classes had
| different names.
In the case where __GXX_MERGED_TYPEINFO_NAMES is not defined, that
would not be true. Because the current definition of
type_info::before uses a strcmp() on their mangled name.
To make the implementation correct, the mangled name need to
incorporate the visibility attribute.
And even where __GXX_MERGED_TYPEINFO_NAMES is defined, it appears to
me that it is also a Good Thing to incorporate the visibility in the
mangled name so that the result of before() becomes deterministic and
does not depend on the order of loading of shared libraries.