Register Groups (again)

Register Groups (again)

[Andrew Cagney]

See: http://sources.redhat.com/ml/gdb/2001-02/msg00268.html for the 
origins of this idea.


I'd like to propose a new object ``struct reggroup'' and a number of 
methods:


struct reggroup; // the opaque object

// Some predefined register groups
struct reggroup *general_reggroup;
struct reggroup *float_reggroup;
struct reggroup *system_reggroup;
struct reggroup *vector_reggroup;
struct reggroup *all_reggroup;

// architecture method indicating membership of a register group
int register_reggroup_p (gdbarch, regnum, reggroup);

// The reggroup's attributes
const char *reggroup_name (reggroup);

// Null terminated list of the architectures reggroups
struct reggroup **reggroups (gdbarch);

// Add a custom register group to an architecture
struct reggroup *reggroup_add (gdbarch, name, other attributes?);


A default register group function could look something like:

	if all group
	  return 1
	if float group and register's type is float
	  return 1;
	if vector group and register's type is vector
	  return 1;
	if general group and register's type isn't float or vector
	  return 1
	return 0

And the ``info registers', ``info float'', ``info all-registers'' and 
``info vector'' (``info system''?) commands would then use it.


The big gapeing holes in this proposal are:


- an MI/GUI interface.

The above interface provides:

	for (regnum = 0; regnum < NUM_REGS+NUM_PSEUDO_REGS; regnum++)
	  if (register_reggroup_p (arch, regnum, XXXX_group)
	    ....

I guess that would be abstracted somehow.  Somebody elses problem though :-)


- how it relates to frames

It currently assumes that the register groups are identical between 
frames :-/


comments, thoughts?
Andrew


PS: I guess this gets written up and goes into the ``Registers'' chapter.

Re: Register Groups (again)

[Daniel Jacobowitz]

On Sat, Aug 17, 2002 at 07:48:22PM -0400, Andrew Cagney wrote:
> See: http://sources.redhat.com/ml/gdb/2001-02/msg00268.html for the 
> origins of this idea.
> 
> 
> I'd like to propose a new object ``struct reggroup'' and a number of 
> methods:

Hmm, it seems more intuitive to me to have attributes for each
register.  Float, vector, system for the register's class or group, and
then we could have other not necessarily mutually exclusive flags. 
Like, available in kernel or user mode.

Just a thought though.
 
> - how it relates to frames
> 
> It currently assumes that the register groups are identical between 
> frames :-/

With an attribute scheme, once we know which registers are present in a
frame we'd know which (say) float registers are present in that
frame...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Register Groups (again)

[Andrew Cagney]

> On Sat, Aug 17, 2002 at 07:48:22PM -0400, Andrew Cagney wrote:
> 
>> See: http://sources.redhat.com/ml/gdb/2001-02/msg00268.html for the 
>> origins of this idea.
>> 
>> 
>> I'd like to propose a new object ``struct reggroup'' and a number of 
>> methods:
> 
> 
> Hmm, it seems more intuitive to me to have attributes for each
> register.  Float, vector, system for the register's class or group, and
> then we could have other not necessarily mutually exclusive flags. 
> Like, available in kernel or user mode.
> 
> Just a thought though.

Sorry, I think I'm missing something.  I don't see a difference. 
s/reggroup/regattrib/?

>> - how it relates to frames
>> 
>> It currently assumes that the register groups are identical between 
>> frames :-/

i.e.:
	register_reggroup_p(gdbarch,regnum,group)
rather than:
	frame_register_reggroup_p(frame,regnum,group)

> With an attribute scheme, once we know which registers are present in a
> frame we'd know which (say) float registers are present in that
> frame...

Now I'm really confused.  How is this not possible using what I described?

Andrew

Re: Register Groups (again)

[Daniel Jacobowitz]

On Sun, Aug 18, 2002 at 01:45:40AM -0400, Andrew Cagney wrote:
> >On Sat, Aug 17, 2002 at 07:48:22PM -0400, Andrew Cagney wrote:
> >
> >>See: http://sources.redhat.com/ml/gdb/2001-02/msg00268.html for the 
> >>origins of this idea.
> >>
> >>
> >>I'd like to propose a new object ``struct reggroup'' and a number of 
> >>methods:
> >
> >
> >Hmm, it seems more intuitive to me to have attributes for each
> >register.  Float, vector, system for the register's class or group, and
> >then we could have other not necessarily mutually exclusive flags. 
> >Like, available in kernel or user mode.
> >
> >Just a thought though.
> 
> Sorry, I think I'm missing something.  I don't see a difference. 
> s/reggroup/regattrib/?

In your scheme, you have reggroups as a structure.  In mine, you'd have
a set of flags associated with each register.  Not a fundamental
difference, but it seems a little more straightforward.  As I said,
just a passing thought.

> 
> >>- how it relates to frames
> >>
> >>It currently assumes that the register groups are identical between 
> >>frames :-/
> 
> i.e.:
> 	register_reggroup_p(gdbarch,regnum,group)
> rather than:
> 	frame_register_reggroup_p(frame,regnum,group)
> 
> >With an attribute scheme, once we know which registers are present in a
> >frame we'd know which (say) float registers are present in that
> >frame...
> 
> Now I'm really confused.  How is this not possible using what I described?

I don't understand why this should be dependent on the frame?  If
you're talking about a hypothetical future GDB where the gdbarch varies
by frame, then we'll have to know the gdbarch anyway...

I was just suggesting that, with an attribute attached to each
register, we would know "for free" which ones were in a register group
for a given frame.  Maybe I'm wrong, since I don't understand how they
could ever vary.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Register Groups (again)

[Andrew Cagney]

http://sources.redhat.com/ml/gdb/2001-02/msg00268.html
>> Sorry, I think I'm missing something.  I don't see a difference. 
>> s/reggroup/regattrib/?
> 
> 
> In your scheme, you have reggroups as a structure.  In mine, you'd have
> a set of flags associated with each register.  Not a fundamental
> difference, but it seems a little more straightforward.  As I said,
> just a passing thought.

(NickD's original proposal had reggroups implemented as integers.)

Ah, yes, I even considered proposing flags.  Looking through the 
responses for NickD's proposoal (before it went off on a tangent :-( ) I 
think it is evident that people liked the ability to define their own 
groups over and above the predefined ones.

Since I had flags in mind, my query interface looks like:

	register_reggroup_p (gdbarch, regnum, group)
vs
	register_reggroups (gdbarch, regnum) & group)

where as NickD's proposal used iterators.  I figure that if the overhead 
of iterating through NUM_REGS+NUM_PSEUDO_REGS becomes measurable then 
someone will comeup with a new interface.

>> >>- how it relates to frames
>> >>
>> >>It currently assumes that the register groups are identical between 
>> >>frames :-/
> 
>> 
>> i.e.:
>> 	register_reggroup_p(gdbarch,regnum,group)
>> rather than:
>> 	frame_register_reggroup_p(frame,regnum,group)
>> 
> 
>> >With an attribute scheme, once we know which registers are present in a
>> >frame we'd know which (say) float registers are present in that
>> >frame...
> 
>> 
>> Now I'm really confused.  How is this not possible using what I described?
> 
> 
> I don't understand why this should be dependent on the frame?  If
> you're talking about a hypothetical future GDB where the gdbarch varies
> by frame, then we'll have to know the gdbarch anyway...

(A frame ``has a'' architecture.)

Consider trying to unwind an IA-64 kernel stack back through to an IA-32 
user land.

At present things like Arm, MIPS and SH (pretty extreem) handle this 
using a single architecture object.  At some point, it is going to 
become easier to have a per-frame architecture and allow them to vary.

I'm trying to avoid doing anything that precludes that possibility (with 
out making a developers life unreasonable :-)

> I was just suggesting that, with an attribute attached to each
> register, we would know "for free" which ones were in a register group
> for a given frame.

That is already the case in the above.

Well strictly speaking the above defines a large sparse 2d array (regnum 
X reggroup) and the presence of an element can be interpreted as having 
an attribute, or ....

> Maybe I'm wrong, since I don't understand how they
> could ever vary.

At present they can't.

thanks!
Andrew

Re: Register Groups (again)

[Daniel Jacobowitz]

On Sun, Aug 18, 2002 at 11:34:50AM -0400, Andrew Cagney wrote:
> http://sources.redhat.com/ml/gdb/2001-02/msg00268.html
> >>Sorry, I think I'm missing something.  I don't see a difference. 
> >>s/reggroup/regattrib/?
> >
> >
> >In your scheme, you have reggroups as a structure.  In mine, you'd have
> >a set of flags associated with each register.  Not a fundamental
> >difference, but it seems a little more straightforward.  As I said,
> >just a passing thought.
> 
> (NickD's original proposal had reggroups implemented as integers.)
> 
> Ah, yes, I even considered proposing flags.  Looking through the 
> responses for NickD's proposoal (before it went off on a tangent :-( ) I 
> think it is evident that people liked the ability to define their own 
> groups over and above the predefined ones.

On a per-target basis?  We could simply reserve flags for
"target-specific use"... I don't know which would be cleaner.  You
were probably on the right track with groups at that point.

But my primary point was non-orthogonal flags.  Particularly the
kernel-vs-usermode thing, which the SH-Linux people have done some
fairly ugly things to handle.  (Not contributed, I think)

> Since I had flags in mind, my query interface looks like:
> 
> 	register_reggroup_p (gdbarch, regnum, group)
> vs
> 	register_reggroups (gdbarch, regnum) & group)
> 
> where as NickD's proposal used iterators.  I figure that if the overhead 
> of iterating through NUM_REGS+NUM_PSEUDO_REGS becomes measurable then 
> someone will comeup with a new interface.

Sounds fine to me.

> >>>>- how it relates to frames
> >>>>
> >>>>It currently assumes that the register groups are identical between 
> >>>>frames :-/
> >
> >>
> >>i.e.:
> >>	register_reggroup_p(gdbarch,regnum,group)
> >>rather than:
> >>	frame_register_reggroup_p(frame,regnum,group)
> >>
> >
> >>>With an attribute scheme, once we know which registers are present in a
> >>>frame we'd know which (say) float registers are present in that
> >>>frame...
> >
> >>
> >>Now I'm really confused.  How is this not possible using what I described?
> >
> >
> >I don't understand why this should be dependent on the frame?  If
> >you're talking about a hypothetical future GDB where the gdbarch varies
> >by frame, then we'll have to know the gdbarch anyway...
> 
> (A frame ``has a'' architecture.)
> 
> Consider trying to unwind an IA-64 kernel stack back through to an IA-32 
> user land.
> 
> At present things like Arm, MIPS and SH (pretty extreem) handle this 
> using a single architecture object.  At some point, it is going to 
> become easier to have a per-frame architecture and allow them to vary.
> 
> I'm trying to avoid doing anything that precludes that possibility (with 
> out making a developers life unreasonable :-)

Sure, a frame has an architecture.  But I don't think this interface
should use the frame directly; I think it should use the architecture
as you originally suggested, since that is the only piece of data in
the frame it should be allowed to depend on.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Register Groups (again)

[Kevin Buettner]

On Aug 17,  7:48pm, Andrew Cagney wrote:

> - how it relates to frames
> 
> It currently assumes that the register groups are identical between 
> frames :-/

So long as we have a way to distinguish architectures between frames,
we should have a way to identify different register groups (between
frames), right?

> comments, thoughts?

Aside from not understanding the frame comment, it looks okay to
me.

Kevin

Re: Register Groups (again)

[Kevin Buettner]

On Aug 18, 12:01am, Daniel Jacobowitz wrote:

> On Sat, Aug 17, 2002 at 07:48:22PM -0400, Andrew Cagney wrote:
> > See: http://sources.redhat.com/ml/gdb/2001-02/msg00268.html for the 
> > origins of this idea.
> > 
> > I'd like to propose a new object ``struct reggroup'' and a number of 
> > methods:
> 
> Hmm, it seems more intuitive to me to have attributes for each
> register.  Float, vector, system for the register's class or group, and
> then we could have other not necessarily mutually exclusive flags. 
> Like, available in kernel or user mode.

I think the attribute idea might be useful elsewhere, but for the
purposes of being easily able to specify a register group for ``info
registers'' (and other user interface uses), I think Andrew's
proposal was fine.

Kevin

Re: Register Groups (again)

[Daniel Jacobowitz]

On Mon, Aug 19, 2002 at 11:54:12AM -0700, Kevin Buettner wrote:
> On Aug 18, 12:01am, Daniel Jacobowitz wrote:
> 
> > On Sat, Aug 17, 2002 at 07:48:22PM -0400, Andrew Cagney wrote:
> > > See: http://sources.redhat.com/ml/gdb/2001-02/msg00268.html for the 
> > > origins of this idea.
> > > 
> > > I'd like to propose a new object ``struct reggroup'' and a number of 
> > > methods:
> > 
> > Hmm, it seems more intuitive to me to have attributes for each
> > register.  Float, vector, system for the register's class or group, and
> > then we could have other not necessarily mutually exclusive flags. 
> > Like, available in kernel or user mode.
> 
> I think the attribute idea might be useful elsewhere, but for the
> purposes of being easily able to specify a register group for ``info
> registers'' (and other user interface uses), I think Andrew's
> proposal was fine.

I also agree.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Register Groups (again)

[Andrew Cagney]

>> I think the attribute idea might be useful elsewhere, but for the
>> purposes of being easily able to specify a register group for ``info
>> registers'' (and other user interface uses), I think Andrew's
>> proposal was fine.
> 
> 
> I also agree.

M'kay, better find out if it works :-)

Andrew