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