(gdbint.info)Native


Next: Target Prev: Host Up: Top

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.  (Note: 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.


automatically generated by info2www