Register group proposal

[Andrew Cagney]

Andrew Cagney wrote:
> 
> 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.
> >
> > Therefore, users would benefit from being able to switch easily between
> > register subsets.
> >
> > The CLI already provides two register subsets:
> >   1. non-floating-point registers, displayed by "info registers";
> >   2. all registers, displayed by "info all-registers".
> >
> > This grouping is not as useful as it could be, for various reasons:
> 
> Nick,

Hmm, to expand a little:

> > Actually, try this:
> >
> >             context
> >              /    \  .----.
> >             /      \ |    |
> >            /      frame---'
> >           /       /   \
> >    continuation  /     \
> >         |       /       \
> >         |      /         \
> >         |   memcache   regcache
> >         |      |           |
> > ..........................................
> >         |      |           |
> >    targ-run  targ-mem  targ-regs

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 date *****gimi_register_groups_for_frame (struct frame_info *);

where you might have:

	frame.c:

	some data *****
	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 points are that:

	o	core-gdb doesn't try to access
		gdbarch directly - instead it
		asks the frame what it thinks.

	o	the information isn't in someway
		bound to the raw byte register
		cache.

	Andrew