From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 1hilHuMKxmcODgQAWB0awg (envelope-from ) for ; Mon, 03 Mar 2025 15:02:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741032163; bh=5/QjCIE2H///saxYO8XTzlxk83XhT7Wfq7eq6ALwLVI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=PWcXsuQTEm8Jz7tSkpXEsvVNsoJ0c5IDGXxDnqs2vXxy1iL1SEFlqLz1bn4EsAeqX qn3Z+qfaAN0jjs5TeiG7vcJ8HRBYbyFcmomyglynU44RpaMNHBzsEn5I4G2lbEsNIs dcjXMqmx27uzAqH55lVNpm8htqglr1lkXp2ZQwQs= Received: by simark.ca (Postfix, from userid 112) id 6E1A01E105; Mon, 3 Mar 2025 15:02:43 -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=vK98uHI5; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=NNNsEz65; 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 B3AA31E05C for ; Mon, 3 Mar 2025 15:02:42 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5B3163858D28 for ; Mon, 3 Mar 2025 20:02:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5B3163858D28 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=vK98uHI5; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=NNNsEz65 Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 881153858D26 for ; Mon, 3 Mar 2025 20:02:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 881153858D26 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 881153858D26 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=1741032128; cv=none; b=pXznSyKqvwl6JPklNLRDCDHSUU1OYKL1lB5NW1thzCf6gE4LngmqOwYR4Zmy/wBO9+8EVWYU/IwlexsR+ux194ONQSO1oxNcwbTGtRczqK6r5PpIxS0mrz8iJZe9d16J74+EpibQG7ACqPJwf0VMHu55Ft394ggt+Y9E7WNtVsU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741032128; c=relaxed/simple; bh=5/QjCIE2H///saxYO8XTzlxk83XhT7Wfq7eq6ALwLVI=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=fOmYsfbEApSu9uzUeInSESEEZMT6WkUovXQFROCYyk7XDYWHvL1yAQW76OUp+5yEr4gqjXQds1rXkoQAzmg9ITP4+QL03qB6srCxAyN7MmwFchsNtYINLHrDMoVHP54OVyJPDP7OQWnF4pKMfqMjkJnrsqALr0MUWiiilm3gcX0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 881153858D26 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741032128; bh=5/QjCIE2H///saxYO8XTzlxk83XhT7Wfq7eq6ALwLVI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=vK98uHI5S9NfYiAaYQpkXa3ESaNhND6ztvSjuBHSkPa67qzvkYzJBXv/Y466gSUGr IGcwd079J0g4siOoKB7QDKVZ2o/LQjSOKyxCvOafH8qwcmQ3aWwmXXeLbGTpE7iIVs Ci75WTcAovWcHqeAqD11QQ9pYqGpZOUZgxUerVig= Received: by simark.ca (Postfix, from userid 112) id 4356A1E110; Mon, 3 Mar 2025 15:02:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1741032126; bh=5/QjCIE2H///saxYO8XTzlxk83XhT7Wfq7eq6ALwLVI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=NNNsEz65Y2wltqFBPE5opEwd+u1wtMcKlcRzu1dhYemr/9AGYncMS2rUo7WSLA/QN fwmkSDcxkWTpH9xZJ4G4eijIV5JrxzxU591eksjQg8d4PyxKWUfhqkgeSHKXp3JhuF 242BHw7CD7lvpiM+qUd0e3+HUqsQDXZPnLAO4ftw= 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 B461A1E05C; Mon, 3 Mar 2025 15:02:06 -0500 (EST) Message-ID: Date: Mon, 3 Mar 2025 15:02:06 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] [gdb/symtab] Fix dwarf version of DWO TU 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 From: Simon Marchi In-Reply-To: <1e6e2875-acb5-40e7-99aa-d5d15d245b8e@suse.de> 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 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. Simon