Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]

[Alan Modra <amodra@gmail.com>]

On Tue, Apr 19, 2016 at 10:20:23AM +0200, Richard Biener wrote:
> On Tue, Apr 19, 2016 at 7:08 AM, Alan Modra <amodra@gmail.com> wrote:
> > On Mon, Apr 18, 2016 at 07:59:50AM -0700, H.J. Lu wrote:
> >> On Mon, Apr 18, 2016 at 7:49 AM, Alan Modra <amodra@gmail.com> wrote:
> >> > On Mon, Apr 18, 2016 at 11:01:48AM +0200, Richard Biener wrote:
> >> >> To summarize: there is currently no testcase for a wrong-code issue
> >> >> because there is no wrong-code issue.
> >
> > I've added a testcase at
> > https://sourceware.org/bugzilla/show_bug.cgi?id=19965#c3
> > that shows the address problem (&x != x) with older gcc *or* older
> > glibc, and shows the program behaviour problem with current
> > binutils+gcc+glibc.
> 
> Thanks.
> 
> So with all this it sounds that current protected visibility is just broken
> and we should forgo with it, making it equal to default visibility?

Well, using protected visibility variables makes no sense in
executables.  They really are only useful in shared libraries, but
have been of limited use on architectures like x86 for a long time
due to non-PIC executable copying shared library variables into
.dynbss.  The concepts of copying variables into .dynbss, and
protected visibility, are fundamentally incompatible.

HJ's changes addressed the program level semantic issues, but in the
process lost the main reason to use protected visibility variables,
which is to tell a compiler that a global variable cannot be preempted
(and therefore can use faster code for access, typically pc or GOT
pointer relative rather than GOT indirect.)  So IMO, "of limited use"
has now become "not much use at all" on x86_64 and other architectures
that have blindly followed suit.

> At least I couldn't decipher a solution that solves all of the issues
> with protected visibility apart from trying to error at link-time
> (or runtime?) for the cases that are tricky (impossible?) to solve.

I described the problem and solutions in
https://sourceware.org/ml/binutils/2016-03/msg00431.html.  A followup
by Cary pointed out that one of the solutions, emitting text dynamic
relocations, won't work on some architectures (of which x86_64 is
one).

> glibc uses "protected visibility" via its using of local aliases, correct?

Yes, glibc defines a hidden visibility symbol for internal use, with
an exported alias.

> But it doesn't use anything like that for data symbols?

I believe it does.  See occurrences of libc_hidden_data_def.

-- 
Alan Modra
Australia Development Lab, IBM