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