Re: PR 18167, Relax PR 15228 protected visibility restriction

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Mar 27, 2015 at 9:38 AM, Pedro Alves <palves@redhat.com> wrote:
> On 03/27/2015 12:29 PM, Alan Modra wrote:
>
>>
>> Modifying app:
>> extern int protected_var;
>> extern void library (int *);
>>
>> int main ()
>> {
>>   library (&protected_var);
>>   return 0;
>> }
>>
>> Now if the app is compiled -fPIE you shouldn't have the .dynbss copy
>> and no abort, but if the app is non-PIC then yes, pointer comparisons
>> won't be correct.
>>
>> HJ has gcc, glibc and ld patches to fix the mess by
>> a) modifying gcc to emit the same code for protected visibility
>> variables in shared libraries as default visibility, and
>> b) modifying ld.so to enforce proper protected semantics, and
>> c) disabling the linker checks.
>>
>> They look reasonable to me except there is no provision to deal with
>> any mismatch in the toolchain components, which is a nasty problem.
>> For example if you have a new gcc but older glibc then gcc will
>> generate code that is quite wrong for protected variables.  (It's also
>> slower since access to a protected variable in a shared library uses a
>> GOT indirection with HJ's patch.)  Similarly with ld, and note that
>> current x86_64 ld already has (c) installed, effectively disabling my
>> pr15228 fix..
>>
>
> Urgh.  The glibc issue sounds the most alarming.  If we can't keep
> back compatibility, isn't there a new bit/attribute we can put
> somewhere to tag new binaries with protected symbols in a
> way that existing systems just error out when loading them?


There is no backward compatibility to speak with since protected
data symbol never worked before.

-- 
H.J.