[PATCH] D12029: [lld] LinkDriver, lld-link: introduce shim.

[Rui Ueyama via llvm-commits]

On Tue, Aug 18, 2015 at 2:36 AM, Saleem Abdulrasool <compnerd at compnerd.org>
wrote:

> On Monday, August 17, 2015, Rui Ueyama <ruiu at google.com> wrote:
>
>> On Sun, Aug 16, 2015 at 1:43 AM, Saleem Abdulrasool <
>> compnerd at compnerd.org> wrote:
>>
>>> compnerd added a comment.
>>>
>>> If we are fine with adding custom flags to the link command line, then
>>> aliases would be sufficient I think.  The idea is that you want to preserve
>>> the semantics of PE/COFF (which you called the semantics of Windows).  The
>>> difference is that the linker invocation should be similar to ld's, but
>>> continue to provide the current semantics.  There are a few extensions that
>>> are useful (which are compatible with the PE/COFF semantics), but the
>>> binaries that are generated by the alternate interface are meant to run on
>>> a Windows system, so losing the semantics of PE/COFF would be problematic.
>>>
>>> Just because the driver is written on/for unix, doesn't mean that the
>>> linker should provide unix semantics.  The semantics are that of PE/COFF
>>> because that is the target.  Its similar to how clang provides a GCC
>>> compatible interface which can still be used to generate a proper COFF
>>> object, even though ELF and COFF semantics are quite different.
>>>
>>
>> That's true, but in most use cases, Unix driver is used for Unix and
>> provides Unix semantics, and so are COFF. Probably more than 99 out of 100
>> linker invocations, the default semantics are used. So defining a new
>> driver layer for both Unix and Windows and then re-building the Unix and
>> Windows drivers on top of it is too much. I really want something simpler.
>>
>> There seems not necessary to create a new abstraction layer. We can write
>> a small Python script or something which takes Unix ld-ish command line,
>> translate that, and invokes lld-link with the translated options, can't we?
>>
>
> As long as the script is part of the same repository, I see no
> difference.  It's just Python vs c++.  I'm not attached to any language,
> and we already need Python to build, so having that as a runtime dependency
> for llvm doesn't seem too big of a deal.  We should be able to document
> Python as a runtime dependency for lld I assume?
>

They are different. IIUC, Martell's original proposal is to create a new
linker driver LinkDriver, move everything in COFF/Driver.{cpp,h} to that,
and then add GNU ld support to that. As a result we'd have a super driver
which understands both GNU and link.exe options/semantics. My proposal is
different. I don't want to add a full support for GNU ld options or
semantics for COFF. Instead I'd write an add-on script or something (which
can even live outside LLVM project) which is a wrapper for lld-link. Such
wrapper will never be able to be complete since not all GNU ld features are
supported by link.exe, but that may be able to be "good enough".


>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150818/bc457a1c/attachment.html>