Re: RFC: Available registers as a target property

Chris Zankel
2005-05-09T21:33:12Z

Daniel Jacobowitz wrote:
> Here's my current idea for an improved interface.

Great!

> 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:
>
> set:<NAME>:<PROTOCOL NUMBER>

Sorry, but what do you mean by 'protocol number'? Is that 'pnum' in
remote.c?

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];
if (gdbarch_pnum_to_regnum_p)
r->pnum = gdbarch_pnum_to_regnum(regnum);
else
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
> those.

I think that would be a nice feature. However, it probably requires
quite a few changes to the register cache, does it not?

~Chris