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 D9DD13858D20 for ; Wed, 13 Sep 2023 13:50:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D9DD13858D20 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 38DDoMrh007379 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Sep 2023 09:50:27 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 38DDoMrh007379 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1694613027; bh=u6o/EN3Z9d3ZPkhkCPXFZmXYgaydiOeJifAAMbCuD78=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=uOXDMs0Q/QFn5Yw32moCGMlE/YmCnO8RL5ZXaY41U0zHBgWjgfo759Ngv8240328R WsorYCbXotqYg2yWXNpQb/GEJAMEyNb63JeOT9BK4ptcSIgHJCLxxa8HPXmH3KP2Br q4FhH+/WT2Yt/uB9fuer+eUW+4K3TS+4wR+sj3Jw= 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 978AB1E028; Wed, 13 Sep 2023 09:50:22 -0400 (EDT) Message-ID: <5d4e32ce-8e52-49ab-927a-cc850528e44a@polymtl.ca> Date: Wed, 13 Sep 2023 09:50:21 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 13/16] [gdb/generic] corefile/bug: Fixup (gcore) core file target description reading order Content-Language: fr To: Luis Machado , gdb-patches@sourceware.org Cc: thiago.bauermann@linaro.org References: <20230907152018.1031257-1-luis.machado@arm.com> <20230907152018.1031257-14-luis.machado@arm.com> <5b65717d-0a67-5f4c-e9ae-ff99cc00f369@arm.com> From: Simon Marchi In-Reply-To: <5b65717d-0a67-5f4c-e9ae-ff99cc00f369@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 13 Sep 2023 13:50:22 +0000 X-Spam-Status: No, score=-3031.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,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: >> I'm not convinced that this is right. The current role of >> gdbarch_core_read_description (AFAIU) is to provide a fallback to the >> note method. Usually, the note method is preferred, because it's >> precise, but if there's no note, maybe the gdbarch can derive a tdesc >> from what it sees in the core. Naturally, this use of >> gdbarch_core_read_description (as a fallback) has to go after trying the >> note method. >> >> Now, you want to to use gdbarch_core_read_description as an override to >> the note method, which is why you want to call it before trying the note >> method. I don't think the same gdbarch method can be used for both >> fallback and override. With your change, with an arch that defines a >> gdbarch_core_read_description hook, where we would have used the note >> before, we will now always use the hook. Not what we want. > > Yeah, it seems that way unfortunately. Looking back, maybe it would've been better to define the gdb tdesc note as a per-thread entry instead. > > I suppose we can still do it from now on, but the previous core files generated by gdb would > still need to be handled in a special way for AArch64. > >> >> Some options I see: >> >> - Add another gdbarch hook, so one is called before trying the note, >> and one after. >> - Add another gdbarch hook that allows the arch to modify the target >> desc read from the note. So the flow would be: >> core_target::read_description creates a target from the note, then >> calls the gdbarch hook. The latter could return the same tdesc, or a >> new tdesc. The AArch64 hook could then create a new tdesc based on >> the one read from the note, but with the SVE/SME bits tweaked. > > I think the first solution would work. But I see it as a temporary measure until we update the core file target description note to be per-thread. > > After that, I believe the gdbarch hook wouldn't be too useful. Well, as you mentioned above, there will still be the case of supporting old cores that only have one global target description note, right? Simon