From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14488 invoked by alias); 18 Apr 2016 17:05:07 -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 14458 invoked by uid 89); 18 Apr 2016 17:05:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-io0-f175.google.com Received: from mail-io0-f175.google.com (HELO mail-io0-f175.google.com) (209.85.223.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 18 Apr 2016 17:05:03 +0000 Received: by mail-io0-f175.google.com with SMTP id 2so201097431ioy.1 for ; Mon, 18 Apr 2016 10:05:03 -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=afcqY1c+hHACquCwveh6xjLUCL6K38TuIJxAYfuZhmg=; b=eMvRAyYEPBPfS6GImuMAHLVkCCba5PcGt/tWrZJfHM92hk4m47GcXbZvTWdcciW0GZ nUWBNeUTFDl0b9b4sPq5NRMxfBJTlgZBQlUYsCjCWQDtFOvl2CAHs8jv9sTsPEc/PC3C +z98JtsYE37azIxZ0t8BAmFFOmeWincyCChgotJqwYnnyTBH9z4cRPn/nijZB4f8ftbm IvgCpoMW3Jl7wxouOC5htHkwvBziZOi33xBhd921fYJCF/Ra5w+rjUmtFzEYyqjvwYiU QqNIm715J1WBS/1jWtjg8AE55e5WQVlXIoSTDvUcO/V+ehsl+F5RRryOsadUfhUS/vVF m4pg== X-Gm-Message-State: AOPr4FWfPivjpJORv/u8czvR4YEzQCAbg3f8WPTTt+zgyAWmkYC3GCOgcXQBLDV2+OEkJfd6QLt/iOYGnEJiQw== MIME-Version: 1.0 X-Received: by 10.107.34.65 with SMTP id i62mr34543778ioi.39.1460999101417; Mon, 18 Apr 2016 10:05:01 -0700 (PDT) Received: by 10.36.50.22 with HTTP; Mon, 18 Apr 2016 10:05:01 -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 17:05: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: Cary Coutant To: Richard Biener Cc: "H.J. Lu" , Jeff Law , Alan Modra , Joe Groff , Binutils , GCC Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00276.txt.bz2 >> 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? Ugh. Besides being a bad idea from a performance point of view, it's not even always possible to do. Depending on the architecture, a direct reference from an executable to a variable in a shared library may not have the necessary reach. > 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. When the whole point of a feature is to enable a particular optimization, the missed optimization *is* a correctness issue. Symbol visibility is not a standard language feature. It's an extension that many compilers provide to give access to an ELF/gABI feature, and it comes with limitations. When the only way to eliminate those limitations is to disable the intended optimization, the only real choices are to live with the limitations (i.e., issue an error when we would need a COPY relocation for a protected symbol), or to forgo the extension altogether. -cary