From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +Uw7EQizz2os8AkAWB0awg (envelope-from ) for ; Wed, 14 Oct 2026 12:51:20 -0400 Received: by simark.ca (Postfix, from userid 112) id 3BD941E050; Wed, 14 Oct 2026 12:51:20 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (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 39BC21E04E for ; Wed, 14 Oct 2026 12:51:18 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C50D54BA23C8 for ; Wed, 14 Oct 2026 16:51:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C50D54BA23C8 Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 4E87A4BA2E1F; Wed, 14 Oct 2026 16:48:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4E87A4BA2E1F Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=efficios.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=efficios.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4E87A4BA2E1F Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1791996514; cv=none; b=U/HuJ/4F9PVgDBq0ZM/DlQUSWykOXhTgbH7e4h/U2cK5krvGAUOs0OdfXL/t1H5SlWKLeObidZaZi1gKL4QAo4mr1WOkuKfnwd074zDYzxbDTV7QqhrdiTFxnEkVu1nZEheA8ZnGOES3vDZtoSO66gRglPDLM9NUm8CcYYJ4Er4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1791996514; c=relaxed/simple; bh=OVQFrig8JUr7WTtMNynGr4o8+divJnOlbNwBP27Aj9M=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=LR4cdcnveLDvr9rE0Cg6HdLNX+uYnbP+6xZWGVEoNQFytzay8sk4JmAwx6htrsn0wjUYngiUj/LaPtRR01IBtnEEcjbDMFjzDKo5XdtKZnby1KFlyGGYBuHmBrNsVoVKhPCJHjFCtiu4Z9aKT0lNaFI1kve/P0qeRdrA2K6LaVo= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4E87A4BA2E1F Received: by simark.ca (Postfix) id C86C41E050; Wed, 14 Oct 2026 12:48:33 -0400 (EDT) From: Simon Marchi To: gcc-patches@sourceware.org, gdb-patches@sourceware.org Cc: Simon Marchi Subject: [PATCH v2 2/2] gdb/dwarf: fix crash when .gdb_index contains Rust legacy mangled names Date: Wed, 14 Oct 2026 12:46:59 -0400 Message-ID: <20261014164830.358677-3-simon.marchi@efficios.com> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261005052602.1288766-3-simon.marchi@polymtl.ca> References: <20261005052602.1288766-3-simon.marchi@polymtl.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 From: Simon Marchi PR 34707 reports that loading the separate debug file of /usr/lib/libglycin-2.so from Arch Linux crashes GDB (when built with -D_GLIBCXX_DEBUG): $ ./gdb -q -nx --data-directory data-directory $(DEBUGINFOD_URLS=https://debuginfod.archlinux.org debuginfod-find debuginfo /usr/lib/libglycin-2.so) /usr/include/c++/16/string_view:291: ... Assertion 'this->_M_len > 0' failed. This catches a case of calling string_view::back() when the string_view is empty. The file in question contains a .gdb_index with some Rust symbol names that are mangled with the legacy mangling style. The legacy mangling style was the default one until the Rust 1.97 release in July 2026, so it's still very much in use, even though it's called "legacy". Source: https://blog.rust-lang.org/2026/07/09/Rust-1.97.0/ An example of a problematic symbol is: _ZN4core3ptr271drop_in_place$LT$core..iter..adapters..filter..Filter$LT$alloc..vec..into_iter..IntoIter$LT$core..net..socket_addr..SocketAddr$GT$$C$zbus..address..transport..tcp..Tcp..connect..$u7b$$u7b$closure$u7d$$u7d$..$u7b$$u7b$closure$u7d$$u7d$..$u7b$$u7b$closure$u7d$$u7d$$GT$$GT$17h57c03bb201e55682E Method mapped_gdb_index::build_name_components attempts to split the demangled fully-qualified symbol names into parts (it does not know in advance whether a symbol name is a mangled (linkage) name or a demangled one). Since this name does not match the C++ and Ada special cases, it falls into the DOT_STYLE else: components = split_name (name, split_style::DOT_STYLE); Because of the consecutive dots in the symbol name, `components` (an std::vector) contains some empty components. Some code later calls .back() on one of those empty string_views, which is invalid. It seems like it's only caught when gdb is built with _GLIBCXX_DEBUG / _GLIBCXX_ASSERTIONS, which apparently is the case for the official Arch Linux packages. This patch fixes the problem in split_name: with DOT_STYLE, if splitting would produce an empty component (because of leading, trailing or consecutive dots), we assume that we are probably not looking at a fully qualified dot-separated demangled symbol name. split_name then bails out and returns the whole name as a single component. In build_name_components, the name is therefore treated like other names without separators (a single component with an unknown language). Update the split_name selftests accordingly. This is a regression introduced by commit 486bc5ac812f ("Rewrite the .gdb_index reader", 2025-03-06). Before that, the reader only split names on "::" and "__". This is new in the GDB 18.1 release, so this patch would be a candidate for the gdb-18-branch. Add a gdb.dwarf2 test that builds a Rust CU with such a linkage name, adds an index using gdb-add-index, and verifies that GDB can load it and find the function. The test is done with both .gdb_index and .debug_names, although only the .gdb_index reader was affected. Like the original crash, the test only fails without the fix if GDB is built with libstdc++ assertions. One last thing, I don't know if it's expected for Rust mangled names to appear in the index. For C++, index-write.c does not write them: else if (entry->lang == language_cplus && (entry->flags & IS_LINKAGE) != 0) { /* GDB never put C++ linkage names into .gdb_index. The theory here is that a linkage name will normally be in the minimal symbols anyway, so including it in the index is usually redundant -- and the cases where it would not be redundant are rare and not worth supporting. */ continue; } Perhaps this is the real root of the problem: maybe those names should not have been in the index in the first place, if the same rationale applies to Rust. We could make that change, but even if we do, there are already indexes out there with those mangled names, so we have to handle them. Change-Id: I2c346dfba25edecda970af0726f9d77216838cbd Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34707 --- gdb/split-name.c | 36 ++++--- .../gdb-index-rust-legacy-linkage-name.c | 29 ++++++ .../gdb-index-rust-legacy-linkage-name.exp | 98 +++++++++++++++++++ 3 files changed, 150 insertions(+), 13 deletions(-) create mode 100644 gdb/testsuite/gdb.dwarf2/gdb-index-rust-legacy-linkage-name.c create mode 100644 gdb/testsuite/gdb.dwarf2/gdb-index-rust-legacy-linkage-name.exp diff --git a/gdb/split-name.c b/gdb/split-name.c index cb740a968d49..b8605c4040f4 100644 --- a/gdb/split-name.c +++ b/gdb/split-name.c @@ -52,11 +52,22 @@ split_name (const char *name, split_style style) iter != nullptr; iter = strchr (iter, '.')) { + /* If the name contains a leading dot or consecutive dots, it's not a + valid qualified dot-separated name. */ + if (iter == &name[previous_len]) + return { name }; + result.emplace_back (&name[previous_len], iter - &name[previous_len]); ++iter; previous_len = iter - name; } + + /* If there is a trailing dot, it's not a valid qualified dot-separated + name either. */ + if (name[previous_len] == '\0') + return { name }; + break; default: @@ -223,19 +234,18 @@ test_split_name_dot_style () check_split_name ("pkg.\"+\"", split_style::DOT_STYLE, { "pkg", "\"+\"" }); - /* Leading, trailing or consecutive dots produce empty components. */ - check_split_name (".", split_style::DOT_STYLE, { "", "" }); - check_split_name ("..", split_style::DOT_STYLE, { "", "", "" }); - check_split_name (".a", split_style::DOT_STYLE, { "", "a" }); - check_split_name ("a.", split_style::DOT_STYLE, { "a", "" }); - check_split_name ("a..b", split_style::DOT_STYLE, { "a", "", "b" }); - check_split_name (".a.b", split_style::DOT_STYLE, { "", "a", "b" }); - check_split_name ("a.b.", split_style::DOT_STYLE, { "a", "b", "" }); - check_split_name ("a.b..c", split_style::DOT_STYLE, - { "a", "b", "", "c" }); - check_split_name ("a..b.c", split_style::DOT_STYLE, - { "a", "", "b", "c" }); - check_split_name ("a...b", split_style::DOT_STYLE, { "a", "", "", "b" }); + /* Names with leading, trailing or consecutive dots are not recognized as + qualified names are are returned as-is. */ + check_split_name (".", split_style::DOT_STYLE, { "." }); + check_split_name ("..", split_style::DOT_STYLE, { ".." }); + check_split_name (".a", split_style::DOT_STYLE, { ".a" }); + check_split_name ("a.", split_style::DOT_STYLE, { "a." }); + check_split_name ("a..b", split_style::DOT_STYLE, { "a..b" }); + check_split_name (".a.b", split_style::DOT_STYLE, { ".a.b" }); + check_split_name ("a.b.", split_style::DOT_STYLE, { "a.b." }); + check_split_name ("a.b..c", split_style::DOT_STYLE, { "a.b..c" }); + check_split_name ("a..b.c", split_style::DOT_STYLE, { "a..b.c" }); + check_split_name ("a...b", split_style::DOT_STYLE, { "a...b" }); } } /* namespace selftests */ diff --git a/gdb/testsuite/gdb.dwarf2/gdb-index-rust-legacy-linkage-name.c b/gdb/testsuite/gdb.dwarf2/gdb-index-rust-legacy-linkage-name.c new file mode 100644 index 000000000000..ea6d12575233 --- /dev/null +++ b/gdb/testsuite/gdb.dwarf2/gdb-index-rust-legacy-linkage-name.c @@ -0,0 +1,29 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2026 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +void +func (void) +{ + asm ("func_label: .globl func_label"); +} + +int +main (void) +{ + func (); + return 0; +} diff --git a/gdb/testsuite/gdb.dwarf2/gdb-index-rust-legacy-linkage-name.exp b/gdb/testsuite/gdb.dwarf2/gdb-index-rust-legacy-linkage-name.exp new file mode 100644 index 000000000000..b995e986355f --- /dev/null +++ b/gdb/testsuite/gdb.dwarf2/gdb-index-rust-legacy-linkage-name.exp @@ -0,0 +1,98 @@ +# Copyright 2026 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +# Test reading an index containing a Rust "legacy" mangled linkage +# name. These names contain ".." sequences, which the .gdb_index +# reader used to split into empty components, leading to a crash. +# The .debug_names index is tested too, for completeness. +# +# Note that the crash only happened with libstdc++ assertions enabled +# (e.g. with -D_GLIBCXX_DEBUG). Otherwise, it was silent undefined +# behavior. + +load_lib dwarf.exp + +require dwarf2_support +require !readnow + +standard_testfile .c -dw.S + +set asm_file [standard_output_file $srcfile2] +Dwarf::assemble $asm_file { + cu {} { + DW_TAG_compile_unit { + DW_AT_language @DW_LANG_Rust + DW_AT_name lib.rs + } { + DW_TAG_namespace { + DW_AT_name foo + } { + # The linkage name demangles to foo::bar. + DW_TAG_subprogram { + DW_AT_name "bar" + DW_AT_linkage_name \ + "_ZN3foo19bar\$LT\$foo..Baz\$GT\$17h0123456789abcdefE" + DW_AT_external 1 DW_FORM_flag + MACRO_AT_range {func} + } + } + } + } +} + +if { [build_executable "failed to prepare" ${testfile} \ + [list $srcfile $asm_file] {nodebug}] == -1 } { + return +} + +# For simplicity, skip the test if the executable already has an index (e.g. +# with the cc-with-gdb-index board). The test will be covered when running +# with the unix board. +clean_restart $testfile +if { [get_index_type $binfile "check index type"] ne "cooked" } { + unsupported "executable already has an index" + return +} + +foreach_with_prefix index_type { gdb_index debug_names } { + set testfile_with_index ${testfile}-${index_type} + set binfile_with_index [standard_output_file $testfile_with_index] + remote_exec build "cp $binfile $binfile_with_index" + + if { $index_type eq "gdb_index" } { + set style "" + } else { + set style "-dwarf-5" + } + + if { [add_gdb_index $binfile_with_index $style] != 1 } { + untested "error adding index" + continue + } + + clean_restart $testfile_with_index + gdb_assert { [have_index $binfile_with_index] eq $index_type } \ + "index used" + + # Check that the function can be found. + set re "^foo::bar$" + gdb_test "info functions $re" \ + [multi_line \ + [string_to_regexp \ + "All functions matching regular expression \"$re\":"] \ + "" \ + "File lib.rs:" \ + "\[^\r\n\]*[string_to_regexp "fn foo::bar();"]"] +} -- 2.56.0