set software breakpoints.
Software breakpoints require GDB to do somewhat more work. The basic
-theory is that GDB will replace a program instruction a trap, illegal
-divide, or some other instruction that will cause an exception, and then
-when it's encountered, GDB will take the exception and stop the program.
-When the user says to continue, GDB will restore the original
+theory is that GDB will replace a program instruction with a trap,
+illegal divide, or some other instruction that will cause an exception,
+and then when it's encountered, GDB will take the exception and stop the
+program. When the user says to continue, GDB will restore the original
instruction, single-step, re-insert the trap, and continue on.
Since it literally overwrites the program being tested, the program area
Symbol files are initially opened by code in @file{symfile.c} using the
BFD library. BFD identifies the type of the file by examining its
-header. @code{symfile_init} then uses this identification to locate a
+header. @code{find_sym_fns} then uses this identification to locate a
set of symbol-reading functions.
Symbol reading modules identify themselves to GDB by calling
HPPA's. This should all be ripped out, and a scheme like elfread.c
used.
-@item GDB_TARGET_IS_MACH386
-@item GDB_TARGET_IS_SUN3
-@item GDB_TARGET_IS_SUN386
-Kludges that should go away.
-
@item GET_LONGJMP_TARGET
For most machines, this is a target-dependent parameter. On the
DECstation and the Iris, this is a native-dependent parameter, since
Define this to evaluate to nonzero if the program is stopped in the
trampoline that returns from a shared library.
+@item IN_SOLIB_DYNSYM_RESOLVE_CODE pc
+Define this to evaluate to nonzero if the program is stopped in the
+dynamic linker.
+
+@item SKIP_SOLIB_RESOLVER pc
+Define this to evaluate to the (nonzero) address at which execution
+should continue to get past the dynamic linker's symbol resolution
+function. A zero value indicates that it is not important or necessary
+to set a breakpoint to get through the dynamic linker and that single
+stepping will suffice.
+
@item IS_TRAPPED_INTERNALVAR (name)
This is an ugly hook to allow the specification of special actions that
should occur as a side-effect of setting the value of a variable
@item SHIFT_INST_REGS
(Only used for m88k targets.)
+@item SKIP_PERMANENT_BREAKPOINT
+Advance the inferior's PC past a permanent breakpoint. GDB normally
+steps over a breakpoint by removing it, stepping one instruction, and
+re-inserting the breakpoint. However, permanent breakpoints are
+hardwired into the inferior, and can't be removed, so this strategy
+doesn't work. Calling SKIP_PERMANENT_BREAKPOINT adjusts the processor's
+state so that execution will resume just after the breakpoint. This
+macro does the right thing even when the breakpoint is in the delay slot
+of a branch or jump.
+
@item SKIP_PROLOGUE (pc)
A C expression that returns the address of the ``real'' code beyond the
function entry prologue found at @var{pc}.
@item gdb/config/@var{arch}/@var{ttt}.mt
Contains a Makefile fragment specific to this target. Specifies what
object files are needed for target @var{ttt}, by defining
-@samp{TDEPFILES=@dots{}}. Also specifies the header file which
-describes @var{ttt}, by defining @samp{TM_FILE= tm-@var{ttt}.h}. You
-can also define @samp{TM_CFLAGS}, @samp{TM_CLIBS}, @samp{TM_CDEPS}, but
-these are now deprecated and may go away in future versions of GDB.
+@samp{TDEPFILES=@dots{}} and @samp{TDEPLIBS=@dots{}}. Also specifies
+the header file which describes @var{ttt}, by defining @samp{TM_FILE=
+tm-@var{ttt}.h}.
+
+You can also define @samp{TM_CFLAGS}, @samp{TM_CLIBS}, @samp{TM_CDEPS},
+but these are now deprecated, replaced by autoconf, and may go away in
+future versions of GDB.
@item gdb/config/@var{arch}/tm-@var{ttt}.h
(@file{tm.h} is a link to this file, created by configure). Contains
@subsection Function Prototypes
-Prototypes must be used to @emph{declare} functions but never to
+Prototypes must be used to @emph{declare} functions, and may be used to
@emph{define} them. Prototypes for GDB functions must include both the
argument type and name, with the name matching that used in the actual
function definition.
-For the sake of compatibility with pre-ANSI compilers, define prototypes
-with the @code{PARAMS} macro:
-
-@example @code
-extern int memory_remove_breakpoint PARAMS ((CORE_ADDR addr,
- char *contents_cache));
-@end example
-
-Note the double parentheses around the parameter types. This allows an
-arbitrary number of parameters to be described, without freaking out the
-C preprocessor. When the function has no parameters, it should be
-described like:
-
-@example @code
-extern void noprocess PARAMS ((void));
-@end example
-
-The @code{PARAMS} macro expands to its argument in ANSI C, or to a
-simple @code{()} in traditional C.
-
-All external functions should have a @code{PARAMS} declaration in a
-header file that callers include, except for @code{_initialize_*}
-functions, which must be external so that @file{init.c} construction
-works, but shouldn't be visible to random source files.
+All external functions should have a declaration in a header file that
+callers include, except for @code{_initialize_*} functions, which must
+be external so that @file{init.c} construction works, but shouldn't be
+visible to random source files.
All static functions must be declared in a block near the top of the
source file.
@c Conditionals}, @pxref{Native Conditionals}, and @pxref{Obsolete
@c Conditionals})
-Start with the header files. Once you some idea of how GDB's internal
+Start with the header files. Once you have some idea of how GDB's internal
symbol tables are stored (see @file{symtab.h}, @file{gdbtypes.h}), you
will find it much easier to understand the code which uses and creates
those symbol tables.
projects / deliverable / binutils-gdb.git / blobdiff