Next: Languages Prev: Native Up: Top
Adding a New Target
For a new target called TTT, first specify the configuration as
described in Note: Adding a New Configuration. If your new
target is the same as your new host, you've probably already done that.
A variety of files specify attributes of the GDB target environment:
Contains a Makefile fragment specific to this target. Specifies
what object files are needed for target TTT, by defining
`TDEPFILES=...'. Also specifies the header file which describes
TTT, by defining `TM_FILE= tm-TTT.h'. You can also define
`TM_CFLAGS', `TM_CLIBS', `TM_CDEPS', and other Makefile variables
here; see `Makefile.in'.
(`tm.h' is a link to this file, created by configure). Contains
macro definitions about the target machine's registers, stack
frame format and instructions. Crib from existing `tm-*.h' files
when building a new one.
Contains any miscellaneous code required for this target machine.
On some machines it doesn't exist at all. Sometimes the macros in
`tm-TTT.h' become very complicated, so they are implemented as
functions here instead, and the macro is simply defined to call
Defines functions for accessing files that are executable on the
target system. These functions open and examine an exec file,
extract data from one, write data to one, print information about
one, etc. Now that executable files are handled with BFD, every
target should be able to use the generic exec.c rather than its
own custom code.
Prints (disassembles) the target machine's instructions. This
file is usually shared with other target machines which use the
same processor, which is why it is `ARCH-pinsn.c' rather than
Contains some large initialized data structures describing the
target machine's instructions. This is a bit strange for a `.h'
file, but it's OK since it is only included in one place.
`ARCH-opcode.h' is shared between the debugger and the assembler,
if the GNU assembler has been ported to the target machine.
This often exists to describe the basic layout of the target
machine's processor chip (registers, stack, etc). If used, it is
included by `tm-XXX.h'. It can be shared among many targets that
use the same processor.
Similarly, there are often common subroutines that are shared by
all target machines that use this particular architecture.
When adding support for a new target machine, there are various areas
of support that might need change, or might be OK.
If you are using an existing object file format (a.out or COFF),
there is probably little to be done. See `bfd/doc/bfd.texinfo' for
more information on writing new a.out or COFF versions.
If you need to add a new object file format, you must first add it to
BFD. This is beyond the scope of this document right now. Basically
you must build a transfer vector (of type `bfd_target'), which will
mean writing all the required routines, and add it to the list in
You must then arrange for the BFD code to provide access to the
debugging symbols. Generally GDB will have to call swapping routines
from BFD and a few other BFD internal routines to locate the debugging
information. As much as possible, GDB should not depend on the BFD
internal data structures.
For some targets (e.g., COFF), there is a special transfer vector
used to call swapping routines, since the external data structures on
various platforms have different sizes and layouts. Specialized
routines that will only ever be implemented by one object file format
may be called directly. This interface should be described in a file
`bfd/libxxx.h', which is included by GDB.
If you are adding a new operating system for an existing CPU chip,
add a `tm-XOS.h' file that describes the operating system facilities
that are unusual (extra symbol table info; the breakpoint instruction
needed; etc). Then write a `tm-XARCH-XOS.h' that just `#include's
`tm-XARCH.h' and `tm-XOS.h'. (Now that we have three-part
configuration names, this will probably get revised to separate the XOS
configuration from the XARCH configuration.)
automatically generated by info2www