[swift-dev] Build Error: Relocation R_X86_64_PC32

[Joe Groff]

> On Mar 22, 2016, at 9:55 AM, Ryan Lovelett <swift-dev at ryan.lovelett.me> wrote:
> 
> On Mon, Mar 14, 2016, at 06:42 PM, Dmitri Gribenko wrote:
>> On Mon, Mar 14, 2016 at 3:38 PM, Ryan Lovelett
>> <swift-dev at ryan.lovelett.me> wrote:
>>> On Tue, Mar 1, 2016, at 12:16 AM, Dmitri Gribenko wrote:
>>>> IIRC there is no issue in the bug tracker, please feel free to file one!
>>>> 
>>>> Also, if you are familiar with binutils internals, it might be helpful
>>>> to bisect the linker.
>>> 
>>> I'm finally getting around to bisecting binutils. I'm making some
>>> progress but I'm getting hung up on one thing. The build script keeps
>>> finding the "regular" linker at `/usr/bin/ld` instead of mine
>>> `/tmp/binutils/2.25/usr/local/bin/ld`.
>>> 
>>> I tried to update the PATH environment variable such that mine is before
>>> `/usr/bin` but that doesn't seem to work. Is there an argument to send
>>> that can force mine?
>> 
>> I'm afraid '/usr/bin/ld' is hardcoded in clang.  A few days ago Clang
>> added a command-line option to override that:
>> 
>> commit 635bc7fefc12cc1333ba6ec77e563b7c8af01265
>> Author: Peter Zotov <whitequark at whitequark.org>
>> Date:   Wed Mar 9 05:18:16 2016 +0000
>> 
>>    Accept absolute paths in the -fuse-ld option.
>> 
>>    This patch extends the -fuse-ld option to accept a full path to an
>> executable
>>    and use it verbatim to invoke the linker. There are generally two
>>    reasons
>>    to desire this.
>> 
>>    The first reason relates to the sad truth is that Clang is
>>    retargetable,
>>    Binutils are not.
>> 
>>    While any Clang from a binary distribution is sufficient to compile
>>    code
>>    for a wide range of architectures and prefixed BFD linkers (e.g.
>>    installed as /usr/bin/arm-none-linux-gnueabi-ld) as well as
>>    cross-compiled
>>    libc's (for non-bare-metal targets) are widely available, including
>>    on all
>>    Debian derivatives, it is impossible to use them together because
>>    the -fuse-ld= option allows to specify neither a linker prefix nor
>>    a full path to one.
>> 
>>    The second reason is linker development, both when porting existing
>>    linkers
>>    to new architectures and when working on a new linker such as LLD.
>> 
>>    Differential Revision: http://reviews.llvm.org/D17952
>> 
>>    git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262996
>> 91177308-0d34-0410-b5e6-96231b3b80d8
>> 
>> Dmitri
> 
> Phew. Well I finally got everything ready to where I could bisect
> binutils. I won't bore with the details of what it took to actually be
> able to bisect binutils (unless someone actually wants to know).
> 
> I bisected from 71090e7a9dde8d28ff5c4b44d6d83e270d1088e4 to
> 2bd25930221dea4bf33c13a89c111514491440e2. 2bd259 was good and 71090 was
> bad.
> 
> ca3fe95e469b9daec153caa2c90665f5daaec2b5 is the first bad commit
> commit ca3fe95e469b9daec153caa2c90665f5daaec2b5
> Author: H.J. Lu <hjl.tools at gmail.com <mailto:hjl.tools at gmail.com>>
> Date:   Thu Mar 5 06:34:39 2015 -0800
> 
>    Add extern_protected_data and set it for x86
> 
>    With copy relocation, address of protected data defined in the
>    shared
>    library may be external.  This patch adds extern_protected_data and
>    changes _bfd_elf_symbol_refs_local_p to return false for protected
>    data
>    if extern_protected_data is true.
> 
>    bfd/
> 
>    	PR ld/pr15228
>    	PR ld/pr17709
>    	* elf-bfd.h (elf_backend_data): Add extern_protected_data.
>    	* elf32-i386.c (elf_backend_extern_protected_data): New.
>    	Defined to 1.
>    	* elf64-x86-64.c (elf_backend_extern_protected_data): Likewise.
>    	* elflink.c (_bfd_elf_adjust_dynamic_copy): Don't error on
>    	copy relocs against protected symbols if extern_protected_data
>    	is true.
>    	(_bfd_elf_symbol_refs_local_p): Don't return true on protected
>    	non-function symbols if extern_protected_data is true.
>    	* elfxx-target.h (elf_backend_extern_protected_data): New.
>    	Default to 0.
>    	(elfNN_bed): Initialize extern_protected_data with
>    	elf_backend_extern_protected_data.
> 
>    ld/testsuite/
> 
>    	PR ld/pr15228
>    	PR ld/pr17709
>    	* ld-i386/i386.exp (i386tests): Add a test for PR ld/17709.
>    	* ld-i386/pr17709-nacl.rd: New file.
>    	* ld-i386/pr17709.rd: Likewise.
>    	* ld-i386/pr17709a.s: Likewise.
>    	* ld-i386/pr17709b.s: Likewise.
>    	* ld-i386/protected3.d: Updated.
>    	* ld-i386/protected3.s: Likewise.
>    	* ld-x86-64/pr17709-nacl.rd: New file.
>    	* ld-x86-64/pr17709.rd: Likewise.
>    	* ld-x86-64/pr17709a.s: Likewise.
>    	* ld-x86-64/pr17709b.s: Likewise.
>    	* ld-x86-64/protected3.d: Updated.
>    	* ld-x86-64/protected3.s: Likewise.
>    	* ld-x86-64/x86-64.exp (x86_64tests): Add a test for PR
>    	ld/17709.
> 
> :040000 040000 7fc861c288f9bed44c6444d1b04e2f6e688aeeaf
> fca3f6ce979e7c00ed44c04f506880015235806d M      bfd
> :040000 040000 a5e358abb99b2b4089765f16904f9ebc496c0f12
> 7ccba1e77448a0155e56e8155073b40804b00daa M      ld
> 
> I'd like to write this up as an issue, if one has not been created in
> the 8-days it took me to get this working, is that a good idea or a bad
> one?

Does this mean we need to do something on our side to suppress "extern_protected_data"?

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160322/d1f16d56/attachment.html>