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