darkkirb/old-cross-binutils
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

* gdb-int.texinfo: Add text on how to define a new host or target

Browse source 
architecture, prompted by Per Bothner's questions about MIPS
        support.
This commit is contained in:
John Gilmore 1991-02-05 23:47:22 +00:00
parent d62719de80
commit 46bc46ebd7
1 changed files with 55 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

55
gdb/doc/gdbint.texinfo
View file

@ -88,3 +88,58 @@ after changing Makefile.dist, alldeps.mak, etc.
Check the README file, it often has useful information that does not Check the README file, it often has useful information that does not
appear anywhere else in the directory. 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.