Add a ld64.lld alias for the MACHO LLD target

[martell]

Summary

Currently when we do -fuse-ld=lld for apple targets this invokes the gnu frontend because of the ld.lld alias
This creates a new alias for ld64 as ld64.lld to avoid this.

[martell]

I have a patch that does a bunch of updates for testing lld correctly in clang and this was a part of it but I didn't want the patch to get too involved so I separated this out.
I have seen this issue raised on various forums such as stackoverflow here and figured I would just fix it for users.
https://stackoverflow.com/questions/44106329/lld-unknown-argument-arch

[mstorsjo]

tools/clang/lib/Driver/ToolChain.cpp

394 ↗

(On Diff #116697)

Space between if and (

[martell]

address comment

[ruiu]

Is this for cross-compilation? If you invoke lld on macOS, it should act as ld64.

macOS lld is not actively maintained, so I wouldn't make it available more widely.

[martell]

In D38290#882911, @ruiu wrote:

Is this for cross-compilation?

It is mostly for native compilation on mac but this will work for cross compiling also.

If you invoke lld on macOS, it should act as ld64.

That is if the file name is ld or if you pass the darwin flavour but that is not how clang invokes lld.

-fuse-ld=lld invokes ld.lld which is bound to the gnu frontend only, even on MacOS hosts.
The reason for introducing ld64 is so we can still cross compile from MacOS to linux targets cleanly.

macOS lld is not actively maintained, so I wouldn't make it available more widely.

It seems to be able to link simple programs at least.
A user has to specifically pass -fuse-ld=lld to use lld for apple targets, I'm not making it the default here.
Most importantly though it makes less sense to have users invoking the ELF linker for MACHO targets as I highlighted above.

[ruiu]

This patch virtually sets ld64 the linker command name for macOS. I'd be a bit reluctant doing that, because ld64 sounds like a too generic name to indicate "a linker for macOS". But that's probably okay because we don't have a better name.

Can you get an LGTM from someone who owns the clang driver?

[martell]

CODE_OWNERS.TXT does not have a list of driver owners.
It does have rsmith as an owner for all things not covered by someone else so I added him.
Reid usually reviews driver patches I submit to clang and is on the owner list so I added him here initially.
I think either should be fine.
ping @rnk

[rnk]

In D38290#885503, @ruiu wrote:

This patch virtually sets ld64 the linker command name for macOS. I'd be a bit reluctant doing that, because ld64 sounds like a too generic name to indicate "a linker for macOS". But that's probably okay because we don't have a better name.

It's not a good name, but I do believe it is recognizable as the Darwin linker. It's also consistent with the names we invent on other platforms, which are essentially "native linker binary name plus lld".

Can you get an LGTM from someone who owns the clang driver?

lgtm

Thinking *LONG LONG* term, what I want to see happen is:

1. Annotate the exported C++ API of libLLVM.so to ensure that this does not regress clang compilation time (avoids PLT indirection for calls internal to LLVM)
2. Build with -fvisibility=hidden, so MachO and ELF builds of LLVM work like COFF
3. Make building LLVM.dll/libLLVM.dylib/libLLVM.so the default
4. Stop busy-boxing the LLD ports, and have separate executables for each: ld64.lld, lld-link.exe, and ld.lld

This will save disk space and potentially runtime if the loader keeps the LLVM shared object in memory, rather than loading a second copy for every link step in the buidl.

lld/trunk/tools/lld/CMakeLists.txt

target_link_libraries(lld
   lldELF
   lldMinGW
   )
 
 install(TARGETS lld
   RUNTIME DESTINATION bin)
 
 if(NOT LLD_SYMLINKS_TO_CREATE)
-  set(LLD_SYMLINKS_TO_CREATE lld-link ld.lld)
+  set(LLD_SYMLINKS_TO_CREATE lld-link ld.lld ld64.lld)
 endif()
 
 foreach(link ${LLD_SYMLINKS_TO_CREATE})
   add_lld_symlink(${link} lld)
 endforeach()

lld/trunk/tools/lld/lld.cpp

LLVM_ATTRIBUTE_NORETURN static void die(const Twine &S) {
   errs() << S << "\n";
   exit(1);
 }
 
 static Flavor getFlavor(StringRef S) {
   return StringSwitch<Flavor>(S)
       .CasesLower("ld", "ld.lld", "gnu", Gnu)
       .CaseLower("link", WinLink)
-      .CaseLower("darwin", Darwin)
+      .CasesLower("ld64", "ld64.lld", "darwin", Darwin)
       .Default(Invalid);
 }
 
 static bool isPETarget(const std::vector<const char *> &V) {
   for (auto It = V.begin(); It + 1 != V.end(); ++It) {
     if (StringRef(*It) != "-m")
       continue;
     StringRef S = *(It + 1);