From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id sQzvAw7z52hf7SUAWB0awg (envelope-from ) for ; Thu, 09 Oct 2025 13:38:22 -0400 Authentication-Results: simark.ca; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=dominicclifton.name header.i=@dominicclifton.name header.a=rsa-sha256 header.s=email header.b=YeI1MbRY; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 03E331E0B6; Thu, 09 Oct 2025 13:38:21 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_INVALID,DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 2BC391E047 for ; Thu, 09 Oct 2025 13:38:21 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C98E8385841F for ; Thu, 9 Oct 2025 17:38:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C98E8385841F Authentication-Results: sourceware.org; dkim=fail reason="signature verification failed" (1024-bit key, unprotected) header.d=dominicclifton.name header.i=@dominicclifton.name header.a=rsa-sha256 header.s=email header.b=YeI1MbRY Received: from mx03.hydraservices.com (mx03.hydraservices.com [82.113.145.160]) by sourceware.org (Postfix) with ESMTPS id 1573E3858D21 for ; Thu, 9 Oct 2025 17:37:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1573E3858D21 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=dominicclifton.name Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dominicclifton.name ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1573E3858D21 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=82.113.145.160 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760031460; cv=none; b=A1jsRM5Ry2gV2EUp78sjNy6yftMlAjiiARdrwUmXuB/GHuGEI5Ob5RTLsUobQEO7smODsScrJLQaBmQbJEErHudv1CXJqIgoh2El1rIqTpQddRzGOme4XLfa0IcMBJglubSVT1qO5y+tjQwhN2drBy3eytGCdqlXjHwUPfu2Jdw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760031460; c=relaxed/simple; bh=RtNFurSOevgJiOK2fX6kdeX2wMRNKRUU+bufXWcb4vc=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=XPjxUS/ltTjvkdsCFn02OLGhkWtTHYw8H3nFYm0sXPBMgWfR+v3SJ9U3xrB9lszyB8n+cGSkFEy2NnJZAtCp/biP5Di3L2qeThAKtGS4AohkglVbTnul6QQJi+C1ZUiQ2Cp8XSnj4phccLzn9aZ36kzWbd7IGrZ+CV6stvDEXLQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1573E3858D21 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dominicclifton.name; s=email; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RtNFurSOevgJiOK2fX6kdeX2wMRNKRUU+bufXWcb4vc=; b=YeI1MbRYVk7tJvl4BkNvI2jde1 kxoDdqcUN6melL/MmWluyAqRjBbgX1XKBGHALMnOQvgS2bsYiWhWvonf8NqMfh6R9X8mvJRg6eDHx i3GNkaup9GDYNJOQc8zkNiUDA5skyf1hN4OxnsMN5H19RAWHbDnrhQedQ3xes3L9tHr0=; Received: from [45.86.185.202] (helo=HYDRA01) by mx03.hydraservices.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1v6uaA-00ExPo-S9 for gdb-patches@sourceware.org; Thu, 09 Oct 2025 18:37:38 +0100 From: "Dominic Clifton" To: References: <00d101dc3609$37564b00$a602e100$@dominicclifton.name> In-Reply-To: <00d101dc3609$37564b00$a602e100$@dominicclifton.name> Subject: RE: Fixing gdb crash issue when loading an elf file compiled with rust 1.87.0 Date: Thu, 9 Oct 2025 19:37:37 +0200 Message-ID: <017401dc3943$6794f680$36bee380$@dominicclifton.name> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGDN+atxJvNFm6cT9B7vvoZgOzQVLVsFlPA X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hi, since I=92ve 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 =20 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' =A0 what():=A0 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++.=A0 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 =3D working, = but too old, wasn=92t compiled with python arm-gnu-toolchain-14.2.rel1-mingw-w64-i686-arm-none-eabi =3D not = working, same issue arm-gnu-toolchain-14.3.rel1-mingw-w64-x86_64-arm-none-eabi =3D not = working, same issue $ /C/Program\ Files/JetBrains/CLion\ = 2025.2.3/bin/gdb/win/x64/bin/gdb.exe =96version (GNU gdb (GDB; JetBrains IDE bundle; build 216) 15.2) =3D not working, same issue Locally built "GNU gdb (GDB) 16.3" =3D not working, same issue. So down the rabbit hole I went=85 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 commands.mi2 $ gdb /ucrt64/bin/arm-none-eabi-gdb (gdb) set args D:\\Users\\Hydra\\Documents\\dev\\projects\\embassy\\examples\\stm32h7\\t= arg et\\thumbv7em-none-eabihf\\release\\blinky --interpreter=3Dmi2 < = commands.mi2 (gdb) catch throw (gdb) run This caused the same error again, I dumped the backtrace. (gdb) bt =85 #9=A0 0x00007ff7a66e0e28 in std::__cxx11::basic_string, std::allocator >::basic_string > (__a=3D..., this=3D0x7feb80, __s=3D) =A0=A0=A0 at C:/msys64/ucrt64/include/c++/14.2.0/bits/basic_string.h:651 #10 read_file_scope (die=3D0x5d42d40, cu=3D0x5b148b0) at = dwarf2/read.c:7536 #11 process_die (die=3D0x5d42d40, cu=3Dcu@entry=3D0x5b148b0) at = dwarf2/read.c:6497 #12 0x00007ff7a66e4680 in process_full_comp_unit (pretend_language=3D, cu=3D0x5b148b0) at = dwarf2/read.c:6260 #13 process_queue (per_objfile=3D) at dwarf2/read.c:5552 #14 dw2_do_instantiate_symtab (per_cu=3D0x5a69e20, = per_objfile=3D, skip_partial=3D) at dwarf2/read.c:1779 =85 After=A0 looking at the code and trying a few things, with the aid of = chatgpt since I=92m 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=92m 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 =96release 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=92s also possible that there=92s 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).=A0 The rust=A0 = 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=92t have to go = though a day=92s worth of troubleshooting and compiling of and patching gdb to be = able to debug their embedded apps. Kind regards, Dominic Clifton