Problem:
When starting a debugger session to an STM32H743ZI development board with the Embassy stm32h7 blinky example GDB crashes with this error:
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string: construction from null is not valid
TL;DR: missing null-pointer checking for the name and directory in the dwarf debug info, patches attached.
Background:
I do desktop and embedded development, for many years, in Rust and C/C++. My C/C++ is rusty though, so this patch should be checked by maintainers familiar with the code for handling dwarf files.
I tried older released versions of arm-gnu-toolchain with GDB, as follows:
arm-gnu-toolchain-13.3.rel1-mingw-w64-i686-arm-none-eabi = working, but too old, wasn’t compiled with python
arm-gnu-toolchain-14.2.rel1-mingw-w64-i686-arm-none-eabi = not working, same issue
arm-gnu-toolchain-14.3.rel1-mingw-w64-x86_64-arm-none-eabi = not working, same issue
$ /C/Program\ Files/JetBrains/CLion\ 2025.2.3/bin/gdb/win/x64/bin/gdb.exe –version (GNU gdb (GDB; JetBrains IDE bundle; build 216) 15.2) = not working, same issue
Locally built "GNU gdb (GDB) 16.3" = not working, same issue.
So down the rabbit hole I went…
After enabling RustRover 2025.2 debug logging and finding the MI2 communication sequence I found this in the log:
2025-10-04 09:19:22,164 [48150271] FINE - #c.j.c.e.debugger - 32676>31-target-select remote :1337
2025-10-04 09:19:22,379 [48150486] FINE - #c.j.c.e.debugger - 32676<terminate called after throwing an instance of 'std::logic_error'
2025-10-04 09:19:22,379 [48150486] FINE - #c.j.c.e.debugger - 32676< what(): basic_string: construction from null is not valid
I re-created this on the command line, avoiding the IDE entirely, built the the latest released version of gdb (16.2) from a release tarball, on mysys2 ucrt64, and ran it though a local gdb instance:
$ echo "-target-select remote :1337" > commands.mi2
$ gdb /ucrt64/bin/arm-none-eabi-gdb
(gdb) set args D:\\Users\\Hydra\\Documents\\dev\\projects\\embassy\\examples\\stm32h7\\target\\thumbv7em-none-eabihf\\release\\blinky --interpreter=mi2 < commands.mi2
(gdb) catch throw
(gdb) run
This caused the same error again, I dumped the backtrace.
(gdb) bt
…
#9 0x00007ff7a66e0e28 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string<std::allocator<char> > (__a=..., this=0x7feb80, __s=<optimized out>)
at C:/msys64/ucrt64/include/c++/14.2.0/bits/basic_string.h:651
#10 read_file_scope (die=0x5d42d40, cu=0x5b148b0) at dwarf2/read.c:7536
#11 process_die (die=0x5d42d40, cu=cu@entry=0x5b148b0) at dwarf2/read.c:6497
#12 0x00007ff7a66e4680 in process_full_comp_unit (pretend_language=<optimized out>, cu=0x5b148b0) at dwarf2/read.c:6260
#13 process_queue (per_objfile=<optimized out>) at dwarf2/read.c:5552
#14 dw2_do_instantiate_symtab (per_cu=0x5a69e20, per_objfile=<optimized out>, skip_partial=<optimized out>) at dwarf2/read.c:1779
…
After looking at the code and trying a few things, with the aid of chatgpt since I’m unfamiliar with the codebase and gdb internals, it seems some additional null-pointer checking is required when handing some debugging information for the `asm.S` file used in the build process for elf files generated by cargo/rust for the Embassy stm32 examples.
I made two patches, one to find_file_and_directory and one to read_file_scope.
After applying the first patch, the problem still occurred, and after further digging a second patch was made, when it was applied the debugger no-longer crashes and I’m able to step-debug the embedded rust program in RustRover 2025.2
For reference, you can generate the same elf file I was using as follows:
git clone https://github.com/embassy-rs/embassy.git
cd embassy
git checkout e4e06ab5b136a21c98d42491ef1e31b6dc25e08e
cd examples/stm32h7
cargo build --bin blinky –release
the obj-dump tool can be used to dump the dwarf debugging information.
arm-none-eabi-objdump.exe -h ./target/thumbv7em-none-eabihf/release/blinky -W > dwarf.txt
I then checked out the latest version of gdb from the gdb git repo and build it, again on windows 11/msys2/ucrt64.
I then ported the changes to the latest version and built again, re-tested, all ok, and exported two patches from git, attached.
0001-find_file_and_directory-return-empty-strings-instead.patch
0002-read_file_scope-avoid-eventual-crash-when-the-file-o.patch
It’s also possible that there’s an issue with the tools used to create the .elf file in the first place which may also need investigating and reporting to the appropriate team (I think llvm in this case). The rust tools (cargo/rustc/llvm linker/etc) are are already in the wild, I was using stable rust 1.87.0.
It would be fantastic to have these fixes, or a better one based on these patches, applied to GDB so that other developers don’t have to go though a day’s worth of troubleshooting and compiling of and patching gdb to be able to debug their embedded apps.
Kind regards,
Dominic Clifton