From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: insight@sources.redhat.com, gdb@sources.redhat.com, fnasser@redhat.com
Subject: Re: Register group proposal
Date: Wed, 21 Feb 2001 11:43:00 -0000
Message-id: <3A9419DE.9B502F9D@cygnus.com>
References: <200102210504.f1L54xJ01509@rtl.cygnus.com>
X-SW-Source: 2001-02/msg00279.html

Nick Duffek wrote:
> 
> On an architecture with a large register set, GDBtk's register window can
> be difficult to read and slow to update.  Users can customize the window
> to hide individual registers, but that's a tedious procedure.

Much thanks for posting this.  It is at a level that makes discussion
easy.

> Therefore, users would benefit from being able to switch easily between
> register subsets.
[...]
> Whoever ports GDB to a particular architecture is likely to have a good
> idea of what register groupings would be useful.

I definitly agree with the idea.  I've several generic and some specific
thoughts.

--

Per other e-mail.  I think this interface is bound to the ``frame''.  It
is the frame, and not regcache, that determines the current
architecture.  With that in mind, I suspect that the implementation
would end up looking like:

	frame.h:

	some table *****gimi_register_groups_for_frame (struct frame_info *);

where you might have:

	frame.c:

	some table *****
	gimi_register_groups_for_frame (struct_frame_info *frame)
	{
	   return gimi_gdbarch_register_groups_for_frame (frame->arch, frame?,
...???);
	}

Given that at present a frame doesn't have an architecture (instead
there is a hardwired default) an intermediate version could just use the
default - ``current_gdbarch''.

The main thing is that core-gdb wouldn't try to access gdbarch directly
when obtaining this information.

--





> I propose the following gdbarch.sh macros with which architectures can
> define register groupings:
> 
>   /* Return a null-terminated list of register group names.  */
>   char **REGISTER_GROUPS (void)
> 
>   /* Return the REGISTER_GROUPS index of the group that "info registers"
>      should display.  */
>   int REGISTERS_SOME (void)
> 
>   /* Return the REGISTER_GROUPS index of the group that "info
>      all-registers" should display.  */
>   int REGISTERS_ALL (void)
> 
> The register cache would define these gdbarch.sh macros:
> 
>   /* Return the number of the first register to display in GROUP, which is
>      an index in REGISTER_GROUPS.  */
>   int REGISTER_INFO_FIRST (int group)
> 
>   /* Return the number of the register to display after register REGNUM
>      in GROUP, which is an index in REGISTER_GROUPS.  If no registers
>      should be displayed after register REGNUM, return -1.  */
>   int REGISTER_INFO_NEXT (int group, int regnum)
> 
> GDBtk could use REGISTER_GROUPS to generate a menu of register windows.
> Users could still customize window contents, but the predefined sets
> might make customization unnecessary for most users.
> 
> The CLI "info registers" command already accepts a register name as an
> optional paramter.  It could be extended to try that parameter as a group
> name first and a register name second, so e.g. "info registers float"
> would display all floating-point registers.
> 
> What do you think?
> 
> Nick