gcc-patches@gcc.gnu.org
[Top] [All Lists]

Re: PATCH: Add -fsystem-header-visibility=

Subject: Re: PATCH: Add -fsystem-header-visibility=
From: Geoff Keating
Date: Fri, 26 Aug 2005 14:24:36 -0700

On 26/08/2005, at 1:47 PM, H. J. Lu wrote:

On Fri, Aug 26, 2005 at 01:34:04PM -0700, Geoffrey Keating wrote:

"H. J. Lu" <hjl@xxxxxxxxx> writes:


The current visibility scheme doesn't work too well with symbols from system headers. In most cases, symbols from system headers are defined
in libraries which always have default visibility. But when
-fvisibililty= or "#pragma GCC visibililty push" is used, symbols from system headers may have non-default visibility. This leads to link-time or run-time problems. This patch adds -fsystem-header- visibility=. It
can be used to set the symbols from system headers with different
visibility.


I think this would be better dealt with in another way, for instance
by changing the headers in question. Otherwise I see that this is the first in a long line of patches which end up with command-line options
to control visibility for everything individually.


It is impractical to change all those header files come with all
libraries.

Really? I mean, it's not like 'system headers which define symbols and require those symbols to be visible' is an unknowably large set. On most of the platforms on which GCC runs, that's limited to libstdc+ +, and not all of libstdc++. On Linux, the set is larger, but it's not infinitely large, and you have the source available.

The only other approach is to require

#pragma GCC visibililty push(default)

#pragma GCC visibililty pop

when a library header file is included. That brings to

You don't have to do that, you can use __attribute__ instead.  But...

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

since you can't use more than 16 nested pushes with gcc 4.0.

I agree that's a problem, but you should fix that problem rather than trying to find a workaround.

Isn't that bug fixed?  The bugzilla has some patches in it...

(In particular, I don't see why 'system' headers should be treated
specially.)


Does -flibrary-visibility sound better? Some C++ symbols don't come
from header files. They are generated by gcc automatically.

See, this is the other problem with doing things specially based on system header or not system header. How can you tell if something is a 'library' or not?

We've had lots of problems like this before when we tried to do things based on system header-ness. Look at the problems we had with NO_IMPLICIT_EXTERN_C.

<Prev in Thread] Current Thread [Next in Thread>