Re: gcc visibility used by moz

[Geoffrey Keating]

On 14/07/2006, at 3:01 PM, Gabriel Dos Reis wrote:

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

Geoffrey Keating <[EMAIL PROTECTED]> writes:

| Joe Buck <[EMAIL PROTECTED]> writes:
|
| > I wrote [for two classes S with visibility == hidden ]
| > > | > | We can have two distinct

| > > | > | definition of S.
| >
| > Jason Merrill <[EMAIL PROTECTED]> writes:

| > > | them, because no piece of code knows about both of them.
| >

| > occasion).
|

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

| > > | > | classes named S, and no one can tell. Each bit of code will see one | > > | 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 | > 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 | I don't think you can say 'no piece of code knows about both of them'.

Well, yes and no. Actually, what I'd like C++ to do is to not have the mangled name for an anonymous namespace object contain the random string it currently contains. I think Jason's changes now let me do this!

| > On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
| > > I'm not clear about "you can't compare them".
| > >

| > > a function in another translation unit.  I can do

| > > from two such different translation units.
| > >

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

| > > Surely, I can take the address of typeid(S) and pass it around to | > > typeinfo1->before(*typeinfo2), where typeinfo1 and typeinfo2 comes | > > How the current visibility framework prevent that from happening?

I'm not sure what you mean by the 'visibility attribute'. I think that to make this work, you would need to have the mangled name contain a unique identifier (perhaps its load address) for the shared object instance in question, just as for anonymous namespace names we have the name contain a unique identifier for the translation unit in question. However, getting this unique identifier is going to be a little tricky. You can't do it at compile time (since this .o file might be in more than one shared object) or at link time (since this shared library might be loaded more than once, for instance using dlopen ()). So it has to be set up at load time. So we're talking about strings in writable memory, linker and assembler and compiler changes to generate the relocations, binary incompatibility... It seems like it would be just as easy to implement weak symbols and then have __GXX_MERGED_TYPEINFO_NAMES to be defined. I don't believe there's any platform yet which has visibility but not weak symbols, so this is not a problem that needs to be solved at the moment.

smime.p7s
Description: S/MIME cryptographic signature