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

[Martell Malone via llvm-commits]

>
> Can't mingw just use lld-link style command line options instead of Unix
> style?

Not really, there would be a lot or projects that invoke the linker
directly that assume ld style.
On top of that I seriously doubt that gcc would add support for passing
link style commands.
So lld would become unusable with gcc for mingw targets.




On Tue, Aug 18, 2015 at 1:38 AM, Rui Ueyama <ruiu at google.com> wrote:

> Can't mingw just use lld-link style command line options instead of Unix
> style? I'm not really excited about adding a new driver for COFF.
>
> On Tue, Aug 18, 2015 at 9:28 AM, Martell Malone <martellmalone at gmail.com>
> wrote:
>
>> 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
>>
>> That's not what the proposal was
>> It was to move the current COFF driver to lib/LinkDriver.
>> Then add a new gnu driver into COFF/Driver so that ELF/Driver and
>> COFF/Driver could share more of the same code.
>>
>> The gist I sent in above however was to just add a new GNUDriver.cpp into
>> COFF where they can live side by side.
>>
>> On Tue, Aug 18, 2015 at 1:05 AM, Rui Ueyama <ruiu at google.com> wrote:
>>
>>> 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/13d0a4a1/attachment.html>