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 255993858D20 for ; Tue, 19 Sep 2023 20:50:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 255993858D20 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 38JKnvS1006367 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Sep 2023 16:50:02 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 38JKnvS1006367 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1695156603; bh=n8Sa1tDwrmM14uxFL+OYjvWsb51rdGUOgn05Li4w2Ds=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=HETAEu8/sX28e8yxc8NjQl+7kOzUK4u3B+yt16quI9XpCnUHxGJ5fSQZP7dDOeBrB HcBOW0Dohz0MMz+YoNGwgq3SJiBDJoTgURXMDgnqyoR4E4tmyp9lhPBKt91tW0MxiE gEQmbV4sVUvUgUtQA/fN9DPo44ay4OwiXSzUYd5k= 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 99C6C1E028; Tue, 19 Sep 2023 16:49:57 -0400 (EDT) Message-ID: <957943ea-a51a-4cdb-b86e-68d2fb85de9d@polymtl.ca> Date: Tue, 19 Sep 2023 16:49:57 -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 , gdb-patches@sourceware.org Cc: thiago.bauermann@linaro.org References: <20230918212651.660141-1-luis.machado@arm.com> <20230918212651.660141-16-luis.machado@arm.com> From: Simon Marchi In-Reply-To: <20230918212651.660141-16-luis.machado@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 19 Sep 2023 20:49:58 +0000 X-Spam-Status: No, score=-3037.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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/18/23 17:26, Luis Machado wrote: > New entry in v7. > > --- Note: when you use `---` in a commit message, git-am drops whatever comes after that, so here we lose the commit message when applying. I think the intention is that you'd put whatever you don't want to appear in the commit message (like the "new in version X" notes) after the `---`. I'll try to do that from now on. > > Due to the nature of the AArch64 SVE/SME extensions in GDB, each thread > can potentially have distinct target descriptions/gdbarches. > > When loading a gcore-generated core file, at the moment GDB gives priority > to the target description dumped to NT_GDB_TDESC. Though technically correct > for most targets, it doesn't work correctly for AArch64 with SVE or SME > support. > > The correct approach for AArch64/Linux is to either have per-thread target > description notes in the corefiles or to rely on the > gdbarch_core_read_description hook, so it can figure out the proper target > description for a given thread based on the various available register notes. > > The former, although more correct, doesn't address the case of existing gdb's > that only output a single target description note. > > This patch goes for the latter, and adds a new gdbarch hook to conditionalize > the use of the corefile target description note. The hook is called > use_target_description_from_corefile_notes. > > The hook defaults to returning true, meaning targets will use the corefile > target description note. AArch64 Linux overrides the hook to return false > when it detects any of the SVE or SME register notes in the corefile. > > Otherwise it should be fine for AArch64 Linux to use the corefile target > description note. > > When we support per-thread target description notes, then we can augment > the AArch64 Linux hook to rely on those notes. > > Regression-tested on aarch64-linux Ubuntu 22.04/20.04. The question that came to mind when reading this is (I already asked you on IRC, but perhaps someone else has an idea): if GDB has to know how to infer target descriptions from the core file contents (the kernel-generated core files don't include target description notes, only GDB-generated core files do), what advantage do we have of storing and reading the target description in the core? Are there any scenarios where the target description note conveys something that GDB wouldn't figure out by analyzing the core file content? > diff --git a/gdb/gdbarch_components.py b/gdb/gdbarch_components.py > index 846467b8d83..bbb9b188286 100644 > --- a/gdb/gdbarch_components.py > +++ b/gdb/gdbarch_components.py > @@ -2732,3 +2732,22 @@ Read core file mappings > predefault="default_read_core_file_mappings", > invalid=False, > ) > + > +Method( > + comment=""" > +Return true if the target description for all threads should be read from the > +target description core file note(s). Return false if the target description > +for all threads should be inferred from the core file contents/sections. > + > +The corefile's bfd is passed through OBFD. > + > +This hook should be used by targets that can have distinct target descriptions > +for each thread when the core file only holds a single target description > +note. I think the last paragraph should be left out. An arch could decide not to use the target description note for whatever reason it sees fit, this is just one example. The reason for AArch64 appears to be sufficiently described in the AArch64-specific files. > +""", > + type="bool", > + name="use_target_description_from_corefile_notes", > + params=[("struct bfd *", "obfd")], Can you name the parameter core_bfd maybe? Just a bit more precise. Otherwise: Approved-By: Simon Marchi Simon