This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PR 18167, Relax PR 15228 protected visibility restriction
- From: Pedro Alves <palves at redhat dot com>
- To: binutils at sourceware dot org
- Date: Fri, 27 Mar 2015 10:32:10 +0000
- Subject: Re: PR 18167, Relax PR 15228 protected visibility restriction
- Authentication-results: sourceware.org; auth=none
- References: <20150327054327 dot GB26234 at bubble dot grove dot modra dot org>
On 03/27/2015 05:43 AM, Alan Modra wrote:
> Allows .dynbss copy of shared library protected visibility variables
> if they are read-only.
>
> To recap: Copying a variable from a shared library into an executable's
> .dynbss is an old hack invented for non-PIC executables, to avoid the
> text relocations you'd otherwise need to access a shared library
> variable. This works with ELF shared libraries because global
> symbols can be overridden. The trouble is that protected visibility
> symbols can't be overridden. A shared library will continue to access
> it's own protected visibility variable while the executable accesses a
> copy. If either the shared library or the executable updates the
> value then the copy diverges from the original. This is wrong since
> there is only one definition of the variable in the application.
>
> So I made the linker report an error on attempting to copy protected
> visibility variables into .dynbss. However, you'll notice the above
> paragraph contains an "If". An application that does not modify the
> variable value remains correct even though two copies of the variable
> exist. The linker can detect this situation if the variable was
> defined in a read-only section.
Except pointer comparison won't be correct, right? I mean,
lib:
const int protected_var __attribute__ ((visibility ("protected")));
void
library (int *var)
{
if (var != &protected_var)
abort ();
}
app:
const int protected_var __attribute__ ((visibility ("protected")));
library (&protected_var);
Or is there something else that already makes it invalid to expect
that the variable's address taken by program and library match?
Thanks,
Pedro Alves