Re: RFC: Available registers as a target property

[Paul Brook <paul@codesourcery.com>]

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.

Paul