This is the mail archive of the
mailing list for the GCC project.
Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]
- From: Alan Modra <amodra at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Jeff Law <law at redhat dot com>, Cary Coutant <ccoutant at gmail dot com>, Joe Groff <jgroff at apple dot com>, Binutils <binutils at sourceware dot org>, GCC <gcc at gcc dot gnu dot org>
- Date: Wed, 20 Apr 2016 01:16:18 +0930
- Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]
- Authentication-results: sourceware.org; auth=none
- References: <CAJimCsHfT=cfb4kZysB2W_1HFfOq==TpP=wa47XPGB41MHmGyQ at mail dot gmail dot com> <56FB5061 dot 9010303 at redhat dot com> <20160330143421 dot GM15812 at bubble dot grove dot modra dot org> <571161D0 dot 10601 at redhat dot com> <CAMe9rOpt2Fd6RLtjr10wCHz9PVsXxtO9a0yvMR_DeHt1OK0ieg at mail dot gmail dot com> <CAFiYyc2PFQdiUj=UPY8HLv+PjwVaNpcvDW6Skp8JC4DR56MkBg at mail dot gmail dot com> <20160418144911 dot GG15088 at bubble dot grove dot modra dot org> <CAMe9rOog=FJ2Si-mUqHYoOsHVwVFcZavT4X7wQdRjRhbDDWRvQ at mail dot gmail dot com> <20160419050805 dot GI15088 at bubble dot grove dot modra dot org> <CAFiYyc1NJD0LAW2Mxe+xdgizTd3j7A9gwHEzHJA3A+hWpDO+Ew at mail dot gmail dot 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 <firstname.lastname@example.org> 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 <email@example.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.
> 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
> 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.
Australia Development Lab, IBM