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

    <tr>
        <th>Summary</th>
        <td>
            [clangd] LLVM-style Baremetal toolchain driver was selected for TUs built with `arm-none-eabi-gcc` GNU toolchain
        </td>
    </tr>

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

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

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

<pre>
    Note: this issue is opened based on suggestion of clangd maintainer under clangd/clangd#2289. Specifics of the issue can also be found in the referred issue under clangd.

I've been building an ARM microcontroller toolchain with `arm-none-eabi` GNU toolchain provided by ARM, and clangd was used for code completion. Clangd will consume `compile_commands.json` generated by CMake Ninja generator and provide completion and live error checks in Visual Studio Code.

The issue is that, clangd will choose `clang::driver::toolchains::BareMetal` as the toolchain driver for translation units built by my GNU toolchain (for example `arm-none-eabi-gcc.exe`). Further inspection found that any toolchain that had neither an OS target nor an designated architecture will all cause `BareMetal` selected as the driver, which will lead to clangd looking for system headers in LLVM-style include paths rather than the correct GNU style. (See `clang/lib/Driver/Driver.cpp, Driver::getToolChain`.)

Using `--query-driver` is said to be *the most robust way* of fixing these issues of cross-compilation toolchains but to me this seems like a bug (not handling GNU toolchain correctly). Also, having to add `--query-driver` option on every computer that has a different GCC installation path is not so practical either. RISC-V also has a special check for existence of GNU toolchain, and when a GNU toolchain is present then a GNU-style toolchain driver will be created. Clearly this is only fixing it for RISC-V, and ARM was not getting some love. I thin maybe the detection of GNU toolchain should be improved overall so that other architectures like Xtensa (used extensively in ESP32S3, for example) will also benefit, and maintainer on clangd side suggested that this topic may be more appropriately discussed on LLVM issue tracker.


</pre>
<img width="1" height="1" alt="" src="http://email.email.llvm.org/o/eJxsVs1y2zwSfBrqMiUWRVlSdNBBkVepVNnZLTtJ7W1rCIxIxCDAxYCy-fZfDUjGys_JNImf7p6eHiGzqR3RIdt8zDb3C-xj48PhydT-wdT-6eG0qLweDl98pGx9hNgYBsPcExgG35EjDRUyafAOuK9r4mi8A38BZdHVGlo0LqJxFKB3msL0PivP88O6LD_sc3juSJmLUSybY0PTPQodoGUPFcHF906DcelzoAuFQHpad3t4nhXHrDh-zsrdlaAiclD1xmrjakAHx6dHaI0KXnkXg7eWAkTvrWrQOHg1sYFsW2Bol847WhJWJtsW8OnLt5tlXfBXo4X-IAdm5QnQ6Zn1KzL0IsvFB1BeEyjfdpZEnBxO0yJjLSjvuG9JbpQlxtL_lG9bdJrzH-yd3FyTo4BxvOz0iC8EX4z7gfMHH9LdE6Sbq9Jra64EFIIgaUi9sCj43XCPFp5jr42Hk9c0ifb1p_KGITYYhZm6Bdx4zyNeeZutj9n6qIO5Uhiff2rE4_8fMdAjRbRCBTkV713HcWfSKQZ0bDEB752JnKoWhXQ7_CZ_Vn6QLfSGwvWPei1rpXJ6o2xbZOU-h3MfYkMBjOOOVLphNJMwBHTDzdHpVYMaHJm0CR38-xkihpoiuCQ2aJLOSTXBoBoTScU-0CgRikzYjyr9Qp_JkkqbRh0m3coTvDZGNeN2S6gh-ll16_2LOFf48sCRWmgINYVUyIeH749LjoMlME7ZXhN0GBuGgAl8bHDsF-VDIBWTjml9LiI-000py7M1VVae7ydU00Ouuk4g3t8Uuab41Xt7EsWybZFn5X70zzcWrNm2WC7_31MYlhPFbSGGYjSJWkWQlUeB1XqOEHzVc4RXHLLyKP1_MW9yTGyIJzumWFDBMy_HPhl98m42qPooR7c0xhQTtQzWvBAgVH0tbJ2Xyjpt5fBfDTXJY4fkl6NlL5QbvCYcHlDrv7Py3Zh4DuhKYUjd18dRebmNAUGby4UCuQifTicxYUQ7EZBiiTICjT10AVU0Ci2M5svh6fPzafl9zMDxNLGwQTt2M4xtYDiSUyQi_cJrzqXXhhzgb5wNQxeIBVf8-X0y0x8dmqxZEahAYntJMcJgh3kogHd2mAtnYsI1Yp8xSO5KMArVmmKUhexbAuuvlMNnOclBi0NFY3NQnHr1d1bAje-tFjimldiTAXSlII3HflTej71705yTG_4byTGKHVJC05v8b65kB-mnfz3_Z10-rwXzTcBk5X5u7TSKHF1MnHndjDjv5q5lSeJpItKUM0mp6DujhKWgb30gwK4LvgsGo2DQhlXP00iV7p7iOAZULxSmmF7ow1rv13tc0GG1W2_3m91qVy6aQ1Ug7S6bqlrfrardplLbzWVXbleqXG93d5dqYQ5lUW6K1Wqz2hbbVZmvsdI7WlX6bq9WO11ldwW1aGxu7bXNfagXCcBhVa6L3XphsSLL8y-GcJBVy6qvObsrrOHI7_uiiTb9tphG_eb-Nq4kGFsJxr94Dfk9KqUMX7_Nw-Cv41ni_o8RveiDPTQxdmkOleesPNcmNn2VK99K1tnr_GfZBf-DVMzK8xg2WXme6F4P5T8BAAD__4X9L9k">