From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id I0ZjB84dxmdtHQQAWB0awg (envelope-from ) for ; Mon, 03 Mar 2025 16:23:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741037006; bh=I7SXxO2Xl3K1efFuZ7imLTMRa4cVeOkjhmLBs5k1HFo=; h=Date:Subject:From:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=q9gXAAvbdt4j/hdn38NQXL/hPrB1zs6ct9ctZE0UY1czcZuypj2hWtqXYJa26D7EQ +/s0SDykmReJDKcR4gercAYu0nFVh+s+2X7iod7KOvW3Fwqri6ojCwyzYGeJ1zHo+1 h9kaMiVYSSyAnJMv3KG5hacpqJ2gfhuiJ5YsDV2Q= Received: by simark.ca (Postfix, from userid 112) id 0D02C1E105; Mon, 3 Mar 2025 16:23:26 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.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 autolearn=unavailable autolearn_force=no version=4.0.0 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=WFq6c2K/; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=cuQnNZ7m; dkim-atps=neutral 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 507651E05C for ; Mon, 3 Mar 2025 16:23:25 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 012703858410 for ; Mon, 3 Mar 2025 21:23:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 012703858410 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=WFq6c2K/; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=cuQnNZ7m Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id B4DC43858D26 for ; Mon, 3 Mar 2025 21:22:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B4DC43858D26 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 B4DC43858D26 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741036963; cv=none; b=L8b0pB6M0MuOeTYpnukDwPTram00Jsz6HMCu9E+0UpCY6F+6MPALA9IZS7MUx8ZlEAd56VY4iWcDRCyxYEIFr96zFTVZ8mo+e/wrn2MIMnLhfLu4RaPSwE8+oHsGUGJIhd31lT4UDBuuh6KSTblcbDRMrMyyFe4CeL4c80Afl3Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741036963; c=relaxed/simple; bh=I7SXxO2Xl3K1efFuZ7imLTMRa4cVeOkjhmLBs5k1HFo=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:From:To; b=tSjm+6Fq8B1fqWTaDw84OHgQM0UEnD/Zzc/Huy+JXITib54aGfxOrIKfO8y/gTmtelxcu+h5ZDNKN8IdBMccDGaM7XW5OvqjGsQ3fGlpXIbfI5UMTT19GV914ljmtYqYhNwaPw+chVIMH0jrJK99itIRfkSkJ8zTodpPfyiqQpk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B4DC43858D26 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741036963; bh=I7SXxO2Xl3K1efFuZ7imLTMRa4cVeOkjhmLBs5k1HFo=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=WFq6c2K/FyMkMWTdo1QiiQOWkgp1DhmhLgPIsyjZjhvt5gdtlFAdDAIvEr/eqqlaJ BG9EAbU/iF/+OPhVbSpsmsDRxJzTg8H7inuZHTrtDqsTEESShqAxRxrCeeYfkSpRAN fP4LukkW1C3DhmobxHm/I1/+JRPn35yGfWBAMi/U= Received: by simark.ca (Postfix, from userid 112) id 736DD1E10A; Mon, 3 Mar 2025 16:22:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741036961; bh=I7SXxO2Xl3K1efFuZ7imLTMRa4cVeOkjhmLBs5k1HFo=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=cuQnNZ7mNY3KaGow1paI5hSlTrD7epf70A+jVN/Nj/MBtXEseVgKH+pELHuFcgkKS iGIT1mxcRRMegOqnW+aYaX/CrQRTS6yjviVhlRPZNJdWR9RqgQKfRvJ+Dbv7M847wX ILD+7edQfSBUzB/GHb4KGHWJXGiyCoNZbl+eTQv0= Received: from [172.16.0.192] (96-127-217-162.qc.cable.ebox.net [96.127.217.162]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 9492A1E05C; Mon, 3 Mar 2025 16:22:41 -0500 (EST) Message-ID: Date: Mon, 3 Mar 2025 16:22:41 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] [gdb/symtab] Fix dwarf version of DWO TU From: Simon Marchi To: Tom de Vries , Tom Tromey Cc: gdb-patches@sourceware.org References: <20250120085723.5693-1-tdevries@suse.de> <87ikq8pa0o.fsf@tromey.com> <1e6e2875-acb5-40e7-99aa-d5d15d245b8e@suse.de> <86d6f8f6-8fad-46ad-ae37-9fbbadb6586f@simark.ca> Content-Language: fr In-Reply-To: <86d6f8f6-8fad-46ad-ae37-9fbbadb6586f@simark.ca> 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 3/3/25 3:44 PM, Simon Marchi wrote: > On 3/3/25 3:02 PM, Simon Marchi wrote: >> On 1/21/25 10:09 AM, Tom de Vries wrote: >>> On 1/21/25 14:32, Tom Tromey wrote: >>>>>>>>> "Tom" == Tom de Vries writes: >>>> >>>> Tom> When running test-case gdb.ada/access_tagged_param.exp with target board >>>> Tom> fission, we run into: >>>> Tom> ... >>>> Tom> (gdb) break pck.adb:19^M >>>> Tom> gdb/dwarf2/read.h:289: internal-error: version: \ >>>> Tom> Assertion `m_dwarf_version != 0' failed.^M >>>> Tom> ... >>>> >>>> Tom> - && (cu->per_cu->version () == 2 >>>> Tom> + && (cu->header.version == 2 >>>> >>>> All the stuff in this area seems kind of horrible to me. Like, first of >>>> all, how can this even fail? It seems like the CU version should be set >>>> when setting up the reader. >>> >>> Hi Tom, >>> >>> thanks for the review. >>> >>> The v1 ( https://sourceware.org/pipermail/gdb-patches/2024-October/212676.html ) takes the approach of making sure "cu->per_cu->version ()" is set. >>> >>> Do you prefer that one? >>> >>> Thanks, >>> - Tom >>> >>>> And if not, what's gone wrong there? >>>> Relatedly, can the other callers of version() fail in the same way? >>>> Finally there aren't really that many callers of this method so I wonder >>>> if it can be removed, maybe making this code less fragile. Looking at >>>> it, I feel pretty sure if I needed a version check I'd probably write >>>> code to call this method but ... maybe that's unsafe? >>>> >>>> Tom >>> >> >> My understanding of what Tom T said is that the >> dwarf2_per_cu_data::version method could be removed. Callers could use >> the dwarf2_cu::header::version field, since they do have access to a >> dwarf2_cu anyway. I will give that a shot. > > I spoke too soon, there are uses of dwarf2_per_cu_data::version in loc.c > that my indexer hadn't picked up yet for some reason. When those run, > the dwarf2_cu is probably gone. > > It would be nice if we could ensure that the DWARF is set at the > creation of any dwarf2_per_cu_data, but it doesn't seem possible. When > we read a .gdb_index index, we create some dwarf2_per_cu_data objects > out of it, but we don't know the DWARF version of those. We will only > know when reading them with a cutu_reader. > > So I see 3 options on the table: > > 1. Tom's first patch would obtain the DWARF version of the from the > skeleton unit, and pass it when creating the signatured_type object for > the type unit that is stored in the dwo file > > 2. A patch proposed in the bug just sets the field in the "type unit in > dwo file" code path, like we do for other kinds of units. > > 3. Another option would be to save the DWARF version in > dwarf2_loclist_baton (those are the users of the version in loc.c I > referred to above). That would duplicate the value, versus having it > in dwarf2_per_cu_data alone. But it would make it so we never have a > possibly uninitialized version field, which is easier to reason about. > > When first looking at the problem, I independently arrived at solution > #2. It means we can still have a gap of time between the creation of a > dwarf2_per_cu_data object and when we read its header where the DWARF > version is unknown (and the version field is unset), but it seems > inevitable. We just need to ensure that in all paths where we read its > header, we set the field. > > If prefer the peace of mind of knowing the version field can never be > "unset", then solution #3 is good I guess. Actually, dwarf2_loclist_baton has some wasted space (padding) at the end, so now I vote for option #3 for simplicity - not thread safety issue, no field possible left unset. Patch here: https://inbox.sourceware.org/gdb-patches/20250303212126.728156-1-simon.marchi@efficios.com/T/#u Simon