From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105807 invoked by alias); 15 Apr 2016 23:59:43 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 105766 invoked by uid 89); 15 Apr 2016 23:59:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.1 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=www.sco.com, wwwscocom, UD:www.sco.com, UD:sco.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 2 recipients X-HELO: mailapp01.imgtec.com Date: Fri, 01 Jan 2016 00:00:00 -0000 From: "Maciej W. Rozycki" To: Szabolcs Nagy CC: "H.J. Lu" , , Ramana Radhakrishnan , Jeff Law , Cary Coutant , Joe Groff , Alan Modra , Binutils , nd , Rich Felker Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 In-Reply-To: <57111A0F.6030507@arm.com> Message-ID: References: <57111A0F.6030507@arm.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [10.20.78.229] X-SW-Source: 2016-q2/txt/msg00005.txt.bz2 On Fri, 15 Apr 2016, Szabolcs Nagy wrote: > > Copy relocation and protected visibility are fundamentally incompatible. > > On on hand, copy relocation is the part of the psABI and is used to > > access global data defined in a shared object from the executable. It > > moves the definition of global data, which is defined in a share object, > > to the executable at run-time. On the other hand, protected visibility > > indicates that a symbol is defined locally in the shared object at > > run-time. Both can't be true at the same time. The current solution > > protected visibility indicates > > "that references within the defining module bind to > the definition in that module. That is, the declared > entity cannot be overridden by another module." > > here "definition in that module" does not mean addresses > at runtime, but the c language level definition. > (c semantics can only indicate abstract machine behaviour, > not relocation types and in memory layout at runtime). Where did you get this definition from and how do you infer this is a "c language level" rather than a binary level definition? The SVR4/ELF gABI says[1]: "A symbol defined in the current component is protected if it is visible in other components but not preemptable, meaning that any reference to such a symbol from within the defining component must be resolved to the definition in that component, even if there is a definition in another component that would preempt by the default rules." and: "The presence of the STV_PROTECTED flag on a symbol in a given load module does not affect the symbol resolution rules for references to that symbol from outside the containing load module." so it clearly indicates that it is dynamic load modules (i.e. either the main executable or any of its referred DSOs) that are considered here, not C source-level semantics. Besides the ELF ABI is programming language agnostic, using the C language as a reference only, so it cannot really consider source-level semantics. > so there is no conflict between copy relocation and > protected visibility: the definition is not overridden, > it's an implementation detail that the address happens > to be in the data section of the main executable instead > of the defining module. Both the reference above and established practice assume a protected symbol must have its address within the module that defines it. See also: for my earlier comment. References: [1] "System V Application Binary Interface - DRAFT - 10 June 2013", The Santa Cruz Operation, Inc., "Symbol Table", Maciej