Re: RFC: Available registers as a target property

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, May 09, 2005 at 05:23:38PM -0700, Chris Zankel wrote:
> 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'm afraid that doesn't answer my question :-)  First of all, the
daemon would not necessarily have to be modified for each
configuration; it would need a different configuration file, which is
not the same thing.  Secondly, in this case, GDB _wouldn't_ need to
know about the particular configuration.  All the configuration
information GDB needed, it could retrieve from the daemon.

Sometimes, GDB needs configuration information and the target can
supply it. Sometimes (apparently) the target needs information about
its own configuration and GDB can supply it.

I think we'll always be doing one or the other; one endpoint needs to
have enough information for both rather than GDB needing to negotiate
with the target.  That suggests that the two configuration steps should
be implemented independently.

> >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.

The options are to tell GDB about this directly, or to have the OCD
tell GDB about the real properties of the target.  I obviously prefer
the latter when possible, because it allows GDB to gracefully handle
binaries built for one configuration, and run on another configuration
where they still work (but may be somehow affected by state they can
not see).

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

Do you use a 'g' packet at all?  Certainly you're free not to.  If you
do, then I'm not sure what it means with non-sequential pnums.

> 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.

You mean, like the function of that same name and implementation
already in remote.c?  Otherwise I'm not sure what you're talking about.

-- 
Daniel Jacobowitz
CodeSourcery, LLC