This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug other/15000] Support setting the default symbol visibility for ELF
- From: "s_gccbugzilla at nedprod dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 22 Apr 2004 18:16:52 -0000
- Subject: [Bug other/15000] Support setting the default symbol visibility for ELF
- References: <20040418032536.15000.bryner@brianryner.com>
- Reply-to: 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