From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28027 invoked by alias); 15 Apr 2016 16:36:42 -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 27942 invoked by uid 89); 15 Apr 2016 16:36:41 -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.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=szabolcs.nagy@arm.com, szabolcsnagyarmcom, Hx-languages-length:3335, standing X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_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: mx1.redhat.com Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 To: "H.J. Lu" , Szabolcs Nagy , gnu-gabi@sourceware.org References: Cc: Ramana Radhakrishnan , Cary Coutant , Joe Groff , Alan Modra , Binutils , nd From: Jeff Law Message-ID: <5711188D.3000500@redhat.com> Date: Fri, 01 Jan 2016 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-SW-Source: 2016-q2/txt/msg00002.txt.bz2 On 04/15/2016 10:16 AM, H.J. Lu wrote: > On Fri, Apr 15, 2016 at 9:09 AM, Szabolcs Nagy wrote: >> On 31/03/16 14:26, Ramana Radhakrishnan wrote: >>> On Thu, Mar 31, 2016 at 1:52 AM, Jeff Law wrote: >>>> On 03/30/2016 06:40 PM, Cary Coutant wrote: >>>>>> >>>>>> It would help me immensely on the GCC side if things if you and Alan >>>>>> could >>>>>> easily summarize correct behavior and the impact if we were to just >>>>>> revert >>>>>> HJ's change. A testcase would be amazingly helpful too. >>>>> >>>>> >>>>> It looks like it's not just the one change. There's this patch: >>>>> >>>>> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01871.html >>>>> >>>>> which took the idea that protected can still be pre-empted by a COPY >>>>> relocation and extended it to three more targets that use COPY >>>>> relocations. >>>>> >>>>> I wonder how many other patches have been based on the same >>>>> misunderstanding? >> >> (sorry i missed this thread) >> >> this was not a misunderstanding. >> >> that patch is necessary for correctness (odr) in >> the presence of copy relocations as described in >> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02365.html >> and >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55012 >> >> this was a long standing code gen bug in gcc and was >> about time to fix it (it was also broken in glibc's >> dynamic linker, but e.g. not in musl libc). >> >> (i don't see what is the issue with using the copy in >> the main executable from a shared library, performance >> is not a correctness issue, nor how it is possible to >> avoid the copy relocs.) >> > > Here is my understanding: > > 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 > is to make protected symbol more or less like normal symbol, which > prevents optimizing local access to protected symbol within the shared > object. > > I propose to add GNU_PROPERTY_NO_COPY_ON_PROTECTED: > > https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI > > GNU_PROPERTY_NO_COPY_ON_PROTECTED This indicates that there > should be no copy relocations against protected data symbols. If a relocat- > able object contains this property, linker should treat protected data symbol > as defined locally at run-time and copy this property to the output share > object. Linker should add this property to the output share object if any pro- > tected symbol is expected to be defined locally at run-time. Run-time loader > should disallow copy relocations against protected data symbols defined in > share objects with GNU_PROPERTY_NO_COPY_ON_PROTECTED prop- > erty. Its PR_DATASZ should be 0. I'd strongly suggest discussing directly with Carlos, Cary and Alan. My worry here is this just adding another layer of stuff to deal with a fundamentally broken concept -- protected visibility. Jeff