On Tue, Apr 19, 2016 at 10:20:23AM +0200, Richard Biener wrote: > On Tue, Apr 19, 2016 at 7:08 AM, Alan Modra <amo...@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 <amo...@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
