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

10. Target Descriptions

The target architecture definition (see section 9. Target Architecture Definition) contains GDB's hard-coded knowledge about an architecture. For some platforms, it is handy to have more flexible knowledge about a specific instance of the architecture--for instance, a processor or development board. Target descriptions provide a mechanism for the user to tell GDB more about what their target supports, or for the target to tell GDB directly.

For details on writing, automatically supplying, and manually selecting target descriptions, see section `Target Descriptions' in Debugging with GDB. This section will cover some related topics about the GDB internals.

10.1 Target Descriptions Implementation  
10.2 Adding Target Described Register Support  

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

10.1 Target Descriptions Implementation

Before GDB connects to a new target, or runs a new program on an existing target, it discards any existing target description and reverts to a default gdbarch. Then, after connecting, it looks for a new target description by calling target_find_description.

A description may come from a user specified file (XML), the remote `qXfer:features:read' packet (also XML), or from any custom to_read_description routine in the target vector. For instance, the remote target supports guessing whether a MIPS target is 32-bit or 64-bit based on the size of the `g' packet.

If any target description is found, GDB creates a new gdbarch incorporating the description by calling gdbarch_update_p. Any `<architecture>' element is handled first, to determine which architecture's gdbarch initialization routine is called to create the new architecture. Then the initialization routine is called, and has a chance to adjust the constructed architecture based on the contents of the target description. For instance, it can recognize any properties set by a to_read_description routine. Also see 10.2 Adding Target Described Register Support.

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

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:

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:

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

Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.

These pages are maintained by the GDB developers.

Copyright Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA.

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

This document was generated by GDB Administrator on March, 31 2007 using texi2html