From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Ouj5LqYJCmUaUxkAWB0awg (envelope-from ) for ; Tue, 19 Sep 2023 16:50:46 -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=nnyXE03a; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id B34D71E0C3; Tue, 19 Sep 2023 16:50:46 -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 A0DE41E028 for ; Tue, 19 Sep 2023 16:50:44 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 102333858D39 for ; Tue, 19 Sep 2023 20:50:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 102333858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1695156644; bh=n8Sa1tDwrmM14uxFL+OYjvWsb51rdGUOgn05Li4w2Ds=; 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=nnyXE03a9Kk4JElWgFXV3hNznF3/NZSC0Vun37uprjMpYF970MkycOsnNhrKl0k9K Ms1ohCD8hHUc/vDQYyXMYOvrEEDs8Pp+YQTjp6gw3IBeOB117vpEwVS6vGKS2hn8N8 o51zshRDCDhjsxsesNzOQmJtM1UiIUfqYXvkLv4o= 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 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 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> 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 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/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