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

[Martell Malone via llvm-commits]

>
> Based on our experience with clang vs clang-cl, I think we want to
> implement a driver that consumes all options, aliases everything that can
> be aliased, and treats the ld-style flags as first class citizens. In
> retrospect, I wish that clang-cl used a blacklist approach, where
> incompatible GCC-style flags are blacklisted, rather than whitelisting core
> options one by one. If there aren't any conflicts between link.exe and gnu
> ld flags, we can go ahead and do this.
>
> We can avoid duplicating the common options between ELF and COFF by
> generating a single option table and adding COFF / ELF flags like we do for
> clang / clang-cc1.
>
I think this approach would probably be the best in the long run.
At the same time agree with Rui on getting something simple into the
project.

I would like to avoid using a python script and have something within lld
in c/c++ itself just for consistency.
What are your thoughts on a patch like this (keep in mind that it is not
finished and i haven't added the ld options yet)

https://gist.github.com/martell/0f510546ebb01a2fb04e

I created 2 new files GNUDriverUtils.cpp and GNUDriver.cpp and from within
the universal Driver checked if it was using ld front end with a windows pe
target and got it to use that new driver if that was the case.
With this it keeps the 2 drivers separate but simple and we can start
filling out the ld options and build in the relevant alias's.

This seems like the simplest get support in to me.
We could then match up the options and once we are happy with them merge
them into the one options/driver file that consumes everything?

Thoughts?


On Mon, Aug 17, 2015 at 6:54 PM, Reid Kleckner <rnk at google.com> wrote:

> rnk added a subscriber: rnk.
> rnk added a comment.
>
> BFD ld has some options that link.exe doesn't have. If we do aliasing and
> argument translation, what will we do for such options? Invent our own
> link.exe-style options? Or try to pass through the BFD option?
>
> Based on our experience with clang vs clang-cl, I think we want to
> implement a driver that consumes all options, aliases everything that can
> be aliased, and treats the ld-style flags as first class citizens. In
> retrospect, I wish that clang-cl used a blacklist approach, where
> incompatible GCC-style flags are blacklisted, rather than whitelisting core
> options one by one. If there aren't any conflicts between link.exe and gnu
> ld flags, we can go ahead and do this.
>
> We can avoid duplicating the common options between ELF and COFF by
> generating a single option table and adding COFF / ELF flags like we do for
> clang / clang-cc1.
>
>
> http://reviews.llvm.org/D12029
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150817/1aeb9913/attachment.html>