This is the mail archive of the gdb@sources.redhat.com 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:
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.

The daemon would already have to be updated to understand any new
protocol extensions, so we're talking about modifying that agent in any
case.  Given that, can you explain what advantage we would gain by
having GDB pass configuration information to the daemon, instead of
having the daemon parse some text file at startup and then communicate
the configuration information to GDB?

I was thinking about an architecture with multiple configurations (registers), such as Arc, Tensilica, ARM coprocessors (?), etc.


Having a single daemon supporting these multiple (arbitrary) configurations would probably be easier for JTAG probe vendors. Since GDB certainly needs to know about the particular configuration, the daemon wouldn't need to be modified for each configuration.

I don't want to support both directions just for kicks, but there may
be value here that I haven't thought of yet.  That's why I asked
Tensilica for feedback.

I understand. I was just wondering if this would be useful and actully agree that your proposal makes much more sense and that the target should know about the configuration.


In our case, the daemon currently doesn't know about a particular configuration, and GDB only queries for registers the processor (better) has. For example, to read 'special register' <SR>, OCD simply issues a rsr a2,<SR> and doesn't know if this <SR> really exists.

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.
That would work fine as long as you mapped them to sequential register
numbers internal to GDB.

Sorry, but what do you mean by 'protocol number'? Is that 'pnum' in remote.c?
A number specific to whatever protocol is being used.  For the remote
protocol that's the index into the g/G packet and the index used with
p/P packets.  So, yes.

Note, however, that in our case, pnum is not the index into the g/G packet, and hopefully doesn't need to be?


In cases where pnum is not sequential, you would also need a 'reverse' lookup function to get the register from pnum, something like this:

static struct packet_reg *
packet_reg_from_pnum (struct remote_state *rs, LONGEST pnum)
{
  int i;
  for (i = 0; i < NUM_REGS + NUM_PSEUDO_REGS; i++)
    {
      struct packet_reg *r = &rs->regs[i];
      if (r->pnum == pnum)
        return r;
    }
  return NULL;
}

Again, this function would only be called if gdbarch provided a pnum<->regnum mapping function.

~Chris


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