[Clang][Driver] GCC used as backend linking driver in scenarios that do not call for it

[mintsuki]

Hello,

I open this issue to replace PR #149681. I closed that PR as I do not feel I have the know-how to make modifications of this scale on LLVM's codebase, or the Clang driver, to effectively contribute to the project without wasting too much of everyone's time.

Boring introduction aside, this is the issue I face:

In many cases, the clang driver will call into host gcc to handle linking despite the fact that it sometimes makes no sense given the triple mismatch between the host gcc and the target used with clang. For example, linking a loongarch64-elf program with clang will call an x86_64-linux-gnu host gcc for linking, despite the fact that both the architecture and the OS/environment are completely mismatched; gcc isn't a native cross compiler unlike Clang.

As an aside, what even is the rationale for calling into gcc for linking, at all? The clang driver is, for what I was able to tell, perfectly capable of handling the linking of aarch64-elf and riscv64-elf programs without calling into gcc, as it seems there are explicit exceptions carved out for these specific targets, and a few others (sorry if this is incorrect, I, again, am not an LLVM expert).

These exceptions seem arbitrary. For how I see it, system gcc should absolutely never, ever be called unless the triple (as per gcc -dumpmachine) matches our Clang target. If ever.

As it stands, this just so happens to work, in most cases. Mostly because the gcc driver will forward arguments down, more or less untouched, to the linker of choice. These arguments, by the way, can include LLVM IR bitcode objects in the case of using LTO, which otherwise gcc has no idea how to handle.

To me, if Clang/LLVM are to be a drop in replacement for a GNU-compatible toolchain (amongst other things of course), and native cross compilers at that, it makes no sense in general to ever call into gcc, for any reason. But assuming there are good reasons that I am ignorant about to call into gcc, this should only ever be done, IMO, after making sure that the gcc being called into actually targets the same system.

[mintsuki]

Something I didn't mention, or mention clearly enough, is that, additionally, defaulting to calling gcc for linking will always prefer ld.bfd, unless explicitly overridden, and won't pass the required LTO plugins, breaking LTO, even if the target triple matches. And to me, this alone is enough reason that this shouldn't be done.

It also breaks cross compilation but that's obvious enough.

Funnily enough, on my system, if doing a native build of something with -flto, everything works as the clang driver seems to actually call the linker directly with the appropriate plugins passed (though it still defaults to calling ld, rather than preferring lld).

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: None (mintsuki)

Hello,

I open this issue to replace PR #149681. I closed that PR as I do not feel I have the know-how to make modifications of this scale on LLVM's codebase, or the Clang driver, to effectively contribute to the project without wasting too much of everyone's time.

Boring introduction aside, this is the issue I face:

In many cases, the clang driver will call into host gcc to handle linking despite the fact that it sometimes makes no sense given the triple mismatch between the host gcc and the target used with clang. For example, linking a loongarch64-elf program with clang will call an x86_64-linux-gnu host gcc for linking, despite the fact that both the architecture and the OS/environment are completely mismatched; gcc isn't a native cross compiler unlike Clang.

As an aside, what even is the rationale for calling into gcc for linking, at all? The clang driver is, for what I was able to tell, perfectly capable of handling the linking of aarch64-elf and riscv64-elf programs without calling into gcc, as it seems there are explicit exceptions carved out for these specific targets, and a few others (sorry if this is incorrect, I, again, am not an LLVM expert).

These exceptions seem arbitrary. For how I see it, system gcc should absolutely never, ever be called unless the triple (as per gcc -dumpmachine) matches our Clang target. If ever.

As it stands, this just so happens to work, in most cases. Mostly because the gcc driver will forward arguments down, more or less untouched, to the linker of choice. These arguments, by the way, can include LLVM IR bitcode objects in the case of using LTO, which otherwise gcc has no idea how to handle.

To me, if Clang/LLVM are to be a drop in replacement for a GNU-compatible toolchain (amongst other things of course), and native cross compilers at that, it makes no sense in general to ever call into gcc, for any reason. But assuming there are good reasons that I am ignorant about to call into gcc, this should only ever be done, IMO, after making sure that the gcc being called into actually targets the same system.

[mintsuki]

On macOS, where gcc is a symlink to clang, using a target that uses gcc like x86_64-elf will cause the driver to basically call itself, but stripping out the target flag, which makes doing something like -fuse-ld=lld --ld-path=<path to ld.lld> impossible, without clang passing a bunch of macOS specific flags to the linker due to the target having been stripped.

[mintsuki]

cc @MaskRay