This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Register Groups (again)
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