Re: Register Groups (again)

[Daniel Jacobowitz <drow at mvista dot com>]

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