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\\targ
et\\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