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

[Sean Silva via llvm-commits]

On Mon, Aug 17, 2015 at 6:16 PM, Rui Ueyama <ruiu at google.com> wrote:

> On Tue, Aug 18, 2015 at 10:12 AM, Sean Silva <chisophugis at gmail.com>
> wrote:
>
>>
>>
>> On Mon, Aug 17, 2015 at 10: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?
>>>
>>
>> If I'm understanding this right, we would also need to add a dependency
>> on a tool that converts python to .exe's. On unix, the file name of an
>> executable doesn't matter and there is shebang. But on windows, you can't
>> have a .exe program which is a python script without actually transforming
>> it manually. So if a user wants to run the program without typing `python
>> foo.py`, I believe that a py2exe-like solution will be needed. This would
>> be an unfortunate dependency I think.
>>
>
> Python was not important point in my proposal. Sorry for the confusion. My
> point is to make an add-on command (in any language convenient for you)
> which is independent from LLD which accepts GNU command line and runs
> lld-link.
>

Yeah, I was simply providing some information which might help evaluate the
feasibility of using the Python language in particular.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150817/a5c5b4f8/attachment.html>