Re: PR 18167, Relax PR 15228 protected visibility restriction

[Pedro Alves <palves at redhat dot com>]

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?

Thanks,
Pedro Alves