From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id x2xFLjaqEWWiuhwAWB0awg (envelope-from ) for ; Mon, 25 Sep 2023 11:41:42 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=IiJRT4Go; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id B44F91E0C3; Mon, 25 Sep 2023 11:41:42 -0400 (EDT) Received: from server2.sourceware.org (ip-8-43-85-97.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 A25771E092 for ; Mon, 25 Sep 2023 11:41:40 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 086273857029 for ; Mon, 25 Sep 2023 15:41:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 086273857029 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1695656500; bh=ww6yG5ijuFl4ZINkCeE5rWg1Rs3bmkOzvzHbjl5PZaI=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=IiJRT4GoQwSdQz1Ga04FVG2kZafXYgxZC18O2rUouZM4XPkSYyqvcol95KMxGpF8d uT5nQSbXFv+XeoiKOEXIch1vf0Z4CKzaTcfeWQO4+RQ/yM3YEhh1YVvfE4+omEEMo4 yC0AmylAEmdpoNxO5JH8TgUDb81qtRDRyG1sUTD8= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 1F4BF3858CDA for ; Mon, 25 Sep 2023 15:41:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1F4BF3858CDA Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 38PFfASf000618 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 25 Sep 2023 11:41:15 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 38PFfASf000618 Received: from [172.16.0.192] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (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 48AF51E092; Mon, 25 Sep 2023 11:41:10 -0400 (EDT) Message-ID: <082c6cbd-7a30-4b21-962a-3c87f4da9aa8@polymtl.ca> Date: Mon, 25 Sep 2023 11:41:09 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 15/18] [gdb/generic] corefile/bug: Add hook to control the use of target description notes from corefiles Content-Language: fr To: Luis Machado , Andrew Burgess , gdb-patches@sourceware.org Cc: thiago.bauermann@linaro.org References: <20230918212651.660141-1-luis.machado@arm.com> <20230918212651.660141-16-luis.machado@arm.com> <87pm2cyldy.fsf@redhat.com> <87led0yif2.fsf@redhat.com> <423fed06-ce80-52d0-013d-03384fecc853@arm.com> <87il83yhbj.fsf@redhat.com> <10c90dbb-75fc-43fa-a3b4-90359ad21f51@arm.com> In-Reply-To: <10c90dbb-75fc-43fa-a3b4-90359ad21f51@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 25 Sep 2023 15:41:10 +0000 X-Spam-Status: No, score=-3031.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 9/21/23 06:44, Luis Machado via Gdb-patches wrote: >>>> For point (2) I agree with the premise that we need a mechanism to stop >>>> AArch64 loading the incorrect single NT_GDB_TDESC. This is a slight >>>> change in stance from what I originally wrote, but our IRC conversation >>>> showed me I was wrong originally. I don't have time this evening to >>>> look at this, but will follow up again tomorrow with more thoughts. >> >> I wonder, instead of adding the new hook, maybe we should just reorder >> the checks in core_target::read_description -- ask the gdbarch to grok a >> tdesc from the .regs (etc) sections, and if that fails, check for an >> encoded tdesc. >> > > That's exactly what I did a few versions earlier. But Simon pointed out it would > effectively be a conflicting situation given our choice of defaulting to reading the > target description from the NT_GDB_TDESC. So I went with the hook, which, to be honest, > seems cleaner. Hi, I did not have the complete historical picture when I suggested this, Andrew later explained that this was added for some RISC-V target for which a tdesc could not be reconstructed from just the dumped register state. I thought that the NT_GDB_TDESC note was a better source of truth than just the register state. My understanding now is that for most targets (including AArch64 with SME and friends), reconstructing the tdesc from the register state works equally well as reading an NT_GDB_TDESC note (that holds the right tdesc). So, we can say that having the NT_GDB_TDESC note there is useless in these cases. So now, my question is: when we generate a core, should we only generate an NT_GDB_TDESC note for those targets for which we know a tdesc note will be necessary? That would involve a gdbarch hook where the arch can say "yes please generate a tdesc note in this core", which would default to false. Simon