Re: RFC: Available registers as a target property

Daniel Jacobowitz
2005-05-09T16:32:27Z

On Mon, May 09, 2005 at 04:57:46PM +0100, Paul Brook wrote:
> On Friday 06 May 2005 17:20, Daniel Jacobowitz wrote:
> > set:<NAME>:<PROTOCOL NUMBER>
> >...
> > reg:<NAME>:<PROTOCOL NUMBER>:<BITSIZE>:<TYPE>:<TARGET DATA>...
>
> Would it make sense to allow these two overlap? ie. if gdb can understand the
> set it will use that and ignore the associated reg entries. If it doesn't
> understand the set it will use the individual set entries.
>
> Assume I have an coprocessor not currently supported by gdb (Arm maverick for
> the sake of argument), and a target that exposes maverick registers via reg:.
>
> At some time in the future gdb implements proper maverick support, and adds
> set:maverick. Under your proposal I can't use my old gdb with my new target.
> My new target doesn't generate reg: entries for maverick regs, and my old gdb
> doesn't understand set:maverick.
>
> Obviously this is is purely a backwards compatibility QoI issue, and doesn't
> matter if you expect everyone to use latest gdb.
>
> I'd suggest:
> reg:<NAME>:<SET NAME>:<PROTOCOL NUMBER>:<BITSIZE>:<TYPE>:<TARGET DATA>...
>
> Where <SET NAME> can be empty if the register doesn't belong to a known set.
> In fact I guess including the set name in the reg: component makes the set:
> component redundant.

I've envisioned a different solution to this problem. The set
information does not need to come from the target; GDB can recognize it
via pattern information. "If we have eight registers named this of
these types, and eight registers named that of those types, then that's
this coprocessor".

I do see that there's some fudge factor here because register names and
types aren't a very good key. How about the tags field that I
mentioned in my last mail to Mark, which is basically the same as set?

If you report a set, you are relying upon GDB to recognize it or choose
to ignore the associated registers.

--
Daniel Jacobowitz
CodeSourcery, LLC