This is the mail archive of the
mailing list for the GDB project.
Re: RFC: Available registers as a target property
- From: Chris Zankel <zankel at tensilica dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Mon, 09 May 2005 14:33:02 -0700
- Subject: Re: RFC: Available registers as a target property
- References: <20050506162029.GA30792@nevyn.them.org>
Daniel Jacobowitz wrote:
Here's my current idea for an improved interface.
GDB then reads the TARGET_OBJECT_AVAILABLE_REGISTERS object from the target,
parses it, and hands it to the gdbarch for final processing. This means
that the object must have a target-independent format, although it will
have target-dependent content also.
I am wondering if it would also make sense to support the other way
around and let GDB tell the target about the processor/register
configuration. A scenario for this would be where GDB talks to an OCD
daemon (=target) that controls the processor via JTAG. The daemon
wouldn't need to know everything about the processor configuration.
First of all, the target object. It can describe either individual
registers or register sets known to the target (for brevity). Each
component is an ASCII string. Colon is used as a field delimiter and
semicolon as a component delimiter. A register set would look like:
Sorry, but what do you mean by 'protocol number'? Is that 'pnum' in
The reason why I ask this is because although the current remote.c file
supports pnums, they are currently mapped 1:1 to regnum. It would be
great if you could allow a gdbarch to modify the that mapping.
I guess this is what you mean by the following:
> The architecture would have to register the remote protocol <-> gdb
> regcache number mapping.
Do you intend to introduce a gdbarch function (for example,
gdbarch_pnum_to_regnum_p) and use it to define the pnum value in
remote.c (and other files)?
For example, in remote.c you could use something like this:
for (regnum = 0; regnum < NUM_REGS + NUM_PSEUDO_REGS; regnum++)
struct packet_reg *r = &rs->regs[regnum];
r->pnum = gdbarch_pnum_to_regnum(regnum);
r->pnum = regnum;
In our case (Tensilica-Xtensa), we have a non-sequential register
encoding and use the pnum <-> regnum mapping. For example, all address
registers might have a pnum 0x10XX, special register 0x11XX, etc.
For instance, if MIPS used this feature to expect 32-bit
vs 64-bit GPRs, it would be desirable to continue using a g/G packet for
I think that would be a nice feature. However, it probably requires
quite a few changes to the register cache, does it not?