From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id WY80Ahb7k2l9cD4AWB0awg (envelope-from ) for ; Tue, 17 Feb 2026 00:22:30 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=DRo636jw; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 040AC1E089; Tue, 17 Feb 2026 00:22:29 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (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 CFED11E089 for ; Tue, 17 Feb 2026 00:22:28 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 22CDA4BAE7CA for ; Tue, 17 Feb 2026 05:22:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 22CDA4BAE7CA Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=DRo636jw Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) by sourceware.org (Postfix) with ESMTPS id 970DE4BAD155 for ; Tue, 17 Feb 2026 05:21:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 970DE4BAD155 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 970DE4BAD155 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::936 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1771305718; cv=none; b=DTKUvtrCGKgrDdozpTjGz7eb//Kfed+37QE1ePTCA0hc6KiyIg8YqBJPysf4WxaZU8xxnLd05FSY1M6nEAv6/FRnFj2CjHMafWmA2TsVC22cpcnDOhivJdrwHpWzAoDQy2VzgwkwVWbu/itRSVmwBq1lEZrnyBxZRq0XPHX+kGs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1771305718; c=relaxed/simple; bh=xxmvRVcMUkGTqVMUcnuL09X+vP13EpEQh7+zeWIAE8Q=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=kAeIPl22Alz76euB3WpFN9BDMeKWaKPcC491yxS4/Zxc5IMVfZZuJcrPEiAhfXeSHko4rMbzRzMuOlEarpNDtKvaZSK8CljvtBAmu2+GIkfESovIquqa8XCvYScw8PQGM8EtcAv3OEX6FdQZEbkykuWboIgThlkxlvwh/HEW/TE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 970DE4BAD155 Received: by mail-ua1-x936.google.com with SMTP id a1e0cc1a2514c-948ab1c79ebso1019174241.1 for ; Mon, 16 Feb 2026 21:21:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1771305718; x=1771910518; darn=sourceware.org; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=/h7E17SnXmfr/i14htY2iFINVokrbNFJLKCcBzg5VaQ=; b=DRo636jwdSXj6BQcODy1PRhFUWxm1FJ96ONrQIOPSsp0qIiWWSImFUnl59ZVbna9ya ZCML+2FDbesnIEHLM6h/YdP96wWGqi9WpzhYspWXjjB+kvh0PjvXO35AuezF3zSF6pKv 149p0Ewm1BWLm00Qc56nzKSw5QRgc7n8I6TOKFkmdzCbuUt520uDc9UgSxB39AFJ+nfd PD/ILnlQRELiPNpuZvoBN2sugnMNO5MbyHO2oXfUYc1geLsCoEb8CdElWvyxAln4ij0x QWHGWvVmORaCL+gM1+ujCddmSZ/HW78nBxBV2t6EKxEA0kIiZLFIajg138ZGptwYnkN3 3rjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771305718; x=1771910518; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/h7E17SnXmfr/i14htY2iFINVokrbNFJLKCcBzg5VaQ=; b=dX9MiGScjoqM+SmFqQ/u2uviZPh75cxx7VHWti2D5yIFxzEyEB41Iahyk9aFK+AGrt +OECLXaURmInNMjXd6Kn2oVY/X+31dbFsDfDDL/AjUa52JeFnWjjjug2UjxFPuh8PbZr b4pmnrVRo9jG4gingFrM0mPzZE4iMSfaL7/I3+XbizNVue9RKk0g+EUeTzucIBOQB1D/ BjdN79ob1NuXzsy48u1WzdC46IAqHnuNmBioP/FvJfeGLVk3BA+B/88iZXMn87CUjeO2 K6oSb/7rxIij5lCAVFclONOCmhuei1+yzKGMbjTTj7I2255ktQ1yPthi408YZK9CeH5k UJAw== X-Gm-Message-State: AOJu0YyKxX8C6WZLiYydefSVpz+NHOnzquZ292R48KnbOaK4YGdLOFtS lKMDMGG6sPxGlGR5WM3S8Huc8JaQ0EVoHrqumMIDGtdmb639PTjVy7Y9QWSmnMP9Cvk= X-Gm-Gg: AZuq6aJLjKpqhjwd52V36+OC+pNRlPNuJ6bO5ZrHIiwpRqi/qI6tsJ2XVX+stygBoPK dw+Z5usTvPttTqF/VzAO7K0n26kdRCiclmLvaTE8BFxfasF3l6jwU+tBiMxEyhABKndKB+iyg14 +MjSOOqcsPCsZBR11CsQKrYL2U2JiXf6aiJ+uDb8L/HFD13Vi7mg18vwRmj0Qe6OgxH2PxqpzpW 313MMz+GHL+885JHhoFHEqWpuPh6VVt8iqGCVM1MHipz12bqW3JfXEYpe7dnkbqSp/ZMATFVU2c 1U5yTTzqBIfwUpKOe4/TuNg7g0rq6kH7JaWIERAm7v01AeLTW2XN9T2A1zTFc/0E+8NR8f2MD3v FKS0IyQWTHNvRDoVunR2OMePP3cshTJ/Gt092hlM2ScsYw2Xjuwg5t4fMTCaTvnbXnbqsf6QSAb rChZKpogqjwWqeOe5TsKkeaqGnmIZfKSti/g== X-Received: by 2002:a05:6102:162a:b0:5f8:e323:580d with SMTP id ada2fe7eead31-5fe16d85b0bmr5110931137.11.1771305717771; Mon, 16 Feb 2026 21:21:57 -0800 (PST) Received: from localhost ([2804:14d:7e39:8083:f04c:42e3:5943:38f6]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-5fde87fb840sm8328648137.3.2026.02.16.21.21.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Feb 2026 21:21:56 -0800 (PST) From: Thiago Jung Bauermann To: Luis Cc: gdb-patches@sourceware.org, Chris Packham , Tom Tromey , Simon Marchi Subject: Re: [PATCH v2 1/2] GDB: aarch64-linux: Reorganize gdb/arch/aarch64-gcs-linux.h In-Reply-To: <20e08a82-2522-4aee-bcbd-6125a4042f76@gmail.com> (Luis's message of "Sat, 14 Feb 2026 09:38:16 +0000") References: <20260214045504.361392-1-thiago.bauermann@linaro.org> <20260214045504.361392-2-thiago.bauermann@linaro.org> <20e08a82-2522-4aee-bcbd-6125a4042f76@gmail.com> User-Agent: mu4e 1.12.15; emacs 30.2 Date: Tue, 17 Feb 2026 02:21:53 -0300 Message-ID: <877bscx7v2.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hello, Luis writes: > Hi, > > First, aarch64's code could really use a refactoring in terms of cleaning= up the headers > and splitting things into their own files. With that said, we don=C2=B4t = need to do that now, > but would be nice to do it eventually. Ok. I cleaned up the things you pointed out in this review, at least. > On 14/02/2026 04:54, Thiago Jung Bauermann wrote: >> This file implicitly depends on aarch64-linux's for >> the definition of GCS_MAGIC and on its for the definition >> of HWCAP_GCS, but files on gdb/arch/ shouldn't depend on include files >> specific to the architecture. >> Regarding GCS_MAGIC and struct user_gcs, move that code section to >> gdb/nat/aarch64-linux.h which can rely on and >> . >> To fix the use of struct user_gcs in gdb/aarch64-linuxt-dep.c, define a >> macro with the size of the GCS regset in aarch64-linux-tdep.h and use it >> in aarch64-linux-tdep.c, as is done for other regsets and following a >> suggestion from Simon Marchi. >> Regarding HWCAP_GCS, rename it to AARCH64_HWCAP_GCS to ensure that it >> won't conflict with any system header definition and define it >> unconditionally, following the example of AARCH64_HWCAP_PACA. >> Renaming HWCAP_GCS also avoids a potential (and I would say unlikely) >> problem on non-AArch64 systems: naming conflict if by coincidence they h= ave >> an unrelated hardware capability bit also named HWCAP_GCS. >> Finally, I noticed that AARCH64_HWCAP_PACA is duplicated in GDB and >> gdbserver files, so consolidate them in the same header and rename it to >> gdb/arch/aarch64-linux.h since it isn't just about GCS anymore. >> --- >> As I mentioned on v1's email thread, this patch opens a small can of wor= ms, >> since other gdb/arch/aarch64*.h do the same kind of thing (mostly with >> HWCAP macros but also a few others). >> Perhaps I'm going too far with the HWCAP_GCS renaming and the current >> handling of it is fine? >> gdb/Makefile.in | 2 +- >> gdb/aarch64-linux-nat.c | 4 +-- >> gdb/aarch64-linux-tdep.c | 9 +++--- >> gdb/aarch64-linux-tdep.h | 6 ++-- >> .../{aarch64-gcs-linux.h =3D> aarch64-linux.h} | 30 +++++------------= -- >> gdb/nat/aarch64-linux.h | 16 ++++++++++ >> gdbserver/linux-aarch64-low.cc | 7 ++--- >> 7 files changed, 36 insertions(+), 38 deletions(-) >> rename gdb/arch/{aarch64-gcs-linux.h =3D> aarch64-linux.h} (61%) >> diff --git a/gdb/Makefile.in b/gdb/Makefile.in >> index 2aa95be968ac..fd47c613966a 100644 >> --- a/gdb/Makefile.in >> +++ b/gdb/Makefile.in >> @@ -1301,7 +1301,7 @@ HFILES_NO_SRCDIR =3D \ >> amdgpu-tdep.h \ >> annotate.h \ >> arch/aarch32.h \ >> - arch/aarch64-gcs-linux.h \ >> + arch/aarch64-linux.h \ > > If there is anything feature-specific about things in aarch64-linux.h, I= =C2=B4d rather have a > new featute-specific file here. Ok. For v3 I kept arch/aarch64-gcs-linux.h and there's no arch/aarch64-linux.h anymore. >> arch/aarch64.h \ >> arch/aarch64-insn.h \ >> arch/aarch64-mte.h \ >> diff --git a/gdb/aarch64-linux-nat.c b/gdb/aarch64-linux-nat.c >> index 028de981588b..b2dd192a7b56 100644 >> --- a/gdb/aarch64-linux-nat.c >> +++ b/gdb/aarch64-linux-nat.c >> @@ -51,7 +51,7 @@ >> #include "gdb_proc_service.h" >> #include "arch-utils.h" >> -#include "arch/aarch64-gcs-linux.h" >> +#include "arch/aarch64-linux.h" > > Likewise above. > >> #include "arch/aarch64-mte-linux.h" >> #include "nat/aarch64-mte-linux-ptrace.h" >> @@ -1013,7 +1013,7 @@ aarch64_linux_nat_target::read_description () >> active or not. */ >> features.vq =3D aarch64_sve_get_vq (tid); >> features.pauth =3D hwcap & AARCH64_HWCAP_PACA; >> - features.gcs =3D features.gcs_linux =3D hwcap & HWCAP_GCS; >> + features.gcs =3D features.gcs_linux =3D hwcap & AARCH64_HWCAP_GCS; >> features.mte =3D hwcap2 & HWCAP2_MTE; >> features.tls =3D aarch64_tls_register_count (tid); >> /* SME feature check. */ >> diff --git a/gdb/aarch64-linux-tdep.c b/gdb/aarch64-linux-tdep.c >> index b85c25ecae1d..33e1b411ff1d 100644 >> --- a/gdb/aarch64-linux-tdep.c >> +++ b/gdb/aarch64-linux-tdep.c >> @@ -51,7 +51,7 @@ >> #include "record-full.h" >> #include "linux-record.h" >> -#include "arch/aarch64-gcs-linux.h" >> +#include "arch/aarch64-linux.h" > > Likewise here. > >> #include "arch/aarch64-mte.h"> #include "arch/aarch64-mte-linux.h" >> #include "arch/aarch64-scalable-linux.h" >> @@ -1734,8 +1734,9 @@ aarch64_linux_iterate_over_regset_sections (struct= gdbarch *gdbarch, >> gcs_regmap, regcache_supply_regset, regcache_collect_regset >> }; >> - cb (".reg-aarch-gcs", sizeof (user_gcs), sizeof (user_gcs), >> - &aarch64_linux_gcs_regset, "GCS registers", cb_data); >> + cb (".reg-aarch-gcs", AARCH64_LINUX_SIZEOF_GCS_REGSET, >> + AARCH64_LINUX_SIZEOF_GCS_REGSET, &aarch64_linux_gcs_regset, >> + "GCS registers", cb_data); >> } >> } >> @@ -1761,7 +1762,7 @@ aarch64_linux_core_read_description (struct gdba= rch *gdbarch, >> length. */ >> features.vq =3D aarch64_linux_core_read_vq_from_sections (gdbarch, a= bfd); >> features.pauth =3D hwcap & AARCH64_HWCAP_PACA; >> - features.gcs =3D features.gcs_linux =3D hwcap & HWCAP_GCS; >> + features.gcs =3D features.gcs_linux =3D hwcap & AARCH64_HWCAP_GCS; >> features.mte =3D hwcap2 & HWCAP2_MTE; >> features.fpmr =3D hwcap2 & HWCAP2_FPMR; >> diff --git a/gdb/aarch64-linux-tdep.h b/gdb/aarch64-linux-tdep.h >> index e926687ff6eb..f247d6aa72cd 100644 >> --- a/gdb/aarch64-linux-tdep.h >> +++ b/gdb/aarch64-linux-tdep.h >> @@ -39,10 +39,10 @@ >> /* The MTE regset consists of a 64-bit register. */ >> #define AARCH64_LINUX_SIZEOF_MTE_REGSET (8) >> +/* The GCS regset consists of 3 64-bit registers. */ >> +#define AARCH64_LINUX_SIZEOF_GCS_REGSET (3 * 8) >> + > > The above is the kind of feature-specific data we should put into > arch/aarch64-linux-.[c|h]. At the moment not all of it follows t= his particular > pattern, and that's annoying. But we should strive to clean it up. Ok, in v3 I moved this constant to gdb/arch/aarch64-gcs-linux.h. >> extern const struct regset aarch64_linux_gregset; >> extern const struct regset aarch64_linux_fpregset; >> -/* Matches HWCAP_PACA in kernel header arch/arm64/include/uapi/asm/hw= cap.h. */ >> -#define AARCH64_HWCAP_PACA (1 << 30) >> - > > The above is older code, and that bit is likely available out there. We s= hould do the same > treatment to it as the others. That is, if it is not defined, define it. = Otherwise use > whatever is defined. Ok. In v3 I added a patch renaming this to HWCAP_PACA and moving it to gdb/arch/aarch64-pauth-linux.h. >> #endif /* GDB_AARCH64_LINUX_TDEP_H */ >> diff --git a/gdb/arch/aarch64-gcs-linux.h b/gdb/arch/aarch64-linux.h >> similarity index 61% >> rename from gdb/arch/aarch64-gcs-linux.h >> rename to gdb/arch/aarch64-linux.h >> index b31fc32daa03..a33c082a0318 100644 >> --- a/gdb/arch/aarch64-gcs-linux.h >> +++ b/gdb/arch/aarch64-linux.h >> @@ -1,4 +1,4 @@ >> -/* Common Linux target-dependent definitions for AArch64 GCS >> +/* Common Linux target-dependent definitions for AArch64 running Linux. >> > Copyright (C) 2025-2026 Free Software Foundation, Inc. >> @@ -17,28 +17,12 @@ >> You should have received a copy of the GNU General Public License >> along with this program. If not, see . */ >> -#ifndef GDB_ARCH_AARCH64_GCS_LINUX_H >> -#define GDB_ARCH_AARCH64_GCS_LINUX_H >> - >> -#include >> +#ifndef GDB_ARCH_AARCH64_LINUX_H >> +#define GDB_ARCH_AARCH64_LINUX_H >> +/* Matches HWCAP_PACA in kernel header arch/arm64/include/uapi/asm/hw= cap.h. */ >> +#define AARCH64_HWCAP_PACA (1 << 30) > > We should either move all of the definitions to arch/aarch64-linux.h or m= ove them to their > own separate feature files. See mte/sve/sme for instance. I chose the separate feature files option, as you suggested below. >> /* Feature check for Guarded Control Stack. */ >> -#ifndef HWCAP_GCS >> -#define HWCAP_GCS (1ULL << 32) >> -#endif >> - >> -/* Make sure we only define these if the kernel header doesn't. */ >> -#ifndef GCS_MAGIC >> - >> -/* GCS state (NT_ARM_GCS). */ >> - >> -struct user_gcs >> -{ >> - uint64_t features_enabled; >> - uint64_t features_locked; >> - uint64_t gcspr_el0; >> -}; >> - >> -#endif /* GCS_MAGIC */ >> +#define AARCH64_HWCAP_GCS (1ULL << 32) >> -#endif /* GDB_ARCH_AARCH64_GCS_LINUX_H */ >> +#endif /* GDB_ARCH_AARCH64_LINUX_H */ >> diff --git a/gdb/nat/aarch64-linux.h b/gdb/nat/aarch64-linux.h >> index bb5381eba3ef..f7c09aa112bf 100644 >> --- a/gdb/nat/aarch64-linux.h >> +++ b/gdb/nat/aarch64-linux.h >> @@ -19,7 +19,9 @@ >> #ifndef GDB_NAT_AARCH64_LINUX_H >> #define GDB_NAT_AARCH64_LINUX_H >> +#include >> #include >> +#include >> /* Defines ps_err_e, struct ps_prochandle. */ >> #include "gdb_proc_service.h" >> @@ -113,6 +115,20 @@ typedef struct compat_siginfo >> #define cpt_si_band _sifields._sigpoll._band >> #define cpt_si_fd _sifields._sigpoll._fd >> +/* Make sure we only define these if the kernel header doesn't. */ >> +#ifndef GCS_MAGIC >> + >> +/* GCS state (NT_ARM_GCS). */ >> + >> +struct user_gcs >> +{ >> + uint64_t features_enabled; >> + uint64_t features_locked; >> + uint64_t gcspr_el0; >> +}; >> + >> +#endif /* GCS_MAGIC */ >> + > > To keep things clean I=C2=B4d define the above in a separare file for the= feature. See > gdb/nat/aarch64-mte-linux-ptrace.[h|c] for instance. Ok. In v3 I created gdb/nat/aarch64-gcs-linux-ptrace.h and moved the struct user_gcs definition to it. >> void aarch64_siginfo_from_compat_siginfo (siginfo_t *to, >> compat_siginfo_t *from); >> void aarch64_compat_siginfo_from_siginfo (compat_siginfo_t *to, >> diff --git a/gdbserver/linux-aarch64-low.cc b/gdbserver/linux-aarch64-lo= w.cc >> index b19e605f55d6..60ea50f609cc 100644 >> --- a/gdbserver/linux-aarch64-low.cc >> +++ b/gdbserver/linux-aarch64-low.cc >> @@ -39,7 +39,7 @@ >> #include "gdb_proc_service.h" >> #include "arch/aarch64.h" >> -#include "arch/aarch64-gcs-linux.h" >> +#include "arch/aarch64-linux.h" > > See the comment below about having per-feature files. I think having per-= feature files is > less work at this point. Agreed. >> #include "arch/aarch64-mte-linux.h" >> #include "arch/aarch64-scalable-linux.h" >> #include "linux-aarch32-tdesc.h" >> @@ -984,9 +984,6 @@ aarch64_adjust_register_sets (const struct aarch64_f= eatures &features) >> } >> } >> -/* Matches HWCAP_PACA in kernel header arch/arm64/include/uapi/asm/hw= cap.h. */ >> -#define AARCH64_HWCAP_PACA (1 << 30) >> - >> /* Implementation of linux target ops method "low_arch_setup". */ >> void >> @@ -1009,7 +1006,7 @@ aarch64_target::low_arch_setup () >> /* A-profile MTE is 64-bit only. */ >> features.mte =3D linux_get_hwcap2 (pid, 8) & HWCAP2_MTE; >> features.tls =3D aarch64_tls_register_count (tid); >> - features.gcs =3D features.gcs_linux =3D linux_get_hwcap (pid, 8) = & HWCAP_GCS; >> + features.gcs =3D features.gcs_linux =3D linux_get_hwcap (pid, 8) = & AARCH64_HWCAP_GCS; >> features.fpmr =3D linux_get_hwcap2 (pid, 8) & HWCAP2_FPMR; >> /* Scalable Matrix Extension feature and size check. */ > > Checking arch/aarch64.h, HWCAP2_FPMR looks out of place as well. So yeah,= overall these > files need a bit of a cleanup. Ok. In v3 I added a patch moving it to gdb/arch/aarch64-fpmr-linux.h. --=20 Thiago