From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125012 invoked by alias); 18 Apr 2016 09:02:06 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 124942 invoked by uid 89); 18 Apr 2016 09:02:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=unavailable version=3.3.2 spammy=HX-Gm-Message-State:AOPr4FX X-HELO: mail-wm0-f48.google.com Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 18 Apr 2016 09:01:51 +0000 Received: by mail-wm0-f48.google.com with SMTP id n3so113863833wmn.0 for ; Mon, 18 Apr 2016 02:01:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=R9RCuR1/w28MAqJ7/YubGIqSozMVt63vqNkSLJb2BGc=; b=Kw3nkggX65CrW+esKADP0/jrEkAWYmJhdP1b9wUNeB/sNT6F9IAClEaZWULpuydsjr l9GaHfKaiuskIyEIh6x9qgponYsqYgYOZyBb1Q5PX7SBD+jo9a55Zz8OZL8lr3qXnReC Qt+qcC23lqEs8ow1YSUk/fOBEMWahXkUUskIkPmmJb/Vtp5JWmM2nec7vVn/6dF2dHYy 2f8DP/nrtoLtkk5JhpByCS3w9dEWhh4QWjfjq2zweELuXVFA2YKE4bOmPJIUhh4yFqFZ 0byU0OP1+Dqsr6bp0r6xEk9uxBe0lh4W1Zl+vo05In70JeElu9UAi2UC2qUz4MMEnLIx 2/Jg== X-Gm-Message-State: AOPr4FX+sEBGGuzu6r0N9eTx3zOUSuVD7Nijv3BIL7eXNz/Lj0gYAEJGdQliiKEBNnbzJb1ATJKPyBq0rbog2g== MIME-Version: 1.0 X-Received: by 10.28.238.15 with SMTP id m15mr18186346wmh.9.1460970108568; Mon, 18 Apr 2016 02:01:48 -0700 (PDT) Received: by 10.194.51.104 with HTTP; Mon, 18 Apr 2016 02:01:48 -0700 (PDT) In-Reply-To: References: <983472E1-A1BC-4970-9CF9-0138A6BAD16D@apple.com> <6AAD87D2-90F9-4AD7-A195-AC91B76EA6AE@apple.com> <56FB5061.9010303@redhat.com> <20160330143421.GM15812@bubble.grove.modra.org> <571161D0.10601@redhat.com> Date: Mon, 18 Apr 2016 09:02:00 -0000 Message-ID: Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248] From: Richard Biener To: "H.J. Lu" Cc: Jeff Law , Alan Modra , Cary Coutant , Joe Groff , Binutils , GCC Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-04/txt/msg00263.txt.bz2 On Fri, Apr 15, 2016 at 11:56 PM, H.J. Lu wrote: > On Fri, Apr 15, 2016 at 2:49 PM, Jeff Law 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.