This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Register group proposal
- To: Nick Duffek <nsd at redhat dot com>
- Subject: Re: Register group proposal
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 21 Feb 2001 14:41:18 -0500
- Cc: insight at sources dot redhat dot com, gdb at sources dot redhat dot com, fnasser at redhat dot com
- References: <200102210504.f1L54xJ01509@rtl.cygnus.com>
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