microsoft / vscode-cmake-tools

CMake integration in Visual Studio Code
https://marketplace.visualstudio.com/items?itemName=vector-of-bool.cmake-tools
MIT License
1.48k stars 454 forks source link

OSX Problem to get debug from cache. Error: Unable to find GDB in default search path #514

Open hemmick opened 6 years ago

hemmick commented 6 years ago

Brief Issue Summary

On OSX with a cross compiler in $ARMGCC_DIR attempting to debug via jtag with cortex-debug yields the error:

"Problem to get debug from cache. Error: Unable to find GDB in default search path and /usr/local/opt/toolchain/lldb-arm-none-eabi/bin/arm-none-eabi-lldb."

from CMake Tools

this is with gdb installed in /usr/local/bin, the same place cmake is installed and cmake.cmakePath="/usr/local/bin/cmake"

I don't expect that an arm-none-eabi-lldb is required if my jtag is acting as a gdb server, so what do I do to get rid of this error so that CMake can see gdb?

Expected:

  1. configure CMake tools to create a CMakeCache that stores the location of gdb
  2. click the "Debug" button
  3. gdb launches and attaches

Apparent Behavior:

CMake configure seems to not be aware of my PATH? or perhaps only the path to the debugger . I can compile fine, which requires access to environment variables and an updated PATH (to point to my cross-compiler) . what I am not getting is why "Unable to find GDB in default search path" is occuring

  1. Push button
  2. CMake tools reports Unable to find GDB

CMake Tools Log

[build] [29/30  96% :: 0.520] Building C object CMakeFiles/<output_thing>.obj
[build] [30/30 100% :: 0.550] Linking C executable Debug/<arm_executable>.elf
[driver] Run _refreshExpansions
[cms-driver] Run doRefreshExpansions
[driver] Run _refreshExpansions cb
[build] Build finished with exit code 0
[cache] Reading CMake cache file /<project_root>/build/CMakeCache.txt
[cache] Parsing CMake cache string
[proc] Executing command: /usr/local/opt/toolchain/lldb-arm-none-eabi/bin/arm-none-eabi-lldb --version
[cache] Reading CMake cache file /<project_root>/build/CMakeCache.txt
[main] Problem to get debug from cache. Error: Unable to find GDB in default search path and /usr/local/opt/toolchain/lldb-arm-none-eabi/bin/arm-none-eabi-lldb.
[extension] [3824] cmake.debugTarget finished (returned null)
[cache] Parsing CMake cache string

Platform and Versions

hemmick commented 6 years ago

After adding the following to my CMakeLists.txt

SET(CMAKE_C_COMPILER "arm-none-eabi-gcc" CACHE FILEPATH "Compiler") 
SET(CMAKE_CXX_COMPILER "arm-none-eabi-c++" CACHE FILEPATH "Compiler")

the error is now:

[build] Starting build
[driver] Start build agent_firmware.elf
[driver] Runnnig pre-configure checks and steps
[proc] Executing command: /usr/local/bin/cmake --build <project_root>/build --config Debug --target firmware.elf -- -j 10
[build] ninja: no work to do.
[driver] Run _refreshExpansions
[cms-driver] Run doRefreshExpansions
[driver] Run _refreshExpansions cb
[build] Build finished with exit code 0
[cache] Reading CMake cache file <project_root>/build/CMakeCache.txt
[cache] Parsing CMake cache string
[main] Debug configuration from cache:  null
[extension] [6834] cmake.debugTarget finished (returned null)
[cache] Reading CMake cache file <project_root>/build/CMakeCache.txt
[cache] Parsing CMake cache string

A corresponding popup "Unable to generate a debugging configuration." appears in VSCode

hemmick commented 6 years ago

here's my toolchain file, armcc.cmake:

INCLUDE(CMakeForceCompiler)

# TOOLCHAIN EXTENSION
IF(WIN32)
    SET(TOOLCHAIN_EXT ".exe")
ELSE()
    SET(TOOLCHAIN_EXT "")
ENDIF()

# EXECUTABLE EXTENSION
SET (CMAKE_EXECUTABLE_SUFFIX ".elf")

# TOOLCHAIN_DIR AND NANO LIBRARY
SET(TOOLCHAIN_DIR $ENV{ARMGCC_DIR})
STRING(REGEX REPLACE "\\\\" "/" TOOLCHAIN_DIR "${TOOLCHAIN_DIR}")

IF(NOT TOOLCHAIN_DIR)
    MESSAGE(FATAL_ERROR "***Please set ARMGCC_DIR in envionment variables***")
ENDIF()

MESSAGE(STATUS "TOOLCHAIN_DIR: " ${TOOLCHAIN_DIR})

# TARGET_TRIPLET
SET(TARGET_TRIPLET "arm-none-eabi")

SET(TOOLCHAIN_BIN_DIR ${TOOLCHAIN_DIR}/bin)
SET(TOOLCHAIN_INC_DIR ${TOOLCHAIN_DIR}/${TARGET_TRIPLET}/include)
SET(TOOLCHAIN_LIB_DIR ${TOOLCHAIN_DIR}/${TARGET_TRIPLET}/lib)

SET(CMAKE_SYSTEM_NAME Generic)
SET(CMAKE_SYSTEM_PROCESSOR arm)

CMAKE_FORCE_C_COMPILER(${TOOLCHAIN_BIN_DIR}/${TARGET_TRIPLET}-gcc${TOOLCHAIN_EXT} GNU)
CMAKE_FORCE_CXX_COMPILER(${TOOLCHAIN_BIN_DIR}/${TARGET_TRIPLET}-g++${TOOLCHAIN_EXT} GNU)
SET(CMAKE_ASM_COMPILER ${TOOLCHAIN_BIN_DIR}/${TARGET_TRIPLET}-gcc${TOOLCHAIN_EXT})

SET(CMAKE_OBJCOPY ${TOOLCHAIN_BIN_DIR}/${TARGET_TRIPLET}-objcopy CACHE INTERNAL "objcopy tool")
SET(CMAKE_OBJDUMP ${TOOLCHAIN_BIN_DIR}/${TARGET_TRIPLET}-objdump CACHE INTERNAL "objdump tool")

SET(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -O0 -g" CACHE INTERNAL "c compiler flags debug")
SET(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -O0 -g" CACHE INTERNAL "cxx compiler flags debug")
SET(CMAKE_ASM_FLAGS_DEBUG "${CMAKE_ASM_FLAGS_DEBUG} -g" CACHE INTERNAL "asm compiler flags debug")
SET(CMAKE_EXE_LINKER_FLAGS_DEBUG "${CMAKE_EXE_LINKER_FLAGS_DEBUG}" CACHE INTERNAL "linker flags debug")

SET(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} -O3 " CACHE INTERNAL "c compiler flags release")
SET(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -O3 " CACHE INTERNAL "cxx compiler flags release")
SET(CMAKE_ASM_FLAGS_RELEASE "${CMAKE_ASM_FLAGS_RELEASE}" CACHE INTERNAL "asm compiler flags release")
SET(CMAKE_EXE_LINKER_FLAGS_RELESE "${CMAKE_EXE_LINKER_FLAGS_RELESE}" CACHE INTERNAL "linker flags release")

SET(CMAKE_FIND_ROOT_PATH ${TOOLCHAIN_DIR}/${TARGET_TRIPLET} ${EXTRA_FIND_PATH})
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

SET(EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/${CMAKE_BUILD_TYPE})
SET(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/${CMAKE_BUILD_TYPE})

MESSAGE(STATUS "BUILD_TYPE: " ${CMAKE_BUILD_TYPE})

I'm noticing I get a warning when I delete and regenerate my CMake configuration:

The CMAKE_FORCE_CXX_COMPILER macro is deprecated. Instead just set [cmake] CMAKE_CXX_COMPILER and allow CMake to identify the compiler.

But when I attempt to do so I get an " undefined reference to `_exit' " corresponding to semihosting for the arm-none-eabi cross compiler. See link for related error:

https://stackoverflow.com/questions/19419782/exit-c-text0x18-undefined-reference-to-exit-when-using-arm-none-eabi-gcc

If I then add:

SET(CMAKE_CXX_COMPILER ${TOOLCHAIN_BIN_DIR}/${TARGET_TRIPLET}-c++${TOOLCHAIN_EXT} --specs=rdimon.specs)
SET(CMAKE_C_COMPILER ${TOOLCHAIN_BIN_DIR}/${TARGET_TRIPLET}-gcc${TOOLCHAIN_EXT} --specs=rdimon.specs)

to my armcc.cmake I get "Unable to generate debug configuration" again...

andreeis commented 4 years ago

A fix in the 1.4 release (that will be released soon) will make it possible for the extension to properly consume debugger path settings via cmake.debugConfig (miDebuggerPath).

andreeis commented 4 years ago

CMake Tools 1.4.0 Beta is available on GitHub. https://github.com/microsoft/vscode-cmake-tools/releases/tag/1.4.0-beta

Please try it out and let us know if you encounter any issues.

charlesfayal commented 4 years ago

Didn't fix this issue for me

andreeis commented 4 years ago

I see. Then we will have a more detailed look at your scenario for one of our future releases. In the meantime, please confirm if the work around (setting cmake.debugConfig - miDebuggerPath) didn't work for you. That was actually what the fix addressed.

tjayrush commented 3 years ago

@andreeis How does one "Set cmake.debugConfig - miDebuggerPath"?

andreeis commented 3 years ago

In your project .vscode/settings.json you can write this:

"cmake.debugConfig": {
    "miDebuggerPath": "define/your/path/here"
}
github-actions[bot] commented 1 year ago

This issue is now marked as 'stale-old' due to there being no activity on it for the past 720 days. Unless the 'stale-old' label is removed or the issue is commented on, this will be remain open for at least 14 days and then it may be closed. If you would like to make this issue exempt from getting stale, please add the 'stale-exempt' label.

gcampbell-msft commented 1 month ago

@hemmick @tjayrush @charlesfayal Could you all confirm whether you are still seeing this issue? Since this issue has been around for quite awhile, I am trying to learn the state of the bug to understand whether it still needs investigation or if it can be closed. Thanks!

thedmd commented 1 month ago

Xcode 15.3 CMake Tools v1.19.52 macOS 14.5 (23F79) (ARM)

Issue appears to be still in there: Image

[proc] Executing command: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lldb --version
[proc] The command: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lldb --version exited with code: 127

I do not see lldb in the path above.

lldb can be found in /Applications/Xcode.app/Contents/Developer/usr/bin

This is confirmed by xcodebuild -find:

xcodebuild -find lldb
/Applications/Xcode.app/Contents/Developer/usr/bin/lldb

I tried to set 'miDebuggerPath' which give me an error:

Starting: "/Applications/Xcode.app/Contents/Developer/usr/bin/lldb" --interpreter=mi
error: unknown option: --interpreter=mi
Use 'lldb --help' for a complete list of options.
"/Applications/Xcode.app/Contents/Developer/usr/bin/lldb" exited with code 1 (0x1).

I do admit I stopped tracking what Apple change in Xcode some time ago.

Amy-Li03 commented 1 month ago

Hi @thedmd , thanks for your detailed reply! I found an issue: https://github.com/microsoft/vscode-cmake-tools/issues/1060, it's about "Unable to find GDB in default search path" when using CMake Tools's Debug. Please to review whether this is same as yours, if yes, maybe you can reference it to resolve your issue, thanks!

gcampbell-msft commented 1 month ago

@thedmd Please keep in mind that you can set up your debugging configuration manually using the launch.json. However, we will keep this on our backlog and investigate it when we can.