Several files control GDB's configuration for native support:
configure
). Contains C
macro definitions describing the native system environment, such as
child process control and core file support.
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-xyz.h' file. If these routines work for
the xyz 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 `xyz-nat.c', and put `xyz-nat.o'
into NATDEPFILES
.
ptrace
call in a vanilla way.
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 xyz-nat.c
(or
REGISTER_U_ADDR
in nm-xyz.h
).
nm-xyz.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
xyz-nat.c
file, and be sure xyz-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 `xyz-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.
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.
When GDB is configured and compiled, various macros are defined or left undefined, to control compilation when the host and target systems are the same. These macros should be defined (or left undefined) in `nm-system.h'.
CHILD_PREPARE_TO_STORE
FETCH_INFERIOR_REGISTERS
fetch_inferior_registers
and store_inferior_registers
in
`host-nat.c'. If this symbol is not defined, and
`infptrace.c' is included in this configuration, the default
routines in `infptrace.c' are used for these functions.
FP0_REGNUM
GET_LONGJMP_TARGET
longjmp
will jump to,
assuming that we have just stopped at a longjmp breakpoint. It takes a
CORE_ADDR *
as argument, and stores the target PC value through this
pointer. It examines the current state of the machine as needed.
I386_USE_GENERIC_WATCHPOINTS
KERNEL_U_ADDR
u
structure (the "user
struct", also known as the "u-page") in kernel virtual memory. GDB
needs to know this so that it can subtract this address from absolute
addresses in the upage, that are obtained via ptrace or from core files.
On systems that don't need this value, set it to zero.
KERNEL_U_ADDR_HPUX
u
at
runtime, by using HP-style nlist
on the kernel's image in the
root directory.
ONE_PROCESS_WRITETEXT
PROC_NAME_FMT
PTRACE_ARG3_TYPE
ptrace
system call, if it
exists and is different from int
.
REGISTER_U_ADDR
SHELL_COMMAND_CONCAT
SHELL_FILE
"/bin/sh"
.
SOLIB_ADD (filename, from_tty, targ, readsyms)
SOLIB_CREATE_INFERIOR_HOOK
START_INFERIOR_TRAPS_EXPECTED
USE_PROC_FS
U_REGS_OFFSET
FETCH_INFERIOR_REGISTERS
is not defined). If
the default value from `infptrace.c' is good enough, leave it
undefined.
The default value means that u.u_ar0 points to the location of
the registers. I'm guessing that #define U_REGS_OFFSET 0
means
that u.u_ar0
is the location of the registers.
CLEAR_SOLIB
DEBUG_PTRACE
ptrace
calls.
Go to the first, previous, next, last section, table of contents.