doc/
[deliverable/binutils-gdb.git] / gdb / doc / gdbint.texinfo
index 187da2ff00c9a407bf45d0e0b61bc505730e1442..0255c028aa9aab81cb29163ca6be32d9c739224e 100644 (file)
@@ -694,11 +694,6 @@ changed are announced as hit.
 watchpoints:
 
 @table @code
-@findex TARGET_HAS_HARDWARE_WATCHPOINTS
-@item TARGET_HAS_HARDWARE_WATCHPOINTS
-If defined, the target supports hardware watchpoints.
-(Currently only used for several native configs.)
-
 @findex TARGET_CAN_USE_HARDWARE_WATCHPOINT
 @item TARGET_CAN_USE_HARDWARE_WATCHPOINT (@var{type}, @var{count}, @var{other})
 Return the number of hardware watchpoints of type @var{type} that are
@@ -991,13 +986,6 @@ the debug registers to watch instruction execution, and each
 hardware-assisted breakpoint always requires exactly one debug
 register.
 
-@findex i386_stopped_by_hwbp
-@item i386_stopped_by_hwbp (void)
-This function returns non-zero if the inferior has some watchpoint or
-hardware breakpoint that triggered.  It works like
-@code{i386_stopped_data_address}, except that it doesn't record the
-address whose watchpoint triggered.
-
 @findex i386_cleanup_dregs
 @item i386_cleanup_dregs (void)
 This function clears all the reference counts, addresses, and control
@@ -1405,8 +1393,8 @@ This function outputs a value of an @code{int} variable.  It differs from
 the name of the field.
 @end deftypefun
 
-@deftypefun void ui_out_field_core_addr (struct ui_out *@var{uiout}, const char *@var{fldname}, CORE_ADDR @var{address})
-This function outputs an address.
+@deftypefun void ui_out_field_core_addr (struct ui_out *@var{uiout}, const char *@var{fldname}, struct gdbarch *@var{gdbarch}, CORE_ADDR @var{address})
+This function outputs an address as appropriate for @var{gdbarch}.
 @end deftypefun
 
 @deftypefun void ui_out_field_string (struct ui_out *@var{uiout}, const char *@var{fldname}, const char *@var{string})
@@ -1594,7 +1582,7 @@ Here's the new version:
     @{
      if (nr_printable_breakpoints > 0)
        annotate_field (4);
-     if (gdbarch_addr_bit (current_gdbarch) <= 32)
+     if (print_address_bits <= 32)
        ui_out_table_header (uiout, 10, ui_left, "addr", "Address");/* 5 */
      else
        ui_out_table_header (uiout, 18, ui_left, "addr", "Address");/* 5 */
@@ -2047,9 +2035,17 @@ address as its caller.  On some platforms, a third address is part of
 the ID to further disambiguate frames---for instance, on IA-64
 the separate register stack address is included in the ID.
 
-An invalid frame ID (@code{null_frame_id}) returned from the
+An invalid frame ID (@code{outer_frame_id}) returned from the
 @code{this_id} method means to stop unwinding after this frame.
 
+@code{null_frame_id} is another invalid frame ID which should be used
+when there is no frame.  For instance, certain breakpoints are attached
+to a specific frame, and that frame is identified through its frame ID
+(we use this to implement the "finish" command).  Using
+@code{null_frame_id} as the frame ID for a given breakpoint means
+that the breakpoint is not specific to any frame.  The @code{this_id}
+method should never return @code{null_frame_id}.
+
 @section Unwinding Registers
 
 Each unwinder includes a @code{prev_register} method.  This method
@@ -2831,6 +2827,7 @@ using the Bourne shell script @file{gdbarch.sh}.
 * Register Representation::
 * Frame Interpretation::
 * Inferior Call Setup::
+* Adding support for debugging core files::
 * Defining Other Architecture Features::
 * Adding a New Target::
 @end menu
@@ -3312,7 +3309,7 @@ relationship between pointers and addresses.  These have default
 definitions, appropriate for architectures on which all pointers are
 simple unsigned byte addresses.
 
-@deftypefun CORE_ADDR gdbarch_pointer_to_address (struct gdbarch *@var{current_gdbarch}, struct type *@var{type}, char *@var{buf})
+@deftypefun CORE_ADDR gdbarch_pointer_to_address (struct gdbarch *@var{gdbarch}, struct type *@var{type}, char *@var{buf})
 Assume that @var{buf} holds a pointer of type @var{type}, in the
 appropriate format for the current architecture.  Return the byte
 address the pointer refers to.
@@ -3321,7 +3318,7 @@ This function may safely assume that @var{type} is either a pointer or a
 C@t{++} reference type.
 @end deftypefun
 
-@deftypefun void gdbarch_address_to_pointer (struct gdbarch *@var{current_gdbarch}, struct type *@var{type}, char *@var{buf}, CORE_ADDR @var{addr})
+@deftypefun void gdbarch_address_to_pointer (struct gdbarch *@var{gdbarch}, struct type *@var{type}, char *@var{buf}, CORE_ADDR @var{addr})
 Store in @var{buf} a pointer of type @var{type} representing the address
 @var{addr}, in the appropriate format for the current architecture.
 
@@ -3345,18 +3342,18 @@ following macros should be defined in order to disambiguate these
 types within @value{GDBN} as well as provide the added information to
 a @value{GDBN} user when printing type expressions.
 
-@deftypefun int gdbarch_address_class_type_flags (struct gdbarch *@var{current_gdbarch}, int @var{byte_size}, int @var{dwarf2_addr_class})
+@deftypefun int gdbarch_address_class_type_flags (struct gdbarch *@var{gdbarch}, int @var{byte_size}, int @var{dwarf2_addr_class})
 Returns the type flags needed to construct a pointer type whose size
 is @var{byte_size} and whose address class is @var{dwarf2_addr_class}.
 This function is normally called from within a symbol reader.  See
 @file{dwarf2read.c}.
 @end deftypefun
 
-@deftypefun {char *} gdbarch_address_class_type_flags_to_name (struct gdbarch *@var{current_gdbarch}, int @var{type_flags})
+@deftypefun {char *} gdbarch_address_class_type_flags_to_name (struct gdbarch *@var{gdbarch}, int @var{type_flags})
 Given the type flags representing an address class qualifier, return
 its name.
 @end deftypefun
-@deftypefun int gdbarch_address_class_name_to_type_flags (struct gdbarch *@var{current_gdbarch}, int @var{name}, int *@var{type_flags_ptr})
+@deftypefun int gdbarch_address_class_name_to_type_flags (struct gdbarch *@var{gdbarch}, int @var{name}, int *@var{type_flags_ptr})
 Given an address qualifier name, set the @code{int} referenced by @var{type_flags_ptr} to the type flags
 for that address class qualifier.
 @end deftypefun
@@ -4420,6 +4417,17 @@ Some Harvard architectures may not allow this.
 
 @end deftypefn
 
+@node Adding support for debugging core files
+@section Adding support for debugging core files
+@cindex core files
+
+The prerequisite for adding core file support in @value{GDBN} is to have
+core file support in BFD.
+
+Once BFD support is available, writing the apropriate
+@code{regset_from_core_section} architecture function should be all
+that is needed in order to add support for core files in @value{GDBN}.
+
 @node Defining Other Architecture Features 
 @section Defining Other Architecture Features 
 
@@ -4820,10 +4828,6 @@ guess the starting and ending addresses of the compilation unit from them.
 nonzero if a function argument of type @var{type} is passed by reference
 instead of value.
 
-@item PROCESS_LINENUMBER_HOOK
-@findex PROCESS_LINENUMBER_HOOK
-A hook defined for XCOFF reading.
-
 @item CORE_ADDR gdbarch_push_dummy_call (@var{gdbarch}, @var{function}, @var{regcache}, @var{bp_addr}, @var{nargs}, @var{args}, @var{sp}, @var{struct_return}, @var{struct_addr})
 @findex gdbarch_push_dummy_call
 @anchor{gdbarch_push_dummy_call} Define this to push the dummy frame's call to
@@ -5412,64 +5416,6 @@ This is the low level interface to inferior processes for systems using
 the Unix @code{ptrace} call in a vanilla way.
 @end table
 
-@section Native core file Support
-@cindex native core files
-
-@table @file
-@findex fetch_core_registers
-@item core-aout.c::fetch_core_registers()
-Support for reading registers out of a core file.  This routine calls
-@code{register_addr()}, see below.  Now that BFD is used to read core
-files, virtually all machines should use @code{core-aout.c}, and should
-just provide @code{fetch_core_registers} in @code{@var{xyz}-nat.c} (or
-@code{REGISTER_U_ADDR} in @code{nm-@var{xyz}.h}).
-
-@item core-aout.c::register_addr()
-If your @code{nm-@var{xyz}.h} file defines the macro
-@code{REGISTER_U_ADDR(addr, blockend, regno)}, it should be defined to
-set @code{addr} to the offset within the @samp{user} struct of @value{GDBN}
-register number @code{regno}.  @code{blockend} is the offset within the
-``upage'' of @code{u.u_ar0}.  If @code{REGISTER_U_ADDR} is defined,
-@file{core-aout.c} will define the @code{register_addr()} function and
-use the macro in it.  If you do not define @code{REGISTER_U_ADDR}, but
-you are using the standard @code{fetch_core_registers()}, you will need
-to define your own version of @code{register_addr()}, put it into your
-@code{@var{xyz}-nat.c} file, and be sure @code{@var{xyz}-nat.o} is in
-the @code{NATDEPFILES} list.  If you have your own
-@code{fetch_core_registers()}, you may not need a separate
-@code{register_addr()}.  Many custom @code{fetch_core_registers()}
-implementations simply locate the registers themselves.@refill
-@end table
-
-When making @value{GDBN} 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
-@file{bfd/trad-core.c}.  First, use whatever @code{#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
-@file{machine/reg.h}), and an include file that defines whatever header
-exists on a core file (e.g., the u-area or a @code{struct core}).  Then
-modify @code{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 @value{GDBN}, you need a matching routine called
-@code{fetch_core_registers}.  If you can use the generic one, it's in
-@file{core-aout.c}; if not, it's in your @file{@var{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 @value{GDBN}'s ``registers'' array.
-
-If your system uses @file{/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.
-
 @section ptrace
 
 @section /proc
@@ -5492,12 +5438,6 @@ undefined) in @file{nm-@var{system}.h}.
 An x86-based machine can define this to use the generic x86 watchpoint
 support; see @ref{Algorithms, I386_USE_GENERIC_WATCHPOINTS}.
 
-@item PROC_NAME_FMT
-@findex 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
-definition in @file{procfs.c}.
-
 @item SOLIB_ADD (@var{filename}, @var{from_tty}, @var{targ}, @var{readsyms})
 @findex SOLIB_ADD
 Define this to expand into an expression that will cause the symbols in
@@ -6709,7 +6649,7 @@ adding more reviewers or deciding who can commit).
 
 @item all commits are posted
 All changes committed to a branch shall also be posted to
-@email{gdb-patches@@sources.redhat.com, the @value{GDBN} patches
+@email{gdb-patches@@sourceware.org, the @value{GDBN} patches
 mailing list}.  While commentary on such changes are encouraged, people
 should remember that the changes only apply to a branch.
 
@@ -6876,13 +6816,13 @@ Remember, everything on the Internet takes a week.
 
 @enumerate
 @item
-Post the proposal on @email{gdb@@sources.redhat.com, the GDB mailing
+Post the proposal on @email{gdb@@sourceware.org, the GDB mailing
 list} Creating a bug report to track the task's state, is also highly
 recommended.
 @item
 Wait a week or so.
 @item
-Post the proposal on @email{gdb-announce@@sources.redhat.com, the GDB
+Post the proposal on @email{gdb-announce@@sourceware.org, the GDB
 Announcement mailing list}.
 @item
 Wait a week or so.
@@ -6942,7 +6882,7 @@ file)
 
 @subheading Check the ARI
 
-@uref{http://sources.redhat.com/gdb/ari,,A.R.I.} is an @code{awk} script
+@uref{http://sourceware.org/gdb/ari,,A.R.I.} is an @code{awk} script
 (Awk Regression Index ;-) that checks for a number of errors and coding
 conventions.  The checks include things like using @code{malloc} instead
 of @code{xmalloc} and file naming problems.  There shouldn't be any
@@ -6968,15 +6908,15 @@ $  V=`echo $v | sed 's/\./_/g'`
 $  D=`date -u +%Y-%m-%d`
 $  echo $u $V $D
 5.1 5_2 2002-03-03
-$  echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
+$  echo cvs -f -d :ext:sourceware.org:/cvs/src rtag \
 -D $D-gmt gdb_$V-$D-branchpoint insight
-cvs -f -d :ext:sources.redhat.com:/cvs/src rtag
+cvs -f -d :ext:sourceware.org:/cvs/src rtag
 -D 2002-03-03-gmt gdb_5_2-2002-03-03-branchpoint insight
 $  ^echo ^^
 ...
-$  echo cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
+$  echo cvs -f -d :ext:sourceware.org:/cvs/src rtag \
 -b -r gdb_$V-$D-branchpoint gdb_$V-branch insight
-cvs -f -d :ext:sources.redhat.com:/cvs/src rtag \
+cvs -f -d :ext:sourceware.org:/cvs/src rtag \
 -b -r gdb_5_2-2002-03-03-branchpoint gdb_5_2-branch insight
 $  ^echo ^^
 ...
@@ -7006,9 +6946,9 @@ $  V=`echo $v | sed 's/\./_/g'`
 $  echo $u $v$V
 5.1 5_2
 $  cd /tmp
-$  echo cvs -f -d :ext:sources.redhat.com:/cvs/src co \
+$  echo cvs -f -d :ext:sourceware.org:/cvs/src co \
 -r gdb_$V-branch src/gdb/version.in
-cvs -f -d :ext:sources.redhat.com:/cvs/src co
+cvs -f -d :ext:sourceware.org:/cvs/src co
  -r gdb_5_2-branch src/gdb/version.in
 $  ^echo ^^
 U src/gdb/version.in
@@ -7069,10 +7009,10 @@ Send an announcement to the mailing lists:
 
 @itemize @bullet
 @item
-@email{gdb-announce@@sources.redhat.com, GDB Announcement mailing list}
+@email{gdb-announce@@sourceware.org, GDB Announcement mailing list}
 @item
-@email{gdb@@sources.redhat.com, GDB Discussion mailing list} and
-@email{gdb-testers@@sources.redhat.com, GDB Testers mailing list}
+@email{gdb@@sourceware.org, GDB Discussion mailing list} and
+@email{gdb-testers@@sourceware.org, GDB Testers mailing list}
 @end itemize
 
 @emph{Pragmatics: The branch creation is sent to the announce list to
@@ -7114,7 +7054,7 @@ candidate).
 @subsubheading Freeze the branch
 
 Send out an e-mail notifying everyone that the branch is frozen to
-@email{gdb-patches@@sources.redhat.com}.
+@email{gdb-patches@@sourceware.org}.
 
 @subsubheading Establish a few defaults.
 
@@ -7139,10 +7079,9 @@ Notes:
 @itemize @bullet
 @item
 Check the @code{autoconf} version carefully.  You want to be using the
-version taken from the @file{binutils} snapshot directory, which can be
-found at @uref{ftp://sources.redhat.com/pub/binutils/}.  It is very
-unlikely that a system installed version of @code{autoconf} (e.g.,
-@file{/usr/bin/autoconf}) is correct.
+version documented in the toplevel @file{README-maintainer-mode} file.
+It is very unlikely that the version of @code{autoconf} installed in
+system directories (e.g., @file{/usr/bin/autoconf}) is correct.
 @end itemize
 
 @subsubheading Check out the relevant modules:
@@ -7345,10 +7284,10 @@ Tweak @file{version.in} (and @file{ChangeLog} to read
 process can restart.
 @item
 Make the release candidate available in
-@uref{ftp://sources.redhat.com/pub/gdb/snapshots/branch}
+@uref{ftp://sourceware.org/pub/gdb/snapshots/branch}
 @item
-Notify the relevant mailing lists ( @email{gdb@@sources.redhat.com} and
-@email{gdb-testers@@sources.redhat.com} that the candidate is available.
+Notify the relevant mailing lists ( @email{gdb@@sourceware.org} and
+@email{gdb-testers@@sourceware.org} that the candidate is available.
 @end enumerate
 
 @subsection Make a formal release available
@@ -7455,7 +7394,7 @@ Post the @file{ANNOUNCEMENT} file you created above to:
 
 @itemize @bullet
 @item
-@email{gdb-announce@@sources.redhat.com, GDB Announcement mailing list}
+@email{gdb-announce@@sourceware.org, GDB Announcement mailing list}
 @item
 @email{info-gnu@@gnu.org, General GNU Announcement list} (but delay it a
 day or so to let things get out)
@@ -7519,7 +7458,7 @@ trunk.
 
 @subsubheading Revise the release schedule
 
-Post a revised release schedule to @email{gdb@@sources.redhat.com, GDB
+Post a revised release schedule to @email{gdb@@sourceware.org, GDB
 Discussion List} with an updated announcement.  The schedule can be
 generated by running:
 
@@ -7580,6 +7519,16 @@ make check RUNTESTFLAGS='@var{tests}'
 where @var{tests} is a list of test script file names, separated by
 spaces.
 
+If you use GNU make, you can use its @option{-j} option to run the
+testsuite in parallel.  This can greatly reduce the amount of time it
+takes for the testsuite to run.  In this case, if you set
+@code{RUNTESTFLAGS} then, by default, the tests will be run serially
+even under @option{-j}.  You can override this and force a parallel run
+by setting the @code{make} variable @code{FORCE_PARALLEL} to any
+non-empty value.  Note that the parallel @kbd{make check} assumes
+that you want to run the entire testsuite, so it is not compatible
+with some dejagnu options, like @option{--directory}.
+
 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 @value{GDBN} or in the testsuite.  Expected
@@ -7621,6 +7570,27 @@ will give a result of ``UNRESOLVED'', like this:
 UNRESOLVED: gdb.base/example.exp: This test script does not work on a remote host.
 @end smallexample
 
+Sometimes it is convenient to get a transcript of the commands which
+the testsuite sends to @value{GDBN}.  For example, if @value{GDBN}
+crashes during testing, a transcript can be used to more easily
+reconstruct the failure when running @value{GDBN} under @value{GDBN}.
+
+You can instruct the @value{GDBN} testsuite to write transcripts by
+setting the DejaGNU variable @code{TRANSCRIPT} (to any value)
+before invoking @code{runtest} or @kbd{make check}.  The transcripts
+will be written into DejaGNU's output directory.  One transcript will
+be made for each invocation of @value{GDBN}; they will be named
+@file{transcript.@var{n}}, where @var{n} is an integer.  The first
+line of the transcript file will show how @value{GDBN} was invoked;
+each subsequent line is a command sent as input to @value{GDBN}.
+
+@smallexample
+make check RUNTESTFLAGS=TRANSCRIPT=y
+@end smallexample
+
+Note that the transcript is not always complete.  In particular, tests
+of completion can yield partial command lines.
+
 @section Testsuite Organization
 
 @cindex test suite organization
@@ -7889,7 +7859,7 @@ permits, which, since the maintainers have many demands to meet, may not
 be for quite some time.
 
 Please send patches directly to
-@email{gdb-patches@@sources.redhat.com, the @value{GDBN} maintainers}.
+@email{gdb-patches@@sourceware.org, the @value{GDBN} maintainers}.
 
 @section Build Script
 
This page took 0.030797 seconds and 4 git commands to generate.