This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Available registers as a target property



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.


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 (

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]