Re: Preventing preemption of 'protected' symbols in GNU ld 2.26

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Mar 24, 2016 at 8:01 AM, Cary Coutant <ccoutant@gmail.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!
>
> Your intended use of "protected" actually matches the actual intended
> use, and I believe the change you point to was a mistake. The gABI
> says that STV_PROTECTED must resolve to a definition in the same
> module:
>
> "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."
>
> That's pretty clear, and its intent was to allow compilers to generate
> more efficient code to access protected variables, knowing that they
> can't be pre-empted. Allowing COPY relocations for protected symbols
> breaks this guarantee, and is a bug. In fact, I'm about to fix just
> such a bug in gold:
>
>    https://sourceware.org/bugzilla/show_bug.cgi?id=19823
>
> Worse, GCC 5 and 6 no longer generate direct references to protected
> symbols, so the whole point of STV_PROTECTED (at least as it applies
> to data symbols) is currently broken in the Gnu toolchain.

I disagree.  Protected means that it won't be preempted.  It
doesn't mean the address of protected symbol will be local.
With copy relocation, the run-time address of the protected
symbol can be in executable.  There are a couple run-time
tests in glibc to verify it.  See:

https://sourceware.org/bugzilla/show_bug.cgi?id=17711


-- 
H.J.