This is the mail archive of the
mailing list for the GDB project.
Re: RFC: Available registers as a target property
- From: Ramana Radhakrishnan <ramana dot radhakrishnan at codito dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb at sourceware dot org
- Date: Tue, 10 May 2005 06:23:43 +0530
- Subject: Re: RFC: Available registers as a target property
- References: <20050506162029.GA30792@nevyn.them.org>
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.
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:
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. )
codito ergo sum (www.codito.com)