This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc visibility used by moz

First of all, thank you for "seeing" the problem I was trying to

Geoffrey Keating <> 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 <> 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.

-- Gaby

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]