Re: RFC: Available registers as a target property

[Ramana Radhakrishnan <ramana.radhakrishnan@codito.com>]

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.

<snip>

> DETAILS
> =======
> 
> 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>
> 
> No more information is necessary; the register set is an abbreviation of a
> well-defined group of registers that both the stub and GDB have external
> knowledge of.  GDB will already know the order, types, and sizes of
> registers, and potentially other details (such as how to pass them as
> arguments to functions).  If GDB does not recognize the register set, it can
> safely ignore it, but should issue a warning to the user recommending use of
> a later GDB.  If the protocol does not require numbers, they will be
> ignored, but they are non-optional in the syntax.
> 
> I have spent less time thinking about how to specify individual registers.
> This should suffice, but if anyone can see cause for another standard field,
> please speak up.
> 
> 	reg:<NAME>:<PROTOCOL NUMBER>:<BITSIZE>:<TYPE>:<TARGET DATA>...
> 
> Types unknown to GDB would default to integral display; common types such as
> integral, floating point (native byte order), integral vector, fp vector, et
> cetera would be documented in the manual with fixed names.

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

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


cheers
Ramana
-- 
Ramana Radhakrishnan
GNU Tools
codito ergo sum (www.codito.com)