[RFC] "info registers" and register group information

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[RFC] "info registers" and register group information

Luis Machado-2
Hi,

You may have seen some discussion about the following change:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=aa66aac47b4dd38f9524ddb5546c08cc09930d37

It changes the code so it honors what is documented here:
https://sourceware.org/gdb/current/onlinedocs/gdb/Target-Description-Format.html#Target-Description-Format

In particular, "If no group is specified, GDB will not display the
register in info registers."

It's been pretty common for targets to define register sets without an
explicit group. That, in some cases, doesn't stop GDB from displaying
such registers in "info registers".

The current heuristic for registers without an explicit group is to find
out their type and print them if they look non-vector and non-float.
Such is the case, for example, with aarch64 general purpose registers.

So the current behavior does not match the documentation and should, in
theory, be fixed. On the other hand, we have plenty of target
description producers out there that will be generating register
descriptions without a group in the future.

In my mind, those producers should still be supported. GDB shouldn't
just print nothing for "info registers" all of a sudden. That is a
considerable regression for the user, since "info registers" is used
quite often.

So this leaves us with a couple options to get this problem sorted out
without breaking backwards compatibility.

1 - Make the documentation match the current behavior, and instruct
developers who want their registers excluded from the "info registers"
listing to put those registers under an arbitrary group.

2 - Make GDB honor the current documentation, update all target
descriptions to contain register group information (we can't update
target description producers outside GDB, like QEMU, OpenOCD and other
debugging stubs), and tweak the existing problematic targets to subvert
the documented behavior and print registers anyway (for backwards
compatibility).

I think solution 1 is cleaner. Even though it involves changing existing
documented behavior, such behavior was never really honored anyway.

Thoughts?