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

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

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-04-22 20:19 -------
(In reply to comment #17)
> > Is 
> > your new patch and its use of the type decl instead of the class stack to 
store 
> > visibility a better solution here? 
> 
> I think the reasoning is just that we already have an appropriate place to 
store
> this information, so why invent something new.  Note that the attribute stored
> on the type decl is basically used the same way that DECL_VISIBILITYSPECIFIED 
is
> in your patch.  DECL_VISIBILITY is still used for determining the actual
> visibility of a symbol.  Also, the 'overrides' thing requires a linear search 
of
> the overrides list every time you assign symbol visibility, so why not just do 
a
> linear search of the attributes list of the decl instead.  There's something 
to
> be said for simplicity as well, and the second patch is certainly much shorter
> than the original.

Sounds spot on to me. I'll remake my patch based on your new one. This may 
happen tonight, depending on other factors.

> Could you please elaborate on your changes related to inline and virtual 
functions?

Yes. As Dave Abrahams pointed out in that link I posted previously, we must 
ensure that setting class member visibility follows the same semantics as MSVC 
or nasty problems creep in (and he should certainly know, he's an extremely 
capable programmer). To my knowledge, MSVC treats inlineable code as a 
non-external symbol because it assumes it'll be assembled at the point of use - 
therefore almost all templated code won't appear in the DLL's export table. This 
implies that instantiations of templates have one per DLL and that 
instantiations are not shared across DLL's. The exception to this obviously is 
virtual methods in templates as these *must* be shared across DLL boundaries to 
work correctly - though having just said that, I don't actually know if MSVC 
does this or not - I'll have to come up with a test.

I've followed this behaviour in my patch for GCC. It also comes with the 
significant benefit of totally removing all template generated symbols from the 
export table when compiled with -fvisibility=hidden which as template generated 
symbols tend to be very long, it very substantially reduces binary size and load 
times. The amazing thing is that the mangled symbol usually takes up more space 
than the code it represents so this is actually an optimisation!

All this said, my understanding of how inlining works in MSVC as against GCC may 
be imperfect so I suggest running the patch past Dave before committing. I need 
to remove a warning generated when Boost.Python is compiled with visibility 
support patched in just to give it a real professional air! :)

Are you happy with the pragma idea? Shall I implement that in the next patch?

Cheers,
Niall


-- 


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