<div dir="ltr"><div><div><div><div><div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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.<br>
<br>
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.<br></blockquote>I think this approach would probably be the best in the long run.<br></div>At the same time agree with Rui on getting something simple into the project.<br><br></div>I would like to avoid using a python script and have something within lld in c/c++ itself just for consistency.<br></div>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)<br><br><a href="https://gist.github.com/martell/0f510546ebb01a2fb04e">https://gist.github.com/martell/0f510546ebb01a2fb04e</a><br><br></div>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.<br></div>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.<br><br></div><div><div><div><div><div><div>This seems like the simplest get support in to me.<br></div><div>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?<br><br></div><div>Thoughts?<br></div><div><div><div><br></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 17, 2015 at 6:54 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">rnk added a subscriber: rnk.<br>
rnk added a comment.<br>
<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<a href="http://reviews.llvm.org/D12029" rel="noreferrer" target="_blank">http://reviews.llvm.org/D12029</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>