Re: gcc visibility used by moz

[Tristan Wibberley <maihem at maihem dot org>]

Gabriel Dos Reis wrote:
> Joe Buck <Joe.Buck@synopsys.COM> writes:
>
> | On Thu, Jul 13, 2006 at 01:36:46AM +0200, Gabriel Dos Reis wrote:
> | > 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?
> | 
> | Well, there are the C++ rules, and then there are the ELF rules.  At the
> | object code level we have only symbol definitions (corresponding to
> | the addresses of member functions, virtual tables, and typeinfo). If
> | the relevant symbols are hidden, then it's as if they aren't there, so
> | we can violate the one-definition rule. 
>
> Thanks.  So both notions are not as orthogonal as they may appear.
> Now, this being a conscious decision for ODR violation, it would
> probably need to be documented because then we may have
>
>    typeinfo1 != typeinfo2
>
> and yet
>
>     !typeinfo1.before(typeinfo2) && !typeinfo2.before(typeinfo1)
>
> There are probably other inconsistencies to audit.
>
> | We can have two distinct
> | classes named S, and no one can tell.  Each bit of code will see one
> | definition of S.


But I think it is important that there are three places where visibility 
is a factor (as a concept of "being able to see things" rather than the 
attribute).


1) If a class definition is not present in a given translation unit, but 
a class declaration is, then the translation unit may normally pass 
around a pointer to an instance of that class and also a reference to an 
instance of that class, but may not do anything else with it.

2) Until now, the visibility attribute was used for optimising symbols 
exported from a .so for when things will only be used within that .so 
(but used across its constituent .o files). Saving unnecessary runtime 
costs and non-volatile storage costs. This is really valuable and I'd 
like to see it remain available.

The last is the interesting case, which it seems 2) has broken while 
this was being worked on.

3) For file scope functions and file scope variables, the static keyword 
is overloaded to indicate that their definition should be created for 
this translation unit such that it is a unique function or variable even 
if other functions or variables use the same name in both translation 
units. I can see that something could be desirable to define classes 
just for the internal behaviour of a translation unit without having to 
consider name conflict, but the unnamed namespace should do that 
shouldn't it? Which also satisfies the ODR since each unnamed namespace 
in separate translation units is a different one.

It kind of makes sense to hide functions that take arguments or return 
pointers to types in the translation unit unnamed namespace (but that is 
so easy for the programmer to cause just by putting the prototype into 
the unnamed namespace that its not worth doing anything fancy other than 
warning since they may be trying to do some clever multi-language 
interoperability thing.


--
Tristan Wibberley

These opinions are my own, and do not reflect those of my employer.