[swift-dev] Build Error: Relocation R_X86_64_PC32

Tue Mar 22 11:55:28 CDT 2016

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

> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/