From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6101 invoked by alias); 27 Mar 2016 16:26:47 -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 4294 invoked by uid 89); 27 Mar 2016 16:26:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=handy, living X-HELO: mail-ob0-f182.google.com Received: from mail-ob0-f182.google.com (HELO mail-ob0-f182.google.com) (209.85.214.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 27 Mar 2016 16:26:44 +0000 Received: by mail-ob0-f182.google.com with SMTP id fp4so85443564obb.2 for ; Sun, 27 Mar 2016 09:26:44 -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=0zYrzaK45DC0ezHaq2IBaCDQcIf/6A0RAs6PG1Qcvqs=; b=hODRTZ6nKxRbd5sS9S/mz+4+ltNebr3cng7Bn6m2WDhFdNBDcr8OzOr4B/Tg3wpyIE sMjZPnku+0ZBUjfZ4K4QfRqj31WXpqvDcvcwjKleJ03oCc+K8SocpLVYQZSVVtCOWN35 MwkJXOMl1wskcGjq9bFxjnFXrKkpcmUkROFUYs7ZKeEsBU/g9Ly3+uIH+F4mCns5nO2v kP45EewQy58xfMHnI927dtH5pQZMrwRJqN0a23FVsbCNhbXx85GUizqWBIjnEo2+ydKm pmCBzIZvR0gHYQPdCYaGKYvf4Wxv0YlWLx1RyrybbbNxrhyeM7DIWMHCOjbk1VYF8kVv gjqw== X-Gm-Message-State: AD7BkJLXi98WCw6ecvQ6yF9wHCHXcrNgoy5Fb7gYSc1RPLL8LY+0o1KId7uEa32PEDAcEfFUq14GOx5XfKqXvA== MIME-Version: 1.0 X-Received: by 10.182.50.136 with SMTP id c8mr11031550obo.66.1459096002341; Sun, 27 Mar 2016 09:26:42 -0700 (PDT) Received: by 10.76.35.8 with HTTP; Sun, 27 Mar 2016 09:26:42 -0700 (PDT) In-Reply-To: References: <9106B2FB-BB06-413A-A04D-EEFB992784FA@apple.com> <9EFBBDCE-4054-4867-B3E9-9DFE216A234F@apple.com> Date: Sun, 27 Mar 2016 16:26:00 -0000 Message-ID: Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 From: =?UTF-8?Q?Rafael_Esp=C3=ADndola?= To: Cary Coutant Cc: "H.J. Lu" , Joe Groff , Binutils Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00342.txt.bz2 On 24 March 2016 at 14:31, Cary Coutant wrote: >>>> What relocation do you propose to access external protected >>>> symbol on x86 for non-PIC code? >>> >>> Non-PIC code can still use a GOT, can't it? >> >> Yes. > > Right. > > Some additional thoughts: > > - This has nothing to do with PIE. Non-PIC-non-PIE code has been > living with this restriction for at least 18 years (since visiblity > was introduced into the gABI). > > - This has nothing to do with Ulrich's diatribe against protected > visibility, which applies only to function symbols (and really only to > one platform, due to how function pointer comparison works). The old powerpc ABI? > - You don't need to go full-on PIC to reference a protected data > symbol in a shared library. You can always statically initialize a > pointer variable, and go indirect through that ("poor-man's PIC"). > > - We could add support for __attribute__((dllimport)) or > __declspec(dllimport) when declaring an external variable that is > expected to be defined in a shared library (ideally, that attribute > ought to be placed in the library's public interface). The compiler > can generate a PIC-style reference for that variable without > penalizing all the other variables in the main program. This is how > HP-UX compilers work on PA and Itanium (using #pragma external). > > - Compilers could also generate tentative PIC-style references, with > sufficient relocations to allow the linker to convert the indirect > reference to a direct reference when possible (changing the second > load into a nop or copy). HP-UX also does this. > > - Indirect references from PIC code to a protected symbol penalize the > common case (referencing a symbol within its own module) to support > the uncommon case, while introducing the nasty side effects of a COPY > relocation. > > - COPY relocations are evil. They bind an application to a specific > version of a shared library's ABI, and introduce a hidden startup > cost. If we're going to make any changes, we should be moving towards > elimination of COPY relocations, rather than disabling features that > were designed to improve performance. > > - Arguing that protected means that the definition is in the same > module but its address might be external is absurd. The *only* reason > for the gABI to make that guarantee is so the compilers can optimize > the code based on the knowledge that the symbol can't be pre-empted. For what it is worth I strongly agree with Cary on these points. I never quite understood the warning against using protected. Without copy relocations or the PLT hacks, they are a really handy way to produce visible symbols from dsos that are efficient to use in the DSO itself. It is unfortunate that without copy reloc and PLT hack they are not easy to use from executables, but that can be fixed. Having the compiler be conservative and the linker relax access would do it and it is something I think we should try. I will try to audit the llvm side to make sure protected in there works as expected. Cheers, Rafael