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

Tue Aug 18 19:19:26 PDT 2015

That's pretty much exactly what the original design for "flavors" meant. We also have to have command line compatibility to other linkers, so we do that with TableGen as well.

Alex

> On Aug 18, 2015, at 11:20 AM, Reid Kleckner <rnk at google.com> wrote:
> 
> (elaborating with a real keyboard)
> 
> Our experience with clang-cl is more like the following:
> - Many of the options are different spellings of the same thing. We alias them in tablegen.
> - Many of the options are irrelevant and can be ignored for compatibility. We do this in tablegen.
> - Many of the options look like aliases, but are actually annoyingly subtly different (-EHs- vs -fno-exceptions, -GR- vs -fno-rtti). We handle these manually.
> - A small number of options provide new functionality, and need to be passed through LangOptions, which is similar to LLD's Config object. (--defsym)
> 
> I am not suggesting that there should be a common driver between ELF and COFF. As we have discovered, they perform different steps in different orders, so I don't think we want this. I am only suggesting that the options tablegen files can be partially shared, so that we don't have to write down "--defsym" twice.
> 
> I also don't think we need more symlinks or copies of the LLD binary. The GNU options and the MSVC options don't appear to conflict, so we can probably accept both together. It sounds like Saleem is in favor of this approach.
> 
> To sum up, I think adding a gnu ld command line interface for COFF should primarily be a tablegen change instead of a C++ change. There may be GNU ld flag parsing utilities that we want to share between ELF and COFF, but we should only share those, and not the whole driver.
> 
> ----
> 
> Also, I guess it's not -rdynamic that we want to support, but the mingw equivalent called --export-all-symbols. It's useful to projects (like LLVM!) that don't have any dllexport annotations, but want to build a DLL that exports the same set of things that would be dynamically visible in an ELF shared object.
> 
>> On Mon, Aug 17, 2015 at 11:41 PM, Rui Ueyama <ruiu at google.com> wrote:
>> I guess that the experience of the compiler is not directly applicable to this because the architecture is pretty different. I'd like to know which options cannot be mapped to link.exe options, which can, and which options don't have to be supported (some GNU ld options for PE/COFF seem to implement experimental features which does not seem to me to have to be supported). Also, do we have to support linker script on Windows?
>> 
>>> On Tue, Aug 18, 2015 at 12:28 PM, Reid Kleckner <rnk at google.com> wrote:
>>> I don't think a pure aliasing or wrapping approach will work long term. There are things like -rdynamic that we want to support but they have no link.exe analogue.
>>> 
>>> Sent from phone
>>> 
>>>> On Aug 17, 2015 7:50 PM, "Saleem Abdulrasool" <compnerd at compnerd.org> wrote:
>>>> compnerd added a comment.
>>>> 
>>>> @rnk, fwiw, that sounds very much in line with what I was trying to push for.  AFAIK, the options don't conflict.
>>>> 
>>>> 
>>>> http://reviews.llvm.org/D12029
>>>> 
>>>> 
>>>> 
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150818/57437ec3/attachment.html>