Debugging with GDB: Target Descriptions

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

# G. Target Descriptions

One of the challenges of using GDB to debug embedded systems is that there are so many minor variants of each processor architecture in use. It is common practice for vendors to start with a standard processor core -- ARM, PowerPC, or MIPS, for example --- and then make changes to adapt it to a particular market niche. Some architectures have hundreds of variants, available from dozens of vendors. This leads to a number of problems:

- With so many different customized processors, it is difficult for the GDB maintainers to keep up with the changes.
- Since individual variants may have short lifetimes or limited audiences, it may not be worthwhile to carry information about every variant in the GDB source tree.
- When GDB does support the architecture of the embedded system at hand, the task of finding the correct architecture name to give the `set architecture` command can be error-prone.

To address these problems, the GDB remote protocol allows a target system to not only identify itself to GDB, but to actually describe its own features. This lets GDB support processor variants it has never seen before -- to the extent that the descriptions are accurate, and that GDB understands them.

GDB must be linked with the Expat library to support XML target descriptions. See Expat.

> G.1 Retrieving Descriptions |  | How descriptions are fetched from a target.
> G.2 Target Description Format |  | The contents of a target description.
> G.3 Predefined Target Types |  | Standard types available for target descriptions.
> G.4 Standard Target Features |  | Features GDB knows about.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## G.1 Retrieving Descriptions

Target descriptions can be read from the target automatically, or specified by the user manually. The default behavior is to read the description from the target. GDB retrieves it via the remote protocol using ``qXfer'` requests (see section qXfer). The annex in the ``qXfer'` packet will be ``target.xml'`. The contents of the ``target.xml'` annex are an XML document, of the form described in G.2 Target Description Format.

Alternatively, you can specify a file to read for the target description. If a file is set, the target will not be queried. The commands to specify a file are:

`set tdesc filename path`
  Read the target description from path.

`unset tdesc filename`
  Do not read the XML target description from a file. GDB will use the description supplied by the current target.

`show tdesc filename`
  Show the filename to read for a target description, if any.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## G.2 Target Description Format

A target description annex is an XML document which complies with the Document Type Definition provided in the GDB sources in ``gdb/features/gdb-target.dtd'`. This means you can use generally available tools like `xmllint` to check that your feature descriptions are well-formed and valid. However, to help people unfamiliar with XML write descriptions for their targets, we also describe the grammar here.

Target descriptions can identify the architecture of the remote target and (for some architectures) provide information about custom register sets. They can also identify the OS ABI of the remote target. GDB can use this information to autoconfigure for your target, or to warn you if you connect to an unsupported target.

Here is a simple target description:

    <target version="1.0">
      <architecture>i386:x86-64</architecture>
    </target>

This minimal description only says that the target uses the x86-64 architecture.

A target description has the following overall form, with [ ] marking optional elements and ... marking repeatable elements. The elements are explained further below.

    <?xml version="1.0"?>
    <!DOCTYPE target SYSTEM "gdb-target.dtd">
    <target version="1.0">
      [architecture]
      [osabi]
      [compatible]
      [feature...]
    </target>

The description is generally insensitive to whitespace and line breaks, under the usual common-sense rules. The XML version declaration and document type declaration can generally be omitted (GDB does not require them), but specifying them may be useful for XML validation tools. The ``version'` attribute for ``<target>'` may also be omitted, but we recommend including it; if future versions of GDB use an incompatible revision of ``gdb-target.dtd'`, they will detect and report the version mismatch.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### G.2.1 Inclusion

It can sometimes be valuable to split a target description up into several different annexes, either for organizational purposes, or to share files between different possible target descriptions. You can divide a description into multiple files by replacing any element of the target description with an inclusion directive of the form:

    <xi:include href="document"/>

When GDB encounters an element of this form, it will retrieve the named XML document, and replace the inclusion directive with the contents of that document. If the current description was read using ``qXfer'`, then so will be the included document; document will be interpreted as the name of an annex. If the current description was read from a file, GDB will look for document as a file in the same directory where it found the original description.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### G.2.2 Architecture

An ``<architecture>'` element has this form:

      <architecture>arch</architecture>

arch is one of the architectures from the set accepted by `set architecture` (see section Specifying a Debugging Target).

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### G.2.3 OS ABI

This optional field was introduced in GDB version 7.0. Previous versions of GDB ignore it.

An ``<osabi>'` element has this form:

      <osabi>abi-name</osabi>

abi-name is an OS ABI name from the same selection accepted by `set osabi` (see section Configuring the Current ABI).

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### G.2.4 Compatible Architecture

This optional field was introduced in GDB version 7.0. Previous versions of GDB ignore it.

A ``<compatible>'` element has this form:

      <compatible>arch</compatible>

arch is one of the architectures from the set accepted by `set architecture` (see section Specifying a Debugging Target).

A ``<compatible>'` element is used to specify that the target is able to run binaries in some other than the main target architecture given by the ``<architecture>'` element. For example, on the Cell Broadband Engine, the main architecture is `powerpc:common` or `powerpc:common64`, but the system is able to run binaries in the `spu` architecture as well. The way to describe this capability with ``<compatible>'` is as follows:

      <architecture>powerpc:common</architecture>
      <compatible>spu</compatible>

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### G.2.5 Features

Each ``<feature>'` describes some logical portion of the target system. Features are currently used to describe available CPU registers and the types of their contents. A ``<feature>'` element has this form:

    <feature name="name">
      [type...]
      reg...
    </feature>

Each feature's name should be unique within the description. The name of a feature does not matter unless GDB has some special knowledge of the contents of that feature; if it does, the feature should have its standard name. See section G.4 Standard Target Features.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### G.2.6 Types

Any register's value is a collection of bits which GDB must interpret. The default interpretation is a two's complement integer, but other types can be requested by name in the register description. Some predefined types are provided by GDB (see section G.3 Predefined Target Types), and the description can define additional composite types.

Each type element must have an ``id'` attribute, which gives a unique (within the containing ``<feature>'`) name to the type. Types must be defined before they are used.

Some targets offer vector registers, which can be treated as arrays of scalar elements. These types are written as ``<vector>'` elements, specifying the array element type, type, and the number of elements, count:

    <vector id="id" type="type" count="count"/>

If a register's value is usefully viewed in multiple ways, define it with a union type containing the useful representations. The ``<union>'` element contains one or more ``<field>'` elements, each of which has a name and a type:

    <union id="id">
      <field name="name" type="type"/>
      ...
    </union>

If a register's value is composed from several separate values, define it with a structure type. There are two forms of the ``<struct>'` element; a ``<struct>'` element must either contain only bitfields or contain no bitfields. If the structure contains only bitfields, its total size in bytes must be specified, each bitfield must have an explicit start and end, and bitfields are automatically assigned an integer type. The field's start should be less than or equal to its end, and zero represents the least significant bit.

    <struct id="id" size="size">
      <field name="name" start="start" end="end"/>
      ...
    </struct>

If the structure contains no bitfields, then each field has an explicit type, and no implicit padding is added.

    <struct id="id">
      <field name="name" type="type"/>
      ...
    </struct>

If a register's value is a series of single-bit flags, define it with a flags type. The ``<flags>'` element has an explicit size and contains one or more ``<field>'` elements. Each field has a name, a start, and an end. Only single-bit flags are supported.

    <flags id="id" size="size">
      <field name="name" start="start" end="end"/>
      ...
    </flags>

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### G.2.7 Registers

Each register is represented as an element with this form:

    <reg name="name"
         bitsize="size"
         [regnum="num"]
         [save-restore="save-restore"]
         [type="type"]
         [group="group"]/>

The components are as follows:

name
  The register's name; it must be unique within the target description.

bitsize
  The register's size, in bits.

regnum
  The register's number. If omitted, a register's number is one greater than that of the previous register (either in the current feature or in a preceding feature); the first register in the target description defaults to zero. This register number is used to read or write the register; e.g. it is used in the remote `p` and `P` packets, and registers appear in the `g` and `G` packets in order of increasing register number.

save-restore
  Whether the register should be preserved across inferior function calls; this must be either `yes` or `no`. The default is `yes`, which is appropriate for most registers except for some system control registers; this is not related to the target's ABI.

type
  The type of the register. type may be a predefined type, a type defined in the current feature, or one of the special types `int` and `float`. `int` is an integer type of the correct size for bitsize, and `float` is a floating point type (in the architecture's normal floating point format) of the correct size for bitsize. The default is `int`.

group
  The register group to which this register belongs. group must be either `general`, `float`, or `vector`. If no group is specified, GDB will not display the register in `info registers`.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## G.3 Predefined Target Types

Type definitions in the self-description can build up composite types from basic building blocks, but can not define fundamental types. Instead, standard identifiers are provided by GDB for the fundamental types. The currently supported types are:

`int8`
`int16`
`int32`
`int64`
`int128`
  Signed integer types holding the specified number of bits.

`uint8`
`uint16`
`uint32`
`uint64`
`uint128`
  Unsigned integer types holding the specified number of bits.

`code_ptr`
`data_ptr`
  Pointers to unspecified code and data. The program counter and any dedicated return address register may be marked as code pointers; printing a code pointer converts it into a symbolic address. The stack pointer and any dedicated address registers may be marked as data pointers.

`ieee_single`
  Single precision IEEE floating point.

`ieee_double`
  Double precision IEEE floating point.

`arm_fpa_ext`
  The 12-byte extended precision format used by ARM FPA registers.

`i387_ext`
  The 10-byte extended precision format used by x87 registers.

`i386_eflags`
  32bit EFLAGS register used by x86.

`i386_mxcsr`
  32bit MXCSR register used by x86.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## G.4 Standard Target Features

A target description must contain either no registers or all the target's registers. If the description contains no registers, then GDB will assume a default register layout, selected based on the architecture. If the description contains any registers, the default layout will not be used; the standard registers must be described in the target description, in such a way that GDB can recognize them.

This is accomplished by giving specific names to feature elements which contain standard registers. GDB will look for features with those names and verify that they contain the expected registers; if any known feature is missing required registers, or if any required feature is missing, GDB will reject the target description. You can add additional registers to any of the standard features -- GDB will display them just as if they were added to an unrecognized feature.

This section lists the known features and their expected contents. Sample XML documents for these features are included in the GDB source tree, in the directory ``gdb/features'`.

Names recognized by GDB should include the name of the company or organization which selected the name, and the overall architecture to which the feature applies; so e.g. the feature containing ARM core registers is named ``org.gnu.gdb.arm.core'`.

The names of registers are not case sensitive for the purpose of recognizing standard features, but GDB will only display registers using the capitalization used in the description.

> G.4.1 AArch64 Features |  |
> G.4.2 ARM Features |  |
> G.4.3 i386 Features |  |
> G.4.4 MIPS Features |  |
> G.4.5 M68K Features |  |
> G.4.6 Nios II Features |  |
> G.4.7 PowerPC Features |  |
> G.4.8 S/390 and System z Features |  |
> G.4.9 TMS320C6x Features |  |

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### G.4.1 AArch64 Features

The ``org.gnu.gdb.aarch64.core'` feature is required for AArch64 targets. It should contain registers ``x0'` through ``x30'`, ``sp'`, ``pc'`, and ``cpsr'`.

The ``org.gnu.gdb.aarch64.fpu'` feature is optional. If present, it should contain registers ``v0'` through ``v31'`, ``fpsr'`, and ``fpcr'`.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### G.4.2 ARM Features

The ``org.gnu.gdb.arm.core'` feature is required for non-M-profile ARM targets. It should contain registers ``r0'` through ``r13'`, ``sp'`, ``lr'`, ``pc'`, and ``cpsr'`.

For M-profile targets (e.g. Cortex-M3), the ``org.gnu.gdb.arm.core'` feature is replaced by ``org.gnu.gdb.arm.m-profile'`. It should contain registers ``r0'` through ``r13'`, ``sp'`, ``lr'`, ``pc'`, and ``xpsr'`.

The ``org.gnu.gdb.arm.fpa'` feature is optional. If present, it should contain registers ``f0'` through ``f7'` and ``fps'`.

The ``org.gnu.gdb.xscale.iwmmxt'` feature is optional. If present, it should contain at least registers ``wR0'` through ``wR15'` and ``wCGR0'` through ``wCGR3'`. The ``wCID'`, ``wCon'`, ``wCSSF'`, and ``wCASF'` registers are optional.

The ``org.gnu.gdb.arm.vfp'` feature is optional. If present, it should contain at least registers ``d0'` through ``d15'`. If they are present, ``d16'` through ``d31'` should also be included. GDB will synthesize the single-precision registers from halves of the double-precision registers.

The ``org.gnu.gdb.arm.neon'` feature is optional. It does not need to contain registers; it instructs GDB to display the VFP double-precision registers as vectors and to synthesize the quad-precision registers from pairs of double-precision registers. If this feature is present, ``org.gnu.gdb.arm.vfp'` must also be present and include 32 double-precision registers.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### G.4.3 i386 Features

The ``org.gnu.gdb.i386.core'` feature is required for i386/amd64 targets. It should describe the following registers:

- ``eax'` through ``edi'` plus ``eip'` for i386
- ``rax'` through ``r15'` plus ``rip'` for amd64
- ``eflags'`, ``cs'`, ``ss'`, ``ds'`, ``es'`, ``fs'`, ``gs'`
- ``st0'` through ``st7'`
- ``fctrl'`, ``fstat'`, ``ftag'`, ``fiseg'`, ``fioff'`, ``foseg'`, ``fooff'` and ``fop'`

The register sets may be different, depending on the target.

The ``org.gnu.gdb.i386.sse'` feature is optional. It should describe registers:

- ``xmm0'` through ``xmm7'` for i386
- ``xmm0'` through ``xmm15'` for amd64
- ``mxcsr'`

The ``org.gnu.gdb.i386.avx'` feature is optional and requires the ``org.gnu.gdb.i386.sse'` feature. It should describe the upper 128 bits of YMM registers:

- ``ymm0h'` through ``ymm7h'` for i386
- ``ymm0h'` through ``ymm15h'` for amd64

The ``org.gnu.gdb.i386.mpx'` is an optional feature representing Intel(R) Memory Protection Extension (MPX). It should describe the following registers:

- ``bnd0raw'` through ``bnd3raw'` for i386 and amd64.
- ``bndcfgu'` and ``bndstatus'` for i386 and amd64.

The ``org.gnu.gdb.i386.linux'` feature is optional. It should describe a single register, ``orig_eax'`.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### G.4.4 MIPS Features

The ``org.gnu.gdb.mips.cpu'` feature is required for MIPS targets. It should contain registers ``r0'` through ``r31'`, ``lo'`, ``hi'`, and ``pc'`. They may be 32-bit or 64-bit depending on the target.

The ``org.gnu.gdb.mips.cp0'` feature is also required. It should contain at least the ``status'`, ``badvaddr'`, and ``cause'` registers. They may be 32-bit or 64-bit depending on the target.

The ``org.gnu.gdb.mips.fpu'` feature is currently required, though it may be optional in a future version of GDB. It should contain registers ``f0'` through ``f31'`, ``fcsr'`, and ``fir'`. They may be 32-bit or 64-bit depending on the target.

The ``org.gnu.gdb.mips.dsp'` feature is optional. It should contain registers ``hi1'` through ``hi3'`, ``lo1'` through ``lo3'`, and ``dspctl'`. The ``dspctl'` register should be 32-bit and the rest may be 32-bit or 64-bit depending on the target.

The ``org.gnu.gdb.mips.linux'` feature is optional. It should contain a single register, ``restart'`, which is used by the Linux kernel to control restartable syscalls.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### G.4.5 M68K Features

```org.gnu.gdb.m68k.core'``
```org.gnu.gdb.coldfire.core'``
```org.gnu.gdb.fido.core'``
  One of those features must be always present. The feature that is present determines which flavor of m68k is used. The feature that is present should contain registers ``d0'` through ``d7'`, ``a0'` through ``a5'`, ``fp'`, ``sp'`, ``ps'` and ``pc'`.

```org.gnu.gdb.coldfire.fp'``
  This feature is optional. If present, it should contain registers ``fp0'` through ``fp7'`, ``fpcontrol'`, ``fpstatus'` and ``fpiaddr'`.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### G.4.6 Nios II Features

The ``org.gnu.gdb.nios2.cpu'` feature is required for Nios II targets. It should contain the 32 core registers (``zero'`, ``at'`, ``r2'` through ``r23'`, ``et'` through ``ra'`), ``pc'`, and the 16 control registers (``status'` through ``mpuacc'`).

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### G.4.7 PowerPC Features

The ``org.gnu.gdb.power.core'` feature is required for PowerPC targets. It should contain registers ``r0'` through ``r31'`, ``pc'`, ``msr'`, ``cr'`, ``lr'`, ``ctr'`, and ``xer'`. They may be 32-bit or 64-bit depending on the target.

The ``org.gnu.gdb.power.fpu'` feature is optional. It should contain registers ``f0'` through ``f31'` and ``fpscr'`.

The ``org.gnu.gdb.power.altivec'` feature is optional. It should contain registers ``vr0'` through ``vr31'`, ``vscr'`, and ``vrsave'`.

The ``org.gnu.gdb.power.vsx'` feature is optional. It should contain registers ``vs0h'` through ``vs31h'`. GDB will combine these registers with the floating point registers (``f0'` through ``f31'`) and the altivec registers (``vr0'` through ``vr31'`) to present the 128-bit wide registers ``vs0'` through ``vs63'`, the set of vector registers for POWER7.

The ``org.gnu.gdb.power.spe'` feature is optional. It should contain registers ``ev0h'` through ``ev31h'`, ``acc'`, and ``spefscr'`. SPE targets should provide 32-bit registers in ``org.gnu.gdb.power.core'` and provide the upper halves in ``ev0h'` through ``ev31h'`. GDB will combine these to present registers ``ev0'` through ``ev31'` to the user.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### G.4.8 S/390 and System z Features

The ``org.gnu.gdb.s390.core'` feature is required for S/390 and System z targets. It should contain the PSW and the 16 general registers. In particular, System z targets should provide the 64-bit registers ``pswm'`, ``pswa'`, and ``r0'` through ``r15'`. S/390 targets should provide the 32-bit versions of these registers. A System z target that runs in 31-bit addressing mode should provide 32-bit versions of ``pswm'` and ``pswa'`, as well as the general register's upper halves ``r0h'` through ``r15h'`, and their lower halves ``r0l'` through ``r15l'`.

The ``org.gnu.gdb.s390.fpr'` feature is required. It should contain the 64-bit registers ``f0'` through ``f15'`, and ``fpc'`.

The ``org.gnu.gdb.s390.acr'` feature is required. It should contain the 32-bit registers ``acr0'` through ``acr15'`.

The ``org.gnu.gdb.s390.linux'` feature is optional. It should contain the register ``orig_r2'`, which is 64-bit wide on System z targets and 32-bit otherwise. In addition, the feature may contain the ``last_break'` register, whose width depends on the addressing mode, as well as the ``system_call'` register, which is always 32-bit wide.

The ``org.gnu.gdb.s390.tdb'` feature is optional. It should contain the 64-bit registers ``tdb0'`, ``tac'`, ``tct'`, ``atia'`, and ``tr0'` through ``tr15'`.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

### G.4.9 TMS320C6x Features

The ``org.gnu.gdb.tic6x.core'` feature is required for TMS320C6x targets. It should contain registers ``A0'` through ``A15'`, registers ``B0'` through ``B15'`, ``CSR'` and ``PC'`.

The ``org.gnu.gdb.tic6x.gp'` feature is optional. It should contain registers ``A16'` through ``A31'` and ``B16'` through ``B31'`.

The ``org.gnu.gdb.tic6x.c6xp'` feature is optional. It should contain registers ``TSR'`, ``ILC'` and ``RILC'`.

[ << ] | [ >> ] |  |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

This document was generated by GNAT Mailserver on April, 17 2014 using texi2html