Hi,
>
>Instead of adding this gdbarch hook, have you considered using enum
>target types¹ in the feature XML instead? E.g:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>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 = " 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 = , I'd be happy to switch back to the original XML
approach from v1.
Regards
Srinath.
________________________________
From: Thiago Jung Bauermann
Sent: 27 June 2026 08:03
To: Srinath Parvathaneni
Cc: gdb-patches@sourceware.org ; luis.machado.foss@gmail.com ; guinevere@redhat.com ; Ezra Sitorus ; Matthieu Longo
Subject: Re: [PATCH v2 2/7] gdb/aarch64: Add custom printing for POR_EL0
writes:
> From: Srinath Parvathaneni
>
> 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 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:
> + [] */
> +
> +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 (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:
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