RE: Fixing gdb crash issue when loading an elf file compiled with rust 1.87.0

["Dominic Clifton" <me@dominicclifton.name>]

Hi, since I’ve had zero response to my email I re-submitted it, maybe
following the https://sourceware.org/gdb/wiki/ContributionChecklist a little
closer...

The new email subject is: "[PATCH] read_file_scope - avoid eventual crash
when the file or directory name is null.".

If I'm still doing something wrong can someone please let me know exactly
what to do so this bug doesn't get forgotten.

Kind regards,

Dominic clifton.

From: Dominic Clifton <me@dominicclifton.name> 
Sent: 05 October 2025 17:04
To: gdb-patches@sourceware.org
Subject: Fixing gdb crash issue when loading an elf file compiled with rust
1.87.0

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