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

[Saleem Abdulrasool via llvm-commits]

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
> <javascript:_e(%7B%7D,'cvml','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?


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