From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62720 invoked by alias); 30 Mar 2016 14:44:10 -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 62706 invoked by uid 89); 30 Mar 2016 14:44:09 -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=ham version=3.3.2 spammy=enforced, ancient, HX-Received:10.66.222.199, (unknown) X-HELO: mail-pa0-f45.google.com Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 30 Mar 2016 14:44:05 +0000 Received: by mail-pa0-f45.google.com with SMTP id tt10so42810470pab.3 for ; Wed, 30 Mar 2016 07:44:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=YJbP1XVDBuW51KS67eQRZrkNuCPh7VZL9HyDUGQQIaY=; b=Fvlyz1M7e8NPUAwlNsr2TsJdyBQUn8v+LauRBftZlrXkzgOtfGFYGsiwgocsTJBB6w EL8w2Zxx+R1kRcT/stMuA9hi0impJsu14V76QeTaSkXuWTeHWoJrvykBtQMaYeWkacvO O/Qt+S7DtTHjGsuPdG/8uaW9NZpKXFOZPuwt10f1flhgPlqpzOHLvYGYpNttx9q1f/FL 6jsDVB22XWnAQL8jVHMKcqE2cguwDEETErM3JBzICYZL+aaHgB6GzlSk/SBiPk/0fh1M 8wZp37t6jyVJ2kT/YJ+wuJCAkgchGNuytIJr9jXbhNPr4UF6Ub4vuKksF+1DI8FDC2Vh PaSQ== X-Gm-Message-State: AD7BkJLWNb26KZZO8jyj0/fouezOOuCWHSGnjOvQK7Mj6qsCpZ1KroBXlOMSd0mXhVhlnQ== X-Received: by 10.66.222.199 with SMTP id qo7mr13840637pac.38.1459349043391; Wed, 30 Mar 2016 07:44:03 -0700 (PDT) Received: from bubble.grove.modra.org (CPE-58-160-146-233.sa.bigpond.net.au. [58.160.146.233]) by smtp.gmail.com with ESMTPSA id 22sm6573287pfh.48.2016.03.30.07.44.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Mar 2016 07:44:02 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id AA08AEA0157; Thu, 31 Mar 2016 01:04:21 +1030 (ACDT) Date: Wed, 30 Mar 2016 14:44:00 -0000 From: Alan Modra To: Jeff Law Cc: Cary Coutant , "H.J. Lu" , Joe Groff , Binutils Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 Message-ID: <20160330143421.GM15812@bubble.grove.modra.org> References: <983472E1-A1BC-4970-9CF9-0138A6BAD16D@apple.com> <6AAD87D2-90F9-4AD7-A195-AC91B76EA6AE@apple.com> <56FB5061.9010303@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56FB5061.9010303@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00431.txt.bz2 OK, I'll try to list the technical issues re. pr65248 "Copy relocation against protected symbol doesn't work". 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. The problem with protected visibility variables in shared libraries is that the shared library continues to access its own copy. So we have two copies of a variable where the source only contained one variable definition. (It's not really the copy relocation as such that causes a problem, but the fact that we have a duplicate in .dynbss.) Solutions are: 1) Have the linker emit an error, suggesting that the executable needs to be PIC to access a protected visibility variable in a shared library. Pass the pain on to users. 2) Emit dynamic text relocations for non-PIC executable access to protected visibility variables defined in shared libraries. Makes executable pages with text relocations non-shared between processes. (But can be shared again after relocation if two processes have the same layout.) 3) Teach the linker to edit non-PIC to PIC. I've done this for ppc32, but it's not very easy for x86 due to the fact that you can't find the start of an instruction from a relocated field. It also results in slow code, since PIC sequences are usually larger than non-PIC, requiring a branch into a patch area and a branch back. 4) Have the compiler always emit PIC for external variable access. The .dynbss hack could then die a natural death. Coupled with linker editing of PIC to non-PIC, you'd get correct and reasonably fast code with perhaps a few nops. Again, x86 has difficulty due to variable length insns, but this could be solved with marker relocs. 5) HJ's solution. Make the compiler emit the same code for protected visibility variables in shared libraries as it does for default visibility variables. ie. shared libraries access their protected visibility variables via the GOT, which allows the .dynbss hack to work. Also, modify the dynamic loader to ensure protected visibility semantics are enforced. (Consider the case of shared lib A that defines protected visibility var V, and shared lib B that also defines protected visibility var V, and an executable that references V. Assuming A is before B in breadth-first order, then the executable and A should use the .dynbss copy of V, but B should use its own V!) I've got to hand it to HJ, I think he has all this working properly to satisfy the semantics of protected visibility. However, shared library access of protected visibility variables is of course no quicker than default visibility variables. Which defeats the main reason to use protected visibility variables in shared libraries! Note also that it unnecessarily slows down shared library code using protected visibility variables that are not accessed by the executable (but perhaps accessed from some other shared library). Also, I don't believe there is anything to prevent a newly compiled program from running with an old glibc, which would mean protected visibility semantics are broken on such a system. To be fair, they were probably broken on such a system before the linker complained about non-PIC protected visibility access, anyway. -- Alan Modra Australia Development Lab, IBM