aboutsummaryrefslogtreecommitdiff
path: root/gdb/doc/gdbint.texinfo
diff options
context:
space:
mode:
authorJohn Gilmore <gnu@cygnus>1991-02-05 23:47:22 +0000
committerJohn Gilmore <gnu@cygnus>1991-02-05 23:47:22 +0000
commit46bc46ebd7b63427e2f9c31161fe76817122d564 (patch)
tree0bf0235039a0b8deb7acba328bc8db2c82742558 /gdb/doc/gdbint.texinfo
parentd62719de80fe5a5139aff826f2c7b46048038be9 (diff)
downloadgdb-46bc46ebd7b63427e2f9c31161fe76817122d564.zip
gdb-46bc46ebd7b63427e2f9c31161fe76817122d564.tar.gz
gdb-46bc46ebd7b63427e2f9c31161fe76817122d564.tar.bz2
* gdb-int.texinfo: Add text on how to define a new host or target
architecture, prompted by Per Bothner's questions about MIPS support.
Diffstat (limited to 'gdb/doc/gdbint.texinfo')
-rw-r--r--gdb/doc/gdbint.texinfo55
1 files changed, 55 insertions, 0 deletions
diff --git a/gdb/doc/gdbint.texinfo b/gdb/doc/gdbint.texinfo
index a7bc095..3eddb3f 100644
--- a/gdb/doc/gdbint.texinfo
+++ b/gdb/doc/gdbint.texinfo
@@ -88,3 +88,58 @@ after changing Makefile.dist, alldeps.mak, etc.
Check the README file, it often has useful information that does not
appear anywhere else in the directory.
+
+
+
+
+ Defining a new host or target architecture
+
+
+When building support for a new host and/or target, this will help you
+organize where to put the various parts. ARCH stands for the
+architecture involved.
+
+Object files needed when the host system is an ARCH are listed in the file
+xconfig/ARCH, in the Makefile macro "XDEPFILES = ...". You can also
+define XXXXXX in there.
+
+There are some "generic" versions of routines that can be used by
+various host systems. If these routines work for the ARCH host, you
+can just include the generic file's name (with .o, not .c) in
+XDEPFILES. Otherwise, you will need to write routines that perform the
+same functions as the generic file, put them into ARCH-xdep.c, and put
+ARCH-xdep.o into XDEPFILES. These generic host support files include:
+
+ coredep.c, coredep.o
+
+fetch_core_registers():
+Support for reading registers out of a core file. This routine calls
+register_addr(), see below.
+
+register_addr():
+If your xm-ARCH.h file defines the macro REGISTER_U_ADDR(reg) to be the
+offset within the "user" struct of a register (represented as a GDB
+register number), coredep.c will define the register_addr() function
+and use the macro in it. If you do not define REGISTER_U_ADDR, but
+you are using the standard fetch_core_registers, you
+will need to define your own version of register_addr, put it into
+your ARCH-xdep.c file, and be sure ARCH-xdep.o is in the XDEPFILES list.
+If you have your own fetch_core_registers, you only need to define
+register_addr if your fetch_core_registers calls it. Many custom
+fetch_core_registers implementations simply locate the registers
+themselves.
+
+
+Files needed when the target system is an ARCH are listed in the file
+tconfig/ARCH, in the Makefile macro "TDEPFILES = ...". You can also
+define XXXXXX in there.
+
+Similar generic support files for target systems are:
+
+ exec.c, exec.o:
+
+This file 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 architecture
+should be able to use the generic exec.c rather than its own custom code.