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

[Rui Ueyama via llvm-commits]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150817/ccd22d6a/attachment.html>