This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Jeff Law <law at redhat dot com>, Alan Modra <amodra at gmail 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: Mon, 18 Apr 2016 11:01:48 +0200
- 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: <AB592ABD-D6D7-4D2F-A0D6-45738F168DC4 at apple dot com> <BEDD88C6-7F80-45DA-9021-10587244AAE5 at apple dot com> <CAMe9rOq6rmvH458nufzfZnnU_=_n1yysbLzERNy-LWvEmjmN1A at mail dot gmail dot com> <983472E1-A1BC-4970-9CF9-0138A6BAD16D at apple dot com> <CAMe9rOqTTwirymAY6ORp6D_GnCsMc_hYEdy1NbZpG6x5vQc5DQ at mail dot gmail dot com> <6AAD87D2-90F9-4AD7-A195-AC91B76EA6AE at apple dot com> <CAMe9rOqNcYnm1YocG-m7XNDE0g68YQAGe=ULP-G98gaatpxSeA at mail dot gmail dot com> <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>
On Fri, Apr 15, 2016 at 11:56 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Apr 15, 2016 at 2:49 PM, Jeff Law <law@redhat.com> wrote:
>>
>> So in the immediate term, if we drop the problem 65248 patch, we're back in
>> a state where the DSO and the executable can have two different views of
>> certain objects. In which case we really need a solution in place to flag
>> that as an error, which is #1 in your list of mitigations.
>
> From program behavior perspective, there is nothing wrong with
> my changes to ld, ld.so and GCC. The main drawback is my
> changes make protected symbol pretty much useless in term
> of faster access within the shared object. All these are due to
> incompatibility between protected symbol and copy relocation.
I agree. There's nothing to do for GCC 6.
> Given a shared library that defines a variable, and a non-PIC
> executable that references that variable, the linker makes a duplicate
> of the variable in the executable .dynbss section and arranges to have
> the copy initialized by the dynamic loader with a copy relocation.
> .dynbss is a linker created section that becomes part of the
> executable bss segment. The idea is that at run-time both the
> executable and the shared library will use the executable copy of the
> variable. It's a rather ancient linker hack to avoid dynamic text
> relocations, invented well before symbol visibility.
So what other choice does the linker have here? AFAICS it's wrong
to create the .dynbss copy for protected symbols. So why not
simply create 'dynamic text relocations' then? Is that possible with
a pure linker change?
That said, correctness trumps optimization. A correctness fix that
works with old objects trumps one that requires a compiler change.
Requiring a compiler change to get back optimization while preserving
correctness is fine.
To summarize: there is currently no testcase for a wrong-code issue
because there is no wrong-code issue. There's a missed-optimization
issue (the library is less optimized) but if we fix that by revering HJs
patch we _do_ have a testcase for a wrong-code issue that re-appears.
=> nothing to block GCC 6 which behaves strictly better than GCC 5 here.
Richard.
>
> --
> H.J.