swift
swift copied to clipboard
swiftlang
Enable Build-Time Configurable Linker Selection in The Old Swift Driver
Adding the ability to specify the default linker at toolchain-build time instead of using the existing heuristics. This will allow us to build internally consistent toolchains that use lld, for example. This also lines the old driver behavior up with the new driver, which falls back on clang to determine the default linker to use. This means that the new driver is indirectly configured to use whatever CLANG_DEFAULT_LINKER was set to as its default linker. To match everything up, I am re-using that macro-define in the old driver to ensure that it uses the same linker.
You may notice that I've also pulled out the PRETTY_NAME check for the string "Amazon Linux 2023". This is fairly brittle as the string may not exactly match that (might contain build numbers or dot releases), and it isn't exactly scalable. Instead, we should just configure the toolchain to use lld when building the toolchain on (and for) Amazon Linux 2023.
Finally, I've added a new set of builbot_linux presets that use lld as the default linker (both in the new and old driver).
CC @finagolfin @futurejones
I think this should make our lives a bit easier since we don't need to try to piece in linkers for new platforms. Instead, just set the CLANG_DEFAULT_LINKER and the default linker will be whatever you want it to be.
preset=buildbot_linux,lld @swift-ci please test with preset Linux platform
I'm open to adding an independent SWIFT_DEFAULT_LINKER, but given that we probably want to keep the new and old drivers using the same linker, and that the old driver is the old driver, I don't see too much value in that (beyond readability which is certainly valuable, but also why I left a comment clarifying).
preset=buildbot_linux,lld @swift-ci please test with preset Linux platform
(even though this is what clang does).
https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/Distro.cpp Oh, that's fun. It looks like a fairly significant piece of engineering. Probably more work to get right than what is worth doing for the old Swift driver. Maybe worth considering in the new driver?
It is a large bit of complexity - do we really need it in the driver? I'd rather try to see if we can get away with the defaults. Of course, if we find that we actually have to have it, we could consider it again then.
The change as it is improves the situation, so I am not against it.
To your discussion about copying the Clang driver code: I would prefer if the legacy driver invoked clang to drive the linking and let it decide these things instead of copying code from Clang. The new driver is more hands-off, IIRC. I think Darwin works like that (but maybe it is because the default is more synced with the OS)
If one removes the lines from https://github.com/apple/swift/blob/main/lib/Driver/UnixToolChains.cpp#L225-L227 and does not try to provide a default linker (only the value taken from -use-ld), the code end up invoking Clang without any flag, and Clang will do the thing it knows how to do with their complicated code, and nobody needs to duplicate. It still leaves the door open for overriding the linker with -use-ld which is forwarded to Clang (and one can also forward -Xclang-linker --ld-path= if they need it).
Maybe worth considering in the new driver?
I should have clarified. I was not at all trying to hint that I want this. If it's absolutely necessary for the Swift driver to understand things about specific distros, it looks like something that would need the appropriate level of engineering work and not slapping it in as a quick fix.
I think being able to set it through the build system is likely quite sufficient for our needs.
If one removes the lines from https://github.com/apple/swift/blob/main/lib/Driver/UnixToolChains.cpp#L225-L227 and does not try to provide a default linker (only the value taken from -use-ld), the code end up invoking Clang without any flag, and Clang will do the thing it knows how to do with their complicated code, and nobody needs to duplicate. It still leaves the door open for overriding the linker with -use-ld which is forwarded to Clang (and one can also forward -Xclang-linker --ld-path= if they need it).
Hmm, yeah, I think I prefer that. It's more consistent with the new driver (assuming that it's picking up the clang-linker in the same way. Will verify). We lose the old behavior, but folks really shouldn't be using the old driver outside of the toolchain anyway, so I'll just be shooting myself in the foot if it goes south.
@etcwilde this looks good. Do we also need to change - https://github.com/apple/swift/blob/e431216db307a982701b53817cba0811d2e93433/CMakeLists.txt#L1011
preset=buildbot_linux,lld @swift-ci please test with preset Linux platform