This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Visibility attribute (was: proposed change: weak symbol support for Darwin)


On Monday, October 13, 2003, at 05:46 PM, Alexandre Oliva wrote:

On Oct 13, 2003, Matt Austern <austern@apple.com> wrote:

symbols that are public within a dynamic library but that aren't
exported beyond the scope of the library boundary.

Like attribute hidden?

I didn't know about the visibility attribute until Alexandre pointed it out to me. But now that I've looked at it, I can answer that question...

Yes, Apple's notion of private extern symbols looks very much
like __attribute__ ((visibility("hidden"))).  It looks so
similar that it would be silly to have two separate
mechanisms.

So I have changed my mind.  I don't want to take one bit in a
decl node for private_extern.  Instead I want to take two bits
and use them for enum symbol_visibility.  Attributes are a
fine user-level syntax, but I don't like using the attribute
mechanism internally for this.

Rationale: anything stored in DECL_ATTRIBUTES is very expensive.
You need to allocate a list node, an attribute node, several
strings.  Looking up an attribute requires several string
comparisons.  (Look at the definition of decl_visibility in
varasm.c: horrible stuff.) All of this is OK if you expect the
thing you're representing to be very rare, but in OS X private
extern function not all that rare.  I'm sure that changing our
private feature to use attributes would hurt compile speed.

So: what I'd like to do is put in a new two-bit visibility field
in struct tree_decl, replace decl_visibility with a DECL_VISIBILIY
macro, and change the parser so that it sets the visibility field
instead of adding an attribute node.

Can anyone convince me that this would be a bad idea?

--Matt


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]