blob: 6e01b703fcf69a42eb4cde811eeeab231fdb4826 [file] [log] [blame]
<!-- The root element of a GDB target description is <target>. It
contains a list of feature definitions, followed by a feature-set.
This is also the only point at which xi:include is supported;
it must be used with xpointer to fetch a feature, from a
document whose root element is either target or feature. -->
<!ELEMENT target (feature*, feature-set)>
<!ATTLIST target
xmlns:xi CDATA #FIXED "http://www.w3.org/2001/XInclude">
<!ELEMENT feature-set (description*, feature-ref+)>
<!-- QUESTION: Is there any reason for feature-ref to have its own
descriptions? Or a short name field (descriptive)? -->
<!ELEMENT feature-ref EMPTY>
<!ATTLIST feature-ref
name IDREF #REQUIRED
base-regnum CDATA #IMPLIED>
<!-- TODO: Handle arch_data, maybe as unvalidated fields; do we want
to define a namespace for arch-specific fields? Issue for feature
and for reg. -->
<!-- QUESTION: Should the feature also have a short description to identify
it? The format of its "name" field is restricted and probably not
user-appropriate. -->
<!ELEMENT feature (description*, reg*)>
<!ATTLIST feature
name ID #REQUIRED>
<!-- TODO: GDB does not yet support descriptions. -->
<!-- Registers are not required to have an explicit register number field;
they are numbered sequentially starting at zero. If a register does
have an explicit number, the next register will be assigned the next
sequential number by default. When the feature is referenced, register
numbers are adjusted by the reference's base-regnum. -->
<!-- arch_data; see above -->
<!-- TODO: Allow save-restore default to be specified by the feature?
Computation coprocessors should generally be saved and restored,
but system control coprocessors generally shouldn't. -->
<!ELEMENT reg (description*)>
<!ATTLIST reg
name CDATA #REQUIRED
bitsize CDATA #REQUIRED
regnum CDATA #IMPLIED
save-restore (yes | no) 'yes'
type CDATA 'int'
group CDATA #IMPLIED
>
<!ELEMENT description (#PCDATA)>
<!ATTLIST description
xml:lang CDATA #IMPLIED>