[RFC] "info registers" and register group information

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?