Adding a New Native Configuration

If you are making GDB run native on the xxx machine, you have plenty more work to do. Several files control GDB's configuration for native support:

`gdb/config/xarch/xxx.mh'

Specifies Makefile fragments needed when hosting or native on machine xxx. In particular, this lists the required native-dependent object files, by defining `NATDEPFILES=...'. Also specifies the header file which describes native support on xxx, by defining `NAT_FILE= nm-xxx.h'. You can also define `NAT_CFLAGS', `NAT_ADD_FILES', `NAT_CLIBS', `NAT_CDEPS', etc.; see `Makefile.in'.

`gdb/config/arch/nm-xxx.h'

(`nm.h' is a link to this file, created by configure). Contains C macro definitions describing the native system environment, such as child process control and core file support. Crib from existing `nm-*.h' files to create a new one.

`gdb/xxx-nat.c'

Contains any miscellaneous C code required for this native support of this machine. On some machines it doesn't exist at all.

Generic Native Support Files

There are some "generic" versions of routines that can be used by various systems. These can be customized in various ways by macros defined in your `nm-xxx.h' file. If these routines work for the xxx host, you can just include the generic file's name (with `.o', not `.c') in NATDEPFILES.

Otherwise, if your machine needs custom support routines, you will need to write routines that perform the same functions as the generic file. Put them into xxx-nat.c, and put xxx-nat.o into NATDEPFILES.

`inftarg.c'

This contains the target_ops vector that supports Unix child processes on systems which use ptrace and wait to control the child.

`procfs.c'

This contains the target_ops vector that supports Unix child processes on systems which use /proc to control the child.

`fork-child.c'

This does the low-level grunge that uses Unix system calls to do a "fork and exec" to start up a child process.

`infptrace.c'

This is the low level interface to inferior processes for systems using the Unix ptrace call in a vanilla way.

`coredep.c::fetch_core_registers()'

Support for reading registers out of a core file. This routine calls register_addr(), see below. Now that BFD is used to read core files, virtually all machines should use coredep.c, and should just provide fetch_core_registers in xxx-nat.c (or REGISTER_U_ADDR in nm-xxx.h).

`coredep.c::register_addr()'

If your nm-xxx.h file defines the macro REGISTER_U_ADDR(addr, blockend, regno), it should be defined to set addr to the offset within the `user' struct of GDB register number regno. blockend is the offset within the "upage" of u.u_ar0. If REGISTER_U_ADDR is defined, `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 xxx-nat.c file, and be sure xxx-nat.o is in the NATDEPFILES list. If you have your own fetch_core_registers(), you may not need a separate register_addr(). Many custom fetch_core_registers() implementations simply locate the registers themselves.

When making GDB run native on a new operating system, to make it possible to debug core files, you will need to either write specific code for parsing your OS's core files, or customize `bfd/trad-core.c'. First, use whatever #include files your machine uses to define the struct of registers that is accessible (possibly in the u-area) in a core file (rather than `machine/reg.h'), and an include file that defines whatever header exists on a core file (e.g. the u-area or a `struct core'). Then modify trad_unix_core_file_p() to use these values to set up the section information for the data segment, stack segment, any other segments in the core file (perhaps shared library contents or control information), "registers" segment, and if there are two discontiguous sets of registers (e.g. integer and float), the "reg2" segment. This section information basically delimits areas in the core file in a standard way, which the section-reading routines in BFD know how to seek around in.

Then back in GDB, you need a matching routine called fetch_core_registers(). If you can use the generic one, it's in `coredep.c'; if not, it's in your `xxx-nat.c' file. It will be passed a char pointer to the entire "registers" segment, its length, and a zero; or a char pointer to the entire "regs2" segment, its length, and a 2. The routine should suck out the supplied register values and install them into GDB's "registers" array. (See section Defining a New Host or Target Architecture, for more info about this.)

If your system uses `/proc' to control processes, and uses ELF format core files, then you may be able to use the same routines for reading the registers out of processes and out of core files.