On Mon, Mar 14, 2016, at 06:42 PM, Dmitri Gribenko wrote:
> On Mon, Mar 14, 2016 at 3:38 PM, Ryan Lovelett
> <swift-...@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 <whitequ...@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.to...@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 <griboz...@gmail.com>*/
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
