Re: RFC: Available registers as a target property

[Chris Zankel <zankel@tensilica.com>]

Daniel,

(Sorry for the delay, but I had some mailer problems....)

Daniel Jacobowitz wrote:
> GDB _wouldn't_ need to
> know about the particular configuration.  All the configuration
> information GDB needed, it could retrieve from the daemon.

Hmmm... I have to think about it. It sounds like it could work. But that 
would be too easy, wouldn't it ;-)

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

Agreed.

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

This actually goes back to your comment above - I think. How do you 
tread 'pseudo' registers? Would it make sense to add 'flags' to the 
'set' command?

set:<NAME>:<PROTOCOL NUMBER>[:<FLAGS>]

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

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

At this point, we don't. However, with the changes you are planing to 
implement (thanks, btw.), we could probably use g/G again.

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

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

Oops... I wasn't sure if I was looking at our code or the original GDB 
sources. It looks like GDB has support for non-sequential pnums, but 
doesn't allow to assign them from gdbarch.

~Chris