public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Joe Groff <jgroff@apple.com>
Cc: Binutils <binutils@sourceware.org>
Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26
Date: Thu, 24 Mar 2016 01:25:00 -0000	[thread overview]
Message-ID: <CAMe9rOoSYZF7BmKB_OFDXfyAUw4OtyZP7vsak-eBtDu3nR_sCg@mail.gmail.com> (raw)
In-Reply-To: <F2740BEF-E6CE-4FF9-A1D5-0F1581978D4D@apple.com>

On Wed, Mar 23, 2016 at 5:52 PM, Joe Groff <jgroff@apple.com> wrote:
>
>> On Mar 23, 2016, at 5:45 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>> On Wed, Mar 23, 2016 at 5:00 PM, Joe Groff <jgroff@apple.com> wrote:
>>> Hi everyone. On the Swift project, we're getting bug reports that people are no longer able to link Swift programs using binutils 2.26:
>>>
>>> https://bugs.swift.org/browse/SR-1023
>>>
>>> This appears to be due to an intentional behavior change in commit https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=ca3fe95e469b9daec153caa2c90665f5daaec2b5, to allow protected symbols to be the targets of copy relocations. This breaks our intended use of "protected" in Swift, where we really want to be able to assume that the relative addresses of our symbols within a single executable or .so won't be preempted or moved. This lets us emit position-independent constant reflection metadata that doesn't need load-time relocations, saving us some startup time and dirty pages. I wanted to know if there's a supported way to express to the linker that "this symbol is protected, and also can never be copied". I'd like to avoid globally setting -Bsymbolic since I wouldn't want to impact non-Swift .o files in a mixed-language project. AIUI, -Bsymbolic also wouldn't prevent object files from trying to use copy relocations to our symbols and breaking our assumptions about their address; I'd like to know if it's possible to prevent that too. Thanks for any help you can give!
>>>
>>
>> What you want is not protected symbol, which is expensive to lookup
>> at run-time.  You need:
>>
>>  -z nocopyreloc              Don't create copy relocs
>>
>> But it requires that everything must be compiled with -fPIC, not even
>> -fPIE, for both executable and shared library.  Otherwise, you will
>> get dynamic relocations in text section.
>>
>> Swift should do something like -fPIC-data, to access external data via
>> PIC.  Then you can pass
>>
>> -z nocopyreloc              Don't create copy relocs
>>
>> to linker.
>
> Thanks H.J. Is it possible to specify this in the object file, at the symbol level, or does "nocopyreloc" have to be specified by linker flags?
>

Not at this moment.  I do have a proposal to specify something like
that in object files.


-- 
H.J.

  reply	other threads:[~2016-03-24  1:25 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-24  0:00 Joe Groff
2016-03-24  0:45 ` H.J. Lu
2016-03-24  0:52   ` Joe Groff
2016-03-24  1:25     ` H.J. Lu [this message]
2016-03-24 15:01 ` Cary Coutant
2016-03-24 15:07   ` H.J. Lu
2016-03-24 16:06     ` Cary Coutant
2016-03-24 16:42       ` H.J. Lu
2016-03-24 16:56         ` Cary Coutant
2016-03-24 17:05           ` H.J. Lu
2016-03-24 17:06             ` Joe Groff
2016-03-24 17:09               ` H.J. Lu
2016-03-24 18:31                 ` Cary Coutant
2016-03-27 16:26                   ` Rafael Espíndola
2016-03-28 12:12                   ` H.J. Lu
     [not found]                     ` <BC969B3B-87A2-4238-90C8-DA2E166707AF@apple.com>
2016-03-28 17:03                       ` Joe Groff
2016-03-28 17:17                       ` H.J. Lu
2016-03-28 22:22                       ` Cary Coutant
2016-03-28 22:24                         ` Joe Groff
2016-03-28 22:38                           ` Cary Coutant
2016-03-28 22:41                             ` Joe Groff
2016-03-28 23:21                             ` Alan Modra
2016-03-29  0:29                               ` Cary Coutant
2016-03-29 15:44                               ` H.J. Lu
2016-03-28 22:12                     ` Cary Coutant
2016-03-29 12:40                   ` Maciej W. Rozycki
     [not found] <AB592ABD-D6D7-4D2F-A0D6-45738F168DC4@apple.com>
2016-03-29 19:31 ` Fwd: " Joe Groff
2016-03-29 19:33   ` H.J. Lu
2016-03-29 19:36     ` Joe Groff
2016-03-29 19:43       ` H.J. Lu
2016-03-29 19:51         ` Joe Groff
2016-03-29 19:54           ` H.J. Lu
2016-03-29 22:05             ` H.J. Lu
2016-03-30  1:44             ` Alan Modra
2016-03-30  1:46             ` Cary Coutant
2016-03-30  4:04               ` Jeff Law
2016-03-30  7:20                 ` Cary Coutant
2016-03-30  7:34                   ` Cary Coutant
2016-03-30 14:44                 ` Alan Modra
2016-03-31  0:45                   ` Cary Coutant
2016-03-31  0:40                 ` Cary Coutant
2016-03-31  0:53                   ` Jeff Law
2016-03-31 13:27                     ` Ramana Radhakrishnan
2016-03-31 15:05                       ` H.J. Lu
2016-04-15 16:10                       ` Szabolcs Nagy
2016-04-01 19:51                   ` Jeff Law
2016-04-02  2:53                     ` Alan Modra
2016-04-15 16:16 H.J. Lu
2016-04-15 16:36 ` Jeff Law
2016-04-15 16:45   ` H.J. Lu
2016-04-15 16:43 ` Szabolcs Nagy
2016-04-15 23:59   ` Maciej W. Rozycki
2016-04-16  1:08     ` Szabolcs Nagy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMe9rOoSYZF7BmKB_OFDXfyAUw4OtyZP7vsak-eBtDu3nR_sCg@mail.gmail.com \
    --to=hjl.tools@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=jgroff@apple.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).