<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/149850>149850</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [Clang][Driver] GCC used as backend linking driver in scenarios that do not call for it
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            clang
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          mintsuki
      </td>
    </tr>
</table>

<pre>
    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](https://github.com/llvm/llvm-project/blob/07100c6658c71e4016675e624da8c94543479745/clang/lib/Driver/ToolChains/BareMetal.cpp#L365) (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.
</pre>
<img width="1" height="1" alt="" src="http://email.email.llvm.org/o/eJyUVkuP47gR_jXsS6ENm5Zk--BDP-CNgZlMsJnkGpSoksRtiiWQlN3-90FR6sfMzh725G6RrOf3fVUYo-080VGVj6p8vsMp9RyOg_UpTi_2rubmdvwHOcdKP6n1g1o_nIFH8pB6G8HGOBEkhkCjQ0Pwr99B6e2mOFT7zQrOYBxHaiD1mOQMI5yhYfCcoCVycIYeLwSpJ3jxfL3v-SrmBnwhGLixrTWYLPsI3M4uo0FHwB6-fPnvV6V3EQw3VGMkpZ-AQ7b15NB30AR7oSCfEwO1LZlkL-RuYNinYOsp5djlwRj4DzIJrjb1PCW4YkzWd5CYYZhML-7pQuHGnrLTZAdazQV55CBXrU-Bm8lIuIDRNjmgpUzZyVytM7RoSG0flnJ6GNDfwGCkOL8gUNXaSAqqWi9ZwNU6BwadE0cMPcck1zpj5JJ8Qd84Amf9i4TTUBxtmkvboklzD2yCyANJ9DFXOYJniOQjQWcvua8EKdjREQw2DphMDzWlKy1nPzlG38xPMHSUYJJuSxE_p7CCEwegVxxGl4vyFiPKLcfsOwymr4p7cq0YHQN3AYc_GfpUBPRy8Lqv_lcV98766fW-85Pc-SnAlsObP3H967LUnPr8SeKwiUyaAr3n9u3fSp_IX2xgP5BPgIHAsGSTBE5vdaJGbR8_ubbRK71LgOBRkAcmcIz5pXUUYPLOvixgXbD0ECWzd_RcJTiStiwQCpkNwgDJSyqxQI__OmVMgM6p7Qm-_xpaNuNOXmV_Z0E_YO1mdpBzcjxSEAIJe3DMh9zOmMs86T-Qx604wR9bKrVU1TrYaC5_anR8592vM8pZxAxeoiFXQtoTCFT5SK-js8YmoFdD4ywWBsOFGhCL7SwJkSCOZERQFqzmpCUshJauwGI0qvJZ6X2f0hiFofqk9KmzqZ_qleFB6ZNzl7ef-0U0lD7VjmulT-vdZr02VVXuzW5DxXpTVbuSKl00uDeHoiy2xe6wK0qlT3MP9MlZefi8KNXpO7N76tH6qPTpEQN9pYRuZcZR6e2XbVUqfQCl95FDuIFt3_XFesMh5Gie4JxT69D6_MeQ9RZnyQR6HSkkpQ8L5L7n4nwqntQYMNQ2BQy3mbyiy2c5AZs9xFtMNHzCXOx5cg0o_YB1ZDdlYnha9Hf-fYCacoepEexTjJ_VRuk9RoHZYhXum2kYBzS99ZRBcICZZhF4CovGz71cwXnW5w8aCVgS-ia-q_AfUxT1gx7HkXwUcF85vMi59TCIbGQRXsFXjgL0mgxOkd4Uecn0sx63HK4YGsDQTaIMERq-5qIPHEimUc5y8omnrA_zLHpjCwUhi-nZGlrB3Ih3U3K3vuW7V7zJf0o_GPTSajc1NHfz_DvUNskIBK4FjQKF_EhyEfNTFEJ9-f5N6YdZU6zMM4H71cbPmfWYp4FtCGEZxPNQeUMKw5BlybZz9ZU-5SCEiYmluwhN4FFCWDaCrJfCQYTf_vmfe9E-THbWFnZGoJ47P7DvYprDknb5Lo98w1OQyX54I-svlTSKxomQ5-DSz4PNeujIU0CXFwHp3scg_UFkcqD-BoEwsl_B45QAY5yGReMW1emYm-VOnAfIWVhmO88BZT7UojyJ_8rNvMjMjGHvbnNMNUGT14snOH_9lhNuEwXJRtxHGUnZ2Y94rElOF1plX2jShM7d3oQuP4g40ELb1V1z3DaH7QHv6LjZldvNpjoU5V1_3GqsasL6UBbtfr2vNvttW64b3G22pjhUmzt71Gtdrnd6s6nKsihXG6x0c9hUxVaXxa4tVbGmAa1biUKuOHR3ees5borDvlzfOazJxbxtar1ooJbFMxyzpNZTF1Wxdjam-GEi2eTyijqjrnxW5eMimeUz_Pb0NO8dGKFG80K--diClgnnIRryGCwvDVuW0Nwg6bpNd1Nwx7-t_Dk7EeslwctR_z8AAP__6eTQ3w">