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
@{
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 */
* Register Representation::
* Frame Interpretation::
* Inferior Call Setup::
+* Adding support for debugging core files::
* Defining Other Architecture Features::
* Adding a New Target::
@end menu
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.
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.
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
@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
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
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
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
@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.
@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.
@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
$ 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 ^^
...
$ 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
@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
@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.
@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
+found at @uref{ftp://sourceware.org/pub/binutils/}. It is very
unlikely that a system installed version of @code{autoconf} (e.g.,
@file{/usr/bin/autoconf}) is correct.
@end itemize
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
@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)
@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:
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
projects / deliverable / binutils-gdb.git / blobdiff