RFC: Available registers as a target property

[Chris Zankel]

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