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

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-05-06 03:21 -------
Please find attached merged patch of Brian's latest with all the new features 
I've added:

-fvisibility
#pragma GCC visibility
-fvisibility-inlines-hidden

What we don't have is nested classes inheriting the visibility setting from 
their enclosing classes. ANY HELP WITH THIS MUCH APPRECIATED AS I'VE GIVEN UP - 
I simply lack the familiarity with GCC's internals.

I've left the debug printing in as it'll aid anyone trying to do the nested 
classes problem. I'll not post this to gcc-patches until I've done more tests 
here ie; building Boost.Python and my library.

Another issue is how MSVC exports inlined code. It would seem that if a class is 
dllexport, all inlineable methods have a version of them generated and its entry 
made public in the export table. If it's not dllexport, it can obviously still 
be used outside its DLL as it'll get reinstantiated where it's used. With this 
patch, this behaviour is approximately emulated such that if something is marked 
as default visibility then it'll always appear in the export table. If not and 
-fvisibility=hidden is in effect, it'll get reinstantiated where it's used. I 
think I have this right now.

A final issue is when a declaration is explicitly marked default visibility but 
is defined within the current compiland. Should calls to that symbol from within 
the current compiland skip the PLT indirection? I'm thinking probably yes, but 
if anyone can think of why not then I won't. This would be a breaking change 
with previous versions of GCC however.

I've also added a test file I use to save you writing one. Best usage is to 
output as assembler and then you can study the assembler.

Cheers,
Niall



-- 


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