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

[Cary Coutant <ccoutant@gmail.com>]

> 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.

-cary