Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Luis <luis.machado.foss@gmail.com>
To: srinath.parvathaneni@arm.com, gdb-patches@sourceware.org
Cc: guinevere@redhat.com, thiago.bauermann@linaro.org
Subject: Re: [PATCH v1] gdb/aarch64: Add support for FEAT_S1POE POR_EL0 register
Date: Sun, 21 Jun 2026 12:50:34 +0100	[thread overview]
Message-ID: <9473f052-ab79-4e2c-897f-1f255873de06@gmail.com> (raw)
In-Reply-To: <20260617170003.1351479-1-srinath.parvathaneni@arm.com>

On Wed, Jun 17, 2026 at 05:00:03PM +0000, srinath.parvathaneni@arm.com 
wrote:
 > From: Srinath Parvathaneni <srinath.parvathaneni@arm.com>
 >
 > Hi,
 >
 > FEAT_S1POE introduces the POR_EL0 register. This patch adds
 > support for POR_EL0 in both native GDB and gdbserver using
 > NT_ARM_POE and HWCAP2_POE detection.

Hi Srinath,

Thanks for the patch. A few comments below (some might overlap with what 
Ezra and Matthieu already raised).

 > +/* Feature check for Permission Overlay Extension.  */

Nit: FEAT_S1POE stands for Stage 1 Permission Overlay Enhancement,
not Extension. Please fix the comment.

 > +#ifndef HWCAP2_POE
 > +#define AARCH64_HWCAP2_POE (1ULL << 63)
 > +#endif

The #ifndef guard checks HWCAP2_POE but the macro being defined is
AARCH64_HWCAP2_POE. If a system header has already provided
HWCAP2_POE, AARCH64_HWCAP2_POE will silently remain undefined.

   #ifndef AARCH64_HWCAP2_POE
   #define AARCH64_HWCAP2_POE (1ULL << 63)
   #endif

 > +#ifndef AARCH64_SEGV_PKUERR
 > +#define AARCH64_SEGV_PKUERR 4  /* Protection overlay violation.  */
 > +#endif

Make it more informative:

   /* Data or instruction abort caused by a POE violation.  */

 > +/* The POE regset consists of 1 64-bit register.  */
 > +#define AARCH64_LINUX_SIZEOF_POE_REGSET (8)

Drop the parenthesis.

 > +#endif /* GDB_ARCH_AARCH64_POE_H */

Once the file is renamed the guard should become
GDB_ARCH_AARCH64_POE_LINUX_H.

 > diff --git a/gdb/nat/aarch64-poe.h b/gdb/nat/aarch64-poe.h
 > new file mode 100644
 > @@ -0,0 +1,49 @@
 > +#ifndef HWCAP2_POE
 > +#define HWCAP2_POE (1ULL << 63)
 > +#endif

<asm/hwcap.h> defines this on kernels >= 6.9. Is this fallback needed, 
and if so, why?

 > +#ifndef NT_ARM_POE
 > +#define NT_ARM_POE 0x40f
 > +#endif

Same question. This is in <uapi/linux/elf.h> on recent kernels.

 > +struct user_poe
 > +{
 > +  uint64_t por_el0;
 > +};

Why a struct for a single scalar? A bare uint64_t works fine here.

 > diff --git a/gdb/aarch64-tdep.h b/gdb/aarch64-tdep.h
 > @@ -208,6 +208,16 @@ struct aarch64_gdbarch_tdep : gdbarch_tdep_base
 >       return gcs_linux_reg_base != -1;
 >     }
 >
 > +  /* First POE register.  This is -1 if no POE feature is available.  */
 > +  int poe_regnum = -1;

"First POE register" implies there may be more than one. Since there
is exactly one, please use:

   /* Index of the POE register.  This is -1 if POE is not supported.  */

Upstream master now has comments for every other boolean in this
struct. Please add a comment as well.

 > diff --git a/gdb/arch/aarch64.h b/gdb/arch/aarch64.h
 > @@ -35,6 +35,7 @@ struct aarch64_features
 >       bool pauth = false;
 >       bool mte = false;
 >       bool fpmr = false;
 > +  bool poe = false;

Missing comment. Please add:

   /* Whether the Permission Overlay Extension (FEAT_S1POE) is
      supported.  */

 > diff --git a/gdb/aarch64-linux-nat.c b/gdb/aarch64-linux-nat.c
 > +/* Fill GDB's register array with the POE register value from the 
current
 > +   thread.  */
 > +
 > +static void
 > +fetch_por_el0_from_thread (regcache *regcache)

The convention for fetch functions in this file is to name them after
the feature or register group, not the specific register:
   fetch_fpmr_from_thread
   fetch_gcsregs_from_thread
   fetch_tlsregs_from_thread

Please rename to fetch_poereg_from_thread.

 > +{
 > +  aarch64_gdbarch_tdep *tdep
 > +      = gdbarch_tdep<aarch64_gdbarch_tdep> (regcache->arch ());
 > +
 > +  gdb_assert (tdep->poe_regnum != -1);

Please use:

   gdb_assert (tdep->has_poe ());

 > +  user_poe user_poe;
 > +  iovec iovec;

Letś not use a variable with the same name as the type.

 > +  int tid = get_ptrace_pid (regcache->ptid ());

get_ptrace_pid here looks correct, as we have the regcache information.

 > diff --git a/gdb/aarch64-linux-tdep.c b/gdb/aarch64-linux-tdep.c
 > +/* Convert a POR_EL0 Perm<m> overlay permission encoding into 
rwx-style string.
 > +   For example:
 > +      0b0011 -> "r-x" (3)
 > +      0b0101 -> "rw-" (5)
 > +      0b0111 -> "rwx" (7)
 > +      0b0000 -> "---" (0)
 > +   Reserved encodings (0b1xxx) are returned as "???".  */
 > +
 > +static const char*
 > +aarch64_perm_overlay_decode (unsigned int perm)

Missing space before *.

 > +/* For POE SEGSEGV, show additional information.  */

Typo: SEGSEGV should be SIGSEGV.

 > +  else if (si_code == AARCH64_SEGV_PKUERR && si_errno == 0)
 > +    meaning = _("Protection overlay violation");

The si_errno == 0 condition is not meaningful for SEGV_PKUERR. si_errno
is not used to qualify this signal code, is it?

If so...

   else if (si_code == AARCH64_SEGV_PKUERR)
     meaning = _("Protection overlay violation");

 > diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c
 > +  if (features.poe)
 > +    regnum = create_feature_aarch64_poe (tdesc.get (), regnum);

Is identation off here?

 > diff --git a/gdbserver/linux-aarch64-low.cc 
b/gdbserver/linux-aarch64-low.cc
 > +static void
 > +aarch64_store_por_el0_regset (struct regcache *regcache, const void 
*buf)
 > +{
 > +  const user_poe *regset = (const user_poe *) buf;
 > +  int poe_regnum  = find_regno (regcache->tdesc, "por_el0");

Single space before =.

 > +  { PTRACE_GETREGSET, PTRACE_SETREGSET, NT_ARM_POE,
 > +    0, OPTIONAL_REGS,
 > +    nullptr, aarch64_store_por_el0_regset },

Document/Add comment that we don´t support writing for now.

Also document/add comment stating we lack core file support as well.

Reviewed-By: Luis Machado <luis.machado.foss@gmail.com>

      parent reply	other threads:[~2026-06-21 11:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-17 17:00 srinath.parvathaneni
2026-06-17 23:38 ` Ezra Sitorus
2026-06-18 17:04 ` Matthieu Longo
2026-06-21 11:32   ` Luis
2026-06-21 11:50 ` Luis [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9473f052-ab79-4e2c-897f-1f255873de06@gmail.com \
    --to=luis.machado.foss@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=guinevere@redhat.com \
    --cc=srinath.parvathaneni@arm.com \
    --cc=thiago.bauermann@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox