From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54383 invoked by alias); 15 Apr 2016 16:45:47 -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 54315 invoked by uid 89); 15 Apr 2016 16:45:46 -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.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=standing X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,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, 3 recipients X-HELO: mail-qk0-f173.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=OorlcpPdyJnj11APh285a/GMMPm30sAZyfS8oEdhZCM=; b=oyy5k7Wbf1Ii3WIm/iKGb8ld2hS/ujrlr3utl1AdEeIsxIOtC3EzrQdb+dVAFqq/Gb CMt/fNXuq9Fy/CGJMJLI8/gsFZYBtQ72oYatBgzx2e3igBkwnpxY3Qv1XI+hetCWPYDc G0QfrafF+DfNeyAcrqmR/UqqRyi7Q2sxs5IZhNSKmpReQmVq9h+o/vH5/B8zcjG6sDba ZPDFSA6Hfn5CGDGefFmQPfIeU5WxOLSCj42sez7BAtzQ6tHn/Z77FCjoYeoS5sBM/hmy JXc6bmYNjCWzwhvhX78A21j7/Q+A09tf+LqMwcXJaWXGhSRe7jaSX/oC0MmXZhsShRrG ydFQ== 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=OorlcpPdyJnj11APh285a/GMMPm30sAZyfS8oEdhZCM=; b=O2VXWyoOxWEjy6fG9mx6dQG4B7jEWTJhVL5XbckMSluMm8YWMjlhD9pvxfvtxKni8H tUUEeW0Y+GUT7jnBVoNV1IPEGliSS3yA4cWRwVojVza786oe4t4BxZ/Vty0rxffxyg10 UBsIZrUYfNlbCknUlU/Ypo/6okq9oMX+MQNiWd545YAO/O8D9OT6P/JbKVF+s9ysOMZG F+YHvuNLG3lcPqU63my9dPPfaEIszEKQcEstXnq/B8ygW+aYbKC8MUk0081ugbNqDNOc hR++etrleP+9soL7hGTeH6+AePYRlQk+N6hRMbR7XKFhnYCNk6zp8sRJmhophgjRWYmZ pubA== X-Gm-Message-State: AOPr4FX3mjXoPxnXL6uSND0wxOyG9g7H9sDsC47dwEjdlW8bTWypYCcye5I4jyU+FWDgXmBzDaTyK1UHu2eInw== MIME-Version: 1.0 X-Received: by 10.55.11.4 with SMTP id 4mr4342954qkl.92.1460738739636; Fri, 15 Apr 2016 09:45:39 -0700 (PDT) In-Reply-To: <5711188D.3000500@redhat.com> References: <5711188D.3000500@redhat.com> Date: Fri, 01 Jan 2016 00:00:00 -0000 Message-ID: Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 From: "H.J. Lu" To: Jeff Law , GNU C Library Cc: Szabolcs Nagy , gnu-gabi@sourceware.org, Ramana Radhakrishnan , Cary Coutant , Joe Groff , Alan Modra , Binutils , nd Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-q2/txt/msg00004.txt.bz2 On Fri, Apr 15, 2016 at 9:36 AM, Jeff Law wrote: > 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. > Adding glibc. Protected symbol has been a tricky issue for glibc and binutils from day 1. We have special treatment for pointers of protected functions in both ld and ld.so. Protected symbol is a useful feature. It just doesn't work with copy relocation. My proposal will make it work for psABIs with copy relocation by disallowing copy relocation on protected symbol. Linker change is minimum and it will bypass extra symbol lookups in ld.so. -- H.J.