This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Available registers as a target property

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 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);
         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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]