From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ncKsGzKN/2lAoykAWB0awg (envelope-from ) for ; Sat, 09 May 2026 15:38:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1778355506; bh=7IeTKG+zi4Cv0fKrR7xuCfCmkeFMKcWZNJmVjEDNl/o=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=gAkMmkYZGm7HrR0Gr3c1gAMOIxZhsognh3JhPN5wzqkCUITIiYNuDInUV7gs2qLx0 xdxgAFm4bnV7TCt2l77uMpIJ+WwWIK0tV60PbZgnPAwIARgCDMpLy1noWEz1gVcMED yZ2T4ApbyzD3bmLVUeQljHINTylUBthJEnlTQfYs= Received: by simark.ca (Postfix, from userid 112) id 5EDBF1E0C3; Sat, 09 May 2026 15:38:26 -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.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, 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=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=cWTmqSI4; dkim-atps=neutral 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 260F41E067 for ; Sat, 09 May 2026 15:38:25 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8C3C04BA2E30 for ; Sat, 9 May 2026 19:38:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8C3C04BA2E30 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=cWTmqSI4 Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 24FAB4BA2E12 for ; Sat, 9 May 2026 19:37:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 24FAB4BA2E12 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 24FAB4BA2E12 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=1778355479; cv=none; b=RaBAb6iVUjECTiVQX1Of3/EVQJvFhk7QAsWP+sgGVHe1gLqbxp4M1SFSsqY+VzZLj3CTWvjKN7RlbfPeepQjWgpu5IT2AW8Zdsg5fp3Gg7pvwXLb2aJfCGNcR5aUAlcFwoBnHrE/BKzdEOK9ixq2i5+OCQKOxEwOwSXzqaq7OMw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778355479; c=relaxed/simple; bh=7IeTKG+zi4Cv0fKrR7xuCfCmkeFMKcWZNJmVjEDNl/o=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=cifCE8PWYahlMSmfJBYA0eHT5j/39i3AGNqBLwvrbSUQ2inlcXCK7cl5Ck/RREBiTEk6gv+M3sXbps/wlLrl2Tm019RvvntsYAVEiIzr5ODiyb7EZY2x7WoaIkkdu433GzR5if39rzOi4J3N4wWFzzci2V0lXQlQp9Up+Ds5HUU= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=cWTmqSI4 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 24FAB4BA2E12 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1778355477; bh=7IeTKG+zi4Cv0fKrR7xuCfCmkeFMKcWZNJmVjEDNl/o=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=cWTmqSI4BSmJIdoPm6mOEn+RS46KjHgM25fopBB8SWcVCHw08OCgsQ1HamPfjXbXu FG/XbQIVsfAdBsHnVpmX8wq+1bR0U97A4FSVDIudJTlNK1HmY1+FRM+CwEEmKVbfgd q272I+6xZNxm/Y5ZF9fgFweNT5kJ4DksHIRWGFZI= Received: by simark.ca (Postfix) id 6903F1E067; Sat, 09 May 2026 15:37:56 -0400 (EDT) Message-ID: <5d39d468-485a-4e05-aa39-edd43ea3e561@simark.ca> Date: Sat, 9 May 2026 15:37:55 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 8/8] gdb/dwarf: read foreign type units To: Tom Tromey , Simon Marchi Cc: gdb-patches@sourceware.org References: <20260316232042.368080-1-simon.marchi@polymtl.ca> <20260416200256.386186-1-simon.marchi@efficios.com> <20260416200256.386186-9-simon.marchi@efficios.com> <871pfykhhb.fsf@tromey.com> Content-Language: fr From: Simon Marchi In-Reply-To: <871pfykhhb.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 On 4/28/26 3:33 PM, Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi writes: > > Simon> However, I know that the current GDB DWARF reader is not able to load > Simon> multiple type units with the same signature but different content. Once > Simon> it loads one type unit with a given signature, all subsequent references > Simon> to that signature will use that loaded type unit. > > FWIW this seems completely sensible to me, since the whole idea of > signatured types is to exploit ODR and linker features to reduce the > size of the DWARF. I had some meeting with Greg Clayton (from LLDB), and he mentioned that in practice, compilers will only include in a given type unit the methods actually used when compiling the compile unit. But the different versions of the type unit for the same type will still have the same signature. For example, if you don't use std::vector::size() in one compile unit, the type unit for std::vector in that .dwo will not include the description of std::vector::size(). If that version of the type unit gets loaded first, and you later try to do "print myVector.size()", then too bad. Even if another instance of the type unit does have the information. > Simon> Setting a dwarf2_per_cu's section a posteriori breaks the assumed > Simon> ordering of the dwarf2_per_bfd::all_units vector. After setting the > Simon> section, re-sort the vector. > > I'm not a huge fan of this but I guess we can live with it. I tried to keep foreign units in a vector on the side (they are not needed for DW_FORM_ref_addr resolution), but it made the code much uglier than just having this re-sort call. > Simon> There is one known failure that I am unable to get to the bottom of. It > Simon> seems orthogonal to my change though, more like an indexer or symbol > Simon> reader issue. There are maybe more of this kind, but this is one > Simon> example: > > Simon> FAIL: gdb.ada/tick_length_array_enum_idx.exp: ptype variable_table'length (GDB internal error) > Simon> /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1839: internal-error: search_one: Assertion `symtab != nullptr' failed. > > See https://sourceware.org/bugzilla/show_bug.cgi?id=31648 > > Not really the same, but the same test case, so I kind of suspect that > older compilers had some issue here. Though: > > Simon> The issue seems sensitive to some aspects of the environment (gnat > Simon> version?). I am able to reproduce the issue on Arch Linux (gnat 15) > Simon> with: > > Simon> $ make check TESTS="gdb.ada/tick_length_array_enum_idx.exp" RUNTESTFLAGS="--target_board=dwarf5-fission-debug-types-debug-names" > > Simon> But it doesn't reproduce on Debian 13 (gnat 14), Ubuntu 24.04 (gnat > Simon> 13) or Fedora Rawhide (gnat 16). > > ... this goes against my thinking here. > > One question is whether this compiler defaults to "minimal" encodings or > GNAT encodings. This Arch machine now has gcc (and gnat) 16.1, and now the test passes with the command above :/. And it's not easy to go back to a previous release so... I guess we'll never know (unless I build myself a gcc 15). The default encodings for the 16.1 one are "gdb". And when forcing minimal encodings, like this, the test still passes: $ make check TESTS="gdb.ada/tick_length_array_enum_idx.exp" RUNTESTFLAGS="--target_board=dwarf5-fission-debug-types-debug-names GNATMAKE_FOR_TARGET='gnatmake -fgnat-encodings=minimal'" > Simon> + /* A convenience function to allocate a signatured_type. The > Simon> + returned object has its "index" field set properly. > Simon> + > > I don't really understand how the index field even really makes sense > any more, because now the vector is sorted after the fact. > > Not that this is new with this change, just pointing out that it seems > incoherent with the description of the field: > > /* Our index in the unshared "symtabs" vector. */ > > Like is this still true? Yes, it is still the index in the dwarf2_per_objfile::m_compunit_symtabs vector. It's really just an arbitrary 0-based unique ID that we assign to each unit. I attempted to remove it once, using an unordered_map for m_compunit_symtabs, but at the end of the day it just switched a O(1) lookup for a O(log(N)) one, so not a net improvement. To be clear, it's not the index in the dwarf2_per_bfd::all_units vector, if that was your worry. Other spots use that index as the key for a map (cooked_index_worker_result::m_reader_hash), I wonder if those should just use the pointer directly as the key. Simon