-
Notifications
You must be signed in to change notification settings - Fork 14.6k
Description
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.