[Bug target/55012] New: Protected visibility wrongly uses GOT-relative addresses

[bugdal at aerifal dot cx]

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

             Bug #: 55012
           Summary: Protected visibility wrongly uses GOT-relative
                    addresses
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: bugdal@aerifal.cx


Consider the shared library code:

int a __attribute__((visibility("protected")));
int f() { return a; }

For this (on i386 at least), gcc generates a GOT-relative (@GOTOFF) reference
to "a" rather than a GOT lookup. This will then reference the wrong location if
"a" is moved into the main program's data via a copy relocation, which will
happen if the main program makes any references to "a".

The issue is a subtlety in the semantics of protected visibility. As I
understand it and as it's documented, it's supposed to convey the semantic that
the definition will not be overridden in the sense of the abstract machine.
Copy relocations are not a case of overriding the definition in the abstract
machine, but an implementation detail used to support data objects in shared
libraries when the main program is non-PIC. With the current behavior, GCC is
requiring library authors using visibility to be aware of this implementation
detail (which only applies on some targets) and avoid using visibility on these
specific targets. That, in my mind, is unreasonable and buggy behavior.

Note that where this came up is when trying to use #pragma to set visibility
globally in a shared library; doing so broke global objects accessed from the
main application, but otherwise behaved as expected.