[LLD] Allow usage of LLD as a library

[aganea]

Summary

As discussed in https://github.com/llvm/llvm-project/issues/53475 this patch allows using LLD-as-a-lib. It also lets clients link-in only the drivers that they want (see tests).

This also adds the unittests infra as in the other LLVM projects. Among the test coverage, I've added the original issue from @krzysz00, see this.

Important note: this doesn't allow (yet) linking in parallel. This will come a bit later, in subsequent patches, for COFF at last.

[aganea]

In D119049#3833491, @jerryyin wrote:

@aganea If you'd be willing to pick this CL again within one/two month-ish timeline, that's great. I can help with testing since I'm a developer from ROCm side. Hopefully we can wrap this whole thing up by the end of this quarter. On the other hand, if this CL may not be your top priority to work on, and just want to let you know that I'd be willing to take over and finish the rest of work of it. But I have close to zero knowledge of the internals of LLD so may need your pointers and code reviews to make sure I'm on the right track.

Sorry for the delay, please see the updated patch.

[aganea]

Fix casing in CMakeLists.txt

lld/tools/lld/lld.cpp

127

Fixed. Using the default OBJ-in-LIB override mechanism now, as described well by Raymond Chen here.

[sbc100]

lld/Common/CMakeLists.txt

30

Can we come up with a better name for this file maybe? That name makes me think its specifically for the library use case but that isn't true.

Also, we don't capitalize lld elsewhere, with in the filenames or directory names.

How about lldMain.cpp, or perhaps we can come up with a name that doesn't start with lld at all?

lld/include/lld/Common/Driver.h

43–44

Why not llvm::ArrayRef<const char *>?

[aganea]

As suggested by @sbc100

lld/Common/CMakeLists.txt

30

DriversMain.cpp ?

lld/include/lld/Common/Driver.h

43–44

Please see updated diff. We had std::vector just because of how the -flavor flag is treated and then stripped from args. I changed to llvm::ArrayRef as you suggested and added -flavor in all drivers as a shallow flag. If we want to go that route, I could send a separate patch for that change.

[jerryyin]

Thanks for your work @aganea. I abstain from giving review from lld's implementation side but thing looks good on the ROCm.cpp unit test. (BTW, do you aim to create that unit test as a demo and then to remove it later? Or else i'd expect to see the "Inputs" folder mocked up in certain way.) Although I did notice a fair amount of test breakages on windows. If you are still actively working on it, I'm willing to approve it once you fix the test failures. Also I plan to give this a test by pulling this diff locally assuming the base of this diff wouldn't cause too much conflicts with our tip of clone.

[aganea]

Fix (hopefully) CI build.

[aganea]

@jerryyin The build errors were due to the fact that I only used LLD as stage-0 linker in my previous tests, assuming that its behavior is conformant with other system linkers. It is not, as described in this paragraph. The same holds for both ELF and COFF drivers.

It seems that there's no universal solution for overriding a symbol in a LIB by a symbol in another LIB. MSVC has /alternatename which works, but there's no such thing on ELF side -- weak symbols cannot be overriden by another LIB once they are visible in the module, or at least I don't know how. There's also the --include=symbol for MSVC and --u=symbol for Unix that can solve the issue by pushing the symbol early in the symbol table, but then we have to deal with the mangling and that doesn't sounds fun. In the end, if users want to use a partial set of the LLD drivers, I resorted to simply implementing the missing drivers with the LLD_IMPLEMENT_SHALLOW_DRIVER macro (see ROCm test). If there's a better/simpler solution for a user perspective, let me know and I'll try it.

[aganea]

Add binaries into diff to fix the preflight build.

[aganea]

hmm the buildkite preflight is still broken, it seems Phabricator is stripping out the binary files from the diff.
My local diff is fine:

but after downloading from this page, they are empty:

[jerryyin]

It seems that there's no universal solution for overriding a symbol in a LIB by a symbol in another LIB...simply implementing the missing drivers with the LLD_IMPLEMENT_SHALLOW_DRIVER macro

Thanks for letting me know, sounds like a fair solution.

lld/Common/DriversMain.cpp

163–172 ↗

(On Diff #491742)

I have a naïve question to ask:

• In my limited knowledge, previously lldELF is dependent on lldCommon target. lld.cpp would compile just fine because its target is an executable.
• Now, since DriversMain.cpp become part of lldCommon, and in the implementation of DriversMain,cpp, we start to invoke those specific link target, it implicitly requires, for example, lld::elf::link to be available before lldCommon is compiled. In other words, lldCommon is dependent on lldELF.

Did we just have a cyclic dependency here? And if it is, do you need to move the lldMain() and safeLldMain() into their own independent target such that we can avoid the existence of such a cycle in the compilation?

[aganea]

lld/Common/DriversMain.cpp

163–172 ↗

(On Diff #491742)

The trickery is that we push lldCommon twice on the command-line, once in lldELF (same in all the other drivers), in another time in the final module. I retained the same mechanic for the unittests.

We could have another lib for LLD-as-lib usage, but I thought from the users' perspective it's simpler if we provided a single "common" lib + the specific drivers' libs.

[arsenm]

lld/CMakeLists.txt

207–212

Feels like this isn't something lld should have to roll its own handling for

lld/Common/DriversMain.cpp

162–172 ↗

(On Diff #491742)

Should move to a separate function with a switch/return

[aganea]

As suggested by @arsenm

[jerryyin]

LGTM with my limited knowledge of lld. Approving it as this is an extremely useful feature to have, and I want it to make progress after almost a year of staging.

lld/Common/DriversMain.cpp

163–172 ↗

(On Diff #491742)

Just want to let you know that I made an (very risky attempt) trying to test this patch in our fork, but this errors out unable to build lld. Based on Harbormaster build result, I don't believe this is due to issues from your patch, but rather our lld fork has been a couple of months old. (Refer to https://github.com/ROCmSoftwarePlatform/rocMLIR/commits/test-lld-update, I pulled the last 3 commits in between this period hoping they are enough narrow the gap.) However, ninja lld would yield a number of linker error as below:

ld.lld: error: undefined symbol: lld::elf::link(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, bool, bool)
referenced by DriversMain.cpp:0 (/root/rocMLIR/external/llvm-project/lld/Common/DriversMain.cpp:0)

external/llvm-project/llvm/tools/lld/Common/CMakeFiles/lldCommon.dir/DriversMain.cpp.o:(lld::lldMain(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, bool))

It would take a while for our fork to completely catch up with the tip of upstream, and I'll give this another test after then. In the mean time I will not hold this review up because of it.

[aganea]

Thanks for reviewing @jerryyin !
Before going further, I'd like an review/approval from the regular lld contributors as well, whenever you got the chance @mstorsjo @MaskRay @hans @thieta

[MaskRay]

There is a layering issue. lld/Common/DriversMain.cpp references lld::elf::link which is defined in the library lldELF. lldELF depends on lldCommon so lldCommon cannot depend on lldELF.
You shall see a linker error with -DBUILD_SHARED_LIBS=on due to -Wl,-z,defs

[aganea]

As suggested by @MaskRay. This changes a few things, but it's for the best I think:

• Fix circular dependency between lldCommon and the lld drivers.
• Change safeLldMain -> lldMain and make it the only entry point.
• Pass down drivers symbols from the caller to lldCommon. This also makes it easier to discriminate between what drivers are linked in the PE, and what it isn't available.
• Remove all drivers' declarations from Drivers.h, the only usage allowed is to just use lldMain().
• Tested on Linux with -DBUILD_SHARED_LIBS=ON.

[MaskRay]

lld/Common/CMakeLists.txt

30

Keep the file list sorted

lld/Common/DriversMain.cpp

1 ↗

(On Diff #494949)

DriverMain instead of DriversMain? I wonder whether Dispatcher in the filename can make it clearer. We have many functions/files with main or Main in the names now...

Also, the header needs a fix.

lld/tools/lld/lld.cpp

92

This can call unsafeLldMain instead, then the parameter bool libUsage can be removed. The downside is that unsafeLldMain will be in an include header but that's probably fine (unsure whether moving it into a nested namespace to discourage its use is useful).

[MaskRay]

Thanks for the patch! I have gone through the code and it looks in a good shape. Left some suggestions.

lld/Common/DriversMain.cpp

60 ↗

(On Diff #494949)

Hopefully share with other template instantiations to decrease the executable size.

152 ↗

(On Diff #494949)

178 ↗

(On Diff #494949)

lld::lldMain (see https://llvm.org/docs/CodingStandards.html#use-namespace-qualifiers-to-implement-previously-declared-functions)

Fix other places as well.

lld/ELF/Driver.cpp

111

https://llvm.org/docs/CodingStandards.html#use-namespace-qualifiers-to-implement-previously-declared-functions

lld/ELF/Options.td

739 ↗

(On Diff #494949)

We should avoid ignoring -flavor in all drivers. It's probably not difficult to strip -flavor from the driver dispatcher.

lld/MachO/Driver.cpp

1367

https://llvm.org/docs/CodingStandards.html#use-namespace-qualifiers-to-implement-previously-declared-functions

lld/unittests/AsLibAll/AllDrivers.cpp

19

static

lld/unittests/AsLibAll/CMakeLists.txt

2

Add a file-level comment explaining what AsLibAll means.

lld/unittests/AsLibELF/CMakeLists.txt

2

Add a file-level comment explaining what AsLibELF means.

lld/unittests/AsLibELF/ROCm.cpp

9

Add a comment about the purpose.

22

remove braces

29

static

lld/unittests/AsLibELF/SomeDrivers.cpp

13

static

[MaskRay]

lld/ELF/Options.td

739 ↗

(On Diff #494949)

Note: we can assert that -flavor is a very first option, i.e. lld -xxx -yyy -flavor gnu isn't allowed.
This may simplify striping the -flavor option.

[MaskRay]

lld/tools/lld/lld.cpp

71

Latest clang gives warnings in a -DLLD_DEFAULT_LD_LLD_IS_MINGW=on build.

/home/maskray/llvm/lld/tools/lld/lld.cpp:64:21: warning: extra ';' outside of a function is incompatible with C++98 [-Wc++98-compat-extra-semi]
LLD_HAS_DRIVER(coff);
                    ^

[MaskRay]

The comment around lld/docs/index.rst:35 needs an update. It still suggests lld::elf::link.

[aganea]

As suggested by @MaskRay

[aganea]

Thanks for the in-depth review @MaskRay, I appreciate!

lld/Common/DriversMain.cpp

60 ↗

(On Diff #494949)

I checked with CruncherSharp, there are already ,256 instances in the PE image.

lld/ELF/Driver.cpp

111

This pattern works only if the symbol is "public", as in, declared in a header that has been seen already by the current TU. Which is not the case here, I've removed declarations for direct drivers calls, only lld::lldMain remains in Drivers.h. Same comment for the other places where this pattern isn't applicable.

lld/MachO/Driver.cpp

1367

It isn't applicable here, since I remove the declarations from Driver.h

lld/tools/lld/lld.cpp

71

Hmm I don't see this with latest patch, would you have a chance to check again if it's still there?

[MaskRay]

lld/Common/Args.cpp

95

This code introduces a new function. We can strip -flavor near whichDriver or its caller to move all -flavor handling to a single place and avoid polluting the common code.

lld/Common/DriverDispatcher.cpp

159

delete blank line

162

d(...) returns a bool, not an int. exitLld(r) passes the bool to CrashRecoveryContext::throwIfCrash (isCrash expects an exit code) which seems incorrect.

lld/unittests/AsLibAll/AllDrivers.cpp

16

warning: extra ';' outside of a function is incompatible with C++98 [-Wc++98-compat-extra-semi]

lld/unittests/AsLibELF/ROCm.cpp

36

warning: extra ';' outside of a function is incompatible with C++98 [-Wc++98-compat-extra-semi]

lld/unittests/AsLibELF/SomeDrivers.cpp

17

warning: extra ';' outside of a function is incompatible with C++98 [-Wc++98-compat-extra-semi]

[aganea]

As sugested by @MaskRay

lld/Common/DriverDispatcher.cpp

162

Actually the bool to int conversion is correct. The drivers and thus d returns false on error, true on success. We invert the result and that makes r equal 1 on error, and 0 on success, which is the value that will be returned by the application. throwIfCrash will be really useful when getting back from the CrashRecoveryHandler below in lld::lldMain, but on this particular codepath in unsafeLldMain that will never be hit.
I've added an extra comment to clarify. Please let me know if you think more should be done.

[MaskRay]

Looks great!

lld/tools/lld/lld.cpp

71

The warning goes away! Thanks.