Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Srinath Parvathaneni <Srinath.Parvathaneni@arm.com>
To: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	"luis.machado.foss@gmail.com" <luis.machado.foss@gmail.com>,
	"guinevere@redhat.com" <guinevere@redhat.com>,
	Ezra Sitorus <Ezra.Sitorus@arm.com>,
	Matthieu Longo <Matthieu.Longo@arm.com>
Subject: Re: [PATCH v2 2/7] gdb/aarch64: Add custom printing for POR_EL0
Date: Mon, 29 Jun 2026 07:02:38 +0000	[thread overview]
Message-ID: <AS8PR08MB10099AF828BCAA07C846ED62E9BE82@AS8PR08MB10099.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <87y0g0h3d6.fsf@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 9110 bytes --]

Hi,

>
>Instead of adding this gdbarch hook, have you considered using enum
>target types¹ in the feature XML instead? E.g:
>
><feature name="org.gnu.gdb.aarch64.poe">
>  <enum id="perms_enum" size="4">
>    <evalue name="---" value="0"/>
>    <evalue name="r--" value="1"/>
>    <evalue name="r-x" value="2"/>
>    <evalue name="r-x" value="3"/>
>    <evalue name="-w-" value="4"/>
>    <evalue name="rw-" value="5"/>
>    <evalue name="-wx" value="6"/>
>    <evalue name="rwx" value="7"/>
>    <!-- Maybe add the other 8 values as "???"? -->
>  </enum>
>  <flags id="por_flags" size="8">
>    <field name="P0" start="0" end="3" type="perms_enum"/>
>    <field name="P1" start="4" end="7" type="perms_enum"/>
>    <field name="P2" start="8" end="11" type="perms_enum"/>
>    <field name="P3" start="12" end="15" type="perms_enum"/>
>    <!-- And so on until P15. -->
>  </flags>
>
>  <reg name="por_el0" bitsize="64" type="por_flags" group="system"/>
></feature>
>
>Note that I haven't tested the above and I'm not sure it would actually
>work (or work well).
>
>I see two advantages:
>
>- It works in the "print $por_el0" case too, not only "info register
>  $por_el0". Or does this patch also work with "print $por_el0" as well?
>
>- It's less code.
>

Thanks Thiago for the review. I'll address the other review comments and
post a new version of the patches.

The approach you suggested above is actually what I used in v1
(https://sourceware.org/pipermail/gdb-patches/2026-June/228082.html).
With that approach, I was able to display the custom string for
info registers, info all-registers, and print $por_el0.

However, the problem I faced was when the register type was por_flags.
In that case, "set $por_el0 = <value>" failed with an "Invalid case" error.
Because of this, I had to drop support for writing to por_el0 in the initial
version of the patch.

When I tried to resolve this, the only approach I found was to use
type="uint64_t" so that set works and I have implement the custom string
handling specifically for info register $por_el0. The downside is that this does
not affect print $por_el0.

If you have any suggestions for avoiding the "Invalid case" issue with
set $por_el0 = <value>, I'd be happy to switch back to the original XML
approach from v1.

Regards
Srinath.

________________________________
From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Sent: 27 June 2026 08:03
To: Srinath Parvathaneni <Srinath.Parvathaneni@arm.com>
Cc: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; luis.machado.foss@gmail.com <luis.machado.foss@gmail.com>; guinevere@redhat.com <guinevere@redhat.com>; Ezra Sitorus <Ezra.Sitorus@arm.com>; Matthieu Longo <Matthieu.Longo@arm.com>
Subject: Re: [PATCH v2 2/7] gdb/aarch64: Add custom printing for POR_EL0

<srinath.parvathaneni@arm.com> writes:

> From: Srinath Parvathaneni <srinath.parvathaneni@arm.com>
>
> Add custom printing support for the POR_EL0 register when displayed
> using `info registers` or `info all-registers`.
>
> The register value is decoded into a human-readable "rwx"
> representation for each nibble in the POR_EL0 register, making the
> POE permissions easier to interpret.
>
> Example:
> (gdb) set $por_el0=0xffffffff77777777
> (gdb) info register por_el0
> por_el0        0xffffffff77777777  [P15=??? P14=??? P13=??? P12=??? P11=??? P10=??? P9=??? P8=??? P7=rwx P6=rwx P5=rwx P4=rwx P3=rwx P2=rwx P1=rwx P0=rwx ]

Nice.

> ---
>  gdb/aarch64-tdep.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 86 insertions(+)
>
> diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c
> index f1e1a9c7a19..3ef4e696c7c 100644
> --- a/gdb/aarch64-tdep.c
> +++ b/gdb/aarch64-tdep.c
> @@ -3135,6 +3135,86 @@ aarch64_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
>                  p_regnum);
>  }
>
> +/* 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)
> +{
> +  switch (perm)
> +   {
> +     case 0: return "---";
> +     case 1: return "r--";
> +     case 2: return "--x";
> +     case 3: return "r-x";
> +     case 4: return "-w-";
> +     case 5: return "rw-";
> +     case 6: return "-wx";
> +     case 7: return "rwx";
> +     default: return "???";
> +   }
> +}
> +
> +/* Display POE reigster POR_EL0 in the following format for the 'info registers'

Typo: reigster

> +   and 'info all-registers' commands:
> +   <register-name> <hex-value> [<decoded per-protection-key permissions>]  */
> +
> +static void
> +aarch64_print_poe_register_info (struct ui_file *file,
> +                              int regnum,
> +                              const char *name,
> +                              const frame_info_ptr &frame)
> +{
> +  value *val = value_of_register (regnum, get_next_frame_sentinel_okay (frame));
> +  ULONGEST por_el0 = (ULONGEST) value_as_long (val);
> +  gdb_printf (file, "%-14s 0x%s  [", name, phex_nz (por_el0, 8));
> +
> +  for (int i = 15; i >= 0; --i)
> +    {
> +      unsigned int perm = (por_el0 >> (i * 4)) & 0xf;
> +      gdb_printf (file, "P%d=%s ", i, aarch64_perm_overlay_decode (perm));
> +    }
> +
> +  gdb_puts ("]\n", file);
> +}
> +
> +/* For 'info registers' and 'info all-registers', print POR_EL0 using the
> +   custom POE register printer and all other registers using the default
> +   register printer.  */
> +
> +static void
> +aarch64_print_registers_info (struct gdbarch *gdbarch,
> +                           struct ui_file *file,
> +                           const frame_info_ptr &frame,
> +                           int regnum,
> +                           bool print_all)
> +{
> +  const int numregs = gdbarch_num_cooked_regs (gdbarch);
> +  aarch64_gdbarch_tdep *tdep = gdbarch_tdep<aarch64_gdbarch_tdep> (gdbarch);
> +
> +  if (regnum == -1)
> +    {
> +      for (int i = 0; i < numregs; i++)
> +     {
> +       if (i == tdep->poe_regnum)
> +         {
> +           aarch64_print_poe_register_info (file, i, "por_el0", frame);
> +           continue;
> +         }
> +       default_print_registers_info (gdbarch, file, frame,  i, print_all);
> +     }
> +    }
> +  else if (regnum == tdep->poe_regnum)
> +    aarch64_print_poe_register_info (file, regnum, "por_el0", frame);
> +  else
> +    default_print_registers_info (gdbarch, file, frame, regnum, print_all);
> +}
> +
>  /* Implement the "pseudo_register_reggroup_p" tdesc_arch_data method.  */
>
>  static bool

Instead of adding this gdbarch hook, have you considered using enum
target types¹ in the feature XML instead? E.g:

<feature name="org.gnu.gdb.aarch64.poe">
  <enum id="perms_enum" size="4">
    <evalue name="---" value="0"/>
    <evalue name="r--" value="1"/>
    <evalue name="r-x" value="2"/>
    <evalue name="r-x" value="3"/>
    <evalue name="-w-" value="4"/>
    <evalue name="rw-" value="5"/>
    <evalue name="-wx" value="6"/>
    <evalue name="rwx" value="7"/>
    <!-- Maybe add the other 8 values as "???"? -->
  </enum>
  <flags id="por_flags" size="8">
    <field name="P0" start="0" end="3" type="perms_enum"/>
    <field name="P1" start="4" end="7" type="perms_enum"/>
    <field name="P2" start="8" end="11" type="perms_enum"/>
    <field name="P3" start="12" end="15" type="perms_enum"/>
    <!-- And so on until P15. -->
  </flags>

  <reg name="por_el0" bitsize="64" type="por_flags" group="system"/>
</feature>

Note that I haven't tested the above and I'm not sure it would actually
work (or work well).

I see two advantages:

- It works in the "print $por_el0" case too, not only "info register
  $por_el0". Or does this patch also work with "print $por_el0" as well?

- It's less code.

> @@ -4141,6 +4221,10 @@ aarch64_features_from_target_desc (const struct target_desc *tdesc)
>    features.fpmr = (tdesc_find_feature (tdesc, "org.gnu.gdb.aarch64.fpmr")
>                   != nullptr);
>
> +  /* Check for POE feature.  */
> +  features.poe = (tdesc_find_feature (tdesc, "org.gnu.gdb.aarch64.poe")
> +               != nullptr);
> +
>    return features;
>  }
>
> @@ -4774,6 +4858,7 @@ aarch64_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
>    tdep->gcs_reg_base = first_gcs_regnum;
>    tdep->gcs_linux_reg_base = first_gcs_linux_regnum;
>    tdep->fpmr_regnum = fpmr_regnum;
> +  tdep->poe_regnum = poe_regnum;
>
>    /* Set the SME register set details.  The pseudo-registers will be adjusted
>       later.  */

This change and the one above it in aarch64_features_from_target_desc
should be in the previous patch instead.

--
Thiago
(he/him)

¹ https://sourceware.org/gdb/current/onlinedocs/gdb.html/Enum-Target-Types.html#Enum-Target-Types

[-- Attachment #2: Type: text/html, Size: 26740 bytes --]

  reply	other threads:[~2026-06-29  7:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26 18:08 [PATCH v2 0/7] gdb/aarch64: Add support for FEAT_S1POE feature srinath.parvathaneni
2026-06-26 18:08 ` [PATCH v2 1/7] gdb/aarch64: Add POR_EL0 register support for FEAT_S1POE srinath.parvathaneni
2026-06-27  6:06   ` Thiago Jung Bauermann
2026-06-29 10:44     ` Srinath Parvathaneni
2026-07-01  5:16       ` Thiago Jung Bauermann
2026-07-01 14:45         ` Marc Zyngier
2026-06-26 18:08 ` [PATCH v2 2/7] gdb/aarch64: Add custom printing for POR_EL0 srinath.parvathaneni
2026-06-27  7:03   ` Thiago Jung Bauermann
2026-06-29  7:02     ` Srinath Parvathaneni [this message]
2026-06-29 15:58       ` Ezra Sitorus
2026-06-26 18:08 ` [PATCH v2 3/7] gdb: Improve SIGSEGV diagnostics for POE faults srinath.parvathaneni
2026-06-29  2:42   ` Thiago Jung Bauermann
2026-06-26 18:08 ` [PATCH v2 4/7] gdbserver/aarch64: Add POR_EL0 register support srinath.parvathaneni
2026-06-29  2:43   ` Thiago Jung Bauermann
2026-06-26 18:08 ` [PATCH v2 5/7] bfd/readelf: Add core file support for FEAT_S1POE srinath.parvathaneni
2026-06-29  2:43   ` Thiago Jung Bauermann
2026-06-26 18:08 ` [PATCH v2 6/7] gdb/aarch64: " srinath.parvathaneni
2026-06-29  2:44   ` Thiago Jung Bauermann
2026-06-26 18:08 ` [PATCH v2 7/7] gdb/testsuite: Add FEAT_S1POE testcases srinath.parvathaneni
2026-07-01  5:12   ` Thiago Jung Bauermann
2026-06-29 12:18 ` [PATCH v2 0/7] gdb/aarch64: Add support for FEAT_S1POE feature Guinevere Larsen

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=AS8PR08MB10099AF828BCAA07C846ED62E9BE82@AS8PR08MB10099.eurprd08.prod.outlook.com \
    --to=srinath.parvathaneni@arm.com \
    --cc=Ezra.Sitorus@arm.com \
    --cc=Matthieu.Longo@arm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=guinevere@redhat.com \
    --cc=luis.machado.foss@gmail.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