From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id PGyVE/AUxmflFQQAWB0awg (envelope-from ) for ; Mon, 03 Mar 2025 15:45:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741034736; bh=+4xPq8yBCyoms+K3wcRrbtP2SbxdHSWx0rBnVz5iNpI=; h=Date:Subject:From:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=JB6FJNuVCf4zizCpy3aERXkBOjBPWqipn1GXA6WPHtq5sHRjDCE2AydJcgbIJnZiv OwMSbcGkveasT06LG/+6KfIUukRJBOGGEMXvscTn7foOpQrDudR9DZhoS+VCWBxxbb 8/dFkvLzHV3i6CJcPdQWHUW2i2oQgr8qtarigXtI= Received: by simark.ca (Postfix, from userid 112) id 3BE9D1E105; Mon, 3 Mar 2025 15:45:36 -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=onMRklGn; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=SqRDR3Lh; 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 BFE611E05C for ; Mon, 3 Mar 2025 15:45:35 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 363A4385841C for ; Mon, 3 Mar 2025 20:45:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 363A4385841C 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=onMRklGn; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=SqRDR3Lh Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 3ECBB3858D21 for ; Mon, 3 Mar 2025 20:45:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3ECBB3858D21 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 3ECBB3858D21 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=1741034701; cv=none; b=iFvGVXEMdG+XViWNITpKp5UVkhcq3VFw81JfBb3Qb9h+MO7jwTzr5yKaJJdu0isJs15ZMDPRHyTbb5PgCpf0fOa2wB8PbsrHBDhj9NVi24E3eIJu8XSZb5DMRtb3KWzEB0fUhiavewvEgKwXsI+7B4g8xgmqKJEYIL8weaIJC90= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741034701; c=relaxed/simple; bh=+4xPq8yBCyoms+K3wcRrbtP2SbxdHSWx0rBnVz5iNpI=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:From:To; b=COnGVjbBWhCf6KeYKp+bIbZ6Xw/Um+jJ3ci3P+gz/sDc8Q8XDO2RR8hVOTD0teFwDV8FiuAxqikAe6uDqpdYL7O/r+r9w0K5XhZBSaS0CYA9QSES0SdmXTQ9es9rfVrw2ALJOFpTUus8EtgCGY7XsGuEPVvyAZtHEQsdW5x2UjU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3ECBB3858D21 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741034700; bh=+4xPq8yBCyoms+K3wcRrbtP2SbxdHSWx0rBnVz5iNpI=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=onMRklGnl6vJXCLqJfrurNVImHgf77/f5wUK5zkoiUUkkGL2bCQZzh7lXUqs6JZIc HwxwrIwlXxO4uIQ6DVTyZxop7hRRhwHSqo2lkiJa6XJ6F7B9HmeFAJksqHNxrXK09r GF1P7DDQCbgSerjO6TMcBgA3NzUBQOq6/BIJMcAw= Received: by simark.ca (Postfix, from userid 112) id B8DDC1E105; Mon, 3 Mar 2025 15:45:00 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741034699; bh=+4xPq8yBCyoms+K3wcRrbtP2SbxdHSWx0rBnVz5iNpI=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=SqRDR3LhaVvTBgKOxvU4Yz9QfW2bMA4advTR/bX8g/yOHqmyx+e2TAAkscyRbNKQx fEccMEy02OfXmx2Nc+lH7aYmYLWKq5vEG3cQjg4NtwTvNy7fz5VvdidsQsHYJhkN63 7U6Jz0Tc8NNLDQsJqs7RccbrIXPOLc20N8a4Tq14= 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 F1A761E05C; Mon, 3 Mar 2025 15:44:58 -0500 (EST) Message-ID: <86d6f8f6-8fad-46ad-ae37-9fbbadb6586f@simark.ca> Date: Mon, 3 Mar 2025 15:44:58 -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> Content-Language: fr In-Reply-To: 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: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. Simon