[swift-dev] [RFC] Moving to gold linker

[William Dillon]

Thanks for the input about the gold linker so far, everyone.

I have a few follow-up questions.

First up is whether there is any desire to keep swift.ld at all.  I believe that I’ll be able to use the same object files using the binutils linker, so the mechanics in place for gold will function in both cases.  I don’t know if there is another compelling reason for keeping it.  Thoughts?

Second, Orlando believes that it’s possible to use C++ to generate the object files rather that assembler.  This would make these source files much more portable and easier to maintain.  There is a catch, however. In the assembler version there is no runtime impact at all; the C++ version requires a subtraction at load time.  The cost is pretty minimal, but it’s worth considering.  Changing from one implementation to another is very simple.

Finally, tying in the discussion of multi-architecture/multi-sdk cross compilation on linux, I noticed that swift.ld is copied to a 2-d array of SDKs and Architectures.  Considering that effory this effort (may?) not support a functional use case anyway, is it desirable to keep this behavior?  It would certainly simplify the generation of the object files.  I’ve already done the work, so it’s not that I’m trying to avoid it. ;)

Thanks again for your comments and thoughts,
- Will

> On Jan 14, 2016, at 9:26 PM, William Dillon via swift-dev <swift-dev at swift.org> wrote:
> 
>> 
>> On Jan 14, 2016, at 9:19 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>>> On Jan 14, 2016, at 11:07 AM, William Dillon via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>>>> 
>>>>> 1. Is moving to or supporting Gold within the swift toolchain (not building swift itself) a goal, non-goal, or not desired?
>>>>> 
>>>> 
>>>> I can't speak for the project, but I can speak for myself.
>>>> My naive understanding is that swift uses two linkers because 'INSERT
>>>> AFTER' linker script directive isn't supported (in gold). I read a lot about
>>>> that -- and I felt like the gold developers didn't care about adding
>>>> this command as it's mainly of use for the default linker script
>>>> shipped with ld.bfd.
>>>> They also provided an alternative way to obtain the same semantics
>>>> without providing an additional directive. Other than that, I don't
>>>> know any other reasons why gold shouldn't be used.
>>>> 
>>> 
>>> That’s right, AFAIK.  Orlando developed a system using two assembler files that bookend the objects during link to achieve the same result as the ld script.  Additionally, this method works with BFD, so swift.ld can be discarded entirely.
>> 
>> That sounds like a great improvement. Supporting gold for the entire build process would be great. Any idea if the assembler input would also work on FreeBSD or other platforms?
>> 
> 
> Yes, as long as you’re using clang, it should work in FreeBSD.  Darwin doesn’t require this at all AFAIK.  So, that would support Linux, FreeBSD, and Darwin, all without swift.ld.
> 
> - Will
>  _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org <mailto:swift-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160118/85381fab/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1428 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160118/85381fab/attachment.p7s>