Re: RFC: Available registers as a target property

[Daniel Jacobowitz <drow@false.org>]

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