Differences between revisions 1 and 2
Revision 1 as of 2013-08-20 23:40:12
Size: 2933
Editor: StanShebs
Comment: Import from gdbint.texinfo
Revision 2 as of 2013-09-01 12:28:15
Size: 2944
Comment: Tidied up and checked links
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
''This page was produced by an automated import process, and may have formatting errors; feel free to fix.'' == Adding target described register support ==
Line 3: Line 3:
=== 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. The relevant functions are described in [[https://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/target-descriptions.h?cvsroot=src|target-descriptions.h]].
Line 5: Line 5:
   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.
Line 7: Line 7:
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:
If {{{tdesc_has_registers}}} returns 1, the description contains registers. The architecture's {{{gdbarch_init}}} routine should:
Line 20: Line 16:
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. 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.

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. The relevant functions are described in target-descriptions.h.

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.

None: Internals Adding-Target-Described-Register-Support (last edited 2013-09-01 12:28:15 by JeremyBennett)

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.