From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1695656475; bh=ww6yG5ijuFl4ZINkCeE5rWg1Rs3bmkOzvzHbjl5PZaI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=HDZCfrfruWis8OzJ4HHIJBDr7yiKySkLW1IDwglLS0iyL/U4jUhYf81z3/Kigu5ed bY7Puv5PnwQ8kiMYiwWNl3QFezSm1gju8iXP1Ca0KyHcBQk0rOvs3xy/vXtapBCHja Z5aAjeoOj/l0i4JQpU3J9LWqs/YxAOvmUUBhazsg= 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> From: Simon Marchi 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 List-Id: 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