NCS 3.3.0: CMake configure hangs at arm-zephyr-eabi-gdb-py --configuration during sysbuild on macOS

[nrbrook]

Hi Nordic team,

I’m seeing a repeatable configure hang with NCS v3.3.0 sysbuild on macOS. The visible build output stops after:

-- Found GnuLd: .../arm-zephyr-eabi/bin/ld.bfd (found version "2.38")

After inspecting the process tree, CMake is blocked waiting on:

.../opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gdb-py --configuration

The arm-zephyr-eabi-gdb-py process sits indefinitely in uninterruptible wait (U state), and the parent CMake process never continues.

Environment:

• macOS 15.6 / Darwin 24.6.0
• NCS v3.3.0
• Zephyr 4.3.99
• Sysbuild enabled

The hang happens during the inner application CMake configure launched by sysbuild.

I tried passing this workaround:

-DCMAKE_GDB=/usr/bin/false

That works for non-sysbuild builds, but with sysbuild it does not reliably solve the issue because the inner application configure does not inherit CMAKE_GDB from the top-level sysbuild configure.

I added a timeout to the command in zephyr (zephyr/cmake/bintools/gnu/target.cmake line 21):

if(CMAKE_GDB)
  execute_process(
    COMMAND ${CMAKE_GDB} --configuration
    TIMEOUT 5
    RESULTS_VARIABLE GDB_CFG_ERR
    OUTPUT_QUIET
    ERROR_QUIET
    )
endif()

This falls back to arm-zephyr-eabi-gdb when arm-zephyr-eabi-gdb-py times out.

Questions:

• Is this a known issue with arm-zephyr-eabi-gdb-py --configuration on macOS?
• Is there a recommended way to disable or override the GDB probe for sysbuild inner image configures?
• Should sysbuild propagate CMAKE_GDB to the application image, or is there another supported cache variable for this?

[nrbrook]

I did some more debugging and found what looks like the underlying cause.

`arm-zephyr-eabi-gdb-py` is linked against an absolute Homebrew Python 3.10 framework path:

/opt/homebrew/opt/[email protected]/Frameworks/Python.framework/Versions/3.10/Python

This is visible with:

otool -L /opt/nordic/ncs/toolchains/185bb0e3b6/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gdb-py

On my machine that path does not exist anymore. I only have newer Homebrew Python versions installed. Plain `arm-zephyr-eabi-gdb` does not have this dependency.

Sampling the stuck `arm-zephyr-eabi-gdb-py` process shows that it never reaches GDB code. It is stopped in dyld during process startup:

dyld4::halt
abort_with_payload
__abort_with_payload

Sampling the parent CMake process shows it is blocked in CMake’s `execute_process()` implementation waiting for the child process:

cmExecuteProcessCommand
cmsysProcess_WaitForData
__select

So this appears to be a toolchain packaging issue: the Python-enabled GDB binary has an absolute runtime dependency on `/opt/homebrew/opt/[email protected]`, but that dependency is not provided by the Nordic toolchain and is not part of the NCS toolchain Python installation.

This also explains why the timeout workaround fixes the configure: when the `gdb-py --configuration` probe times out, Zephyr falls back to plain `arm-zephyr-eabi-gdb`, which does not require Homebrew Python 3.10.

Could Nordic confirm whether `arm-zephyr-eabi-gdb-py` is expected to depend on a user-installed Homebrew `[email protected]`? If not, it seems like the macOS toolchain should either vendor/relocate that Python framework dependency, use an `@rpath`/toolchain-local dependency, or avoid probing `gdb-py` without a timeout.

[Vidar Berg]

The GDB executable bundled in our toolchains comes from the Zephyr SDK and is linked to a specific python release and will only work if you have the exact same version installed on your system. However, as mentioned in this GH issue (https://github.com/zephyrproject-rtos/sdk-ng/issues/1026), this should not be an issue as the build is supposed to fall back to the pythonless version. To troubleshoot this further, could you please try to build the same project from the terminal outside of VS code to see if it hangs then to? This is to understand if it may be related to the issue reported here: https://github.com/microsoft/vscode/issues/301063.

[nrbrook]

It would fall back if it didn't hang waiting for the gdb-py call to return, so adding a TIMEOUT to the call means it successfully falls back to gdb.

However, today arm-zephyr-eabi-gdb-py --configuration isn't hanging at all, in or out of VSCode (Cursor). I don't know what the difference is. I did update Cursor, perhaps there is a fix in VSCode recently.

[Vidar Berg]

I see, is good to hear that it works now at least, but please let us know if you encounter this problem again. I have also asked internally if anyone else has seen this. Will try to update you here if I learn anything new.