[swift-dev] Build Error: Relocation R_X86_64_PC32
jgroff at apple.com
Tue Mar 22 12:01:33 CDT 2016
> 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
>>> 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
>> and use it verbatim to invoke the linker. There are generally two
>> to desire this.
>> The first reason relates to the sad truth is that Clang is
>> Binutils are not.
>> While any Clang from a binary distribution is sufficient to compile
>> for a wide range of architectures and prefixed BFD linkers (e.g.
>> installed as /usr/bin/arm-none-linux-gnueabi-ld) as well as
>> 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
>> 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
> 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
> 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
> library may be external. This patch adds extern_protected_data and
> changes _bfd_elf_symbol_refs_local_p to return false for protected
> if extern_protected_data is true.
> 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
> 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
> :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
Does this mean we need to do something on our side to suppress "extern_protected_data"?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-dev