From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uf01KCvVxGpl6QMAWB0awg (envelope-from ) for ; Tue, 06 Oct 2026 07:02:03 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=MwvD7Sdo; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 9E1971E051; Tue, 06 Oct 2026 07:02:03 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=unavailable autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.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 7C5671E04E for ; Tue, 06 Oct 2026 07:02:01 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E71234BB58D6 for ; Tue, 6 Oct 2026 11:02:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E71234BB58D6 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=MwvD7Sdo Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 46ABC4BA9029 for ; Tue, 6 Oct 2026 11:01:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 46ABC4BA9029 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 46ABC4BA9029 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1791284495; cv=none; b=tl4CmWpaQa0dHeV5ZJm7L0KAhu7MOqjLNHWMzzyYmuSQaptUalXqzuAgWGlF6Lv6oAVjHsbacLud769M1I2sTE4h9Chshb0dE3s6FI3PbB+nhs4h1igQzxFzpKAqTa/obSTG/uRJt1fq5U07DSusAoves2Rc2fC5DUUO2zeHT5M= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1791284495; c=relaxed/simple; bh=CApIYue1UIFrlWiVn2Xm1dBCsEHUnJhGz2Ob/GjZFKc=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=lPySIPQA+g2AfNz0N3WCR1F/EBA7opC4VtSC4lg9Us03P8YmG4QLOZYkYiKQQNtliqOekOXQyMSFIeSnjIkX+s9euxVpwAy96dFLtm8AWvh3GnEaUsB+z+Skqh4a+wlwZW1Yv3gqUY4YxSHdJzacndyaIdtElP4tCqHd1pPHku8= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=MwvD7Sdo DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 46ABC4BA9029 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1791284494; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=A0c3mGchqLKtVuip1fNQk/Y4tqxYgXyuq/VNVIJk7wc=; b=MwvD7Sdo2fmf2U9f0YEeWw/vQ2V3DroPcmGkbo3GlCebpLU07HueF7o2lJ2anya3Hft5pI 5Z8Gd++VOjhncDt7bloOh9FqpgeqDz/cq5WIz5Z5Xzj8TgoawWzWtqsCkjWrjkeXEx1rbJ o6umSevZhpCmfMCx7HcrpJYIJ5lc6A0= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-601-wx7E1MKqMC2ztH3oL4haoA-1; Tue, 06 Oct 2026 07:01:33 -0400 X-MC-Unique: wx7E1MKqMC2ztH3oL4haoA-1 X-Mimecast-MFC-AGG-ID: wx7E1MKqMC2ztH3oL4haoA_1791284492 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-49e6b5c5f44so45182325e9.2 for ; Tue, 06 Oct 2026 04:01:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791284492; x=1791889292; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=A0c3mGchqLKtVuip1fNQk/Y4tqxYgXyuq/VNVIJk7wc=; b=QOilr16J9wn4R1KXtBycrU/auktL0L8qUTy0KysgvQGcgDPU1xAWy0oY8uWRg567rY 2BHkHj/ZdWz3P7uzDCCbZ36Tw44zyV9eNH+CTa2CbczQQKbnoqB716IpdsNJ23R8rgu0 xBIsgJudizOMEzypUHcLAkY9ru5Kl0MhbtcTLGLZ7+s0GFflmZRCdtjUj6R+u6Z2Oq1n NbLUX3oqGd41TQ9taREhU87vrMkeBlutK6U1ItCdqqvEZq6x4DxATtWnNZ21SHFg1Sva 1ZNcmg35KtwWWok6zuMxQy5ijROBtzWaLzB4zi17i5xPlA6qypXAbjA5YlKDimbIYz4x j7+w== X-Forwarded-Encrypted: i=1; AKwUvBwdhAV3tthSVLsvGy+uErbrQH3FDgOhznLmZVeDvs47ZoYoeWWziLrMyOMYD6LPt01b5ccJ+o+PlVwnzw==@sourceware.org X-Gm-Message-State: AFuF++nESQNCP0hqe6hy+h/ScBkgBYUxsjkClrg6Aywn3oKol1GUcwAV sj1TI0g5gchyKFJ3gmzxfuqnm1ysf1hocKen7rqdoKmUfaf6tJowH3ckdZixDRwekcJXZjjOnml NdIbbMeDmq2cjIkn5+ledtEyisyzNldp6MUdZWDyvCBsBLVLYOtAplVrKDBe3E3M= X-Gm-Gg: AYBFou0HKi2O7LDhcMAcNLCLliLFPNZU9n1gxSTdFQuok9wdQxkJztG8YGMSaiVsdjS 8FPk6ambO4foGWwQB0IwDLRkPmhh6Y5y6HfWMeoDZfopSXLqvtrkRQuNxpNPW7Een/oilmWq50t hkbbBzkuhq9Nyu68hchtyCYCw7UFArlN0qjmOT4gr+Jvnp7eIj4H3Hi8bu9qMLn/MUrJq2JwFab 5jbunOtz4zTi3Z8iFd0ToFno9yQb64TNPQnZxdHCmv0aoTJ2K8L8e+wULwLkV4t/mU+SKHI7+Gx SSc2xwZSsgXOeAxTcJOMYc8r0PXqxD7SWB/xRGbg+3KeyqYli6c+Vv4FpC7feZlSH7BE X-Received: by 2002:a05:600c:4f54:b0:4a1:7701:f863 with SMTP id 5b1f17b1804b1-4a17b548f39mr17984135e9.15.1791284492201; Tue, 06 Oct 2026 04:01:32 -0700 (PDT) X-Received: by 2002:a05:600c:4f54:b0:4a1:7701:f863 with SMTP id 5b1f17b1804b1-4a17b548f39mr17983665e9.15.1791284491674; Tue, 06 Oct 2026 04:01:31 -0700 (PDT) Received: from localhost ([213.31.44.29]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a178c33091sm65344595e9.4.2026.10.06.04.01.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Oct 2026 04:01:31 -0700 (PDT) From: Andrew Burgess To: simon.marchi@polymtl.ca, gdb-patches@sourceware.org Cc: Simon Marchi Subject: Re: [PATCH 3/3] gdb/dwarf: fix crash when .gdb_index contains Rust legacy mangled names In-Reply-To: <20261005052602.1288766-3-simon.marchi@polymtl.ca> References: <20261005052602.1288766-1-simon.marchi@polymtl.ca> <20261005052602.1288766-3-simon.marchi@polymtl.ca> Date: Tue, 06 Oct 2026 12:01:30 +0100 Message-ID: <8733ujum7p.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: kkt_kLU5ZWh_IfGQZCUNESl1f1fHVreyyua2hm-Z8VE_1791284492 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 simon.marchi@polymtl.ca writes: > 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. > > I can't think of a pretty way to fix this. Since we don't have a flag that > tells us whether a name is a linkage name or not, we can only make some > educated guesses. > > This patch fixes the problem by looking for empty components in the vector. > If there are, we assume that we are probably looking at a Rust legacy > mangled symbol name, or at the very least not a fully qualified demangled > Go (or whatever) symbol. The name is then treated like other names without > separators (a single component with an unknown language). > > This is a regression introduced by commit 486bc5ac812f ("Rewrite the > .gdb_index reader"). 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. I agree being defensive on the read side is a good idea. Even if these names were not intended to be in the index, and GDB had never emitted them, there's nothing to stop some other tool generating an index, and that tool might emit these names. Conclusion: GDB should treat the index as untrusted input. I actually started looking at making some fixes in this area -- not this particular fix, but others in this area -- the fixes were easy, but writing tests was taking some time. It's a work in progress. I agree that this could be merged to master and gdb-18-branch. Approved-By: Andrew Burgess Thanks, Andrew