clangd assumes compiler target is 'x86_64-pc-windows-msvc' for .cpp files

[jostlowe]

Hi!

I have set up a project for the STM32H523RET6 using the following setup:

CubeMX: 6.15.0

STM32 vscode extension: 3.5.1

The project is configured to use starm-clang and starm-clang++ and the STARM_PICOLIBC toolchain

I have created a .cpp file () that i added to my build and updated my CMakeLists.txt with the following:

 

# Setup compiler settings
set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS ON)

...

enable_language(C CXX ASM)

...

# Add sources to executable
target_sources(${CMAKE_PROJECT_NAME} PRIVATE
 Core/Src/myclass.cpp
 # Add user sources here
)

 

When building the project, it compiles fine, but clangd reports the following problem:

 

nsupported option '-mcpu=' for target 'x86_64-pc-windows-msvc'clang(drv_unsupported_opt_for_target)
Unsupported option '-mfpu=' for target 'x86_64-pc-windows-msvc'clang(drv_unsupported_opt_for_target)
Unsupported option '-mfloat-abi=' for target 'x86_64-pc-windows-msvc'clang(drv_unsupported_opt_for_target)

 

Is this a known issue?

For reference (or anyone having a similar issue) i managed to temporarily fix the issue by explicitly setting the target for clangd by changing the .clangd file from

 

CompileFlags:
 Add:
 - '-ferror-limit=0'
 - '-Wno-implicit-int'
 CompilationDatabase: build/Debug
Diagnostics:
 Suppress:
 - unused-includes
 - unknown_typename
 - unknown_typename_suggest
 - typename_requires_specqual

to

CompileFlags:
 Add:
 - '-ferror-limit=0'
 - '-Wno-implicit-int'
 - '-target'
 - 'thumbv8m.main-st-none-eabihf'
 - '-mfpu=fpv4-sp-d16'
 - '-fno-exceptions'
 - '-fno-rtti'
 CompilationDatabase: build/Debug
Diagnostics:
 Suppress:
 - unused-includes
 - unknown_typename
 - unknown_typename_suggest
 - typename_requires_specqual

 

[Cartu38 OpenDev]

@jostlowe sounds weird.

I've very same usage than you (STM32CubeMX project, ST ARM clang compiler & picolib usage) and works like a charm.

 

Are you pointing to right compilation database serving clangd ?

Have a look to:

[jostlowe]

Thanks for the quick response :) 

Checking that it point to the correct compilation database in the way you suggest i get the following:

 

I[14:07:40.019] Loaded compilation database from c:\my\path\project_folder\build\Debug\compile_commands.json

 

[Cartu38 OpenDev]

Ok ... and what if looking for 'clangd.exe' as part of filter of the very same output channel ?

Are you getting in real something like '<local path>\st-arm-clangd\19.1.2+st.3\bin\st-arm-clangd.exe' ?

Asking because you have to rely on ARM embedded LLVM utilities not PC ones.

[jostlowe]

 C:\Users\<username>\AppData\Local\stm32cube\bundles\st-arm-clangd\19.1.2+st.3\bin\starm-clangd.exe

Did what you suggested: Seems to be using the right utilities?

[Cartu38 OpenDev]

Yes it is. So ?

[jostlowe]

Still seeing the same errors. 

Its no biggie, as i got it to work with the fix in the .clangd file, but I thought it might be interesting for the devs of the STM32 VScode extension to have a look at

[vincent_grenet]

@jostlowe Thanks for reporting here.
Already I can share we have a fix within our current code base about C++ support see https://community.st.com/t5/stm32cube-for-visual-studio-code/clangd-intellisense-issues-plugin-generated-query-driver/td-p/821738 . Will be shared Thanks next update planned already in coming weeks.

When it comes to your unsupported options we have to dig into more because not able to reproduce locally the pain.
Weird stuff is are highlighted by @Cartu38 OpenDev sounds you're not getting right toolchain invoked ... 

target 'x86_64-pc-windows-msvc'

 is ???

[FluxPower42]

Hi @vincent_grenet , @vincent_grenet , @Cartu38 OpenDev 

I have now spent some time on this issue and believe I have taken a small step toward a solution.

My Prerequisites

1. In the Cube32MX project (project-name.ioc)

• under 'Project Manager' / 'Project' / 'Toolchain / IDE'  = 'CMake'
• under 'Project Manager' / 'Project' / 'Default Compiler/Linker' = 'Starm-Clang'
• In the generated file 'cmake/starm-clang.cmake' in line 28
  'STARM_NEWLIB' is used instead of 'STARM_HYBRID':

set(STARM_TOOLCHAIN_CONFIG "STARM_NEWLIB")​

2. Minimum content of the '.clangd' file: 

CompileFlags:
 CompilationDatabase: build/Debug​

Now back to the clangd problem, or hopefully to the solution

In my opinion, the problem lies in the fact that clangd does not successfully query the clang(++) compiler about which intrinsic includes it uses.

Two things are necessary for a successful query:

1. Path to the clangd compiler:
The links to the compilers are stored in the 'settings.json' (or 'project-name.code-workspace') file:

“--query-driver=${env:CUBE_BUNDLE_PATH}/st-arm-clang/19.1.6+st.8/bin/starm-clang.exe”
“--query-driver=${env:CUBE_BUNDLE_PATH}/st-arm-clang/19.1.6+st.8/bin/starm-clang++.exe”​

Problem here:
The 'starm-clang++.exe' part is removed from the file shortly after each restart of the 'STM32Cube clangd VSCode Extension'. And therefore every time the project is opened in VSCode!
Solution:
You can either re-enter this path manually each time or run a script in the background that checks the contents after saving the settings.json (or project-name.code-workspace) file and adds the entry again if necessary (my solution until ST fixed this). 

2. Information about which target is used
The clangd now queries the clang(++) compiler for the intrinsic includes using the information stored in the CMake generated file '\build\Debug\compile_commands.json'.
Problem here:
Unfortunately, clangd cannot do anything with the stored  gcc standard 'TARGET-FLAGS' such as '-mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard'.
This can also be seen from the fact that clangd opens completely incorrect include files.
Solution:
If you now add the correct target via '--target=xyz' in line 37 of the file 'cmake/starm-clang.cmake'.
In my case:

# MCU specific flags
set(TARGET_FLAGS "--target=thumbv7em-st-none-eabihf -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard ${TOOLCHAIN_MULTILIBS}")​

Then: 

• deletes the build folder so that clangd no longer the cache
• and executes 'CMake: Delete Cache and Reconfigure' so that compile_commands.json is regenerated
  clangd works perfectly for me, even with C++ files.

 

If you like to test with a real project and if you have a NUCLEO-H753ZI board, you can try out my little demo:
https://github.com/TimoEngelmann/nucleo-h753zi-threadx-demo
(dont forget to add clang++ entry after open the project in VSCode)

Best regards,
Timo

[unsigned_char_array]

---

@FluxPower42 wrote:

# MCU specific flags
set(TARGET_FLAGS "--target=thumbv7em-st-none-eabihf -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard ${TOOLCHAIN_MULTILIBS}")​

---

I tried this, but it failed initially:

[build] Parse error. Expected a command name, got unquoted argument with text
[build] "ÔÇï".

It turns out there is an invisible non-ascii character after your closing parenthesis! Removing it fixed it for me. Can you please update your code so it won't fail for others too?

[vincent_grenet]

Please be aware that stm32cube-ide-build-cmake-1.40.1.vsix has been released to address C++ concerns.

[FluxPower42]

Hi @vincent_grenet 

thanks for the update.
I can confirm that the --query-driver entry starm-clang++.exe is no longer removed.

Unfortunately, however, I am (still) experiencing the following issue:
The clangd is NOT using the correct paths for the system includes.

I use here the NUCLEO-H753ZI board with STARM_NEWLIB setting. The following paths should be the right:

• C files:
  c:\Users\[user]\AppData\Local\stm32cube\bundles\st-arm-clang\19.1.6+st.9\lib\clang-runtimes\newlib\arm-none-eabi\armv7m_hard_fpv5_d16\include
  
  
• C++ files:
  c:\Users\[user]\AppData\Local\stm32cube\bundles\st-arm-clang\19.1.6+st.9\lib\clang-runtimes\newlib\arm-none-eabi\armv7m_hard_fpv5_d16\include\c++\v1

But if I hover the mouse over the plain C #include “pwd.h”, I see this path:
C:\Users\[user]\AppData\Local\stm32cube\bundles\st-arm-clang\19.1.6+st.9\lib\clang-runtimes\arm-none-eabi\armv4t_exn_rtti\include\pwd.h

Similarly, the path is incorrect when I hovering over the C++ #include <vector>:
C:\Users\[user]\AppData\Local\stm32cube\bundles\st-arm-clang\19.1.6+st.9\lib\clang-runtimes\arm-none-eabi\armv4t_exn_rtti\include\c++\v1\vector

To be absolutely sure that this is NOT the correct path, I can open these headers by clicking the blue Follow link and insert an #error “Test” at the beginning of the file. After this I perform a >CMake: Clean Rebuild , but the build is still error-free. This means: this file is not used for the build but clangd is using this. If I insert now the same #error line into the vector header file in the correct path, the build aborts as expected.

To test this easily, the attached ZIP file contains a very simple project with an application.cpp file.

 

The following changes/additions have been made:

./nucleo-h753zi-simple.ioc (via STM32CubeMx)
- NUCLEO-H753ZI board file error corrected: LD2 pin changed from PB7 to PE1 (ST: please correct the NUCLEO-H753ZI board file).
- Toolchain/IDE = CMake
- Default compiler/linker = Starm-Clang

 

./Application
- application.cpp added
- application.hpp added

 

./Core/Src/main.c
- #include “application.hpp” added to line 24.
- Call appMain(); added to line 95.

./cmake/starm-clang.cmake
- Line 28 set to: set(STARM_TOOLCHAIN_CONFIG “STARM_NEWLIB”)

 

./CMakeLists.txt
- File application.cpp added to target_sources.
- Directory Application added to target_include_directories.

 

To use this, you have to generate the files with the STM32CubeMX and open the folder with VSCode (with installed STM32Cube for VSCode extension).


Additional:
It is not clear to me why clangd does not use the correct path.
If I add --log=verbose and "stm32cube-ide-clangd.trace”: “clangd_trace.json” to settings.json,  it is possible to check what information clangd gets.
If I search for "vector" string I get lines with the correct path (in a "message" node):

but also with the wrong path:

@vincent_grenet 
Can you explain me this behaivior and how can I fix this?

[vincent_grenet]

@FluxPower42, thanks for confirming that the first fix is okay with you.

The second issue has been reproduced and confirmed.

For now, I’m able to solve the issue by hacking the .clangd file.

This may help in the short term while we work on a more solid fix. Please confirm.

I will update you once it’s fully resolved.