Adding architecture-specific commands in GDB

Adding architecture-specific commands in GDB

[Matthieu Longo via Gdb]

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

Re: Adding architecture-specific commands in GDB

[Andrew Burgess via Gdb]

Matthieu Longo via Gdb <gdb@sourceware.org> writes:

> 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.

Maybe I'm wrong, in which case I'd love to see some counter examples,
but the set/show command are usually for settings that are set by the
user of GDB, and the show reads back the setting.

Viewing kernel data would normally be an 'info' command.

>
> ## 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.

Yes adding these commands is totally possible today.  Personally, I'd
rather see it structured as: 'info aarch64 <feature> ....' as I think
users are more likely to think 'info' to find out about the process, but
I understand you might have a strong preference for the other order.

> Those new commands would really be needed for debugging the new AArch64 feature and are not optional.
> Is such an architecture-specific support undesirable ?

No it's fine.  You'd create the commands within an AArch64 only file,
likely aarch64-tdep.c, or similar, within the per-file init function,
look for 'INIT_GDB_FILE'.  That way, the commands will only be
registered for a build of GDB that includes AArch64 support.

> Should such commands be moved to Python extensions even if they are essential ?

I don't think there's anything wrong with writing commands as a Python
extension.  The commands can be included with GDB and always loaded.  Of
course, this does mean that a build of GDB without Python support will
lack these commands, but these days it's pretty rare to find builds of
GDB without Python support.

Thanks,
Andrew

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

Re: Adding architecture-specific commands in GDB

[Matthieu Longo via Gdb]

On 24/06/2026 17:13, Andrew Burgess wrote:
> Matthieu Longo via Gdb <gdb@sourceware.org> writes:
> 
>> 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.
> 
> Maybe I'm wrong, in which case I'd love to see some counter examples,
> but the set/show command are usually for settings that are set by the
> user of GDB, and the show reads back the setting.
> 
> Viewing kernel data would normally be an 'info' command.
> 

What would the opposite of 'info' be ?
If for instance, I wanted to change a value in one of those tables ?

Matthieu

Re: Adding architecture-specific commands in GDB

[Tom Tromey]

>>>>> "Matthieu" == Matthieu Longo via Gdb <gdb@sourceware.org> writes:

>> Maybe I'm wrong, in which case I'd love to see some counter examples,
>> but the set/show command are usually for settings that are set by the
>> user of GDB, and the show reads back the setting.
>> 
>> Viewing kernel data would normally be an 'info' command.

Matthieu> What would the opposite of 'info' be ?
Matthieu> If for instance, I wanted to change a value in one of those tables ?

There isn't really one, but I guess you could introduce some new,
arch-specific prefix.

Somewhere I think there was some rationale for the show/info split,
though I no longer remember it.  I'm not sure it is totally coherent any
more.  But in most cases 'set' affects gdb, not the inferior.  (Except
'set variable'.  And other cases you may discover.)

Tom

Re: Adding architecture-specific commands in GDB

[Basile STARYNKEVITCH]

On Wed, 2026-06-24 at 17:13 +0100, Andrew Burgess via Gdb wrote:
> Matthieu Longo via Gdb <gdb@sourceware.org> writes:
> 
> > 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.

GNU GDB is both open source and extensible with Python

So the hard way is to patch the source code of GDB (mostly C)

The easy way might be (if you are less allergic to Python than I am) to
write Python extensions to GDB
https://www.pythonsheets.com/notes/appendix/python-gdb.html
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Extending-GDB.html#Extending-GDB

I (Basile S.) personally prefer GNU guile to Python and GDB can be
extended using GN§U guile
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Guile.html#Guile

Of course, both Python and GNU guile are interpreters and in some cases
(think of dozen of watchpoints) GDB becomes slow.

I even dream of future GDB accepting open source plugins (coded in C
and dlopen-ed on Linux), like the GCC compiler already does:
https://arxiv.org/abs/1109.0779
https://gcc.gnu.org/onlinedocs/gccint/Plugins.html

Sadly, I don't have the skills to implement them.

NB: my open source project (which I dream to become a GNU one) is an
inference engine for expert systems.


-- 

Basile STARYNKEVITCH                           
<basile@starynkevitch.net>
8 rue de la Faïencerie                      
http://starynkevitch.net/Basile/  
92340 Bourg-la-Reine                        
https://github.com/bstarynk
France                               
https://github.com/RefPerSys/RefPerSys
                  https://orcid.org/0000-0003-0908-5250