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

[Reid Kleckner via llvm-commits]

(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/7a47b463/attachment.html>