### 10.2 Adding Target Described Register Support

Target descriptions can report additional registers specific to an instance of the target. But it takes a little work in the architecture specific routines to support this.

A target description must either have no registers or a complete set—this avoids complexity in trying to merge standard registers with the target defined registers. It is the architecture's responsibility to validate that a description with registers has everything it needs. To keep architecture code simple, the same mechanism is used to assign fixed internal register numbers to standard registers.

If `tdesc_has_registers` returns 1, the description contains registers. The architecture's `gdbarch_init` routine should:

- Call `tdesc_data_alloc` to allocate storage, early, before searching for a matching gdbarch or allocating a new one.
- Use `tdesc_find_feature` to locate standard features by name.
- Use `tdesc_numbered_register` and `tdesc_numbered_register_choices` to locate the expected registers in the standard features.
- Return `NULL` if a required feature is missing, or if any standard feature is missing expected registers. This will produce a warning that the description was incomplete.
- Free the allocated data before returning, unless `tdesc_use_registers` is called.
- Call `set_gdbarch_num_regs` as usual, with a number higher than any fixed number passed to `tdesc_numbered_register`.
- Call `tdesc_use_registers` after creating a new gdbarch, before returning it.

After `tdesc_use_registers` has been called, the architecture's `register_name`, `register_type`, and `register_reggroup_p` routines will not be called; that information will be taken from the target description. `num_regs` may be increased to account for any additional registers in the description.

Pseudo-registers require some extra care:

- Using `tdesc_numbered_register` allows the architecture to give constant register numbers to standard architectural registers, e.g. as an `enum` in `arch-tdep.h`. But because pseudo-registers are always numbered above `num_regs`, which may be increased by the description, constant numbers can not be used for pseudos. They must be numbered relative to `num_regs` instead.
- The description will not describe pseudo-registers, so the architecture must call `set_tdesc_pseudo_register_name`, `set_tdesc_pseudo_register_type`, and `set_tdesc_pseudo_register_reggroup_p` to supply routines describing pseudo registers. These routines will be passed internal register numbers, so the same routines used for the gdbarch equivalents are usually suitable.