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

[Joe Groff]

> On Jan 18, 2016, at 9:46 PM, William Dillon <wdillon at coas.oregonstate.edu> wrote:
> 
> 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?

swift.ld is a means to an end. I don't think we'd keep it if we had a superior alternative, and we wouldn't want the maintenance burden of having to keep multiple techniques working.

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

How different is the .s file across platforms? I'd expect it to just contain data directives.

> 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. ;)

Dmitri would have to comment about this part.

-Joe