This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: RFC: Available registers as a target property
- From: Paul Brook <paul at codesourcery dot com>
- To: gdb at sourceware dot org
- Cc: Daniel Jacobowitz <drow at false dot org>
- Date: Mon, 9 May 2005 16:57:46 +0100
- Subject: Re: RFC: Available registers as a target property
- References: <20050506162029.GA30792@nevyn.them.org>
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