Re: Adding architecture-specific commands in GDB

Matthieu Longo via Gdb <[email protected]> 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