[COFF] Add some ld Aliases for gnu mode

[martell]

Summary

depends on

http://reviews.llvm.org/D12323

[ruiu]

Ah, so this is the other patch to support other options.

As we discussed before, the difference between link.exe and GNU ld are not superficial -- some command line options can be supported as aliases (like the ones you are adding in this patch), but others have significant semantic differences. I want to discuss the plan first. What is your plan on that, and what is the goal?

[martell]

In D13933#272072, @ruiu wrote:

Ah, so this is the other patch to support other options.

As we discussed before, the difference between link.exe and GNU ld are not superficial -- some command line options can be supported as aliases (like the ones you are adding in this patch), but others have significant semantic differences. I want to discuss the plan first. What is your plan on that, and what is the goal?

Yes originally I had created a separate Driver for this but you said you didn't like the idea of a new driver.

I would like to add support for aliases where possible as rnk suggested in the previous thread and then implement handlers for the ones that gnu has that link doesn't.
If I mis interpreted that please feel free to correct me

The goal would be to have all the aliases that ld provides here implemented
EDIT: correct link
http://www.delorie.com/gnu/docs/binutils/ld_4.html

With this patch is already it enough to compile simple executables

As for the functionality that link.exe has that ld doesn't the end user would be able to use the link.exe version in conjunction with their existing arguments. I think that would be a decent compromise.

Alternatively because the ELF2 Driver is a lot more complete now we could bind that driver to COFF like I done previously with the old PECOFF system here.
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-clang/0034-GNU-add-support-for-linking-PECOFF.patch

As I stated previously I don't mind what way we do this.
Just as long as we have something that is working for the COFF target from an ld frontend.

[martell]

Before I forget I know that some of the gnu ld aliases can not be implemented.
But I think the ability to compile exe's dll's and libs without any major customization besides debug and release and a few other supported alias options would cover most mingw-w64 users use cases of the gnu front end.
If someone is doing something crazy that fits outside these use cases then they should be using link.exe
I don't think this will impose too much on the code base of COFF and have the least impact.
For everything else we can fall back to link.exe syntax

[ruiu]

This is for mingw, right? Do you think what you would eventually need in addition to this? I'd like to know the impact of changes you are planning to make.

[martell]

In D13933#272309, @ruiu wrote:

This is for mingw, right?

Yes this is for the mingw-w64 target.

Do you think what you would eventually need in addition to this? I'd like to know the impact of changes you are planning to make.

I'm not sure in what context but I'll try my best to answer.

Other then having the aliases mentioned above we have already dealt with the export library format issue in mingw-w64 with the genlib tool you helped me with with so the only other thing I see is that we would eventually have to remove the dependency on MSVC's lib.exe and rc.exe but this is something that llvm should do anyway even for the MSVC targets. This seems to be moving in the right direction already with the creation of llvm-lib.

In relation you your goal question earlier.
The goal is to have a toolchain stack with llvm, clang, compiler-rt, libunwind, libc++ and lld for mingw-w64 without having a single dependency on anything GNU i.e gcc or binutils or anything copyrighted by MS i.e visual studio.

[ruiu]

If I remember correctly, I recommended to write a shim to convert GNU-style options to link.exe-style options. Does that approach make sense?

[martell]

In D13933#272449, @ruiu wrote:

If I remember correctly, I recommended to write a shim to convert GNU-style options to link.exe-style options. Does that approach make sense?

Yes and there was objections to this because it adds extra dependencies such as python or whatever language the shim is written in.
I'd rather not have an external dependency / external shim when we could just add support for it directly in the driver which is a lot less work.

Originally compnerd suggested having a conversion system where ld syntax was the end result for every linker but you said that would be too much work or overhaul.

I suggested having a seperate driver based on the ELF driver for this but you weren't excited about the idea of adding a new driver.

rnk then gave his input saying that based on his experience with clang-cl that we should go with the alias approach as it would be the best and have the least impact on the code base.

This is where I thought we were at so i implemented this base patch based on this concept.

[ruiu]

Besides the extra dependency, is there any problem with the shim approach? I don't think we should mix GNU and link.exe style command line options in one place.

A shim doesn't have to be an external tool. That can be just another entry point that creates a new argv and pass that to COFF driver. So the external dependency is not really a problem.

COFF/Options.td

 def lldmap : Joined<["/", "-"], "lldmap:">;
 
 //==============================================================================
+// The flags below provide aliases. They are defined for ld compatibility.
+//==============================================================================
+
+def o : Separate<["-"], "o">, Alias<out>;
+def L : Joined<["-"], "L">, Alias<libpath>;
+def e : Separate<["-"], "e">, Alias<entry>;
+def subs : Separate<["--"], "subsystem">, Alias<subsystem>;
+
+def Bdynamic: Flag<["-"], "Bdynamic">,
+  HelpText<"Link against shared libraries">;
+
+def Bstatic: Flag<["-"], "Bstatic">,
+  HelpText<"Do not link against shared libraries">;
+
+// Used to override gnu pe targets
+def m : Separate<["-"], "m">, MetaVarName<"<emulation>">,
+     HelpText<"Select target emulation">;
+
+//==============================================================================
 // The flags below do nothing. They are defined only for link.exe compatibility.
 //==============================================================================