Re: RFC: Available registers as a target property

[Daniel Jacobowitz <drow@false.org>]

On Tue, May 10, 2005 at 06:23:43AM +0530, Ramana Radhakrishnan wrote:
> Hi,
> 
> <snip>
> 
> >Also, it operates at an "optional feature" level rather than an "optional
> >register" level.  The ARM RDI protocol has a nifty feature called
> >Self-Describing Modules, which allows coprocessors to describe themselves 
> >to
> >the debugger, including describing their register sets.  It includes both
> >user-level information (name and type - along with a complicated type
> >description language) and implementation information (like the ARM mode in
> >which the register is accessible, for banked registers).  I would like
> >the GDB solution to this problem to be sufficiently flexible to work with
> >SDM - both because it's a nice model and because that way we can be
> >compatible with ARM debug servers, given an adequate RDI proxy.
> 
> On the ARC there are extension encoding sections (Look at 
> .arcextmaps created in binutils for extension directives. ) 
> which describe such registers by the binary. Its possible to 
> rename registers with other names and to specify other such 
> names for auxiliary registers. Using such a mechanism would 
> definitely be useful  . Again its possible that the same 
> registers appear with different data formats in different 
> configurations of the core.

It sounds like, if the target does not support reporting its formats,
we could query the binary for them.  In fact, this fits onto the
existing target stack.  The BFD target would use a gdbarch method to
query the binary for this information.  If the remote target supported
the query, we would ignore the binary's data; otherwise, we would use
it.

What other kinds of information may be in this section?  Does this
interface offer enough room to make use of them?

> Can one add a gdbarch_defined_type where the arch interprets 
> the raw bit stream to provide the user with a decent view of 
> the registers . It so happens that there are many status 
> registers which are essentially bitfields , so having this 
> as a hook for gdbarch to use for printing register values 
> might be useful. An example where this could be used would 
> be printing the status flags for e.g. on the i386. (One 
> could print the ZNCV values automatically. )

Someone posted a patch to do this for i386 years ago.  It got held up,
I don't remember why.

> Also a way of describing reggroups in this protocol would be 
> very useful and conditions underwhich these are allowed to 
> exist would be something interesting. (would typically be 
> the presence of a sequence of bits in some bcr obtainable by 
> basic bitwise arithmetic on some BCR values. )

I'm afraid you've lost me.  Could you try explaining that whole
paragraph again?  Oh... I think I see... I'm assuming BCR is something
like "board configuration register".  I'm further assuming that this is
going to be a hardwired register, not runtime configurable.  Is that
right?

Others have already persuaded me that we need some way to describe
groupings of registers.  But I don't think that this logic you're
describing is appropriate to live in GDB.  If some registers are only
available in some board configurations, the target stub should read the
BCR, work out which are available in _this_ configuration, and report
those.

-- 
Daniel Jacobowitz
CodeSourcery, LLC