From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>, 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: <3A9419DB.6C3DA172@cygnus.com>
References: <200102210504.f1L54xJ01509@rtl.cygnus.com> <3A93F16C.E59D82AC@cygnus.com>
X-SW-Source: 2001-02/msg00278.html

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