This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Register group proposal

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

> 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


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:


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

where you might have:


	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 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 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]