Re: RFC: Available registers as a target property

[Chris Zankel <zankel@tensilica.com>]

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