Issue with "multilib.yaml" error when using ST_ARM_CLANG in VS Code

[ANeam.1]

Hi,

I am using the latest version of STM32Cube extension for VS Code (3.8.0). I created a simple project for STM32H735G-DK board using CMake as the toolchain and ST-ARM-CLANG as the compiler. I do not know if it is relevant, but I also enabled FreeRTOS and configured the USE_NEWLIB_REENTRANT option to Enabled.

I generated the project and I am compiling it with VSCode. I changed in the starm-clang.make to use the NEWLIB instead of the PICOLIBC:

set(STARM_TOOLCHAIN_CONFIG "STARM_NEWLIB")

The compilation works, but clangd complains about some errors. In the output of clangd, I can see multiple instances of:

D:\ST\stm32cube\bundles\st-arm-clang\21.1.1+st.6\bin\..\lib\clang-runtimes\multilib.yaml:47:3: error: unknown key 'IncludeDirs'
 IncludeDirs:
 ^~~~~~~~~~~
D:\ST\stm32cube\bundles\st-arm-clang\21.1.1+st.6\bin\..\lib\clang-runtimes\multilib.yaml:21:1: error: multilib "arm-none-eabi/armv4t_exn_rtti_size" specifies undefined group name "stdlibs"
MultilibVersion: '1.0'
^

and because of these errors some headers are not found, like:

 

Thank you!

[FluxPower42]

Hi @ANeam.1 ,

could you check what STM32Cube clangd outputs under “OUTPUT” when you run it?
After opening the project in VSCode and opening the first source file, I get this:

 

If you see here old versions, please check the VSCode settings:

(Depending on whether you're using a workspace file, the storage location varies: Workspace, or project folder.)

To get the correct path here, simply delete the two entries (preferably in the JSON view), save the file, close VSCode, and reopen it. The latest entry should now be used.



But, regarding your original question:

D:\ST\stm32cube\bundles\st-arm-clang\21.1.1+st.6\bin\..\lib\clang-runtimes\multilib.yaml:47:3: error: unknown key 'IncludeDirs'
 IncludeDirs:
 ^~~~~~~~~~~

I'm getting the same error, but I haven't noticed any issues.
The old version of multilib.yaml (included st-arm-clang v19.1.6.) don't has this "IncludeDirs:" keyword.

Maybe I'm completely misinterpreting what follows...

This LLVM/Clang RFC introduces the new keyword “IncludeDirs”:
[RFC] Support Target Triple Specific Include Paths Derived from Sysroot via multilib.yaml or Driver Logic - Clang Frontend - LLVM Discussion Forums
In this RFC are linked 2 pull requests:
1. [Multilib] Extend the Multilib system to support an IncludeDirs field. by simpal01 · Pull Request #146651 · llvm/llvm-project
2. [Clang][Driver] Fix the missing Target-Triple-Level include path resolution in Baremetal Driver by simpal01 · Pull Request #165321 · llvm/llvm-project

The second one is merged, the first not. But the first one contains the keyword "IncludeDirs:"

Maybe the patch was applied as a downstream change to the arm/arm-toolchain repository (arm/arm-toolchain#447). It is suspected that ST incorporated this patch into st-arm-clang but not into st-arm-clangd — however, no direct evidence for this has been found.

[ANeam.1]

Hi @FluxPower42 ,

Yes, for this specific bug, I made sure I have the latest drivers for --query-driver. Although I did update them manually after I updated them in the bundles manager through the extension.

I agree with you that it is tedious to update them each time you update the bundles manually. I even have other places where I need to do the same trick. Maybe there is a solution to abstract these in some sort of common place and everywhere else use the alias? Just thoughts.

[Nawres GHARBI]

Hi  @ANeam.1 
a fi is under cooking and will be delivered ASAP

[FluxPower42]

@Nawres GHARBI 

nice!

But which of these two issues?
1. clangd - multilib.yaml - IncludeDirs
2. the not updated query-driver path?
As for the second point: It would be nice if the STMCubeIDE extension asked the user after updating the toolchain whether the paths should also be updated (or did I just not see that?

Regarding the toolchain: Does ST publish the source code for the ST forks (such as st-arm-clang)?
It would be much easier to verify such behavior if the source code were publicly available, as is the case with the LLVM project.

Is there a place where we can look up which bugs are known in ST?
Since I’m reluctant to report bugs that aren’t actually bugs, I take quite a bit of time to reproduce and describe them. We could save that time if there were a page listing known bugs.
 
Beste regards,
Timo