Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Matthieu Longo via Gdb <gdb@sourceware.org>
To: gdb@sourceware.org
Subject: Adding architecture-specific commands in GDB
Date: Mon, 22 Jun 2026 17:26:02 +0100	[thread overview]
Message-ID: <077b9f00-ec84-440f-a84a-d804815aa77e@arm.com> (raw)

Hi all,

Today, GDB seems to support architecture-specific commands for show/set [1]. However, it is not
clear to me whether any commands beyond the scope of show/set can/should be easily added.

My usecase consists in adding AArch64-specific commands to dump some tables and permissions set up
by the Linux kernel.

# Constraints:
1. The tables are AArch64 specific and don't fit into an existing command.
2. The permissions/capability views require to fetch information in different tables and procfs
files to be computed, so the computation of such permissions/capabilities is very tied to the
architecture specificities.

Since I don't see how I could add those features to existing commands, I was thinking about adding
them under an "aarch64" namespace, and following the semantic of existing generic commands as much
as possible.

# Examples

## Dumping the tables

  show aarch64 <feature>-tables [TABLE_NAME]*

NB: those tables should only be set by the kernel, only read access is required. The content is tied
to the architecture.

## Dumping permissions

  aarch64 info <feature> <permissions-type> [some other options and args]

## Dumping capabilities for a code or data

  aarch64 info <feature> caps [some other options and args]

Please note that in the previous examples, <feature> is a subcommand of info, and <permissions-type>
or caps are subcommands of <feature>.
Note: "info aarch64 <subcommand> <subsubcommand>" might make more sense than "aarch64 info
<subcommand> <subsubcommand>" given the existing show/set commands.

Please let me know if adding such architecture-specific commands is possible today, or if it
requires changing the current commands framework.

Those new commands would really be needed for debugging the new AArch64 feature and are not optional.
Is such an architecture-specific support undesirable ?
Should such commands be moved to Python extensions even if they are essential ?

[1]: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Embedded-Processors.html#Embedded-Processors

Regards,
Matthieu

             reply	other threads:[~2026-06-22 16:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-22 16:26 Matthieu Longo via Gdb [this message]
2026-06-24 16:13 ` Andrew Burgess via Gdb
2026-06-26  8:52   ` Matthieu Longo via Gdb

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=077b9f00-ec84-440f-a84a-d804815aa77e@arm.com \
    --to=gdb@sourceware.org \
    --cc=matthieu.longo@arm.com \
    /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