Re: RFC: Available registers as a target property

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, May 09, 2005 at 02:33:02PM -0700, Chris Zankel wrote:
> >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.

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 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 expect that support for feeding GDB from
information provided by a remote stub is actually orthogonal to telling
a remote stub about our 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:
> >
> >	set:<NAME>:<PROTOCOL NUMBER>
> 
> 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.

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

Yes, this is already implemented on the branch I referenced in my
original mail.  It was fairly straightforward.  I'm not sure how
exhaustive it was, since I didn't try renumbering any of the g-packet
registers, but in principle that's no harder.

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

> >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
> >those.
> 
> I think that would be a nice feature. However, it probably requires 
> quite a few changes to the register cache, does it not?

Not at all.  The g packet is just the first however-many hard registers
in the remote protocol numbering (those numbers may need to be
sequential; not sure offhand).

-- 
Daniel Jacobowitz
CodeSourcery, LLC