* Support Libraries::
* Coding::
* Porting GDB::
+* Testsuite::
* Hints::
@end menu
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
i960 Nindy target, and should not be used in any other configuration.
@item ADDR_BITS_REMOVE (addr)
-If a raw machine address includes any bits that are not really part of
-the address, then define this macro to expand into an expression that
-zeros those bits in @var{addr}. For example, the two low-order bits of
-a Motorola 88K address may be used by some kernels for their own
-purposes, since addresses must always be 4-byte aligned, and so are of
-no use for addressing. Those bits should be filtered out with an
-expression such as @code{((addr) & ~3)}.
+If a raw machine instruction address includes any bits that are not
+really part of the address, then define this macro to expand into an
+expression that zeros those bits in @var{addr}. This is only used for
+addresses of instructions, and even then not in all contexts.
+
+For example, the two low-order bits of the PC on the Hewlett-Packard PA
+2.0 architecture contain the privilege level of the corresponding
+instruction. Since instructions must always be aligned on four-byte
+boundaries, the processor masks out these bits to generate the actual
+address of the instruction. ADDR_BITS_REMOVE should filter out these
+bits with an expression such as @code{((addr) & ~3)}.
@item BEFORE_MAIN_LOOP_HOOK
Define this to expand into any code that you want to execute before the
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
feature-specific macros. It was introduced in haste and we are
repenting at leisure.
+@item SYMBOLS_CAN_START_WITH_DOLLAR
+Some systems have routines whose names start with @samp{$}. Giving this
+macro a non-zero value tells GDB's expression parser to check for such
+routines when parsing tokens that begin with @samp{$}.
+
+On HP-UX, certain system routines (millicode) have names beginning with
+@samp{$} or @samp{$$}. For example, @code{$$dyncall} is a millicode
+routine that handles inter-space procedure calls on PA-RISC.
+
@item IEEE_FLOAT
Define this if the target system uses IEEE-format floating point numbers.
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
The number of the ``next next program counter'' register, if defined.
Currently, this is only defined for the Motorola 88K.
+@item PARM_BOUNDARY
+If non-zero, round arguments to a boundary of this many bits before
+pushing them on the stack.
+
@item PRINT_REGISTER_HOOK (regno)
If defined, this must be a function that prints the contents of the
given register to standard output.
Define this to return 1 if the given type will be passed by pointer
rather than directly.
+@item SAVE_DUMMY_FRAME_TOS (sp)
+Used in @samp{call_function_by_hand} to notify the target dependent code
+of the top-of-stack value that will be passed to the the inferior code.
+This is the value of the @var{SP} after both the dummy frame and space
+for parameters/results have been allocated on the stack.
+
@item SDB_REG_TO_REGNUM
Define this to convert sdb register numbers into GDB regnums. If not
defined, no conversion will be done.
@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
Define this to be able to, when a breakpoint insertion fails, warn the
user that another process may be running with the same executable.
+@item PREPARE_TO_PROCEED @var{select_it}
+This (ugly) macro allows a native configuration to customize the way the
+@code{proceed} function in @file{infrun.c} deals with switching between
+threads.
+
+In a multi-threaded task we may select another thread and then continue
+or step. But if the old thread was stopped at a breakpoint, it will
+immediately cause another breakpoint stop without any execution (i.e. it
+will report a breakpoint hit incorrectly). So GDB must step over it
+first.
+
+If defined, @code{PREPARE_TO_PROCEED} should check the current thread
+against the thread that reported the most recent event. If a step-over
+is required, it returns TRUE. If @var{select_it} is non-zero, it should
+reselect the old thread.
+
@item PROC_NAME_FMT
Defines the format for the name of a @file{/proc} device. Should be
defined in @file{nm.h} @emph{only} in order to override the default
@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.
@code{makeinfo} will split the document into one overall file and five
or so included files.
+@node Testsuite
+
+@chapter Testsuite
+
+The testsuite is an important component of the GDB package. While it is
+always worthwhile to encourage user testing, in practice this is rarely
+sufficient; users typically use only a small subset of the available
+commands, and it has proven all too common for a change to cause a
+significant regression that went unnoticed for some time.
+
+The GDB testsuite uses the DejaGNU testing framework. DejaGNU is built
+using tcl and expect. The tests themselves are calls to various tcl
+procs; the framework runs all the procs and summarizes the passes and
+fails.
+
+@section Using the Testsuite
+
+To run the testsuite, simply go to the GDB object directory (or to the
+testsuite's objdir) and type @code{make check}. This just sets up some
+environment variables and invokes DejaGNU's @code{runtest} script. While
+the testsuite is running, you'll get mentions of which test file is in use,
+and a mention of any unexpected passes or fails. When the testsuite is
+finished, you'll get a summary that looks like this:
+@example
+ === gdb Summary ===
+
+# of expected passes 6016
+# of unexpected failures 58
+# of unexpected successes 5
+# of expected failures 183
+# of unresolved testcases 3
+# of untested testcases 5
+@end example
+The ideal test run consists of expected passes only; however, reality
+conspires to keep us from this ideal. Unexpected failures indicate
+real problems, whether in GDB or in the testsuite. Expected failures
+are still failures, but ones which have been decided are too hard to
+deal with at the time; for instance, a test case might work everywhere
+except on AIX, and there is no prospect of the AIX case being fixed in
+the near future. Expected failures should not be added lightly, since
+you may be masking serious bugs in GDB. Unexpected successes are expected
+fails that are passing for some reason, while unresolved and untested
+cases often indicate some minor catastrophe, such as the compiler being
+unable to deal with a test program.
+
+When making any significant change to GDB, you should run the testsuite
+before and after the change, to confirm that there are no regressions.
+Note that truly complete testing would require that you run the
+testsuite with all supported configurations and a variety of compilers;
+however this is more than really necessary. In many cases testing with
+a single configuration is sufficient. Other useful options are to test
+one big-endian (Sparc) and one little-endian (x86) host, a cross config
+with a builtin simulator (powerpc-eabi, mips-elf), or a 64-bit host
+(Alpha).
+
+If you add new functionality to GDB, please consider adding tests for it
+as well; this way future GDB hackers can detect and fix their changes
+that break the functionality you added. Similarly, if you fix a bug
+that was not previously reported as a test failure, please add a test
+case for it. Some cases are extremely difficult to test, such as code
+that handles host OS failures or bugs in particular versions of
+compilers, and it's OK not to try to write tests for all of those.
+
+@section Testsuite Organization
+
+The testsuite is entirely contained in @file{gdb/testsuite}. While the
+testsuite includes some makefiles and configury, these are very minimal,
+and used for little besides cleaning up, since the tests themselves
+handle the compilation of the programs that GDB will run. The file
+@file{testsuite/lib/gdb.exp} contains common utility procs useful for
+all GDB tests, while the directory @file{testsuite/config} contains
+configuration-specific files, typically used for special-purpose
+definitions of procs like @code{gdb_load} and @code{gdb_start}.
+
+The tests themselves are to be found in @file{testsuite/gdb.*} and
+subdirectories of those. The names of the test files must always end
+with @file{.exp}. DejaGNU collects the test files by wildcarding
+in the test directories, so both subdirectories and individual files
+get chosen and run in alphabetical order.
+
+The following table lists the main types of subdirectories and what they
+are for. Since DejaGNU finds test files no matter where they are
+located, and since each test file sets up its own compilation and
+execution environment, this organization is simply for convenience and
+intelligibility.
+
+@table @code
+
+@item gdb.base
+
+This is the base testsuite. The tests in it should apply to all
+configurations of GDB (but generic native-only tests may live here).
+The test programs should be in the subset of C that is valid K&R,
+ANSI/ISO, and C++ (ifdefs are allowed if necessary, for instance
+for prototypes).
+
+@item gdb.@var{lang}
+
+Language-specific tests for all languages besides C. Examples are
+@file{gdb.c++} and @file{gdb.java}.
+
+@item gdb.@var{platform}
+
+Non-portable tests. The tests are specific to a specific configuration
+(host or target), such as HP-UX or eCos. Example is @file{gdb.hp}, for
+HP-UX.
+
+@item gdb.@var{compiler}
+
+Tests specific to a particular compiler. As of this writing (June
+1999), there aren't currently any groups of tests in this category that
+couldn't just as sensibly be made platform-specific, but one could
+imagine a gdb.gcc, for tests of GDB's handling of GCC extensions.
+
+@item gdb.@var{subsystem}
+
+Tests that exercise a specific GDB subsystem in more depth. For
+instance, @file{gdb.disasm} exercises various disassemblers, while
+@file{gdb.stabs} tests pathways through the stabs symbol reader.
+
+@end table
+
+@section Writing Tests
+
+In many areas, the GDB tests are already quite comprehensive; you
+should be able to copy existing tests to handle new cases.
+
+You should try to use @code{gdb_test} whenever possible, since it
+includes cases to handle all the unexpected errors that might happen.
+However, it doesn't cost anything to add new test procedures; for
+instance, @file{gdb.base/exprs.exp} defines a @code{test_expr} that
+calls @code{gdb_test} multiple times.
+
+Only use @code{send_gdb} and @code{gdb_expect} when absolutely
+necessary, such as when GDB has several valid responses to a command.
+
+The source language programs do @emph{not} need to be in a consistent
+style. Since GDB is used to debug programs written in many different
+styles, it's worth having a mix of styles in the testsuite; for
+instance, some GDB bugs involving the display of source lines would
+never manifest themselves if the programs used GNU coding style
+uniformly.
+
@node Hints
@chapter Hints
@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.