Go to the first, previous, next, last section, table of contents.

# 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.
``core-aout.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 `core-aout.c`, and should just provide `fetch_core_registers` in `xxx-nat.c` (or `REGISTER_U_ADDR` in `nm-xxx.h`).
``core-aout.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, ``core-aout.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 ``core-aout.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.

Go to the first, previous, next, last section, table of contents.