[Bug other/15000] Support setting the default symbol visibility for ELF

["s_gccbugzilla at nedprod dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-04-22 18:16 -------
(In reply to comment #15)
> > Regarding your problem, I personally feel marking internal classes as hidden 
> > explicitly is a good idea.
> 
> In my case all of the public classes are already marked as exported (for
> dllexport on msvc++).  Why should I then have to also mark all of my internal
> classes (which in my case, vastly outnumber the public classes) as hidden? 

Because Windows and Unix behave fundamentally differently in how they implement 
shared libraries. Under Windows everything is default hidden unless specified 
otherwise. Under Unix it's the opposite. Good design demands you always specify 
when something is different to the default eg; you use public: when in a class 
or private: in a struct to change from the default. C++ is particularly bad for 
making you have to type more code to make better quality code.

Remember, you don't HAVE to specify all your internal classes as hidden. The DSO 
will work perfectly fine if you don't, however it will be suboptimal.

> It uglifies the source as well (though not nearly as much once bug 9283 lands)

It's not that bad. I know of no source which actually uses __declspec directly 
in the code, it's always via a macro. Similarly here DLLEXPORT and DLLPRIVATE 
are reasonable pseudonyms for that long __attribute__ spec. This I think 
actually aids readability, improves the interface contract and generally is a 
good thing (TM).

> The difference, of course, is that in the system headers on Windows, all of 
the
> functions exported by system libraries are explicitly marked dllexport.  If 
all
> of the system headers on Linux marked exported functions as default visbility,
> we could go ahead and give the default visibility to all declarations that 
don't
> override it.  But as I said earlier, I think getting library authors to do 
this
> will be difficult.

glibc I think already does the right thing here, but yes you're right, we have 
bad precedent against us. I think the people who originally implemented DSO's on 
Linux screwed up by failing to do the right thing (and insisting on 
non-compatibility with Solaris etc.). Windows has it correct here, and Unix is 
wrong - simple as that. However, things are as they are, so we forge ahead.
 
> > easy. What do you think?
> 
> I think given gcc's trend towards removing use of #pragma there could be some
> opposition to that approach.  However, I think it could be useful especially 
for
> C, where there is no way to wrap up a bunch of functions together and mark 
them
> hidden.  Headers which declare non-public functions could simply wrap them:
> 
> #pragma visibility hidden
> void internal_function (...);
> ...
> #pragma visibility default

There is only (valid) opposition because you can't form #pragma's in 
preprocessor magic. However I would have thought the same engine works behind 
#pragma as behind that pragma statement replacement (I forget the details) so it 
still kills both birds with one stone.

Apart from the issue regarding how to mark internal classes as hidden to remove 
the PLT overhead, are we in complete agreement about the form of this patch? Is 
your new patch and its use of the type decl instead of the class stack to store 
visibility a better solution here? I would have thought it makes things unclear 
for GCC maintainers as the symbol visibility is no longer stored with the symbol 
but rather with that symbol's type info which might cause some to get confused 
with the type info's visibility rather than that of which it describes?

Can you tell me what Jason Merrill's argument for storing it within the type 
decl instead was?

Cheers,
Niall


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15000