[Bug c/56527] New: Provide an import counterpart to attribute((visibility("protected")))

[Bug c/56527] New: Provide an import counterpart to attribute((visibility("protected")))

[luto at mit dot edu]

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

             Bug #: 56527
           Summary: Provide an import counterpart to
                    attribute((visibility("protected")))
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: luto@mit.edu


This is a common idiom:

#ifdef BUILDING_LIBWHATEVER
#define LIBWHATEVER_API __attribute__((visibility("protected")))
#else
#define LIBWHATEVER_API ???
#endif

Protected can be replaced with default without changing anything.  The issue
is: what to specify for imports (the ??? above).

The common approach seems to be __attribute__((visibility("default"))), since
hidden is asking for trouble and protected won't link due to undefined
protected symbols.  Neither one is good.

I want an attribute (which could be a new visibility) that acts like default
visibility for undefined symbols, like default visibility [1] for inline
defined symbols, and fails to compile for non-inline symbols.  (In this
definition, "inline" should probably include implicitly instantiated templates
as well.)

This will catch errors when a non-inline function is defined in the right
place.

[1] This isn't quite ideal.  To avoid interposing a possible protected
instantiation of an inline function, these should probably end up as default
visibility but weak.


P.S.  It would be neat if calls to functions with this attribute generated
explicit GOT references rather than going to the PLT.  (IMO Windows gets this
right.)

[Bug c/56527] Provide an import counterpart to attribute((visibility("protected")))

[luto at mit dot edu]

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

--- Comment #1 from Andy Lutomirski <luto at mit dot edu> 2013-03-05 00:37:20 UTC ---
In fact, without an improvement like this, protected visibility is unusable on
objects -- anything linking against a protected object will generate a copy
relocation.  The fact that the resulting binary is even loadable is IMO a bug
(whether in binutils for generating it or in glibc for loading it is
debatable.)