From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80611 invoked by alias); 30 Mar 2016 07:20:56 -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 80598 invoked by uid 89); 30 Mar 2016 07:20:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=advised, xxx X-HELO: mail-io0-f169.google.com Received: from mail-io0-f169.google.com (HELO mail-io0-f169.google.com) (209.85.223.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 30 Mar 2016 07:20:52 +0000 Received: by mail-io0-f169.google.com with SMTP id q128so54264603iof.3 for ; Wed, 30 Mar 2016 00:20:52 -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=NsalbBf135M1G/p2HBJXktIhDVYceFFKQhm69COqFfY=; b=Zb3KYYhLo9IO9gjc/vQOe58rw4Ew0vhCYXNaizVtqnk8MClHEF12Z/Pj10DZv6va7V ZJ/39Dkd+Ds7MtL7zsfCsmtfrLc5KrFtrBcgeYLMtdL3fDhS7J0MtMUyxHOCTYDW7u+S r0Ux9XqMsM4+vMv8eA5KpCbtuA/1dNjtSIhLAXm1aKPdCc9jhz0XPFQL8pYVlgYiPVmL chBIK5hYYf+11If+WGmI5rCdtmeiCXVeNAuq6YF3NDKIizAHzeparOuALgo81ySiz/ur 5jPRwNRTVk9xWZ5wLHGW5yrkBBww20s0Um32JtRPWinfJnHRZK6xe1MPuYybc9yW16ew XjRQ== X-Gm-Message-State: AD7BkJJXJG0h+hPzSkBJSoi+LGTi50XGpSJ9mNx8t7z0ywsc6PpenGLS4HyKopJ7BecyfOfn1gIXQlR6EExKzw== MIME-Version: 1.0 X-Received: by 10.107.135.74 with SMTP id j71mr8306386iod.133.1459322450902; Wed, 30 Mar 2016 00:20:50 -0700 (PDT) Received: by 10.36.200.8 with HTTP; Wed, 30 Mar 2016 00:20:50 -0700 (PDT) In-Reply-To: <56FB5061.9010303@redhat.com> References: <983472E1-A1BC-4970-9CF9-0138A6BAD16D@apple.com> <6AAD87D2-90F9-4AD7-A195-AC91B76EA6AE@apple.com> <56FB5061.9010303@redhat.com> Date: Wed, 30 Mar 2016 07:20:00 -0000 Message-ID: Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 From: Cary Coutant To: Jeff Law Cc: "H.J. Lu" , Joe Groff , Alan Modra , Binutils Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00409.txt.bz2 > And FWIW, there are some folks on the GCC side of things that think that > HJ's change for 65248 is broken and needs to be reverted before gcc-6 > releases. Thanks; I was thinking the next step was to move this discussion over to the GCC side to see if anyone there was in agreement. > 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. On the compiler side, the main thing to check is that any reference to a protected data symbol, whether extern, common, weak, or initialized, is accessed with a pc-relative or GOT-relative addressing mode (i.e., not indirect through a GOT entry). This is the fundamental reason to declare a data symbol protected. The testcases in gcc.target/i386/pr65248-[1234].c look suitable to me, if we simply switch "scan-assembler-not" with "scan-assembler" throughout. These basically take a source like this: __attribute__((visibility("protected"))) int xxx; int foo () { return xxx; } and compile with -fpic. Prior to GCC 5, we got movl xxx(%rip), %eax but with GCC 5, we now get movq xxx@GOTPCREL(%rip), %rax movl (%rax), %eax There was another change to GCC at r218397, in Dec. 2014, to make data access in PIE mode work more like non-PIC mode. This required linker changes to enable the use of COPY relocations when generating PIE output. This patch was originally developed by Sriraman Tallam on the Google branch, but was checked on trunk in by HJ after considerable discussion. As far as I'm concerned (and I advised Sri during the development of this patch), this change was fine -- it simply recognizes that a position-independent executable does not need to use PIC-style references to data when a pc-relative or got-relative access is possible. As in non-PIC mode, these accesses work fine for data defined in the main program, but result in occasional COPY relocations if the data happens to be defined in a shared library. Unfortunately, I think this was the patch that set the rest in motion -- when developing test cases, HJ noted that COPY relocations to protected symbols were not allowed, and set out to fix that. Ultimately, I'd like to see GCC support the use of declspec(dllimport) or __attribute__((dllimport)) to declare a global variable known to be defined externally in a shared library. It should then generate a PIC-style reference even in non-PIC mode. This could be used to eliminate all COPY relocations. On the linker side, the linkers need to check that a reference from a main program to a protected symbol will result in neither a text relocation nor a COPY relocation, but instead issue an error message explaining fairly clearly that a protected symbol in a shared library cannot be referenced from non-PIC code. See PR ld/15228 and PR gold/19823 (the latter being the bug report that started this current thread). -cary