gdb: Remove ~2Mb of doc files from contrib (texi)
authorJohn Marino <draco@marino.st>
Fri, 3 Apr 2015 10:56:33 +0000 (12:56 +0200)
committerJohn Marino <draco@marino.st>
Fri, 3 Apr 2015 11:56:43 +0000 (13:56 +0200)
These texi files are no longer used in the build and they've got
equivalent man pages in most cases.

12 files changed:
contrib/gdb-7/README.DELETED
contrib/gdb-7/gdb/doc/LRS [deleted file]
contrib/gdb-7/gdb/doc/a4rc.sed [deleted file]
contrib/gdb-7/gdb/doc/agentexpr.texi [deleted file]
contrib/gdb-7/gdb/doc/all-cfg.texi [deleted file]
contrib/gdb-7/gdb/doc/annotate.texinfo [deleted file]
contrib/gdb-7/gdb/doc/fdl.texi [deleted file]
contrib/gdb-7/gdb/doc/gdb.texinfo [deleted file]
contrib/gdb-7/gdb/doc/gdbint.texinfo [deleted file]
contrib/gdb-7/gdb/doc/gpl.texi [deleted file]
contrib/gdb-7/gdb/doc/stabs.texinfo [deleted file]
contrib/gdb-7/gdb/doc/stack_frame.txt [deleted file]

index 3d28cb1..938e96a 100644 (file)
@@ -450,8 +450,8 @@ gdb/aarch64-tdep.c
 gdb/aarch64-tdep.h
 gdb/acinclude.m4
 gdb/aclocal.m4
-gdb/ada-lex.l
 gdb/acx_configure_dir.m4
+gdb/ada-lex.l
 gdb/aix-thread.c
 gdb/alpha-linux-nat.c
 gdb/alpha-linux-tdep.c
@@ -551,8 +551,14 @@ gdb/dicos-tdep.c
 gdb/dicos-tdep.h
 gdb/dink32-rom.c
 gdb/doc/ChangeLog
+gdb/doc/LRS
 gdb/doc/Makefile.in
+gdb/doc/a4rc.sed
+gdb/doc/agentexpr.texi
+gdb/doc/all-cfg.texi
 gdb/doc/annotate.info
+gdb/doc/annotate.texinfo
+gdb/doc/fdl.texi
 gdb/doc/gdb.info
 gdb/doc/gdb.info-1
 gdb/doc/gdb.info-2
@@ -561,17 +567,22 @@ gdb/doc/gdb.info-4
 gdb/doc/gdb.info-5
 gdb/doc/gdb.info-6
 gdb/doc/gdb.info-7
+gdb/doc/gdb.texinfo
 gdb/doc/gdbint.info
 gdb/doc/gdbint.info-1
 gdb/doc/gdbint.info-2
+gdb/doc/gdbint.texinfo
+gdb/doc/gpl.texi
 gdb/doc/lpsrc.sed
 gdb/doc/psrc.sed
 gdb/doc/refcard.tex
 gdb/doc/stabs.info
+gdb/doc/stabs.texinfo
 gdb/doc/stack_frame.eps
 gdb/doc/stack_frame.pdf
 gdb/doc/stack_frame.png
 gdb/doc/stack_frame.svg
+gdb/doc/stack_frame.txt
 gdb/dsrec.c
 gdb/exc_request.defs
 gdb/f-exp.c
diff --git a/contrib/gdb-7/gdb/doc/LRS b/contrib/gdb-7/gdb/doc/LRS
deleted file mode 100644 (file)
index 7e25d43..0000000
+++ /dev/null
@@ -1,197 +0,0 @@
-What's LRS?
-===========
-
-LRS, or Live Range Splitting is an optimization technique which allows
-a user variable to reside in different locations during different parts
-of a function.
-
-For example, a variable might reside in the stack for part of a function
-and in a register during a loop and in a different register during
-another loop.
-
-Clearly, if a variable may reside in different locations, then the
-compiler must describe to the debugger where the variable resides for
-any given part of the function.
-
-This document describes the debug format for encoding these extensions
-in stabs.
-
-Since these extensions are gcc specific, these additional symbols and
-stabs can be disabled by the gcc command option -gstabs.
-
-
-GNU extensions for LRS under stabs:
-===================================
-
-
-range symbols:
--------------
-
-    A range symbol will be used to mark the beginning or end of a
-    live range (the range which describes where a symbol is active,
-    or live).  These symbols will later be referenced in the stabs for
-    debug purposes.  For simplicity, we'll use the terms "range_start"
-    and "range_end" to identify the range symbols which mark the beginning
-    and end of a live range respectively.
-
-    Any text symbol which would normally appear in the symbol table
-    (eg. a function name) can be used as range symbol.  If an address
-    is needed to delimit a live range and does not match any of the
-    values of symbols which would normally appear in the symbol table,
-    a new symbol will be added to the table whose value is that address.
-
-    The three new symbol types described below have been added for this 
-    purpose.
-
-    For efficiency, the compiler should use existing symbols as range
-    symbols whenever possible; this reduces the number of additional
-    symbols which need to be added to the symbol table.
-
-    
-New debug symbol type for defining ranges:
-------------------------------------------
-
-    range_off - contains PC function offset for start/end of a live range.
-               Its location is relative to the function start and therefore 
-               eliminates the need for additional relocation.
-
-    This symbol has a values in the text section, and does not have a name.
-
-           NOTE: the following may not be needed but are included here just 
-               in case.
-           range - contains PC value of beginning or end of a live range
-               (relocs required).
-
-           NOTE: the following will be required if we desire LRS debugging
-               to work with old style a.out stabs.
-           range_abs - contains absolute PC value of start/end of a live 
-               range.  The range_abs debug symbol is provided for 
-               completeness, in case there is a need to describe addresses 
-               in ROM, etc.
-
-
-Live range:
------------
-
-    The compiler and debugger view a variable with multiple homes as
-    a primary symbol and aliases for that symbol.  The primary symbol
-    describes the default home of the variable while aliases describe
-    alternate homes for the variable.
-
-    A live range defines the interval of instructions beginning with
-    range_start and ending at range_end-1, and is used to specify a
-    range of instructions where an alias is active or "live".  So,
-    the actual end of the range will be one less than the value of the
-    range_end symbol.
-
-    Ranges do not have to be nested. Eg. Two ranges may intersect while 
-        each range contains subranges which are not in the other range.
-
-    There does not have to be a 1-1 mapping from range_start to
-        range_end symbols.  Eg. Two range_starts can share the same 
-        range_end, while one symbol's range_start can be another symbol's
-        range_end.
-
-    When a variable's storage class changes (eg. from stack to register,
-       or from one register to another), a new symbol entry will be
-       added to the symbol table with stabs describing the new type,
-       and appropriate live ranges refering to the variable's initial
-       symbol index.
-
-    For variables which are defined in the source but optimized away,
-        a symbol should be emitted with the live range l(0,0).
-
-    Live ranges for aliases of a particular variable should always
-       be disjoint.  Overlapping ranges for aliases of the same variable
-       will be treated as an error by the debugger, and the overlapping
-       range will be ignored.
-
-    If no live range information is given, the live range will be assumed to 
-       span the symbol's entire lexical scope.
-
-
-New stabs string identifiers:
------------------------------
-
-  "id" in "#id" in the following section refers to a numeric value.
-
-  New stab syntax for live range:  l(<ref_from>,<ref_to>) 
-
-    <ref_from> - "#id" where #id identifies the text symbol (range symbol) to
-               use as the start of live range (range_start).  The value for 
-               the referenced text symbol is the starting address of the 
-               live range.
-
-    <ref_to> - "#id" where #id identifies the text symbol (range symbol) to
-               use as the end of live range (range_end).  The value for 
-               the referenced text symbol is ONE BYTE PAST the ending 
-               address of the live range.
-
-
-  New stab syntax for identifying symbols.
-
-    <def> - "#id="
-
-           Uses:
-             <def><name>:<typedef1>...
-                 When used in front of a symbol name, "#id=" defines a
-                 unique reference number for this symbol.  The reference
-                 number can be used later when defining aliases for this
-                 symbol.
-             <def>
-                 When used as the entire stab string, "#id=" identifies this 
-                 nameless symbol as being the symbol for which "#id" refers to.
-
-
-    <ref> - "#id" where "#id" refers to the symbol for which the string 
-               "#id=" identifies.
-           Uses:
-             <ref>:<typedef2>;<liverange>;<liverange>...
-                 Defines an alias for the symbol identified by the reference
-                 number ID.
-             l(<ref1>,<ref2>)
-                 When used within a live range, "#id" refers to the text 
-                 symbol identified by "#id=" to use as the range symbol.
-
-    <liverange> - "l(<ref_from>,<ref_to>)" - specifies a live range for a 
-               symbol.  Multiple "l" specifiers can be combined to represent 
-               mutiple live ranges, separated by semicolons.
-
-
-
-
-Example:
-========
-
-Consider a program of the form:
-
-    void foo(){
-      int a = ...;
-      ...
-      while (b--)
-       c += a;
-      ..
-      d = a;
-      ..
-    }
-
-Assume that "a" lives in the stack at offset -8, except for inside the
-loop where "a" resides in register "r5".
-
-The way to describe this is to create a stab for the variable "a" which
-describes "a" as living in the stack and an alias for the variable "a"
-which describes it as living in register "r5" in the loop.
-
-Let's assume that "#1" and "#2" are symbols which bound the area where
-"a" lives in a register.
-
-The stabs to describe "a" and its alias would look like this:
-
-        .stabs "#3=a:1",128,0,8,-8
-        .stabs "#3:r1;l(#1,#2)",64,0,0,5
-
-
-This design implies that the debugger will keep a chain of aliases for
-any given variable with aliases and that chain will be searched first
-to find out if an alias is active.  If no alias is active, then the
-debugger will assume that the main variable is active.
diff --git a/contrib/gdb-7/gdb/doc/a4rc.sed b/contrib/gdb-7/gdb/doc/a4rc.sed
deleted file mode 100644 (file)
index 2292290..0000000
+++ /dev/null
@@ -1,11 +0,0 @@
-/--- Papersize params:/,/--- end papersize params/c\
-%------- Papersize params:\
-%%  A4 paper (297x210mm)\
-%%\
-\\totalwidth=297mm   % total width of paper\
-\\totalheight=210mm  % total height of paper\
-\\hmargin=5mm        % horizontal margin width\
-\\vmargin=10mm       % vertical margin width\
-\\secskip=.6pc       % space between refcard secs\
-\\lskip=1pt          % extra skip between \\sec entries\
-%------- end papersize params
diff --git a/contrib/gdb-7/gdb/doc/agentexpr.texi b/contrib/gdb-7/gdb/doc/agentexpr.texi
deleted file mode 100644 (file)
index ab243cc..0000000
+++ /dev/null
@@ -1,767 +0,0 @@
-@c \input texinfo
-@c %**start of header
-@c @setfilename agentexpr.info
-@c @settitle GDB Agent Expressions
-@c @setchapternewpage off
-@c %**end of header
-
-@c This file is part of the GDB manual.
-@c
-@c Copyright (C) 2003-2013 Free Software Foundation, Inc.
-@c
-@c See the file gdb.texinfo for copying conditions.
-
-@node Agent Expressions
-@appendix The GDB Agent Expression Mechanism
-
-In some applications, it is not feasible for the debugger to interrupt
-the program's execution long enough for the developer to learn anything
-helpful about its behavior.  If the program's correctness depends on its
-real-time behavior, delays introduced by a debugger might cause the
-program to fail, even when the code itself is correct.  It is useful to
-be able to observe the program's behavior without interrupting it.
-
-Using GDB's @code{trace} and @code{collect} commands, the user can
-specify locations in the program, and arbitrary expressions to evaluate
-when those locations are reached.  Later, using the @code{tfind}
-command, she can examine the values those expressions had when the
-program hit the trace points.  The expressions may also denote objects
-in memory --- structures or arrays, for example --- whose values GDB
-should record; while visiting a particular tracepoint, the user may
-inspect those objects as if they were in memory at that moment.
-However, because GDB records these values without interacting with the
-user, it can do so quickly and unobtrusively, hopefully not disturbing
-the program's behavior.
-
-When GDB is debugging a remote target, the GDB @dfn{agent} code running
-on the target computes the values of the expressions itself.  To avoid
-having a full symbolic expression evaluator on the agent, GDB translates
-expressions in the source language into a simpler bytecode language, and
-then sends the bytecode to the agent; the agent then executes the
-bytecode, and records the values for GDB to retrieve later.
-
-The bytecode language is simple; there are forty-odd opcodes, the bulk
-of which are the usual vocabulary of C operands (addition, subtraction,
-shifts, and so on) and various sizes of literals and memory reference
-operations.  The bytecode interpreter operates strictly on machine-level
-values --- various sizes of integers and floating point numbers --- and
-requires no information about types or symbols; thus, the interpreter's
-internal data structures are simple, and each bytecode requires only a
-few native machine instructions to implement it.  The interpreter is
-small, and strict limits on the memory and time required to evaluate an
-expression are easy to determine, making it suitable for use by the
-debugging agent in real-time applications.
-
-@menu
-* General Bytecode Design::     Overview of the interpreter.
-* Bytecode Descriptions::       What each one does.
-* Using Agent Expressions::     How agent expressions fit into the big picture.
-* Varying Target Capabilities:: How to discover what the target can do.
-* Rationale::                   Why we did it this way.
-@end menu
-
-
-@c @node Rationale
-@c @section Rationale
-
-
-@node General Bytecode Design
-@section General Bytecode Design
-
-The agent represents bytecode expressions as an array of bytes.  Each
-instruction is one byte long (thus the term @dfn{bytecode}).  Some
-instructions are followed by operand bytes; for example, the @code{goto}
-instruction is followed by a destination for the jump.
-
-The bytecode interpreter is a stack-based machine; most instructions pop
-their operands off the stack, perform some operation, and push the
-result back on the stack for the next instruction to consume.  Each
-element of the stack may contain either a integer or a floating point
-value; these values are as many bits wide as the largest integer that
-can be directly manipulated in the source language.  Stack elements
-carry no record of their type; bytecode could push a value as an
-integer, then pop it as a floating point value.  However, GDB will not
-generate code which does this.  In C, one might define the type of a
-stack element as follows:
-@example
-union agent_val @{
-  LONGEST l;
-  DOUBLEST d;
-@};
-@end example
-@noindent
-where @code{LONGEST} and @code{DOUBLEST} are @code{typedef} names for
-the largest integer and floating point types on the machine.
-
-By the time the bytecode interpreter reaches the end of the expression,
-the value of the expression should be the only value left on the stack.
-For tracing applications, @code{trace} bytecodes in the expression will
-have recorded the necessary data, and the value on the stack may be
-discarded.  For other applications, like conditional breakpoints, the
-value may be useful.
-
-Separate from the stack, the interpreter has two registers:
-@table @code
-@item pc
-The address of the next bytecode to execute.
-
-@item start
-The address of the start of the bytecode expression, necessary for
-interpreting the @code{goto} and @code{if_goto} instructions.
-
-@end table
-@noindent
-Neither of these registers is directly visible to the bytecode language
-itself, but they are useful for defining the meanings of the bytecode
-operations.
-
-There are no instructions to perform side effects on the running
-program, or call the program's functions; we assume that these
-expressions are only used for unobtrusive debugging, not for patching
-the running code.  
-
-Most bytecode instructions do not distinguish between the various sizes
-of values, and operate on full-width values; the upper bits of the
-values are simply ignored, since they do not usually make a difference
-to the value computed.  The exceptions to this rule are:
-@table @asis
-
-@item memory reference instructions (@code{ref}@var{n})
-There are distinct instructions to fetch different word sizes from
-memory.  Once on the stack, however, the values are treated as full-size
-integers.  They may need to be sign-extended; the @code{ext} instruction
-exists for this purpose.
-
-@item the sign-extension instruction (@code{ext} @var{n})
-These clearly need to know which portion of their operand is to be
-extended to occupy the full length of the word.
-
-@end table
-
-If the interpreter is unable to evaluate an expression completely for
-some reason (a memory location is inaccessible, or a divisor is zero,
-for example), we say that interpretation ``terminates with an error''.
-This means that the problem is reported back to the interpreter's caller
-in some helpful way.  In general, code using agent expressions should
-assume that they may attempt to divide by zero, fetch arbitrary memory
-locations, and misbehave in other ways.
-
-Even complicated C expressions compile to a few bytecode instructions;
-for example, the expression @code{x + y * z} would typically produce
-code like the following, assuming that @code{x} and @code{y} live in
-registers, and @code{z} is a global variable holding a 32-bit
-@code{int}:
-@example
-reg 1
-reg 2
-const32 @i{address of z}
-ref32
-ext 32
-mul
-add
-end
-@end example
-
-In detail, these mean:
-@table @code
-
-@item reg 1
-Push the value of register 1 (presumably holding @code{x}) onto the
-stack.
-
-@item reg 2
-Push the value of register 2 (holding @code{y}).
-
-@item const32 @i{address of z}
-Push the address of @code{z} onto the stack.
-
-@item ref32
-Fetch a 32-bit word from the address at the top of the stack; replace
-the address on the stack with the value.  Thus, we replace the address
-of @code{z} with @code{z}'s value.
-
-@item ext 32
-Sign-extend the value on the top of the stack from 32 bits to full
-length.  This is necessary because @code{z} is a signed integer.
-
-@item mul
-Pop the top two numbers on the stack, multiply them, and push their
-product.  Now the top of the stack contains the value of the expression
-@code{y * z}.
-
-@item add
-Pop the top two numbers, add them, and push the sum.  Now the top of the
-stack contains the value of @code{x + y * z}.
-
-@item end
-Stop executing; the value left on the stack top is the value to be
-recorded.
-
-@end table
-
-
-@node Bytecode Descriptions
-@section Bytecode Descriptions
-
-Each bytecode description has the following form:
-
-@table @asis
-
-@item @code{add} (0x02): @var{a} @var{b} @result{} @var{a+b}
-
-Pop the top two stack items, @var{a} and @var{b}, as integers; push
-their sum, as an integer.
-
-@end table
-
-In this example, @code{add} is the name of the bytecode, and
-@code{(0x02)} is the one-byte value used to encode the bytecode, in
-hexadecimal.  The phrase ``@var{a} @var{b} @result{} @var{a+b}'' shows
-the stack before and after the bytecode executes.  Beforehand, the stack
-must contain at least two values, @var{a} and @var{b}; since the top of
-the stack is to the right, @var{b} is on the top of the stack, and
-@var{a} is underneath it.  After execution, the bytecode will have
-popped @var{a} and @var{b} from the stack, and replaced them with a
-single value, @var{a+b}.  There may be other values on the stack below
-those shown, but the bytecode affects only those shown.
-
-Here is another example:
-
-@table @asis
-
-@item @code{const8} (0x22) @var{n}: @result{} @var{n}
-Push the 8-bit integer constant @var{n} on the stack, without sign
-extension.
-
-@end table
-
-In this example, the bytecode @code{const8} takes an operand @var{n}
-directly from the bytecode stream; the operand follows the @code{const8}
-bytecode itself.  We write any such operands immediately after the name
-of the bytecode, before the colon, and describe the exact encoding of
-the operand in the bytecode stream in the body of the bytecode
-description.
-
-For the @code{const8} bytecode, there are no stack items given before
-the @result{}; this simply means that the bytecode consumes no values
-from the stack.  If a bytecode consumes no values, or produces no
-values, the list on either side of the @result{} may be empty.
-
-If a value is written as @var{a}, @var{b}, or @var{n}, then the bytecode
-treats it as an integer.  If a value is written is @var{addr}, then the
-bytecode treats it as an address.
-
-We do not fully describe the floating point operations here; although
-this design can be extended in a clean way to handle floating point
-values, they are not of immediate interest to the customer, so we avoid
-describing them, to save time.
-
-
-@table @asis
-
-@item @code{float} (0x01): @result{}
-
-Prefix for floating-point bytecodes.  Not implemented yet.
-
-@item @code{add} (0x02): @var{a} @var{b} @result{} @var{a+b}
-Pop two integers from the stack, and push their sum, as an integer.
-
-@item @code{sub} (0x03): @var{a} @var{b} @result{} @var{a-b}
-Pop two integers from the stack, subtract the top value from the
-next-to-top value, and push the difference.
-
-@item @code{mul} (0x04): @var{a} @var{b} @result{} @var{a*b}
-Pop two integers from the stack, multiply them, and push the product on
-the stack.  Note that, when one multiplies two @var{n}-bit numbers
-yielding another @var{n}-bit number, it is irrelevant whether the
-numbers are signed or not; the results are the same.
-
-@item @code{div_signed} (0x05): @var{a} @var{b} @result{} @var{a/b}
-Pop two signed integers from the stack; divide the next-to-top value by
-the top value, and push the quotient.  If the divisor is zero, terminate
-with an error.
-
-@item @code{div_unsigned} (0x06): @var{a} @var{b} @result{} @var{a/b}
-Pop two unsigned integers from the stack; divide the next-to-top value
-by the top value, and push the quotient.  If the divisor is zero,
-terminate with an error.
-
-@item @code{rem_signed} (0x07): @var{a} @var{b} @result{} @var{a modulo b}
-Pop two signed integers from the stack; divide the next-to-top value by
-the top value, and push the remainder.  If the divisor is zero,
-terminate with an error.
-
-@item @code{rem_unsigned} (0x08): @var{a} @var{b} @result{} @var{a modulo b}
-Pop two unsigned integers from the stack; divide the next-to-top value
-by the top value, and push the remainder.  If the divisor is zero,
-terminate with an error.
-
-@item @code{lsh} (0x09): @var{a} @var{b} @result{} @var{a<<b}
-Pop two integers from the stack; let @var{a} be the next-to-top value,
-and @var{b} be the top value.  Shift @var{a} left by @var{b} bits, and
-push the result.
-
-@item @code{rsh_signed} (0x0a): @var{a} @var{b} @result{} @code{(signed)}@var{a>>b}
-Pop two integers from the stack; let @var{a} be the next-to-top value,
-and @var{b} be the top value.  Shift @var{a} right by @var{b} bits,
-inserting copies of the top bit at the high end, and push the result.
-
-@item @code{rsh_unsigned} (0x0b): @var{a} @var{b} @result{} @var{a>>b}
-Pop two integers from the stack; let @var{a} be the next-to-top value,
-and @var{b} be the top value.  Shift @var{a} right by @var{b} bits,
-inserting zero bits at the high end, and push the result.
-
-@item @code{log_not} (0x0e): @var{a} @result{} @var{!a}
-Pop an integer from the stack; if it is zero, push the value one;
-otherwise, push the value zero.
-
-@item @code{bit_and} (0x0f): @var{a} @var{b} @result{} @var{a&b}
-Pop two integers from the stack, and push their bitwise @code{and}.
-
-@item @code{bit_or} (0x10): @var{a} @var{b} @result{} @var{a|b}
-Pop two integers from the stack, and push their bitwise @code{or}.
-
-@item @code{bit_xor} (0x11): @var{a} @var{b} @result{} @var{a^b}
-Pop two integers from the stack, and push their bitwise
-exclusive-@code{or}.
-
-@item @code{bit_not} (0x12): @var{a} @result{} @var{~a}
-Pop an integer from the stack, and push its bitwise complement.
-
-@item @code{equal} (0x13): @var{a} @var{b} @result{} @var{a=b}
-Pop two integers from the stack; if they are equal, push the value one;
-otherwise, push the value zero.
-
-@item @code{less_signed} (0x14): @var{a} @var{b} @result{} @var{a<b}
-Pop two signed integers from the stack; if the next-to-top value is less
-than the top value, push the value one; otherwise, push the value zero.
-
-@item @code{less_unsigned} (0x15): @var{a} @var{b} @result{} @var{a<b}
-Pop two unsigned integers from the stack; if the next-to-top value is less
-than the top value, push the value one; otherwise, push the value zero.
-
-@item @code{ext} (0x16) @var{n}: @var{a} @result{} @var{a}, sign-extended from @var{n} bits
-Pop an unsigned value from the stack; treating it as an @var{n}-bit
-twos-complement value, extend it to full length.  This means that all
-bits to the left of bit @var{n-1} (where the least significant bit is bit
-0) are set to the value of bit @var{n-1}.  Note that @var{n} may be
-larger than or equal to the width of the stack elements of the bytecode
-engine; in this case, the bytecode should have no effect.
-
-The number of source bits to preserve, @var{n}, is encoded as a single
-byte unsigned integer following the @code{ext} bytecode.
-
-@item @code{zero_ext} (0x2a) @var{n}: @var{a} @result{} @var{a}, zero-extended from @var{n} bits
-Pop an unsigned value from the stack; zero all but the bottom @var{n}
-bits.  This means that all bits to the left of bit @var{n-1} (where the
-least significant bit is bit 0) are set to the value of bit @var{n-1}.
-
-The number of source bits to preserve, @var{n}, is encoded as a single
-byte unsigned integer following the @code{zero_ext} bytecode.
-
-@item @code{ref8} (0x17): @var{addr} @result{} @var{a}
-@itemx @code{ref16} (0x18): @var{addr} @result{} @var{a}
-@itemx @code{ref32} (0x19): @var{addr} @result{} @var{a}
-@itemx @code{ref64} (0x1a): @var{addr} @result{} @var{a}
-Pop an address @var{addr} from the stack.  For bytecode
-@code{ref}@var{n}, fetch an @var{n}-bit value from @var{addr}, using the
-natural target endianness.  Push the fetched value as an unsigned
-integer.
-
-Note that @var{addr} may not be aligned in any particular way; the
-@code{ref@var{n}} bytecodes should operate correctly for any address.
-
-If attempting to access memory at @var{addr} would cause a processor
-exception of some sort, terminate with an error.
-
-@item @code{ref_float} (0x1b): @var{addr} @result{} @var{d}
-@itemx @code{ref_double} (0x1c): @var{addr} @result{} @var{d}
-@itemx @code{ref_long_double} (0x1d): @var{addr} @result{} @var{d}
-@itemx @code{l_to_d} (0x1e): @var{a} @result{} @var{d}
-@itemx @code{d_to_l} (0x1f): @var{d} @result{} @var{a}
-Not implemented yet.
-
-@item @code{dup} (0x28): @var{a} => @var{a} @var{a}
-Push another copy of the stack's top element.
-
-@item @code{swap} (0x2b): @var{a} @var{b} => @var{b} @var{a}
-Exchange the top two items on the stack.
-
-@item @code{pop} (0x29): @var{a} =>
-Discard the top value on the stack.
-
-@item @code{pick} (0x32) @var{n}: @var{a} @dots{} @var{b} => @var{a} @dots{} @var{b} @var{a}
-Duplicate an item from the stack and push it on the top of the stack.
-@var{n}, a single byte, indicates the stack item to copy.  If @var{n}
-is zero, this is the same as @code{dup}; if @var{n} is one, it copies
-the item under the top item, etc.  If @var{n} exceeds the number of
-items on the stack, terminate with an error.
-
-@item @code{rot} (0x33): @var{a} @var{b} @var{c} => @var{c} @var{b} @var{a}
-Rotate the top three items on the stack.
-
-@item @code{if_goto} (0x20) @var{offset}: @var{a} @result{}
-Pop an integer off the stack; if it is non-zero, branch to the given
-offset in the bytecode string.  Otherwise, continue to the next
-instruction in the bytecode stream.  In other words, if @var{a} is
-non-zero, set the @code{pc} register to @code{start} + @var{offset}.
-Thus, an offset of zero denotes the beginning of the expression.
-
-The @var{offset} is stored as a sixteen-bit unsigned value, stored
-immediately following the @code{if_goto} bytecode.  It is always stored
-most significant byte first, regardless of the target's normal
-endianness.  The offset is not guaranteed to fall at any particular
-alignment within the bytecode stream; thus, on machines where fetching a
-16-bit on an unaligned address raises an exception, you should fetch the
-offset one byte at a time.
-
-@item @code{goto} (0x21) @var{offset}: @result{}
-Branch unconditionally to @var{offset}; in other words, set the
-@code{pc} register to @code{start} + @var{offset}.
-
-The offset is stored in the same way as for the @code{if_goto} bytecode.
-
-@item @code{const8} (0x22) @var{n}: @result{} @var{n}
-@itemx @code{const16} (0x23) @var{n}: @result{} @var{n}
-@itemx @code{const32} (0x24) @var{n}: @result{} @var{n}
-@itemx @code{const64} (0x25) @var{n}: @result{} @var{n}
-Push the integer constant @var{n} on the stack, without sign extension.
-To produce a small negative value, push a small twos-complement value,
-and then sign-extend it using the @code{ext} bytecode.
-
-The constant @var{n} is stored in the appropriate number of bytes
-following the @code{const}@var{b} bytecode.  The constant @var{n} is
-always stored most significant byte first, regardless of the target's
-normal endianness.  The constant is not guaranteed to fall at any
-particular alignment within the bytecode stream; thus, on machines where
-fetching a 16-bit on an unaligned address raises an exception, you
-should fetch @var{n} one byte at a time.
-
-@item @code{reg} (0x26) @var{n}: @result{} @var{a}
-Push the value of register number @var{n}, without sign extension.  The
-registers are numbered following GDB's conventions.
-
-The register number @var{n} is encoded as a 16-bit unsigned integer
-immediately following the @code{reg} bytecode.  It is always stored most
-significant byte first, regardless of the target's normal endianness.
-The register number is not guaranteed to fall at any particular
-alignment within the bytecode stream; thus, on machines where fetching a
-16-bit on an unaligned address raises an exception, you should fetch the
-register number one byte at a time.
-
-@item @code{getv} (0x2c) @var{n}: @result{} @var{v}
-Push the value of trace state variable number @var{n}, without sign
-extension.
-
-The variable number @var{n} is encoded as a 16-bit unsigned integer
-immediately following the @code{getv} bytecode.  It is always stored most
-significant byte first, regardless of the target's normal endianness.
-The variable number is not guaranteed to fall at any particular
-alignment within the bytecode stream; thus, on machines where fetching a
-16-bit on an unaligned address raises an exception, you should fetch the
-register number one byte at a time.
-
-@item @code{setv} (0x2d) @var{n}: @result{} @var{v}
-Set trace state variable number @var{n} to the value found on the top
-of the stack.  The stack is unchanged, so that the value is readily
-available if the assignment is part of a larger expression.  The
-handling of @var{n} is as described for @code{getv}.
-
-@item @code{trace} (0x0c): @var{addr} @var{size} @result{}
-Record the contents of the @var{size} bytes at @var{addr} in a trace
-buffer, for later retrieval by GDB.
-
-@item @code{trace_quick} (0x0d) @var{size}: @var{addr} @result{} @var{addr}
-Record the contents of the @var{size} bytes at @var{addr} in a trace
-buffer, for later retrieval by GDB.  @var{size} is a single byte
-unsigned integer following the @code{trace} opcode.
-
-This bytecode is equivalent to the sequence @code{dup const8 @var{size}
-trace}, but we provide it anyway to save space in bytecode strings.
-
-@item @code{trace16} (0x30) @var{size}: @var{addr} @result{} @var{addr}
-Identical to trace_quick, except that @var{size} is a 16-bit big-endian
-unsigned integer, not a single byte.  This should probably have been
-named @code{trace_quick16}, for consistency.
-
-@item @code{tracev} (0x2e) @var{n}: @result{} @var{a}
-Record the value of trace state variable number @var{n} in the trace
-buffer.  The handling of @var{n} is as described for @code{getv}.
-
-@item @code{tracenz} (0x2f)  @var{addr} @var{size} @result{}
-Record the bytes at @var{addr} in a trace buffer, for later retrieval
-by GDB.  Stop at either the first zero byte, or when @var{size} bytes
-have been recorded, whichever occurs first.
-
-@item @code{printf} (0x34)  @var{numargs} @var{string} @result{}
-Do a formatted print, in the style of the C function @code{printf}).
-The value of @var{numargs} is the number of arguments to expect on the
-stack, while @var{string} is the format string, prefixed with a
-two-byte length.  The last byte of the string must be zero, and is
-included in the length.  The format string includes escaped sequences
-just as it appears in C source, so for instance the format string
-@code{"\t%d\n"} is six characters long, and the output will consist of
-a tab character, a decimal number, and a newline.  At the top of the
-stack, above the values to be printed, this bytecode will pop a
-``function'' and ``channel''.  If the function is nonzero, then the
-target may treat it as a function and call it, passing the channel as
-a first argument, as with the C function @code{fprintf}.  If the
-function is zero, then the target may simply call a standard formatted
-print function of its choice.  In all, this bytecode pops 2 +
-@var{numargs} stack elements, and pushes nothing.
-
-@item @code{end} (0x27): @result{}
-Stop executing bytecode; the result should be the top element of the
-stack.  If the purpose of the expression was to compute an lvalue or a
-range of memory, then the next-to-top of the stack is the lvalue's
-address, and the top of the stack is the lvalue's size, in bytes.
-
-@end table
-
-
-@node Using Agent Expressions
-@section Using Agent Expressions
-
-Agent expressions can be used in several different ways by @value{GDBN},
-and the debugger can generate different bytecode sequences as appropriate.
-
-One possibility is to do expression evaluation on the target rather
-than the host, such as for the conditional of a conditional
-tracepoint.  In such a case, @value{GDBN} compiles the source
-expression into a bytecode sequence that simply gets values from
-registers or memory, does arithmetic, and returns a result.
-
-Another way to use agent expressions is for tracepoint data
-collection.  @value{GDBN} generates a different bytecode sequence for
-collection; in addition to bytecodes that do the calculation,
-@value{GDBN} adds @code{trace} bytecodes to save the pieces of
-memory that were used.
-
-@itemize @bullet
-
-@item
-The user selects trace points in the program's code at which GDB should
-collect data.
-
-@item
-The user specifies expressions to evaluate at each trace point.  These
-expressions may denote objects in memory, in which case those objects'
-contents are recorded as the program runs, or computed values, in which
-case the values themselves are recorded.
-
-@item
-GDB transmits the tracepoints and their associated expressions to the
-GDB agent, running on the debugging target.
-
-@item
-The agent arranges to be notified when a trace point is hit.
-
-@item
-When execution on the target reaches a trace point, the agent evaluates
-the expressions associated with that trace point, and records the
-resulting values and memory ranges.
-
-@item
-Later, when the user selects a given trace event and inspects the
-objects and expression values recorded, GDB talks to the agent to
-retrieve recorded data as necessary to meet the user's requests.  If the
-user asks to see an object whose contents have not been recorded, GDB
-reports an error.
-
-@end itemize
-
-
-@node Varying Target Capabilities
-@section Varying Target Capabilities
-
-Some targets don't support floating-point, and some would rather not
-have to deal with @code{long long} operations.  Also, different targets
-will have different stack sizes, and different bytecode buffer lengths.
-
-Thus, GDB needs a way to ask the target about itself.  We haven't worked
-out the details yet, but in general, GDB should be able to send the
-target a packet asking it to describe itself.  The reply should be a
-packet whose length is explicit, so we can add new information to the
-packet in future revisions of the agent, without confusing old versions
-of GDB, and it should contain a version number.  It should contain at
-least the following information:
-
-@itemize @bullet
-
-@item
-whether floating point is supported
-
-@item
-whether @code{long long} is supported
-
-@item
-maximum acceptable size of bytecode stack
-
-@item
-maximum acceptable length of bytecode expressions
-
-@item
-which registers are actually available for collection
-
-@item
-whether the target supports disabled tracepoints
-
-@end itemize
-
-@node Rationale
-@section Rationale
-
-Some of the design decisions apparent above are arguable.
-
-@table @b
-
-@item What about stack overflow/underflow?
-GDB should be able to query the target to discover its stack size.
-Given that information, GDB can determine at translation time whether a
-given expression will overflow the stack.  But this spec isn't about
-what kinds of error-checking GDB ought to do.
-
-@item Why are you doing everything in LONGEST?
-
-Speed isn't important, but agent code size is; using LONGEST brings in a
-bunch of support code to do things like division, etc.  So this is a
-serious concern.
-
-First, note that you don't need different bytecodes for different
-operand sizes.  You can generate code without @emph{knowing} how big the
-stack elements actually are on the target.  If the target only supports
-32-bit ints, and you don't send any 64-bit bytecodes, everything just
-works.  The observation here is that the MIPS and the Alpha have only
-fixed-size registers, and you can still get C's semantics even though
-most instructions only operate on full-sized words.  You just need to
-make sure everything is properly sign-extended at the right times.  So
-there is no need for 32- and 64-bit variants of the bytecodes.  Just
-implement everything using the largest size you support.
-
-GDB should certainly check to see what sizes the target supports, so the
-user can get an error earlier, rather than later.  But this information
-is not necessary for correctness.
-
-
-@item Why don't you have @code{>} or @code{<=} operators?
-I want to keep the interpreter small, and we don't need them.  We can
-combine the @code{less_} opcodes with @code{log_not}, and swap the order
-of the operands, yielding all four asymmetrical comparison operators.
-For example, @code{(x <= y)} is @code{! (x > y)}, which is @code{! (y <
-x)}.
-
-@item Why do you have @code{log_not}?
-@itemx Why do you have @code{ext}?
-@itemx Why do you have @code{zero_ext}?
-These are all easily synthesized from other instructions, but I expect
-them to be used frequently, and they're simple, so I include them to
-keep bytecode strings short.
-
-@code{log_not} is equivalent to @code{const8 0 equal}; it's used in half
-the relational operators.
-
-@code{ext @var{n}} is equivalent to @code{const8 @var{s-n} lsh const8
-@var{s-n} rsh_signed}, where @var{s} is the size of the stack elements;
-it follows @code{ref@var{m}} and @var{reg} bytecodes when the value
-should be signed.  See the next bulleted item.
-
-@code{zero_ext @var{n}} is equivalent to @code{const@var{m} @var{mask}
-log_and}; it's used whenever we push the value of a register, because we
-can't assume the upper bits of the register aren't garbage.
-
-@item Why not have sign-extending variants of the @code{ref} operators?
-Because that would double the number of @code{ref} operators, and we
-need the @code{ext} bytecode anyway for accessing bitfields.
-
-@item Why not have constant-address variants of the @code{ref} operators?
-Because that would double the number of @code{ref} operators again, and
-@code{const32 @var{address} ref32} is only one byte longer.
-
-@item Why do the @code{ref@var{n}} operators have to support unaligned fetches?
-GDB will generate bytecode that fetches multi-byte values at unaligned
-addresses whenever the executable's debugging information tells it to.
-Furthermore, GDB does not know the value the pointer will have when GDB
-generates the bytecode, so it cannot determine whether a particular
-fetch will be aligned or not.
-
-In particular, structure bitfields may be several bytes long, but follow
-no alignment rules; members of packed structures are not necessarily
-aligned either.
-
-In general, there are many cases where unaligned references occur in
-correct C code, either at the programmer's explicit request, or at the
-compiler's discretion.  Thus, it is simpler to make the GDB agent
-bytecodes work correctly in all circumstances than to make GDB guess in
-each case whether the compiler did the usual thing.
-
-@item Why are there no side-effecting operators?
-Because our current client doesn't want them?  That's a cheap answer.  I
-think the real answer is that I'm afraid of implementing function
-calls.  We should re-visit this issue after the present contract is
-delivered.
-
-@item Why aren't the @code{goto} ops PC-relative?
-The interpreter has the base address around anyway for PC bounds
-checking, and it seemed simpler.
-
-@item Why is there only one offset size for the @code{goto} ops?
-Offsets are currently sixteen bits.  I'm not happy with this situation
-either:
-
-Suppose we have multiple branch ops with different offset sizes.  As I
-generate code left-to-right, all my jumps are forward jumps (there are
-no loops in expressions), so I never know the target when I emit the
-jump opcode.  Thus, I have to either always assume the largest offset
-size, or do jump relaxation on the code after I generate it, which seems
-like a big waste of time.
-
-I can imagine a reasonable expression being longer than 256 bytes.  I
-can't imagine one being longer than 64k.  Thus, we need 16-bit offsets.
-This kind of reasoning is so bogus, but relaxation is pathetic.
-
-The other approach would be to generate code right-to-left.  Then I'd
-always know my offset size.  That might be fun.
-
-@item Where is the function call bytecode?
-
-When we add side-effects, we should add this.
-
-@item Why does the @code{reg} bytecode take a 16-bit register number?
-
-Intel's IA-64 architecture has 128 general-purpose registers,
-and 128 floating-point registers, and I'm sure it has some random
-control registers.
-
-@item Why do we need @code{trace} and @code{trace_quick}?
-Because GDB needs to record all the memory contents and registers an
-expression touches.  If the user wants to evaluate an expression
-@code{x->y->z}, the agent must record the values of @code{x} and
-@code{x->y} as well as the value of @code{x->y->z}.
-
-@item Don't the @code{trace} bytecodes make the interpreter less general?
-They do mean that the interpreter contains special-purpose code, but
-that doesn't mean the interpreter can only be used for that purpose.  If
-an expression doesn't use the @code{trace} bytecodes, they don't get in
-its way.
-
-@item Why doesn't @code{trace_quick} consume its arguments the way everything else does?
-In general, you do want your operators to consume their arguments; it's
-consistent, and generally reduces the amount of stack rearrangement
-necessary.  However, @code{trace_quick} is a kludge to save space; it
-only exists so we needn't write @code{dup const8 @var{SIZE} trace}
-before every memory reference.  Therefore, it's okay for it not to
-consume its arguments; it's meant for a specific context in which we
-know exactly what it should do with the stack.  If we're going to have a
-kludge, it should be an effective kludge.
-
-@item Why does @code{trace16} exist?
-That opcode was added by the customer that contracted Cygnus for the
-data tracing work.  I personally think it is unnecessary; objects that
-large will be quite rare, so it is okay to use @code{dup const16
-@var{size} trace} in those cases.
-
-Whatever we decide to do with @code{trace16}, we should at least leave
-opcode 0x30 reserved, to remain compatible with the customer who added
-it.
-
-@end table
diff --git a/contrib/gdb-7/gdb/doc/all-cfg.texi b/contrib/gdb-7/gdb/doc/all-cfg.texi
deleted file mode 100644 (file)
index 75f3033..0000000
+++ /dev/null
@@ -1,45 +0,0 @@
-@c GDB MANUAL configuration file.  
-@c
-@c Copyright (C) 1993-2013 Free Software Foundation, Inc.
-@c
-@c NOTE: While the GDB manual is configurable (by changing these
-@c switches), its configuration is ***NOT*** automatically tied in to
-@c source configuration---because the authors expect that, save in
-@c unusual cases, the most inclusive form of the manual is appropriate
-@c no matter how the program itself is configured.
-@c
-@c The only automatically-varying variable is the GDB version number,
-@c which the Makefile rewrites based on the VERSION variable from
-@c `../Makefile.in'.  
-@c 
-@c GDB version number is recorded in the variable GDBVN
-@include GDBvn.texi
-@c
-@c ----------------------------------------------------------------------
-@c PLATFORM FLAGS:
-@set GENERIC
-@c
-@c HP PA-RISC target ONLY:
-@clear HPPA
-@c
-@c Refrain from discussing how to configure sw and format doc?
-@clear PRECONFIGURED
-@c
-@c ----------------------------------------------------------------------
-@c STRINGS:
-@c
-@c Name of GDB program.  Used also for (gdb) prompt string.
-@set GDBP gdb
-@c 
-@c Name of GDB product.  Used in running text.
-@set GDBN @sc{gdb}
-@c
-@c Name of host.  Should not be used in generic configs, but generic
-@c value may catch some flubs.
-@set HOST machine specific
-@c
-@c Name of GCC product
-@set NGCC @sc{gcc}
-@c 
-@c Name of GCC program
-@set GCC gcc
diff --git a/contrib/gdb-7/gdb/doc/annotate.texinfo b/contrib/gdb-7/gdb/doc/annotate.texinfo
deleted file mode 100644 (file)
index 05e1409..0000000
+++ /dev/null
@@ -1,852 +0,0 @@
-\input texinfo   @c -*-texinfo-*-
-@c %**start of header
-@setfilename annotate.info
-
-@c This is a dir.info fragment to support semi-automated addition of
-@c manuals to an info tree.
-@dircategory Software development
-@direntry
-* Annotate: (annotate).                 The obsolete annotation interface.
-@end direntry
-
-@c
-@include gdb-cfg.texi
-@c
-@settitle @value{GDBN}'s Obsolete Annotations
-@setchapternewpage off
-@c %**end of header
-
-@set EDITION 1.0
-@set DATE July 2003
-
-@c NOTE: cagney/2003-07-28:
-@c Don't make this migration document an appendix of GDB's user guide.
-@c By keeping this separate, the size of the user guide is contained. If
-@c the user guide to get much bigger it would need to switch to a larger,
-@c more expensive, form factor and would drive up the manuals publication
-@c cost.  Having a smaller cheaper manual helps the GNU Press with its sales.
-
-@copying
-Copyright @copyright{} 1994-2013 Free Software Foundation, Inc.
-
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
-Texts.  A copy of the license is included in the section entitled ``GNU
-Free Documentation License''.
-@end copying
-
-@ifnottex
-This file documents @value{GDBN}'s obsolete annotations.
-
-@insertcopying
-@end ifnottex
-
-@titlepage
-@title @value{GDBN}'s Obsolete Annotations
-@subtitle Edition @value{EDITION}
-@subtitle @value{DATE}
-@author Free Software Foundation
-@page
-@vskip 0pt plus 1filll
-@insertcopying
-@end titlepage
-
-@ifnottex
-@node Top
-@top GDB Annotations
-
-This document describes the obsolete level two annotation interface
-implemented in older @value{GDBN} versions.
-
-@ignore
-This is Edition @value{EDITION}, @value{DATE}.
-@end ignore
-@end ifnottex
-
-@menu
-* Annotations Overview::  What annotations are; the general syntax.
-* Limitations::           Limitations of the annotation interface.
-* Migrating to GDB/MI::   Migrating to GDB/MI
-* Server Prefix::       Issuing a command without affecting user state.
-* Value Annotations::   Values are marked as such.
-* Frame Annotations::   Stack frames are annotated.
-* Displays::            @value{GDBN} can be told to display something periodically.
-* Prompting::           Annotations marking @value{GDBN}'s need for input.
-* Errors::              Annotations for error messages.
-* Breakpoint Info::     Information on breakpoints.
-* Invalidation::        Some annotations describe things now invalid.
-* Annotations for Running::
-                        Whether the program is running, how it stopped, etc.
-* Source Annotations::  Annotations describing source code.
-* Multi-threaded Apps:: An annotation that reports multi-threadedness.
-
-* GNU Free Documentation License::
-@end menu
-
-@contents
-
-@node Annotations Overview
-@chapter What is an Annotation?
-@cindex annotations
-
-To produce obsolete level two annotations, start @value{GDBN} with the
-@code{--annotate=2} option.
-
-Annotations start with a newline character, two @samp{control-z}
-characters, and the name of the annotation.  If there is no additional
-information associated with this annotation, the name of the annotation
-is followed immediately by a newline.  If there is additional
-information, the name of the annotation is followed by a space, the
-additional information, and a newline.  The additional information
-cannot contain newline characters.
-
-Any output not beginning with a newline and two @samp{control-z}
-characters denotes literal output from @value{GDBN}.  Currently there is
-no need for @value{GDBN} to output a newline followed by two
-@samp{control-z} characters, but if there was such a need, the
-annotations could be extended with an @samp{escape} annotation which
-means those three characters as output.
-
-A simple example of starting up @value{GDBN} with annotations is:
-
-@smallexample
-$ gdb --annotate=2
-GNU GDB 5.0
-Copyright 2000 Free Software Foundation, Inc.
-GDB is free software, covered by the GNU General Public License,
-and you are welcome to change it and/or distribute copies of it
-under certain conditions.
-Type "show copying" to see the conditions.
-There is absolutely no warranty for GDB.  Type "show warranty"
-for details.
-This GDB was configured as "sparc-sun-sunos4.1.3"
-
-^Z^Zpre-prompt
-(gdb) 
-^Z^Zprompt
-quit
-
-^Z^Zpost-prompt
-$ 
-@end smallexample
-
-Here @samp{quit} is input to @value{GDBN}; the rest is output from
-@value{GDBN}.  The three lines beginning @samp{^Z^Z} (where @samp{^Z}
-denotes a @samp{control-z} character) are annotations; the rest is
-output from @value{GDBN}.
-
-@node Limitations
-@chapter Limitations of the Annotation Interface
-
-The level two annotations mechanism is known to have a number of
-technical and architectural limitations.  As a consequence, in 2001,
-with the release of @value{GDBN} 5.1 and the addition of @sc{gdb/mi},
-the annotation interface was marked as deprecated.
-
-This chapter discusses the known problems.
-
-@section Dependant on @sc{cli} output
-
-The annotation interface works by interspersing markups with
-@value{GDBN} normal command-line interpreter output.  Unfortunately, this
-makes the annotation client dependant on not just the annotations, but
-also the @sc{cli} output.  This is because the client is forced to
-assume that specific @value{GDBN} commands provide specific information.
-Any change to @value{GDBN}'s @sc{cli} output modifies or removes that
-information and, consequently, likely breaks the client.
-
-Since the @sc{gdb/mi} output is independent of the @sc{cli}, it does not
-have this problem.
-
-@section Scalability
-
-The annotation interface relies on value annotations (@pxref{Value
-Annotations}) and the display mechanism as a way of obtaining up-to-date
-value information.  These mechanisms are not scalable.
-
-In a graphical environment, where many values can be displayed
-simultaneously, a serious performance problem occurs when the client
-tries to first extract from @value{GDBN}, and then re-display, all those
-values.  The client should instead only request and update the values
-that changed.
-
-The @sc{gdb/mi} Variable Objects provide just that mechanism.
-
-@section Correctness
-
-The annotation interface assumes that a variable's value can only be
-changed when the target is running.  This assumption is not correct.  A
-single assignment to a single variable can result in the entire target,
-and all displayed values, needing an update.
-
-The @sc{gdb/mi} Variable Objects include a mechanism for efficiently
-reporting such changes.
-
-@section Reliability
-
-The @sc{gdb/mi} interface includes a dedicated test directory
-(@file{gdb/gdb.mi}), and any addition or fix to @sc{gdb/mi} must include
-testsuite changes.
-
-@section Maintainability
-
-The annotation mechanism was implemented by interspersing @sc{cli} print
-statements with various annotations.  As a consequence, any @sc{cli}
-output change can alter the annotation output.
-
-Since the @sc{gdb/mi} output is independent of the @sc{cli}, and the
-@sc{gdb/mi} is increasingly implemented independent of the @sc{cli}
-code, its long term maintenance is much easier.
-
-@node Migrating to GDB/MI
-@chapter Migrating to @sc{gdb/mi}
-
-By using the @samp{interp mi} command, it is possible for annotation
-clients to invoke @sc{gdb/mi} commands, and hence access the
-@sc{gdb/mi}.  By doing this, existing annotation clients have a
-migration path from this obsolete interface to @sc{gdb/mi}.
-
-@node Server Prefix
-@chapter The Server Prefix
-@cindex server prefix for annotations
-
-To issue a command to @value{GDBN} without affecting certain aspects of
-the state which is seen by users, prefix it with @samp{server }.  This
-means that this command will not affect the command history, nor will it
-affect @value{GDBN}'s notion of which command to repeat if @key{RET} is
-pressed on a line by itself.
-
-The server prefix does not affect the recording of values into the value
-history; to print a value without recording it into the value history,
-use the @code{output} command instead of the @code{print} command.
-
-@node Value Annotations
-@chapter Values
-
-@emph{Value Annotations have been removed.  @sc{gdb/mi} instead provides
-Variable Objects.}
-
-@cindex annotations for values
-When a value is printed in various contexts, @value{GDBN} uses
-annotations to delimit the value from the surrounding text.
-
-@findex value-history-begin
-@findex value-history-value
-@findex value-history-end
-If a value is printed using @code{print} and added to the value history,
-the annotation looks like
-
-@smallexample
-^Z^Zvalue-history-begin @var{history-number} @var{value-flags}
-@var{history-string}
-^Z^Zvalue-history-value
-@var{the-value}
-^Z^Zvalue-history-end
-@end smallexample
-
-@noindent
-where @var{history-number} is the number it is getting in the value
-history, @var{history-string} is a string, such as @samp{$5 = }, which
-introduces the value to the user, @var{the-value} is the output
-corresponding to the value itself, and @var{value-flags} is @samp{*} for
-a value which can be dereferenced and @samp{-} for a value which cannot.
-
-@findex value-begin
-@findex value-end
-If the value is not added to the value history (it is an invalid float
-or it is printed with the @code{output} command), the annotation is similar:
-
-@smallexample
-^Z^Zvalue-begin @var{value-flags}
-@var{the-value}
-^Z^Zvalue-end
-@end smallexample
-
-@findex arg-begin
-@findex arg-name-end
-@findex arg-value
-@findex arg-end
-When @value{GDBN} prints an argument to a function (for example, in the output
-from the @code{backtrace} command), it annotates it as follows:
-
-@smallexample
-^Z^Zarg-begin
-@var{argument-name}
-^Z^Zarg-name-end
-@var{separator-string}
-^Z^Zarg-value @var{value-flags}
-@var{the-value}
-^Z^Zarg-end
-@end smallexample
-
-@noindent
-where @var{argument-name} is the name of the argument,
-@var{separator-string} is text which separates the name from the value
-for the user's benefit (such as @samp{=}), and @var{value-flags} and
-@var{the-value} have the same meanings as in a
-@code{value-history-begin} annotation.
-
-@findex field-begin
-@findex field-name-end
-@findex field-value
-@findex field-end
-When printing a structure, @value{GDBN} annotates it as follows:
-
-@smallexample
-^Z^Zfield-begin @var{value-flags}
-@var{field-name}
-^Z^Zfield-name-end
-@var{separator-string}
-^Z^Zfield-value
-@var{the-value}
-^Z^Zfield-end
-@end smallexample
-
-@noindent
-where @var{field-name} is the name of the field, @var{separator-string}
-is text which separates the name from the value for the user's benefit
-(such as @samp{=}), and @var{value-flags} and @var{the-value} have the
-same meanings as in a @code{value-history-begin} annotation.
-
-When printing an array, @value{GDBN} annotates it as follows:
-
-@smallexample
-^Z^Zarray-section-begin @var{array-index} @var{value-flags}
-@end smallexample
-
-@noindent
-where @var{array-index} is the index of the first element being
-annotated and @var{value-flags} has the same meaning as in a
-@code{value-history-begin} annotation.  This is followed by any number
-of elements, where is element can be either a single element:
-
-@findex elt
-@smallexample
-@samp{,} @var{whitespace}         ; @r{omitted for the first element}
-@var{the-value}
-^Z^Zelt
-@end smallexample
-
-or a repeated element
-
-@findex elt-rep
-@findex elt-rep-end
-@smallexample
-@samp{,} @var{whitespace}         ; @r{omitted for the first element}
-@var{the-value}
-^Z^Zelt-rep @var{number-of-repetitions}
-@var{repetition-string}
-^Z^Zelt-rep-end
-@end smallexample
-
-In both cases, @var{the-value} is the output for the value of the
-element and @var{whitespace} can contain spaces, tabs, and newlines.  In
-the repeated case, @var{number-of-repetitions} is the number of
-consecutive array elements which contain that value, and
-@var{repetition-string} is a string which is designed to convey to the
-user that repetition is being depicted.
-
-@findex array-section-end
-Once all the array elements have been output, the array annotation is
-ended with
-
-@smallexample
-^Z^Zarray-section-end
-@end smallexample
-
-@node Frame Annotations
-@chapter Frames
-
-@emph{Value Annotations have been removed.  @sc{gdb/mi} instead provides
-a number of frame commands.}
-
-@emph{Frame annotations are no longer available.  The @sc{gdb/mi}
-provides @samp{-stack-list-arguments}, @samp{-stack-list-locals}, and
-@samp{-stack-list-frames} commands.}
-
-@cindex annotations for frames
-Whenever @value{GDBN} prints a frame, it annotates it.  For example, this applies
-to frames printed when @value{GDBN} stops, output from commands such as
-@code{backtrace} or @code{up}, etc.
-
-@findex frame-begin
-The frame annotation begins with
-
-@smallexample
-^Z^Zframe-begin @var{level} @var{address}
-@var{level-string}
-@end smallexample
-
-@noindent
-where @var{level} is the number of the frame (0 is the innermost frame,
-and other frames have positive numbers), @var{address} is the address of
-the code executing in that frame, and @var{level-string} is a string
-designed to convey the level to the user.  @var{address} is in the form
-@samp{0x} followed by one or more lowercase hex digits (note that this
-does not depend on the language).  The frame ends with
-
-@findex frame-end
-@smallexample
-^Z^Zframe-end
-@end smallexample
-
-Between these annotations is the main body of the frame, which can
-consist of
-
-@itemize @bullet
-@item
-@findex function-call
-@smallexample
-^Z^Zfunction-call
-@var{function-call-string}
-@end smallexample
-
-where @var{function-call-string} is text designed to convey to the user
-that this frame is associated with a function call made by @value{GDBN} to a
-function in the program being debugged.
-
-@item
-@findex signal-handler-caller
-@smallexample
-^Z^Zsignal-handler-caller
-@var{signal-handler-caller-string}
-@end smallexample
-
-where @var{signal-handler-caller-string} is text designed to convey to
-the user that this frame is associated with whatever mechanism is used
-by this operating system to call a signal handler (it is the frame which
-calls the signal handler, not the frame for the signal handler itself).
-
-@item
-A normal frame.
-
-@findex frame-address
-@findex frame-address-end
-This can optionally (depending on whether this is thought of as
-interesting information for the user to see) begin with
-
-@smallexample
-^Z^Zframe-address
-@var{address}
-^Z^Zframe-address-end
-@var{separator-string}
-@end smallexample
-
-where @var{address} is the address executing in the frame (the same
-address as in the @code{frame-begin} annotation, but printed in a form
-which is intended for user consumption---in particular, the syntax varies
-depending on the language), and @var{separator-string} is a string
-intended to separate this address from what follows for the user's
-benefit.
-
-@findex frame-function-name
-@findex frame-args
-Then comes
-
-@smallexample
-^Z^Zframe-function-name
-@var{function-name}
-^Z^Zframe-args
-@var{arguments}
-@end smallexample
-
-where @var{function-name} is the name of the function executing in the
-frame, or @samp{??} if not known, and @var{arguments} are the arguments
-to the frame, with parentheses around them (each argument is annotated
-individually as well, @pxref{Value Annotations}).
-
-@findex frame-source-begin
-@findex frame-source-file
-@findex frame-source-file-end
-@findex frame-source-line
-@findex frame-source-end
-If source information is available, a reference to it is then printed:
-
-@smallexample
-^Z^Zframe-source-begin
-@var{source-intro-string}
-^Z^Zframe-source-file
-@var{filename}
-^Z^Zframe-source-file-end
-:
-^Z^Zframe-source-line
-@var{line-number}
-^Z^Zframe-source-end
-@end smallexample
-
-where @var{source-intro-string} separates for the user's benefit the
-reference from the text which precedes it, @var{filename} is the name of
-the source file, and @var{line-number} is the line number within that
-file (the first line is line 1).
-
-@findex frame-where
-If @value{GDBN} prints some information about where the frame is from (which
-library, which load segment, etc.; currently only done on the RS/6000),
-it is annotated with
-
-@smallexample
-^Z^Zframe-where
-@var{information}
-@end smallexample
-
-Then, if source is to actually be displayed for this frame (for example,
-this is not true for output from the @code{backtrace} command), then a
-@code{source} annotation (@pxref{Source Annotations}) is displayed.  Unlike
-most annotations, this is output instead of the normal text which would be
-output, not in addition.
-@end itemize
-
-@node Displays
-@chapter Displays
-
-@emph{Display Annotations have been removed.  @sc{gdb/mi} instead
-provides Variable Objects.}
-
-@findex display-begin
-@findex display-number-end
-@findex display-format
-@findex display-expression
-@findex display-expression-end
-@findex display-value
-@findex display-end
-@cindex annotations for display
-When @value{GDBN} is told to display something using the @code{display} command,
-the results of the display are annotated:
-
-@smallexample
-^Z^Zdisplay-begin
-@var{number}
-^Z^Zdisplay-number-end
-@var{number-separator}
-^Z^Zdisplay-format
-@var{format}
-^Z^Zdisplay-expression
-@var{expression}
-^Z^Zdisplay-expression-end
-@var{expression-separator}
-^Z^Zdisplay-value
-@var{value}
-^Z^Zdisplay-end
-@end smallexample
-
-@noindent
-where @var{number} is the number of the display, @var{number-separator}
-is intended to separate the number from what follows for the user,
-@var{format} includes information such as the size, format, or other
-information about how the value is being displayed, @var{expression} is
-the expression being displayed, @var{expression-separator} is intended
-to separate the expression from the text that follows for the user,
-and @var{value} is the actual value being displayed.
-
-@node Prompting
-@chapter Annotation for @value{GDBN} Input
-
-@cindex annotations for prompts
-When @value{GDBN} prompts for input, it annotates this fact so it is possible
-to know when to send output, when the output from a given command is
-over, etc.
-
-Different kinds of input each have a different @dfn{input type}.  Each
-input type has three annotations: a @code{pre-} annotation, which
-denotes the beginning of any prompt which is being output, a plain
-annotation, which denotes the end of the prompt, and then a @code{post-}
-annotation which denotes the end of any echo which may (or may not) be
-associated with the input.  For example, the @code{prompt} input type
-features the following annotations:
-
-@smallexample
-^Z^Zpre-prompt
-^Z^Zprompt
-^Z^Zpost-prompt
-@end smallexample
-
-The input types are
-
-@table @code
-@findex pre-prompt
-@findex prompt
-@findex post-prompt
-@item prompt
-When @value{GDBN} is prompting for a command (the main @value{GDBN} prompt).
-
-@findex pre-commands
-@findex commands
-@findex post-commands
-@item commands
-When @value{GDBN} prompts for a set of commands, like in the @code{commands}
-command.  The annotations are repeated for each command which is input.
-
-@findex pre-overload-choice
-@findex overload-choice
-@findex post-overload-choice
-@item overload-choice
-When @value{GDBN} wants the user to select between various overloaded functions.
-
-@findex pre-query
-@findex query
-@findex post-query
-@item query
-When @value{GDBN} wants the user to confirm a potentially dangerous operation.
-
-@findex pre-prompt-for-continue
-@findex prompt-for-continue
-@findex post-prompt-for-continue
-@item prompt-for-continue
-When @value{GDBN} is asking the user to press return to continue.  Note: Don't
-expect this to work well; instead use @code{set height 0} to disable
-prompting.  This is because the counting of lines is buggy in the
-presence of annotations.
-@end table
-
-@node Errors
-@chapter Errors
-@cindex annotations for errors, warnings and interrupts
-
-@findex quit
-@smallexample
-^Z^Zquit
-@end smallexample
-
-This annotation occurs right before @value{GDBN} responds to an interrupt.
-
-@findex error
-@smallexample
-^Z^Zerror
-@end smallexample
-
-This annotation occurs right before @value{GDBN} responds to an error.
-
-Quit and error annotations indicate that any annotations which @value{GDBN} was
-in the middle of may end abruptly.  For example, if a
-@code{value-history-begin} annotation is followed by a @code{error}, one
-cannot expect to receive the matching @code{value-history-end}.  One
-cannot expect not to receive it either, however; an error annotation
-does not necessarily mean that @value{GDBN} is immediately returning all the way
-to the top level.
-
-@findex error-begin
-A quit or error annotation may be preceded by
-
-@smallexample
-^Z^Zerror-begin
-@end smallexample
-
-Any output between that and the quit or error annotation is the error
-message.
-
-Warning messages are not yet annotated.
-@c If we want to change that, need to fix warning(), type_error(),
-@c range_error(), and possibly other places.
-
-@node Breakpoint Info
-@chapter Information on Breakpoints
-
-@emph{Breakpoint Annotations have been removed.  @sc{gdb/mi} instead
-provides breakpoint commands.}
-
-@cindex annotations for breakpoints
-The output from the @code{info breakpoints} command is annotated as follows:
-
-@findex breakpoints-headers
-@findex breakpoints-table
-@smallexample
-^Z^Zbreakpoints-headers
-@var{header-entry}
-^Z^Zbreakpoints-table
-@end smallexample
-
-@noindent
-where @var{header-entry} has the same syntax as an entry (see below) but
-instead of containing data, it contains strings which are intended to
-convey the meaning of each field to the user.  This is followed by any
-number of entries.  If a field does not apply for this entry, it is
-omitted.  Fields may contain trailing whitespace.  Each entry consists
-of:
-
-@findex record
-@findex field
-@smallexample
-^Z^Zrecord
-^Z^Zfield 0
-@var{number}
-^Z^Zfield 1
-@var{type}
-^Z^Zfield 2
-@var{disposition}
-^Z^Zfield 3
-@var{enable}
-^Z^Zfield 4
-@var{address}
-^Z^Zfield 5
-@var{what}
-^Z^Zfield 6
-@var{frame}
-^Z^Zfield 7
-@var{condition}
-^Z^Zfield 8
-@var{ignore-count}
-^Z^Zfield 9
-@var{commands}
-@end smallexample
-
-Note that @var{address} is intended for user consumption---the syntax
-varies depending on the language.
-
-The output ends with
-
-@findex breakpoints-table-end
-@smallexample
-^Z^Zbreakpoints-table-end
-@end smallexample
-
-@node Invalidation
-@chapter Invalidation Notices
-
-@cindex annotations for invalidation messages
-The following annotations say that certain pieces of state may have
-changed.
-
-@table @code
-@findex frames-invalid
-@item ^Z^Zframes-invalid
-
-The frames (for example, output from the @code{backtrace} command) may
-have changed.
-
-@findex breakpoints-invalid
-@item ^Z^Zbreakpoints-invalid
-
-The breakpoints may have changed.  For example, the user just added or
-deleted a breakpoint.
-@end table
-
-@node Annotations for Running
-@chapter Running the Program
-@cindex annotations for running programs
-
-@findex starting
-@findex stopping
-When the program starts executing due to a @value{GDBN} command such as
-@code{step} or @code{continue}, 
-
-@smallexample
-^Z^Zstarting
-@end smallexample
-
-is output.  When the program stops, 
-
-@smallexample
-^Z^Zstopped
-@end smallexample
-
-is output.  Before the @code{stopped} annotation, a variety of
-annotations describe how the program stopped.
-
-@table @code
-@findex exited
-@item ^Z^Zexited @var{exit-status}
-The program exited, and @var{exit-status} is the exit status (zero for
-successful exit, otherwise nonzero).
-
-@findex signalled
-@findex signal-name
-@findex signal-name-end
-@findex signal-string
-@findex signal-string-end
-@item ^Z^Zsignalled
-The program exited with a signal.  After the @code{^Z^Zsignalled}, the
-annotation continues:
-
-@smallexample
-@var{intro-text}
-^Z^Zsignal-name
-@var{name}
-^Z^Zsignal-name-end
-@var{middle-text}
-^Z^Zsignal-string
-@var{string}
-^Z^Zsignal-string-end
-@var{end-text}
-@end smallexample
-
-@noindent
-where @var{name} is the name of the signal, such as @code{SIGILL} or
-@code{SIGSEGV}, and @var{string} is the explanation of the signal, such
-as @code{Illegal Instruction} or @code{Segmentation fault}.
-@var{intro-text}, @var{middle-text}, and @var{end-text} are for the
-user's benefit and have no particular format.
-
-@findex signal
-@item ^Z^Zsignal
-The syntax of this annotation is just like @code{signalled}, but @value{GDBN} is
-just saying that the program received the signal, not that it was
-terminated with it.
-
-@findex breakpoint
-@item ^Z^Zbreakpoint @var{number}
-The program hit breakpoint number @var{number}.
-
-@findex watchpoint
-@item ^Z^Zwatchpoint @var{number}
-The program hit watchpoint number @var{number}.
-@end table
-
-@node Source Annotations
-@chapter Displaying Source
-@cindex annotations for source display
-
-@findex source
-The following annotation is used instead of displaying source code:
-
-@smallexample
-^Z^Zsource @var{filename}:@var{line}:@var{character}:@var{middle}:@var{addr}
-@end smallexample
-
-where @var{filename} is an absolute file name indicating which source
-file, @var{line} is the line number within that file (where 1 is the
-first line in the file), @var{character} is the character position
-within the file (where 0 is the first character in the file) (for most
-debug formats this will necessarily point to the beginning of a line),
-@var{middle} is @samp{middle} if @var{addr} is in the middle of the
-line, or @samp{beg} if @var{addr} is at the beginning of the line, and
-@var{addr} is the address in the target program associated with the
-source which is being displayed.  @var{addr} is in the form @samp{0x}
-followed by one or more lowercase hex digits (note that this does not
-depend on the language).
-
-@node Multi-threaded Apps
-@chapter Multi-threaded Applications
-@cindex annotations for multi-threaded apps
-
-The following annotations report thread related changes of state.
-
-@table @code
-@findex new-thread@r{, annotation}
-@item ^Z^Znew-thread
-
-This annotation is issued once for each thread that is created apart from
-the main thread, which is not reported.
-
-@findex thread-changed@r{, annotation}
-@item ^Z^Zthread-changed
-
-The selected thread has changed.  This may occur at the request of the
-user with the @code{thread} command, or as a result of execution,
-e.g., another thread hits a breakpoint.
-
-@end table
-
-@node GNU Free Documentation License
-@appendix GNU Free Documentation License
-@include fdl.texi
-
-@ignore
-@node Index
-@unnumbered Index
-
-@printindex fn
-@end ignore
-
-@bye
diff --git a/contrib/gdb-7/gdb/doc/fdl.texi b/contrib/gdb-7/gdb/doc/fdl.texi
deleted file mode 100644 (file)
index 7c26c34..0000000
+++ /dev/null
@@ -1,505 +0,0 @@
-@c The GNU Free Documentation License.
-@center Version 1.3, 3 November 2008
-
-@c This file is intended to be included within another document,
-@c hence no sectioning command or @node.
-
-@display
-Copyright @copyright{} 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
-@uref{http://fsf.org/}
-
-Everyone is permitted to copy and distribute verbatim copies
-of this license document, but changing it is not allowed.
-@end display
-
-@enumerate 0
-@item
-PREAMBLE
-
-The purpose of this License is to make a manual, textbook, or other
-functional and useful document @dfn{free} in the sense of freedom: to
-assure everyone the effective freedom to copy and redistribute it,
-with or without modifying it, either commercially or noncommercially.
-Secondarily, this License preserves for the author and publisher a way
-to get credit for their work, while not being considered responsible
-for modifications made by others.
-
-This License is a kind of ``copyleft'', which means that derivative
-works of the document must themselves be free in the same sense.  It
-complements the GNU General Public License, which is a copyleft
-license designed for free software.
-
-We have designed this License in order to use it for manuals for free
-software, because free software needs free documentation: a free
-program should come with manuals providing the same freedoms that the
-software does.  But this License is not limited to software manuals;
-it can be used for any textual work, regardless of subject matter or
-whether it is published as a printed book.  We recommend this License
-principally for works whose purpose is instruction or reference.
-
-@item
-APPLICABILITY AND DEFINITIONS
-
-This License applies to any manual or other work, in any medium, that
-contains a notice placed by the copyright holder saying it can be
-distributed under the terms of this License.  Such a notice grants a
-world-wide, royalty-free license, unlimited in duration, to use that
-work under the conditions stated herein.  The ``Document'', below,
-refers to any such manual or work.  Any member of the public is a
-licensee, and is addressed as ``you''.  You accept the license if you
-copy, modify or distribute the work in a way requiring permission
-under copyright law.
-
-A ``Modified Version'' of the Document means any work containing the
-Document or a portion of it, either copied verbatim, or with
-modifications and/or translated into another language.
-
-A ``Secondary Section'' is a named appendix or a front-matter section
-of the Document that deals exclusively with the relationship of the
-publishers or authors of the Document to the Document's overall
-subject (or to related matters) and contains nothing that could fall
-directly within that overall subject.  (Thus, if the Document is in
-part a textbook of mathematics, a Secondary Section may not explain
-any mathematics.)  The relationship could be a matter of historical
-connection with the subject or with related matters, or of legal,
-commercial, philosophical, ethical or political position regarding
-them.
-
-The ``Invariant Sections'' are certain Secondary Sections whose titles
-are designated, as being those of Invariant Sections, in the notice
-that says that the Document is released under this License.  If a
-section does not fit the above definition of Secondary then it is not
-allowed to be designated as Invariant.  The Document may contain zero
-Invariant Sections.  If the Document does not identify any Invariant
-Sections then there are none.
-
-The ``Cover Texts'' are certain short passages of text that are listed,
-as Front-Cover Texts or Back-Cover Texts, in the notice that says that
-the Document is released under this License.  A Front-Cover Text may
-be at most 5 words, and a Back-Cover Text may be at most 25 words.
-
-A ``Transparent'' copy of the Document means a machine-readable copy,
-represented in a format whose specification is available to the
-general public, that is suitable for revising the document
-straightforwardly with generic text editors or (for images composed of
-pixels) generic paint programs or (for drawings) some widely available
-drawing editor, and that is suitable for input to text formatters or
-for automatic translation to a variety of formats suitable for input
-to text formatters.  A copy made in an otherwise Transparent file
-format whose markup, or absence of markup, has been arranged to thwart
-or discourage subsequent modification by readers is not Transparent.
-An image format is not Transparent if used for any substantial amount
-of text.  A copy that is not ``Transparent'' is called ``Opaque''.
-
-Examples of suitable formats for Transparent copies include plain
-@sc{ascii} without markup, Texinfo input format, La@TeX{} input
-format, @acronym{SGML} or @acronym{XML} using a publicly available
-@acronym{DTD}, and standard-conforming simple @acronym{HTML},
-PostScript or @acronym{PDF} designed for human modification.  Examples
-of transparent image formats include @acronym{PNG}, @acronym{XCF} and
-@acronym{JPG}.  Opaque formats include proprietary formats that can be
-read and edited only by proprietary word processors, @acronym{SGML} or
-@acronym{XML} for which the @acronym{DTD} and/or processing tools are
-not generally available, and the machine-generated @acronym{HTML},
-PostScript or @acronym{PDF} produced by some word processors for
-output purposes only.
-
-The ``Title Page'' means, for a printed book, the title page itself,
-plus such following pages as are needed to hold, legibly, the material
-this License requires to appear in the title page.  For works in
-formats which do not have any title page as such, ``Title Page'' means
-the text near the most prominent appearance of the work's title,
-preceding the beginning of the body of the text.
-
-The ``publisher'' means any person or entity that distributes copies
-of the Document to the public.
-
-A section ``Entitled XYZ'' means a named subunit of the Document whose
-title either is precisely XYZ or contains XYZ in parentheses following
-text that translates XYZ in another language.  (Here XYZ stands for a
-specific section name mentioned below, such as ``Acknowledgements'',
-``Dedications'', ``Endorsements'', or ``History''.)  To ``Preserve the Title''
-of such a section when you modify the Document means that it remains a
-section ``Entitled XYZ'' according to this definition.
-
-The Document may include Warranty Disclaimers next to the notice which
-states that this License applies to the Document.  These Warranty
-Disclaimers are considered to be included by reference in this
-License, but only as regards disclaiming warranties: any other
-implication that these Warranty Disclaimers may have is void and has
-no effect on the meaning of this License.
-
-@item
-VERBATIM COPYING
-
-You may copy and distribute the Document in any medium, either
-commercially or noncommercially, provided that this License, the
-copyright notices, and the license notice saying this License applies
-to the Document are reproduced in all copies, and that you add no other
-conditions whatsoever to those of this License.  You may not use
-technical measures to obstruct or control the reading or further
-copying of the copies you make or distribute.  However, you may accept
-compensation in exchange for copies.  If you distribute a large enough
-number of copies you must also follow the conditions in section 3.
-
-You may also lend copies, under the same conditions stated above, and
-you may publicly display copies.
-
-@item
-COPYING IN QUANTITY
-
-If you publish printed copies (or copies in media that commonly have
-printed covers) of the Document, numbering more than 100, and the
-Document's license notice requires Cover Texts, you must enclose the
-copies in covers that carry, clearly and legibly, all these Cover
-Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
-the back cover.  Both covers must also clearly and legibly identify
-you as the publisher of these copies.  The front cover must present
-the full title with all words of the title equally prominent and
-visible.  You may add other material on the covers in addition.
-Copying with changes limited to the covers, as long as they preserve
-the title of the Document and satisfy these conditions, can be treated
-as verbatim copying in other respects.
-
-If the required texts for either cover are too voluminous to fit
-legibly, you should put the first ones listed (as many as fit
-reasonably) on the actual cover, and continue the rest onto adjacent
-pages.
-
-If you publish or distribute Opaque copies of the Document numbering
-more than 100, you must either include a machine-readable Transparent
-copy along with each Opaque copy, or state in or with each Opaque copy
-a computer-network location from which the general network-using
-public has access to download using public-standard network protocols
-a complete Transparent copy of the Document, free of added material.
-If you use the latter option, you must take reasonably prudent steps,
-when you begin distribution of Opaque copies in quantity, to ensure
-that this Transparent copy will remain thus accessible at the stated
-location until at least one year after the last time you distribute an
-Opaque copy (directly or through your agents or retailers) of that
-edition to the public.
-
-It is requested, but not required, that you contact the authors of the
-Document well before redistributing any large number of copies, to give
-them a chance to provide you with an updated version of the Document.
-
-@item
-MODIFICATIONS
-
-You may copy and distribute a Modified Version of the Document under
-the conditions of sections 2 and 3 above, provided that you release
-the Modified Version under precisely this License, with the Modified
-Version filling the role of the Document, thus licensing distribution
-and modification of the Modified Version to whoever possesses a copy
-of it.  In addition, you must do these things in the Modified Version:
-
-@enumerate A
-@item
-Use in the Title Page (and on the covers, if any) a title distinct
-from that of the Document, and from those of previous versions
-(which should, if there were any, be listed in the History section
-of the Document).  You may use the same title as a previous version
-if the original publisher of that version gives permission.
-
-@item
-List on the Title Page, as authors, one or more persons or entities
-responsible for authorship of the modifications in the Modified
-Version, together with at least five of the principal authors of the
-Document (all of its principal authors, if it has fewer than five),
-unless they release you from this requirement.
-
-@item
-State on the Title page the name of the publisher of the
-Modified Version, as the publisher.
-
-@item
-Preserve all the copyright notices of the Document.
-
-@item
-Add an appropriate copyright notice for your modifications
-adjacent to the other copyright notices.
-
-@item
-Include, immediately after the copyright notices, a license notice
-giving the public permission to use the Modified Version under the
-terms of this License, in the form shown in the Addendum below.
-
-@item
-Preserve in that license notice the full lists of Invariant Sections
-and required Cover Texts given in the Document's license notice.
-
-@item
-Include an unaltered copy of this License.
-
-@item
-Preserve the section Entitled ``History'', Preserve its Title, and add
-to it an item stating at least the title, year, new authors, and
-publisher of the Modified Version as given on the Title Page.  If
-there is no section Entitled ``History'' in the Document, create one
-stating the title, year, authors, and publisher of the Document as
-given on its Title Page, then add an item describing the Modified
-Version as stated in the previous sentence.
-
-@item
-Preserve the network location, if any, given in the Document for
-public access to a Transparent copy of the Document, and likewise
-the network locations given in the Document for previous versions
-it was based on.  These may be placed in the ``History'' section.
-You may omit a network location for a work that was published at
-least four years before the Document itself, or if the original
-publisher of the version it refers to gives permission.
-
-@item
-For any section Entitled ``Acknowledgements'' or ``Dedications'', Preserve
-the Title of the section, and preserve in the section all the
-substance and tone of each of the contributor acknowledgements and/or
-dedications given therein.
-
-@item
-Preserve all the Invariant Sections of the Document,
-unaltered in their text and in their titles.  Section numbers
-or the equivalent are not considered part of the section titles.
-
-@item
-Delete any section Entitled ``Endorsements''.  Such a section
-may not be included in the Modified Version.
-
-@item
-Do not retitle any existing section to be Entitled ``Endorsements'' or
-to conflict in title with any Invariant Section.
-
-@item
-Preserve any Warranty Disclaimers.
-@end enumerate
-
-If the Modified Version includes new front-matter sections or
-appendices that qualify as Secondary Sections and contain no material
-copied from the Document, you may at your option designate some or all
-of these sections as invariant.  To do this, add their titles to the
-list of Invariant Sections in the Modified Version's license notice.
-These titles must be distinct from any other section titles.
-
-You may add a section Entitled ``Endorsements'', provided it contains
-nothing but endorsements of your Modified Version by various
-parties---for example, statements of peer review or that the text has
-been approved by an organization as the authoritative definition of a
-standard.
-
-You may add a passage of up to five words as a Front-Cover Text, and a
-passage of up to 25 words as a Back-Cover Text, to the end of the list
-of Cover Texts in the Modified Version.  Only one passage of
-Front-Cover Text and one of Back-Cover Text may be added by (or
-through arrangements made by) any one entity.  If the Document already
-includes a cover text for the same cover, previously added by you or
-by arrangement made by the same entity you are acting on behalf of,
-you may not add another; but you may replace the old one, on explicit
-permission from the previous publisher that added the old one.
-
-The author(s) and publisher(s) of the Document do not by this License
-give permission to use their names for publicity for or to assert or
-imply endorsement of any Modified Version.
-
-@item
-COMBINING DOCUMENTS
-
-You may combine the Document with other documents released under this
-License, under the terms defined in section 4 above for modified
-versions, provided that you include in the combination all of the
-Invariant Sections of all of the original documents, unmodified, and
-list them all as Invariant Sections of your combined work in its
-license notice, and that you preserve all their Warranty Disclaimers.
-
-The combined work need only contain one copy of this License, and
-multiple identical Invariant Sections may be replaced with a single
-copy.  If there are multiple Invariant Sections with the same name but
-different contents, make the title of each such section unique by
-adding at the end of it, in parentheses, the name of the original
-author or publisher of that section if known, or else a unique number.
-Make the same adjustment to the section titles in the list of
-Invariant Sections in the license notice of the combined work.
-
-In the combination, you must combine any sections Entitled ``History''
-in the various original documents, forming one section Entitled
-``History''; likewise combine any sections Entitled ``Acknowledgements'',
-and any sections Entitled ``Dedications''.  You must delete all
-sections Entitled ``Endorsements.''
-
-@item
-COLLECTIONS OF DOCUMENTS
-
-You may make a collection consisting of the Document and other documents
-released under this License, and replace the individual copies of this
-License in the various documents with a single copy that is included in
-the collection, provided that you follow the rules of this License for
-verbatim copying of each of the documents in all other respects.
-
-You may extract a single document from such a collection, and distribute
-it individually under this License, provided you insert a copy of this
-License into the extracted document, and follow this License in all
-other respects regarding verbatim copying of that document.
-
-@item
-AGGREGATION WITH INDEPENDENT WORKS
-
-A compilation of the Document or its derivatives with other separate
-and independent documents or works, in or on a volume of a storage or
-distribution medium, is called an ``aggregate'' if the copyright
-resulting from the compilation is not used to limit the legal rights
-of the compilation's users beyond what the individual works permit.
-When the Document is included in an aggregate, this License does not
-apply to the other works in the aggregate which are not themselves
-derivative works of the Document.
-
-If the Cover Text requirement of section 3 is applicable to these
-copies of the Document, then if the Document is less than one half of
-the entire aggregate, the Document's Cover Texts may be placed on
-covers that bracket the Document within the aggregate, or the
-electronic equivalent of covers if the Document is in electronic form.
-Otherwise they must appear on printed covers that bracket the whole
-aggregate.
-
-@item
-TRANSLATION
-
-Translation is considered a kind of modification, so you may
-distribute translations of the Document under the terms of section 4.
-Replacing Invariant Sections with translations requires special
-permission from their copyright holders, but you may include
-translations of some or all Invariant Sections in addition to the
-original versions of these Invariant Sections.  You may include a
-translation of this License, and all the license notices in the
-Document, and any Warranty Disclaimers, provided that you also include
-the original English version of this License and the original versions
-of those notices and disclaimers.  In case of a disagreement between
-the translation and the original version of this License or a notice
-or disclaimer, the original version will prevail.
-
-If a section in the Document is Entitled ``Acknowledgements'',
-``Dedications'', or ``History'', the requirement (section 4) to Preserve
-its Title (section 1) will typically require changing the actual
-title.
-
-@item
-TERMINATION
-
-You may not copy, modify, sublicense, or distribute the Document
-except as expressly provided under this License.  Any attempt
-otherwise to copy, modify, sublicense, or distribute it is void, and
-will automatically terminate your rights under this License.
-
-However, if you cease all violation of this License, then your license
-from a particular copyright holder is reinstated (a) provisionally,
-unless and until the copyright holder explicitly and finally
-terminates your license, and (b) permanently, if the copyright holder
-fails to notify you of the violation by some reasonable means prior to
-60 days after the cessation.
-
-Moreover, your license from a particular copyright holder is
-reinstated permanently if the copyright holder notifies you of the
-violation by some reasonable means, this is the first time you have
-received notice of violation of this License (for any work) from that
-copyright holder, and you cure the violation prior to 30 days after
-your receipt of the notice.
-
-Termination of your rights under this section does not terminate the
-licenses of parties who have received copies or rights from you under
-this License.  If your rights have been terminated and not permanently
-reinstated, receipt of a copy of some or all of the same material does
-not give you any rights to use it.
-
-@item
-FUTURE REVISIONS OF THIS LICENSE
-
-The Free Software Foundation may publish new, revised versions
-of the GNU Free Documentation License from time to time.  Such new
-versions will be similar in spirit to the present version, but may
-differ in detail to address new problems or concerns.  See
-@uref{http://www.gnu.org/copyleft/}.
-
-Each version of the License is given a distinguishing version number.
-If the Document specifies that a particular numbered version of this
-License ``or any later version'' applies to it, you have the option of
-following the terms and conditions either of that specified version or
-of any later version that has been published (not as a draft) by the
-Free Software Foundation.  If the Document does not specify a version
-number of this License, you may choose any version ever published (not
-as a draft) by the Free Software Foundation.  If the Document
-specifies that a proxy can decide which future versions of this
-License can be used, that proxy's public statement of acceptance of a
-version permanently authorizes you to choose that version for the
-Document.
-
-@item
-RELICENSING
-
-``Massive Multiauthor Collaboration Site'' (or ``MMC Site'') means any
-World Wide Web server that publishes copyrightable works and also
-provides prominent facilities for anybody to edit those works.  A
-public wiki that anybody can edit is an example of such a server.  A
-``Massive Multiauthor Collaboration'' (or ``MMC'') contained in the
-site means any set of copyrightable works thus published on the MMC
-site.
-
-``CC-BY-SA'' means the Creative Commons Attribution-Share Alike 3.0
-license published by Creative Commons Corporation, a not-for-profit
-corporation with a principal place of business in San Francisco,
-California, as well as future copyleft versions of that license
-published by that same organization.
-
-``Incorporate'' means to publish or republish a Document, in whole or
-in part, as part of another Document.
-
-An MMC is ``eligible for relicensing'' if it is licensed under this
-License, and if all works that were first published under this License
-somewhere other than this MMC, and subsequently incorporated in whole
-or in part into the MMC, (1) had no cover texts or invariant sections,
-and (2) were thus incorporated prior to November 1, 2008.
-
-The operator of an MMC Site may republish an MMC contained in the site
-under CC-BY-SA on the same site at any time before August 1, 2009,
-provided the MMC is eligible for relicensing.
-
-@end enumerate
-
-@page
-@heading ADDENDUM: How to use this License for your documents
-
-To use this License in a document you have written, include a copy of
-the License in the document and put the following copyright and
-license notices just after the title page:
-
-@smallexample
-@group
-  Copyright (C)  @var{year}  @var{your name}.
-  Permission is granted to copy, distribute and/or modify this document
-  under the terms of the GNU Free Documentation License, Version 1.3
-  or any later version published by the Free Software Foundation;
-  with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
-  Texts.  A copy of the license is included in the section entitled ``GNU
-  Free Documentation License''.
-@end group
-@end smallexample
-
-If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
-replace the ``with@dots{}Texts.'' line with this:
-
-@smallexample
-@group
-    with the Invariant Sections being @var{list their titles}, with
-    the Front-Cover Texts being @var{list}, and with the Back-Cover Texts
-    being @var{list}.
-@end group
-@end smallexample
-
-If you have Invariant Sections without Cover Texts, or some other
-combination of the three, merge those two alternatives to suit the
-situation.
-
-If your document contains nontrivial examples of program code, we
-recommend releasing these examples in parallel under your choice of
-free software license, such as the GNU General Public License,
-to permit their use in free software.
-
-@c Local Variables:
-@c ispell-local-pdict: "ispell-dict"
-@c End:
diff --git a/contrib/gdb-7/gdb/doc/gdb.texinfo b/contrib/gdb-7/gdb/doc/gdb.texinfo
deleted file mode 100644 (file)
index d4fec54..0000000
+++ /dev/null
@@ -1,41708 +0,0 @@
-\input texinfo      @c -*-texinfo-*-
-@c Copyright (C) 1988-2013 Free Software Foundation, Inc.
-@c
-@c %**start of header
-@c makeinfo ignores cmds prev to setfilename, so its arg cannot make use
-@c of @set vars.  However, you can override filename with makeinfo -o.
-@setfilename gdb.info
-@c
-@include gdb-cfg.texi
-@c
-@settitle Debugging with @value{GDBN}
-@setchapternewpage odd
-@c %**end of header
-
-@iftex
-@c @smallbook
-@c @cropmarks
-@end iftex
-
-@finalout
-@c To avoid file-name clashes between index.html and Index.html, when
-@c the manual is produced on a Posix host and then moved to a
-@c case-insensitive filesystem (e.g., MS-Windows), we separate the
-@c indices into two: Concept Index and all the rest.
-@syncodeindex ky fn
-@syncodeindex tp fn
-
-@c readline appendices use @vindex, @findex and @ftable,
-@c annotate.texi and gdbmi use @findex.
-@syncodeindex vr fn
-
-@c !!set GDB manual's edition---not the same as GDB version!
-@c This is updated by GNU Press.
-@set EDITION Tenth
-
-@c !!set GDB edit command default editor
-@set EDITOR /bin/ex
-
-@c THIS MANUAL REQUIRES TEXINFO 4.0 OR LATER.
-
-@c This is a dir.info fragment to support semi-automated addition of
-@c manuals to an info tree.
-@dircategory Software development
-@direntry
-* Gdb: (gdb).                     The GNU debugger.
-@end direntry
-
-@copying
-Copyright @copyright{} 1988-2013 Free Software Foundation, Inc.
-
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with the
-Invariant Sections being ``Free Software'' and ``Free Software Needs
-Free Documentation'', with the Front-Cover Texts being ``A GNU Manual,''
-and with the Back-Cover Texts as in (a) below.
-
-(a) The FSF's Back-Cover Text is: ``You are free to copy and modify
-this GNU Manual.  Buying copies from GNU Press supports the FSF in
-developing GNU and promoting software freedom.''
-@end copying
-
-@ifnottex
-This file documents the @sc{gnu} debugger @value{GDBN}.
-
-This is the @value{EDITION} Edition, of @cite{Debugging with
-@value{GDBN}: the @sc{gnu} Source-Level Debugger} for @value{GDBN}
-@ifset VERSION_PACKAGE
-@value{VERSION_PACKAGE}
-@end ifset
-Version @value{GDBVN}.
-
-@insertcopying
-@end ifnottex
-
-@titlepage
-@title Debugging with @value{GDBN}
-@subtitle The @sc{gnu} Source-Level Debugger
-@sp 1
-@subtitle @value{EDITION} Edition, for @value{GDBN} version @value{GDBVN}
-@ifset VERSION_PACKAGE
-@sp 1
-@subtitle @value{VERSION_PACKAGE}
-@end ifset
-@author Richard Stallman, Roland Pesch, Stan Shebs, et al.
-@page
-@tex
-{\parskip=0pt
-\hfill (Send bugs and comments on @value{GDBN} to @value{BUGURL}.)\par
-\hfill {\it Debugging with @value{GDBN}}\par
-\hfill \TeX{}info \texinfoversion\par
-}
-@end tex
-
-@vskip 0pt plus 1filll
-Published by the Free Software Foundation @*
-51 Franklin Street, Fifth Floor,
-Boston, MA 02110-1301, USA@*
-ISBN 978-0-9831592-3-0 @*
-
-@insertcopying
-@end titlepage
-@page
-
-@ifnottex
-@node Top, Summary, (dir), (dir)
-
-@top Debugging with @value{GDBN}
-
-This file describes @value{GDBN}, the @sc{gnu} symbolic debugger.
-
-This is the @value{EDITION} Edition, for @value{GDBN}
-@ifset VERSION_PACKAGE
-@value{VERSION_PACKAGE}
-@end ifset
-Version @value{GDBVN}.
-
-Copyright (C) 1988-2013 Free Software Foundation, Inc.
-
-This edition of the GDB manual is dedicated to the memory of Fred
-Fish.  Fred was a long-standing contributor to GDB and to Free
-software in general.  We will miss him.
-
-@menu
-* Summary::                     Summary of @value{GDBN}
-* Sample Session::              A sample @value{GDBN} session
-
-* Invocation::                  Getting in and out of @value{GDBN}
-* Commands::                    @value{GDBN} commands
-* Running::                     Running programs under @value{GDBN}
-* Stopping::                    Stopping and continuing
-* Reverse Execution::           Running programs backward
-* Process Record and Replay::   Recording inferior's execution and replaying it
-* Stack::                       Examining the stack
-* Source::                      Examining source files
-* Data::                        Examining data
-* Optimized Code::              Debugging optimized code
-* Macros::                      Preprocessor Macros
-* Tracepoints::                 Debugging remote targets non-intrusively
-* Overlays::                    Debugging programs that use overlays
-
-* Languages::                   Using @value{GDBN} with different languages
-
-* Symbols::                     Examining the symbol table
-* Altering::                    Altering execution
-* GDB Files::                   @value{GDBN} files
-* Targets::                     Specifying a debugging target
-* Remote Debugging::            Debugging remote programs
-* Configurations::              Configuration-specific information
-* Controlling GDB::             Controlling @value{GDBN}
-* Extending GDB::               Extending @value{GDBN}
-* Interpreters::               Command Interpreters
-* TUI::                         @value{GDBN} Text User Interface
-* Emacs::                       Using @value{GDBN} under @sc{gnu} Emacs
-* GDB/MI::                      @value{GDBN}'s Machine Interface.
-* Annotations::                 @value{GDBN}'s annotation interface.
-* JIT Interface::               Using the JIT debugging interface.
-* In-Process Agent::            In-Process Agent
-
-* GDB Bugs::                    Reporting bugs in @value{GDBN}
-
-@ifset SYSTEM_READLINE
-* Command Line Editing: (rluserman).         Command Line Editing
-* Using History Interactively: (history).    Using History Interactively
-@end ifset
-@ifclear SYSTEM_READLINE
-* Command Line Editing::        Command Line Editing
-* Using History Interactively:: Using History Interactively
-@end ifclear
-* In Memoriam::                 In Memoriam
-* Formatting Documentation::    How to format and print @value{GDBN} documentation
-* Installing GDB::              Installing GDB
-* Maintenance Commands::        Maintenance Commands
-* Remote Protocol::             GDB Remote Serial Protocol
-* Agent Expressions::           The GDB Agent Expression Mechanism
-* Target Descriptions::         How targets can describe themselves to
-                                @value{GDBN}
-* Operating System Information:: Getting additional information from
-                                 the operating system
-* Trace File Format::          GDB trace file format
-* Index Section Format::        .gdb_index section format
-* Copying::                    GNU General Public License says
-                                how you can copy and share GDB
-* GNU Free Documentation License::  The license for this documentation
-* Concept Index::               Index of @value{GDBN} concepts
-* Command and Variable Index::  Index of @value{GDBN} commands, variables,
-                                  functions, and Python data types
-@end menu
-
-@end ifnottex
-
-@contents
-
-@node Summary
-@unnumbered Summary of @value{GDBN}
-
-The purpose of a debugger such as @value{GDBN} is to allow you to see what is
-going on ``inside'' another program while it executes---or what another
-program was doing at the moment it crashed.
-
-@value{GDBN} can do four main kinds of things (plus other things in support of
-these) to help you catch bugs in the act:
-
-@itemize @bullet
-@item
-Start your program, specifying anything that might affect its behavior.
-
-@item
-Make your program stop on specified conditions.
-
-@item
-Examine what has happened, when your program has stopped.
-
-@item
-Change things in your program, so you can experiment with correcting the
-effects of one bug and go on to learn about another.
-@end itemize
-
-You can use @value{GDBN} to debug programs written in C and C@t{++}.
-For more information, see @ref{Supported Languages,,Supported Languages}.
-For more information, see @ref{C,,C and C++}.
-
-Support for D is partial.  For information on D, see
-@ref{D,,D}.
-
-@cindex Modula-2
-Support for Modula-2 is partial.  For information on Modula-2, see
-@ref{Modula-2,,Modula-2}.
-
-Support for OpenCL C is partial.  For information on OpenCL C, see
-@ref{OpenCL C,,OpenCL C}.
-
-@cindex Pascal
-Debugging Pascal programs which use sets, subranges, file variables, or
-nested functions does not currently work.  @value{GDBN} does not support
-entering expressions, printing values, or similar features using Pascal
-syntax.
-
-@cindex Fortran
-@value{GDBN} can be used to debug programs written in Fortran, although
-it may be necessary to refer to some variables with a trailing
-underscore.
-
-@value{GDBN} can be used to debug programs written in Objective-C,
-using either the Apple/NeXT or the GNU Objective-C runtime.
-
-@menu
-* Free Software::               Freely redistributable software
-* Free Documentation::          Free Software Needs Free Documentation
-* Contributors::                Contributors to GDB
-@end menu
-
-@node Free Software
-@unnumberedsec Free Software
-
-@value{GDBN} is @dfn{free software}, protected by the @sc{gnu}
-General Public License
-(GPL).  The GPL gives you the freedom to copy or adapt a licensed
-program---but every person getting a copy also gets with it the
-freedom to modify that copy (which means that they must get access to
-the source code), and the freedom to distribute further copies.
-Typical software companies use copyrights to limit your freedoms; the
-Free Software Foundation uses the GPL to preserve these freedoms.
-
-Fundamentally, the General Public License is a license which says that
-you have these freedoms and that you cannot take these freedoms away
-from anyone else.
-
-@node Free Documentation
-@unnumberedsec Free Software Needs Free Documentation
-
-The biggest deficiency in the free software community today is not in
-the software---it is the lack of good free documentation that we can
-include with the free software.  Many of our most important
-programs do not come with free reference manuals and free introductory
-texts.  Documentation is an essential part of any software package;
-when an important free software package does not come with a free
-manual and a free tutorial, that is a major gap.  We have many such
-gaps today.
-
-Consider Perl, for instance.  The tutorial manuals that people
-normally use are non-free.  How did this come about?  Because the
-authors of those manuals published them with restrictive terms---no
-copying, no modification, source files not available---which exclude
-them from the free software world.
-
-That wasn't the first time this sort of thing happened, and it was far
-from the last.  Many times we have heard a GNU user eagerly describe a
-manual that he is writing, his intended contribution to the community,
-only to learn that he had ruined everything by signing a publication
-contract to make it non-free.
-
-Free documentation, like free software, is a matter of freedom, not
-price.  The problem with the non-free manual is not that publishers
-charge a price for printed copies---that in itself is fine.  (The Free
-Software Foundation sells printed copies of manuals, too.)  The
-problem is the restrictions on the use of the manual.  Free manuals
-are available in source code form, and give you permission to copy and
-modify.  Non-free manuals do not allow this.
-
-The criteria of freedom for a free manual are roughly the same as for
-free software.  Redistribution (including the normal kinds of
-commercial redistribution) must be permitted, so that the manual can
-accompany every copy of the program, both on-line and on paper.
-
-Permission for modification of the technical content is crucial too.
-When people modify the software, adding or changing features, if they
-are conscientious they will change the manual too---so they can
-provide accurate and clear documentation for the modified program.  A
-manual that leaves you no choice but to write a new manual to document
-a changed version of the program is not really available to our
-community.
-
-Some kinds of limits on the way modification is handled are
-acceptable.  For example, requirements to preserve the original
-author's copyright notice, the distribution terms, or the list of
-authors, are ok.  It is also no problem to require modified versions
-to include notice that they were modified.  Even entire sections that
-may not be deleted or changed are acceptable, as long as they deal
-with nontechnical topics (like this one).  These kinds of restrictions
-are acceptable because they don't obstruct the community's normal use
-of the manual.
-
-However, it must be possible to modify all the @emph{technical}
-content of the manual, and then distribute the result in all the usual
-media, through all the usual channels.  Otherwise, the restrictions
-obstruct the use of the manual, it is not free, and we need another
-manual to replace it.
-
-Please spread the word about this issue.  Our community continues to
-lose manuals to proprietary publishing.  If we spread the word that
-free software needs free reference manuals and free tutorials, perhaps
-the next person who wants to contribute by writing documentation will
-realize, before it is too late, that only free manuals contribute to
-the free software community.
-
-If you are writing documentation, please insist on publishing it under
-the GNU Free Documentation License or another free documentation
-license.  Remember that this decision requires your approval---you
-don't have to let the publisher decide.  Some commercial publishers
-will use a free license if you insist, but they will not propose the
-option; it is up to you to raise the issue and say firmly that this is
-what you want.  If the publisher you are dealing with refuses, please
-try other publishers.  If you're not sure whether a proposed license
-is free, write to @email{licensing@@gnu.org}.
-
-You can encourage commercial publishers to sell more free, copylefted
-manuals and tutorials by buying them, and particularly by buying
-copies from the publishers that paid for their writing or for major
-improvements.  Meanwhile, try to avoid buying non-free documentation
-at all.  Check the distribution terms of a manual before you buy it,
-and insist that whoever seeks your business must respect your freedom.
-Check the history of the book, and try to reward the publishers that
-have paid or pay the authors to work on it.
-
-The Free Software Foundation maintains a list of free documentation
-published by other publishers, at
-@url{http://www.fsf.org/doc/other-free-books.html}.
-
-@node Contributors
-@unnumberedsec Contributors to @value{GDBN}
-
-Richard Stallman was the original author of @value{GDBN}, and of many
-other @sc{gnu} programs.  Many others have contributed to its
-development.  This section attempts to credit major contributors.  One
-of the virtues of free software is that everyone is free to contribute
-to it; with regret, we cannot actually acknowledge everyone here.  The
-file @file{ChangeLog} in the @value{GDBN} distribution approximates a
-blow-by-blow account.
-
-Changes much prior to version 2.0 are lost in the mists of time.
-
-@quotation
-@emph{Plea:} Additions to this section are particularly welcome.  If you
-or your friends (or enemies, to be evenhanded) have been unfairly
-omitted from this list, we would like to add your names!
-@end quotation
-
-So that they may not regard their many labors as thankless, we
-particularly thank those who shepherded @value{GDBN} through major
-releases:
-Andrew Cagney (releases 6.3, 6.2, 6.1, 6.0, 5.3, 5.2, 5.1 and 5.0);
-Jim Blandy (release 4.18);
-Jason Molenda (release 4.17);
-Stan Shebs (release 4.14);
-Fred Fish (releases 4.16, 4.15, 4.13, 4.12, 4.11, 4.10, and 4.9);
-Stu Grossman and John Gilmore (releases 4.8, 4.7, 4.6, 4.5, and 4.4);
-John Gilmore (releases 4.3, 4.2, 4.1, 4.0, and 3.9);
-Jim Kingdon (releases 3.5, 3.4, and 3.3);
-and Randy Smith (releases 3.2, 3.1, and 3.0).
-
-Richard Stallman, assisted at various times by Peter TerMaat, Chris
-Hanson, and Richard Mlynarik, handled releases through 2.8.
-
-Michael Tiemann is the author of most of the @sc{gnu} C@t{++} support
-in @value{GDBN}, with significant additional contributions from Per
-Bothner and Daniel Berlin.  James Clark wrote the @sc{gnu} C@t{++}
-demangler.  Early work on C@t{++} was by Peter TerMaat (who also did
-much general update work leading to release 3.0).
-
-@value{GDBN} uses the BFD subroutine library to examine multiple
-object-file formats; BFD was a joint project of David V.
-Henkel-Wallace, Rich Pixley, Steve Chamberlain, and John Gilmore.
-
-David Johnson wrote the original COFF support; Pace Willison did
-the original support for encapsulated COFF.
-
-Brent Benson of Harris Computer Systems contributed DWARF 2 support.
-
-Adam de Boor and Bradley Davis contributed the ISI Optimum V support.
-Per Bothner, Noboyuki Hikichi, and Alessandro Forin contributed MIPS
-support.
-Jean-Daniel Fekete contributed Sun 386i support.
-Chris Hanson improved the HP9000 support.
-Noboyuki Hikichi and Tomoyuki Hasei contributed Sony/News OS 3 support.
-David Johnson contributed Encore Umax support.
-Jyrki Kuoppala contributed Altos 3068 support.
-Jeff Law contributed HP PA and SOM support.
-Keith Packard contributed NS32K support.
-Doug Rabson contributed Acorn Risc Machine support.
-Bob Rusk contributed Harris Nighthawk CX-UX support.
-Chris Smith contributed Convex support (and Fortran debugging).
-Jonathan Stone contributed Pyramid support.
-Michael Tiemann contributed SPARC support.
-Tim Tucker contributed support for the Gould NP1 and Gould Powernode.
-Pace Willison contributed Intel 386 support.
-Jay Vosburgh contributed Symmetry support.
-Marko Mlinar contributed OpenRISC 1000 support.
-
-Andreas Schwab contributed M68K @sc{gnu}/Linux support.
-
-Rich Schaefer and Peter Schauer helped with support of SunOS shared
-libraries.
-
-Jay Fenlason and Roland McGrath ensured that @value{GDBN} and GAS agree
-about several machine instruction sets.
-
-Patrick Duval, Ted Goldstein, Vikram Koka and Glenn Engel helped develop
-remote debugging.  Intel Corporation, Wind River Systems, AMD, and ARM
-contributed remote debugging modules for the i960, VxWorks, A29K UDI,
-and RDI targets, respectively.
-
-Brian Fox is the author of the readline libraries providing
-command-line editing and command history.
-
-Andrew Beers of SUNY Buffalo wrote the language-switching code, the
-Modula-2 support, and contributed the Languages chapter of this manual.
-
-Fred Fish wrote most of the support for Unix System Vr4.
-He also enhanced the command-completion support to cover C@t{++} overloaded
-symbols.
-
-Hitachi America (now Renesas America), Ltd. sponsored the support for
-H8/300, H8/500, and Super-H processors.
-
-NEC sponsored the support for the v850, Vr4xxx, and Vr5xxx processors.
-
-Mitsubishi (now Renesas) sponsored the support for D10V, D30V, and M32R/D
-processors.
-
-Toshiba sponsored the support for the TX39 Mips processor.
-
-Matsushita sponsored the support for the MN10200 and MN10300 processors.
-
-Fujitsu sponsored the support for SPARClite and FR30 processors.
-
-Kung Hsu, Jeff Law, and Rick Sladkey added support for hardware
-watchpoints.
-
-Michael Snyder added support for tracepoints.
-
-Stu Grossman wrote gdbserver.
-
-Jim Kingdon, Peter Schauer, Ian Taylor, and Stu Grossman made
-nearly innumerable bug fixes and cleanups throughout @value{GDBN}.
-
-The following people at the Hewlett-Packard Company contributed
-support for the PA-RISC 2.0 architecture, HP-UX 10.20, 10.30, and 11.0
-(narrow mode), HP's implementation of kernel threads, HP's aC@t{++}
-compiler, and the Text User Interface (nee Terminal User Interface):
-Ben Krepp, Richard Title, John Bishop, Susan Macchia, Kathy Mann,
-Satish Pai, India Paul, Steve Rehrauer, and Elena Zannoni.  Kim Haase
-provided HP-specific information in this manual.
-
-DJ Delorie ported @value{GDBN} to MS-DOS, for the DJGPP project.
-Robert Hoehne made significant contributions to the DJGPP port.
-
-Cygnus Solutions has sponsored @value{GDBN} maintenance and much of its
-development since 1991.  Cygnus engineers who have worked on @value{GDBN}
-fulltime include Mark Alexander, Jim Blandy, Per Bothner, Kevin
-Buettner, Edith Epstein, Chris Faylor, Fred Fish, Martin Hunt, Jim
-Ingham, John Gilmore, Stu Grossman, Kung Hsu, Jim Kingdon, John Metzler,
-Fernando Nasser, Geoffrey Noer, Dawn Perchik, Rich Pixley, Zdenek
-Radouch, Keith Seitz, Stan Shebs, David Taylor, and Elena Zannoni.  In
-addition, Dave Brolley, Ian Carmichael, Steve Chamberlain, Nick Clifton,
-JT Conklin, Stan Cox, DJ Delorie, Ulrich Drepper, Frank Eigler, Doug
-Evans, Sean Fagan, David Henkel-Wallace, Richard Henderson, Jeff
-Holcomb, Jeff Law, Jim Lemke, Tom Lord, Bob Manson, Michael Meissner,
-Jason Merrill, Catherine Moore, Drew Moseley, Ken Raeburn, Gavin
-Romig-Koch, Rob Savoye, Jamie Smith, Mike Stump, Ian Taylor, Angela
-Thomas, Michael Tiemann, Tom Tromey, Ron Unrau, Jim Wilson, and David
-Zuhn have made contributions both large and small.
-
-Andrew Cagney, Fernando Nasser, and Elena Zannoni, while working for
-Cygnus Solutions, implemented the original @sc{gdb/mi} interface.
-
-Jim Blandy added support for preprocessor macros, while working for Red
-Hat.
-
-Andrew Cagney designed @value{GDBN}'s architecture vector.  Many
-people including Andrew Cagney, Stephane Carrez, Randolph Chung, Nick
-Duffek, Richard Henderson, Mark Kettenis, Grace Sainsbury, Kei
-Sakamoto, Yoshinori Sato, Michael Snyder, Andreas Schwab, Jason
-Thorpe, Corinna Vinschen, Ulrich Weigand, and Elena Zannoni, helped
-with the migration of old architectures to this new framework.
-
-Andrew Cagney completely re-designed and re-implemented @value{GDBN}'s
-unwinder framework, this consisting of a fresh new design featuring
-frame IDs, independent frame sniffers, and the sentinel frame.  Mark
-Kettenis implemented the @sc{dwarf 2} unwinder, Jeff Johnston the
-libunwind unwinder, and Andrew Cagney the dummy, sentinel, tramp, and
-trad unwinders.  The architecture-specific changes, each involving a
-complete rewrite of the architecture's frame code, were carried out by
-Jim Blandy, Joel Brobecker, Kevin Buettner, Andrew Cagney, Stephane
-Carrez, Randolph Chung, Orjan Friberg, Richard Henderson, Daniel
-Jacobowitz, Jeff Johnston, Mark Kettenis, Theodore A. Roth, Kei
-Sakamoto, Yoshinori Sato, Michael Snyder, Corinna Vinschen, and Ulrich
-Weigand.
-
-Christian Zankel, Ross Morley, Bob Wilson, and Maxim Grigoriev from
-Tensilica, Inc.@: contributed support for Xtensa processors.  Others
-who have worked on the Xtensa port of @value{GDBN} in the past include
-Steve Tjiang, John Newlin, and Scott Foehner.
-
-Michael Eager and staff of Xilinx, Inc., contributed support for the
-Xilinx MicroBlaze architecture.
-
-@node Sample Session
-@chapter A Sample @value{GDBN} Session
-
-You can use this manual at your leisure to read all about @value{GDBN}.
-However, a handful of commands are enough to get started using the
-debugger.  This chapter illustrates those commands.
-
-@iftex
-In this sample session, we emphasize user input like this: @b{input},
-to make it easier to pick out from the surrounding output.
-@end iftex
-
-@c FIXME: this example may not be appropriate for some configs, where
-@c FIXME...primary interest is in remote use.
-
-One of the preliminary versions of @sc{gnu} @code{m4} (a generic macro
-processor) exhibits the following bug: sometimes, when we change its
-quote strings from the default, the commands used to capture one macro
-definition within another stop working.  In the following short @code{m4}
-session, we define a macro @code{foo} which expands to @code{0000}; we
-then use the @code{m4} built-in @code{defn} to define @code{bar} as the
-same thing.  However, when we change the open quote string to
-@code{<QUOTE>} and the close quote string to @code{<UNQUOTE>}, the same
-procedure fails to define a new synonym @code{baz}:
-
-@smallexample
-$ @b{cd gnu/m4}
-$ @b{./m4}
-@b{define(foo,0000)}
-
-@b{foo}
-0000
-@b{define(bar,defn(`foo'))}
-
-@b{bar}
-0000
-@b{changequote(<QUOTE>,<UNQUOTE>)}
-
-@b{define(baz,defn(<QUOTE>foo<UNQUOTE>))}
-@b{baz}
-@b{Ctrl-d}
-m4: End of input: 0: fatal error: EOF in string
-@end smallexample
-
-@noindent
-Let us use @value{GDBN} to try to see what is going on.
-
-@smallexample
-$ @b{@value{GDBP} m4}
-@c FIXME: this falsifies the exact text played out, to permit smallbook
-@c FIXME... format to come out better.
-@value{GDBN} is free software and you are welcome to distribute copies
- of it under certain conditions; type "show copying" to see
- the conditions.
-There is absolutely no warranty for @value{GDBN}; type "show warranty"
- for details.
-
-@value{GDBN} @value{GDBVN}, Copyright 1999 Free Software Foundation, Inc...
-(@value{GDBP})
-@end smallexample
-
-@noindent
-@value{GDBN} reads only enough symbol data to know where to find the
-rest when needed; as a result, the first prompt comes up very quickly.
-We now tell @value{GDBN} to use a narrower display width than usual, so
-that examples fit in this manual.
-
-@smallexample
-(@value{GDBP}) @b{set width 70}
-@end smallexample
-
-@noindent
-We need to see how the @code{m4} built-in @code{changequote} works.
-Having looked at the source, we know the relevant subroutine is
-@code{m4_changequote}, so we set a breakpoint there with the @value{GDBN}
-@code{break} command.
-
-@smallexample
-(@value{GDBP}) @b{break m4_changequote}
-Breakpoint 1 at 0x62f4: file builtin.c, line 879.
-@end smallexample
-
-@noindent
-Using the @code{run} command, we start @code{m4} running under @value{GDBN}
-control; as long as control does not reach the @code{m4_changequote}
-subroutine, the program runs as usual:
-
-@smallexample
-(@value{GDBP}) @b{run}
-Starting program: /work/Editorial/gdb/gnu/m4/m4
-@b{define(foo,0000)}
-
-@b{foo}
-0000
-@end smallexample
-
-@noindent
-To trigger the breakpoint, we call @code{changequote}.  @value{GDBN}
-suspends execution of @code{m4}, displaying information about the
-context where it stops.
-
-@smallexample
-@b{changequote(<QUOTE>,<UNQUOTE>)}
-
-Breakpoint 1, m4_changequote (argc=3, argv=0x33c70)
-    at builtin.c:879
-879         if (bad_argc(TOKEN_DATA_TEXT(argv[0]),argc,1,3))
-@end smallexample
-
-@noindent
-Now we use the command @code{n} (@code{next}) to advance execution to
-the next line of the current function.
-
-@smallexample
-(@value{GDBP}) @b{n}
-882         set_quotes((argc >= 2) ? TOKEN_DATA_TEXT(argv[1])\
- : nil,
-@end smallexample
-
-@noindent
-@code{set_quotes} looks like a promising subroutine.  We can go into it
-by using the command @code{s} (@code{step}) instead of @code{next}.
-@code{step} goes to the next line to be executed in @emph{any}
-subroutine, so it steps into @code{set_quotes}.
-
-@smallexample
-(@value{GDBP}) @b{s}
-set_quotes (lq=0x34c78 "<QUOTE>", rq=0x34c88 "<UNQUOTE>")
-    at input.c:530
-530         if (lquote != def_lquote)
-@end smallexample
-
-@noindent
-The display that shows the subroutine where @code{m4} is now
-suspended (and its arguments) is called a stack frame display.  It
-shows a summary of the stack.  We can use the @code{backtrace}
-command (which can also be spelled @code{bt}), to see where we are
-in the stack as a whole: the @code{backtrace} command displays a
-stack frame for each active subroutine.
-
-@smallexample
-(@value{GDBP}) @b{bt}
-#0  set_quotes (lq=0x34c78 "<QUOTE>", rq=0x34c88 "<UNQUOTE>")
-    at input.c:530
-#1  0x6344 in m4_changequote (argc=3, argv=0x33c70)
-    at builtin.c:882
-#2  0x8174 in expand_macro (sym=0x33320) at macro.c:242
-#3  0x7a88 in expand_token (obs=0x0, t=209696, td=0xf7fffa30)
-    at macro.c:71
-#4  0x79dc in expand_input () at macro.c:40
-#5  0x2930 in main (argc=0, argv=0xf7fffb20) at m4.c:195
-@end smallexample
-
-@noindent
-We step through a few more lines to see what happens.  The first two
-times, we can use @samp{s}; the next two times we use @code{n} to avoid
-falling into the @code{xstrdup} subroutine.
-
-@smallexample
-(@value{GDBP}) @b{s}
-0x3b5c  532         if (rquote != def_rquote)
-(@value{GDBP}) @b{s}
-0x3b80  535         lquote = (lq == nil || *lq == '\0') ?  \
-def_lquote : xstrdup(lq);
-(@value{GDBP}) @b{n}
-536         rquote = (rq == nil || *rq == '\0') ? def_rquote\
- : xstrdup(rq);
-(@value{GDBP}) @b{n}
-538         len_lquote = strlen(rquote);
-@end smallexample
-
-@noindent
-The last line displayed looks a little odd; we can examine the variables
-@code{lquote} and @code{rquote} to see if they are in fact the new left
-and right quotes we specified.  We use the command @code{p}
-(@code{print}) to see their values.
-
-@smallexample
-(@value{GDBP}) @b{p lquote}
-$1 = 0x35d40 "<QUOTE>"
-(@value{GDBP}) @b{p rquote}
-$2 = 0x35d50 "<UNQUOTE>"
-@end smallexample
-
-@noindent
-@code{lquote} and @code{rquote} are indeed the new left and right quotes.
-To look at some context, we can display ten lines of source
-surrounding the current line with the @code{l} (@code{list}) command.
-
-@smallexample
-(@value{GDBP}) @b{l}
-533             xfree(rquote);
-534
-535         lquote = (lq == nil || *lq == '\0') ? def_lquote\
- : xstrdup (lq);
-536         rquote = (rq == nil || *rq == '\0') ? def_rquote\
- : xstrdup (rq);
-537
-538         len_lquote = strlen(rquote);
-539         len_rquote = strlen(lquote);
-540     @}
-541
-542     void
-@end smallexample
-
-@noindent
-Let us step past the two lines that set @code{len_lquote} and
-@code{len_rquote}, and then examine the values of those variables.
-
-@smallexample
-(@value{GDBP}) @b{n}
-539         len_rquote = strlen(lquote);
-(@value{GDBP}) @b{n}
-540     @}
-(@value{GDBP}) @b{p len_lquote}
-$3 = 9
-(@value{GDBP}) @b{p len_rquote}
-$4 = 7
-@end smallexample
-
-@noindent
-That certainly looks wrong, assuming @code{len_lquote} and
-@code{len_rquote} are meant to be the lengths of @code{lquote} and
-@code{rquote} respectively.  We can set them to better values using
-the @code{p} command, since it can print the value of
-any expression---and that expression can include subroutine calls and
-assignments.
-
-@smallexample
-(@value{GDBP}) @b{p len_lquote=strlen(lquote)}
-$5 = 7
-(@value{GDBP}) @b{p len_rquote=strlen(rquote)}
-$6 = 9
-@end smallexample
-
-@noindent
-Is that enough to fix the problem of using the new quotes with the
-@code{m4} built-in @code{defn}?  We can allow @code{m4} to continue
-executing with the @code{c} (@code{continue}) command, and then try the
-example that caused trouble initially:
-
-@smallexample
-(@value{GDBP}) @b{c}
-Continuing.
-
-@b{define(baz,defn(<QUOTE>foo<UNQUOTE>))}
-
-baz
-0000
-@end smallexample
-
-@noindent
-Success!  The new quotes now work just as well as the default ones.  The
-problem seems to have been just the two typos defining the wrong
-lengths.  We allow @code{m4} exit by giving it an EOF as input:
-
-@smallexample
-@b{Ctrl-d}
-Program exited normally.
-@end smallexample
-
-@noindent
-The message @samp{Program exited normally.} is from @value{GDBN}; it
-indicates @code{m4} has finished executing.  We can end our @value{GDBN}
-session with the @value{GDBN} @code{quit} command.
-
-@smallexample
-(@value{GDBP}) @b{quit}
-@end smallexample
-
-@node Invocation
-@chapter Getting In and Out of @value{GDBN}
-
-This chapter discusses how to start @value{GDBN}, and how to get out of it.
-The essentials are:
-@itemize @bullet
-@item
-type @samp{@value{GDBP}} to start @value{GDBN}.
-@item
-type @kbd{quit} or @kbd{Ctrl-d} to exit.
-@end itemize
-
-@menu
-* Invoking GDB::                How to start @value{GDBN}
-* Quitting GDB::                How to quit @value{GDBN}
-* Shell Commands::              How to use shell commands inside @value{GDBN}
-* Logging Output::              How to log @value{GDBN}'s output to a file
-@end menu
-
-@node Invoking GDB
-@section Invoking @value{GDBN}
-
-Invoke @value{GDBN} by running the program @code{@value{GDBP}}.  Once started,
-@value{GDBN} reads commands from the terminal until you tell it to exit.
-
-You can also run @code{@value{GDBP}} with a variety of arguments and options,
-to specify more of your debugging environment at the outset.
-
-The command-line options described here are designed
-to cover a variety of situations; in some environments, some of these
-options may effectively be unavailable.
-
-The most usual way to start @value{GDBN} is with one argument,
-specifying an executable program:
-
-@smallexample
-@value{GDBP} @var{program}
-@end smallexample
-
-@noindent
-You can also start with both an executable program and a core file
-specified:
-
-@smallexample
-@value{GDBP} @var{program} @var{core}
-@end smallexample
-
-You can, instead, specify a process ID as a second argument, if you want
-to debug a running process:
-
-@smallexample
-@value{GDBP} @var{program} 1234
-@end smallexample
-
-@noindent
-would attach @value{GDBN} to process @code{1234} (unless you also have a file
-named @file{1234}; @value{GDBN} does check for a core file first).
-
-Taking advantage of the second command-line argument requires a fairly
-complete operating system; when you use @value{GDBN} as a remote
-debugger attached to a bare board, there may not be any notion of
-``process'', and there is often no way to get a core dump.  @value{GDBN}
-will warn you if it is unable to attach or to read core dumps.
-
-You can optionally have @code{@value{GDBP}} pass any arguments after the
-executable file to the inferior using @code{--args}.  This option stops
-option processing.
-@smallexample
-@value{GDBP} --args gcc -O2 -c foo.c
-@end smallexample
-This will cause @code{@value{GDBP}} to debug @code{gcc}, and to set
-@code{gcc}'s command-line arguments (@pxref{Arguments}) to @samp{-O2 -c foo.c}.
-
-You can run @code{@value{GDBP}} without printing the front material, which describes
-@value{GDBN}'s non-warranty, by specifying @code{-silent}:
-
-@smallexample
-@value{GDBP} -silent
-@end smallexample
-
-@noindent
-You can further control how @value{GDBN} starts up by using command-line
-options.  @value{GDBN} itself can remind you of the options available.
-
-@noindent
-Type
-
-@smallexample
-@value{GDBP} -help
-@end smallexample
-
-@noindent
-to display all available options and briefly describe their use
-(@samp{@value{GDBP} -h} is a shorter equivalent).
-
-All options and command line arguments you give are processed
-in sequential order.  The order makes a difference when the
-@samp{-x} option is used.
-
-
-@menu
-* File Options::                Choosing files
-* Mode Options::                Choosing modes
-* Startup::                     What @value{GDBN} does during startup
-@end menu
-
-@node File Options
-@subsection Choosing Files
-
-When @value{GDBN} starts, it reads any arguments other than options as
-specifying an executable file and core file (or process ID).  This is
-the same as if the arguments were specified by the @samp{-se} and
-@samp{-c} (or @samp{-p}) options respectively.  (@value{GDBN} reads the
-first argument that does not have an associated option flag as
-equivalent to the @samp{-se} option followed by that argument; and the
-second argument that does not have an associated option flag, if any, as
-equivalent to the @samp{-c}/@samp{-p} option followed by that argument.)
-If the second argument begins with a decimal digit, @value{GDBN} will
-first attempt to attach to it as a process, and if that fails, attempt
-to open it as a corefile.  If you have a corefile whose name begins with
-a digit, you can prevent @value{GDBN} from treating it as a pid by
-prefixing it with @file{./}, e.g.@: @file{./12345}.
-
-If @value{GDBN} has not been configured to included core file support,
-such as for most embedded targets, then it will complain about a second
-argument and ignore it.
-
-Many options have both long and short forms; both are shown in the
-following list.  @value{GDBN} also recognizes the long forms if you truncate
-them, so long as enough of the option is present to be unambiguous.
-(If you prefer, you can flag option arguments with @samp{--} rather
-than @samp{-}, though we illustrate the more usual convention.)
-
-@c NOTE: the @cindex entries here use double dashes ON PURPOSE.  This
-@c way, both those who look for -foo and --foo in the index, will find
-@c it.
-
-@table @code
-@item -symbols @var{file}
-@itemx -s @var{file}
-@cindex @code{--symbols}
-@cindex @code{-s}
-Read symbol table from file @var{file}.
-
-@item -exec @var{file}
-@itemx -e @var{file}
-@cindex @code{--exec}
-@cindex @code{-e}
-Use file @var{file} as the executable file to execute when appropriate,
-and for examining pure data in conjunction with a core dump.
-
-@item -se @var{file}
-@cindex @code{--se}
-Read symbol table from file @var{file} and use it as the executable
-file.
-
-@item -core @var{file}
-@itemx -c @var{file}
-@cindex @code{--core}
-@cindex @code{-c}
-Use file @var{file} as a core dump to examine.
-
-@item -pid @var{number}
-@itemx -p @var{number}
-@cindex @code{--pid}
-@cindex @code{-p}
-Connect to process ID @var{number}, as with the @code{attach} command.
-
-@item -command @var{file}
-@itemx -x @var{file}
-@cindex @code{--command}
-@cindex @code{-x}
-Execute commands from file @var{file}.  The contents of this file is
-evaluated exactly as the @code{source} command would.
-@xref{Command Files,, Command files}.
-
-@item -eval-command @var{command}
-@itemx -ex @var{command}
-@cindex @code{--eval-command}
-@cindex @code{-ex}
-Execute a single @value{GDBN} command.
-
-This option may be used multiple times to call multiple commands.  It may
-also be interleaved with @samp{-command} as required.
-
-@smallexample
-@value{GDBP} -ex 'target sim' -ex 'load' \
-   -x setbreakpoints -ex 'run' a.out
-@end smallexample
-
-@item -init-command @var{file}
-@itemx -ix @var{file}
-@cindex @code{--init-command}
-@cindex @code{-ix}
-Execute commands from file @var{file} before loading the inferior (but
-after loading gdbinit files).
-@xref{Startup}.
-
-@item -init-eval-command @var{command}
-@itemx -iex @var{command}
-@cindex @code{--init-eval-command}
-@cindex @code{-iex}
-Execute a single @value{GDBN} command before loading the inferior (but
-after loading gdbinit files).
-@xref{Startup}.
-
-@item -directory @var{directory}
-@itemx -d @var{directory}
-@cindex @code{--directory}
-@cindex @code{-d}
-Add @var{directory} to the path to search for source and script files.
-
-@item -r
-@itemx -readnow
-@cindex @code{--readnow}
-@cindex @code{-r}
-Read each symbol file's entire symbol table immediately, rather than
-the default, which is to read it incrementally as it is needed.
-This makes startup slower, but makes future operations faster.
-
-@end table
-
-@node Mode Options
-@subsection Choosing Modes
-
-You can run @value{GDBN} in various alternative modes---for example, in
-batch mode or quiet mode.
-
-@table @code
-@anchor{-nx}
-@item -nx
-@itemx -n
-@cindex @code{--nx}
-@cindex @code{-n}
-Do not execute commands found in any initialization file.
-There are three init files, loaded in the following order:
-
-@table @code
-@item @file{system.gdbinit}
-This is the system-wide init file.
-Its location is specified with the @code{--with-system-gdbinit}
-configure option (@pxref{System-wide configuration}).
-It is loaded first when @value{GDBN} starts, before command line options
-have been processed.
-@item @file{~/.gdbinit}
-This is the init file in your home directory.
-It is loaded next, after @file{system.gdbinit}, and before
-command options have been processed.
-@item @file{./.gdbinit}
-This is the init file in the current directory.
-It is loaded last, after command line options other than @code{-x} and
-@code{-ex} have been processed.  Command line options @code{-x} and
-@code{-ex} are processed last, after @file{./.gdbinit} has been loaded.
-@end table
-
-For further documentation on startup processing, @xref{Startup}.
-For documentation on how to write command files,
-@xref{Command Files,,Command Files}.
-
-@anchor{-nh}
-@item -nh
-@cindex @code{--nh}
-Do not execute commands found in @file{~/.gdbinit}, the init file
-in your home directory.
-@xref{Startup}.
-
-@item -quiet
-@itemx -silent
-@itemx -q
-@cindex @code{--quiet}
-@cindex @code{--silent}
-@cindex @code{-q}
-``Quiet''.  Do not print the introductory and copyright messages.  These
-messages are also suppressed in batch mode.
-
-@item -batch
-@cindex @code{--batch}
-Run in batch mode.  Exit with status @code{0} after processing all the
-command files specified with @samp{-x} (and all commands from
-initialization files, if not inhibited with @samp{-n}).  Exit with
-nonzero status if an error occurs in executing the @value{GDBN} commands
-in the command files.  Batch mode also disables pagination, sets unlimited
-terminal width and height @pxref{Screen Size}, and acts as if @kbd{set confirm
-off} were in effect (@pxref{Messages/Warnings}).
-
-Batch mode may be useful for running @value{GDBN} as a filter, for
-example to download and run a program on another computer; in order to
-make this more useful, the message
-
-@smallexample
-Program exited normally.
-@end smallexample
-
-@noindent
-(which is ordinarily issued whenever a program running under
-@value{GDBN} control terminates) is not issued when running in batch
-mode.
-
-@item -batch-silent
-@cindex @code{--batch-silent}
-Run in batch mode exactly like @samp{-batch}, but totally silently.  All
-@value{GDBN} output to @code{stdout} is prevented (@code{stderr} is
-unaffected).  This is much quieter than @samp{-silent} and would be useless
-for an interactive session.
-
-This is particularly useful when using targets that give @samp{Loading section}
-messages, for example.
-
-Note that targets that give their output via @value{GDBN}, as opposed to
-writing directly to @code{stdout}, will also be made silent.
-
-@item -return-child-result
-@cindex @code{--return-child-result}
-The return code from @value{GDBN} will be the return code from the child
-process (the process being debugged), with the following exceptions:
-
-@itemize @bullet
-@item
-@value{GDBN} exits abnormally.  E.g., due to an incorrect argument or an
-internal error.  In this case the exit code is the same as it would have been
-without @samp{-return-child-result}.
-@item
-The user quits with an explicit value.  E.g., @samp{quit 1}.
-@item
-The child process never runs, or is not allowed to terminate, in which case
-the exit code will be -1.
-@end itemize
-
-This option is useful in conjunction with @samp{-batch} or @samp{-batch-silent},
-when @value{GDBN} is being used as a remote program loader or simulator
-interface.
-
-@item -nowindows
-@itemx -nw
-@cindex @code{--nowindows}
-@cindex @code{-nw}
-``No windows''.  If @value{GDBN} comes with a graphical user interface
-(GUI) built in, then this option tells @value{GDBN} to only use the command-line
-interface.  If no GUI is available, this option has no effect.
-
-@item -windows
-@itemx -w
-@cindex @code{--windows}
-@cindex @code{-w}
-If @value{GDBN} includes a GUI, then this option requires it to be
-used if possible.
-
-@item -cd @var{directory}
-@cindex @code{--cd}
-Run @value{GDBN} using @var{directory} as its working directory,
-instead of the current directory.
-
-@item -data-directory @var{directory}
-@cindex @code{--data-directory}
-Run @value{GDBN} using @var{directory} as its data directory.
-The data directory is where @value{GDBN} searches for its
-auxiliary files.  @xref{Data Files}.
-
-@item -fullname
-@itemx -f
-@cindex @code{--fullname}
-@cindex @code{-f}
-@sc{gnu} Emacs sets this option when it runs @value{GDBN} as a
-subprocess.  It tells @value{GDBN} to output the full file name and line
-number in a standard, recognizable fashion each time a stack frame is
-displayed (which includes each time your program stops).  This
-recognizable format looks like two @samp{\032} characters, followed by
-the file name, line number and character position separated by colons,
-and a newline.  The Emacs-to-@value{GDBN} interface program uses the two
-@samp{\032} characters as a signal to display the source code for the
-frame.
-
-@item -annotate @var{level}
-@cindex @code{--annotate}
-This option sets the @dfn{annotation level} inside @value{GDBN}.  Its
-effect is identical to using @samp{set annotate @var{level}}
-(@pxref{Annotations}).  The annotation @var{level} controls how much
-information @value{GDBN} prints together with its prompt, values of
-expressions, source lines, and other types of output.  Level 0 is the
-normal, level 1 is for use when @value{GDBN} is run as a subprocess of
-@sc{gnu} Emacs, level 3 is the maximum annotation suitable for programs
-that control @value{GDBN}, and level 2 has been deprecated.
-
-The annotation mechanism has largely been superseded by @sc{gdb/mi}
-(@pxref{GDB/MI}).
-
-@item --args
-@cindex @code{--args}
-Change interpretation of command line so that arguments following the
-executable file are passed as command line arguments to the inferior.
-This option stops option processing.
-
-@item -baud @var{bps}
-@itemx -b @var{bps}
-@cindex @code{--baud}
-@cindex @code{-b}
-Set the line speed (baud rate or bits per second) of any serial
-interface used by @value{GDBN} for remote debugging.
-
-@item -l @var{timeout}
-@cindex @code{-l}
-Set the timeout (in seconds) of any communication used by @value{GDBN}
-for remote debugging.
-
-@item -tty @var{device}
-@itemx -t @var{device}
-@cindex @code{--tty}
-@cindex @code{-t}
-Run using @var{device} for your program's standard input and output.
-@c FIXME: kingdon thinks there is more to -tty.  Investigate.
-
-@c resolve the situation of these eventually
-@item -tui
-@cindex @code{--tui}
-Activate the @dfn{Text User Interface} when starting.  The Text User
-Interface manages several text windows on the terminal, showing
-source, assembly, registers and @value{GDBN} command outputs
-(@pxref{TUI, ,@value{GDBN} Text User Interface}).  Do not use this
-option if you run @value{GDBN} from Emacs (@pxref{Emacs, ,
-Using @value{GDBN} under @sc{gnu} Emacs}).
-
-@c @item -xdb
-@c @cindex @code{--xdb}
-@c Run in XDB compatibility mode, allowing the use of certain XDB commands.
-@c For information, see the file @file{xdb_trans.html}, which is usually
-@c installed in the directory @code{/opt/langtools/wdb/doc} on HP-UX
-@c systems.
-
-@item -interpreter @var{interp}
-@cindex @code{--interpreter}
-Use the interpreter @var{interp} for interface with the controlling
-program or device.  This option is meant to be set by programs which
-communicate with @value{GDBN} using it as a back end.
-@xref{Interpreters, , Command Interpreters}.
-
-@samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes
-@value{GDBN} to use the @dfn{@sc{gdb/mi} interface} (@pxref{GDB/MI, ,
-The @sc{gdb/mi} Interface}) included since @value{GDBN} version 6.0.  The
-previous @sc{gdb/mi} interface, included in @value{GDBN} version 5.3 and
-selected with @samp{--interpreter=mi1}, is deprecated.  Earlier
-@sc{gdb/mi} interfaces are no longer supported.
-
-@item -write
-@cindex @code{--write}
-Open the executable and core files for both reading and writing.  This
-is equivalent to the @samp{set write on} command inside @value{GDBN}
-(@pxref{Patching}).
-
-@item -statistics
-@cindex @code{--statistics}
-This option causes @value{GDBN} to print statistics about time and
-memory usage after it completes each command and returns to the prompt.
-
-@item -version
-@cindex @code{--version}
-This option causes @value{GDBN} to print its version number and
-no-warranty blurb, and exit.
-
-@end table
-
-@node Startup
-@subsection What @value{GDBN} Does During Startup
-@cindex @value{GDBN} startup
-
-Here's the description of what @value{GDBN} does during session startup:
-
-@enumerate
-@item
-Sets up the command interpreter as specified by the command line
-(@pxref{Mode Options, interpreter}).
-
-@item
-@cindex init file
-Reads the system-wide @dfn{init file} (if @option{--with-system-gdbinit} was
-used when building @value{GDBN}; @pxref{System-wide configuration,
- ,System-wide configuration and settings}) and executes all the commands in
-that file.
-
-@anchor{Home Directory Init File}
-@item
-Reads the init file (if any) in your home directory@footnote{On
-DOS/Windows systems, the home directory is the one pointed to by the
-@code{HOME} environment variable.} and executes all the commands in
-that file.
-
-@anchor{Option -init-eval-command}
-@item
-Executes commands and command files specified by the @samp{-iex} and
-@samp{-ix} options in their specified order.  Usually you should use the
-@samp{-ex} and @samp{-x} options instead, but this way you can apply
-settings before @value{GDBN} init files get executed and before inferior
-gets loaded.
-
-@item
-Processes command line options and operands.
-
-@anchor{Init File in the Current Directory during Startup}
-@item
-Reads and executes the commands from init file (if any) in the current
-working directory as long as @samp{set auto-load local-gdbinit} is set to
-@samp{on} (@pxref{Init File in the Current Directory}).
-This is only done if the current directory is
-different from your home directory.  Thus, you can have more than one
-init file, one generic in your home directory, and another, specific
-to the program you are debugging, in the directory where you invoke
-@value{GDBN}.
-
-@item
-If the command line specified a program to debug, or a process to
-attach to, or a core file, @value{GDBN} loads any auto-loaded
-scripts provided for the program or for its loaded shared libraries.
-@xref{Auto-loading}.
-
-If you wish to disable the auto-loading during startup,
-you must do something like the following:
-
-@smallexample
-$ gdb -iex "set auto-load python-scripts off" myprogram
-@end smallexample
-
-Option @samp{-ex} does not work because the auto-loading is then turned
-off too late.
-
-@item
-Executes commands and command files specified by the @samp{-ex} and
-@samp{-x} options in their specified order.  @xref{Command Files}, for
-more details about @value{GDBN} command files.
-
-@item
-Reads the command history recorded in the @dfn{history file}.
-@xref{Command History}, for more details about the command history and the
-files where @value{GDBN} records it.
-@end enumerate
-
-Init files use the same syntax as @dfn{command files} (@pxref{Command
-Files}) and are processed by @value{GDBN} in the same way.  The init
-file in your home directory can set options (such as @samp{set
-complaints}) that affect subsequent processing of command line options
-and operands.  Init files are not executed if you use the @samp{-nx}
-option (@pxref{Mode Options, ,Choosing Modes}).
-
-To display the list of init files loaded by gdb at startup, you
-can use @kbd{gdb --help}.
-
-@cindex init file name
-@cindex @file{.gdbinit}
-@cindex @file{gdb.ini}
-The @value{GDBN} init files are normally called @file{.gdbinit}.
-The DJGPP port of @value{GDBN} uses the name @file{gdb.ini}, due to
-the limitations of file names imposed by DOS filesystems.  The Windows
-port of @value{GDBN} uses the standard name, but if it finds a
-@file{gdb.ini} file in your home directory, it warns you about that
-and suggests to rename the file to the standard name.
-
-
-@node Quitting GDB
-@section Quitting @value{GDBN}
-@cindex exiting @value{GDBN}
-@cindex leaving @value{GDBN}
-
-@table @code
-@kindex quit @r{[}@var{expression}@r{]}
-@kindex q @r{(@code{quit})}
-@item quit @r{[}@var{expression}@r{]}
-@itemx q
-To exit @value{GDBN}, use the @code{quit} command (abbreviated
-@code{q}), or type an end-of-file character (usually @kbd{Ctrl-d}).  If you
-do not supply @var{expression}, @value{GDBN} will terminate normally;
-otherwise it will terminate using the result of @var{expression} as the
-error code.
-@end table
-
-@cindex interrupt
-An interrupt (often @kbd{Ctrl-c}) does not exit from @value{GDBN}, but rather
-terminates the action of any @value{GDBN} command that is in progress and
-returns to @value{GDBN} command level.  It is safe to type the interrupt
-character at any time because @value{GDBN} does not allow it to take effect
-until a time when it is safe.
-
-If you have been using @value{GDBN} to control an attached process or
-device, you can release it with the @code{detach} command
-(@pxref{Attach, ,Debugging an Already-running Process}).
-
-@node Shell Commands
-@section Shell Commands
-
-If you need to execute occasional shell commands during your
-debugging session, there is no need to leave or suspend @value{GDBN}; you can
-just use the @code{shell} command.
-
-@table @code
-@kindex shell
-@kindex !
-@cindex shell escape
-@item shell @var{command-string}
-@itemx !@var{command-string}
-Invoke a standard shell to execute @var{command-string}.
-Note that no space is needed between @code{!} and @var{command-string}.
-If it exists, the environment variable @code{SHELL} determines which
-shell to run.  Otherwise @value{GDBN} uses the default shell
-(@file{/bin/sh} on Unix systems, @file{COMMAND.COM} on MS-DOS, etc.).
-@end table
-
-The utility @code{make} is often needed in development environments.
-You do not have to use the @code{shell} command for this purpose in
-@value{GDBN}:
-
-@table @code
-@kindex make
-@cindex calling make
-@item make @var{make-args}
-Execute the @code{make} program with the specified
-arguments.  This is equivalent to @samp{shell make @var{make-args}}.
-@end table
-
-@node Logging Output
-@section Logging Output
-@cindex logging @value{GDBN} output
-@cindex save @value{GDBN} output to a file
-
-You may want to save the output of @value{GDBN} commands to a file.
-There are several commands to control @value{GDBN}'s logging.
-
-@table @code
-@kindex set logging
-@item set logging on
-Enable logging.
-@item set logging off
-Disable logging.
-@cindex logging file name
-@item set logging file @var{file}
-Change the name of the current logfile.  The default logfile is @file{gdb.txt}.
-@item set logging overwrite [on|off]
-By default, @value{GDBN} will append to the logfile.  Set @code{overwrite} if
-you want @code{set logging on} to overwrite the logfile instead.
-@item set logging redirect [on|off]
-By default, @value{GDBN} output will go to both the terminal and the logfile.
-Set @code{redirect} if you want output to go only to the log file.
-@kindex show logging
-@item show logging
-Show the current values of the logging settings.
-@end table
-
-@node Commands
-@chapter @value{GDBN} Commands
-
-You can abbreviate a @value{GDBN} command to the first few letters of the command
-name, if that abbreviation is unambiguous; and you can repeat certain
-@value{GDBN} commands by typing just @key{RET}.  You can also use the @key{TAB}
-key to get @value{GDBN} to fill out the rest of a word in a command (or to
-show you the alternatives available, if there is more than one possibility).
-
-@menu
-* Command Syntax::              How to give commands to @value{GDBN}
-* Completion::                  Command completion
-* Help::                        How to ask @value{GDBN} for help
-@end menu
-
-@node Command Syntax
-@section Command Syntax
-
-A @value{GDBN} command is a single line of input.  There is no limit on
-how long it can be.  It starts with a command name, which is followed by
-arguments whose meaning depends on the command name.  For example, the
-command @code{step} accepts an argument which is the number of times to
-step, as in @samp{step 5}.  You can also use the @code{step} command
-with no arguments.  Some commands do not allow any arguments.
-
-@cindex abbreviation
-@value{GDBN} command names may always be truncated if that abbreviation is
-unambiguous.  Other possible command abbreviations are listed in the
-documentation for individual commands.  In some cases, even ambiguous
-abbreviations are allowed; for example, @code{s} is specially defined as
-equivalent to @code{step} even though there are other commands whose
-names start with @code{s}.  You can test abbreviations by using them as
-arguments to the @code{help} command.
-
-@cindex repeating commands
-@kindex RET @r{(repeat last command)}
-A blank line as input to @value{GDBN} (typing just @key{RET}) means to
-repeat the previous command.  Certain commands (for example, @code{run})
-will not repeat this way; these are commands whose unintentional
-repetition might cause trouble and which you are unlikely to want to
-repeat.  User-defined commands can disable this feature; see
-@ref{Define, dont-repeat}.
-
-The @code{list} and @code{x} commands, when you repeat them with
-@key{RET}, construct new arguments rather than repeating
-exactly as typed.  This permits easy scanning of source or memory.
-
-@value{GDBN} can also use @key{RET} in another way: to partition lengthy
-output, in a way similar to the common utility @code{more}
-(@pxref{Screen Size,,Screen Size}).  Since it is easy to press one
-@key{RET} too many in this situation, @value{GDBN} disables command
-repetition after any command that generates this sort of display.
-
-@kindex # @r{(a comment)}
-@cindex comment
-Any text from a @kbd{#} to the end of the line is a comment; it does
-nothing.  This is useful mainly in command files (@pxref{Command
-Files,,Command Files}).
-
-@cindex repeating command sequences
-@kindex Ctrl-o @r{(operate-and-get-next)}
-The @kbd{Ctrl-o} binding is useful for repeating a complex sequence of
-commands.  This command accepts the current line, like @key{RET}, and
-then fetches the next line relative to the current line from the history
-for editing.
-
-@node Completion
-@section Command Completion
-
-@cindex completion
-@cindex word completion
-@value{GDBN} can fill in the rest of a word in a command for you, if there is
-only one possibility; it can also show you what the valid possibilities
-are for the next word in a command, at any time.  This works for @value{GDBN}
-commands, @value{GDBN} subcommands, and the names of symbols in your program.
-
-Press the @key{TAB} key whenever you want @value{GDBN} to fill out the rest
-of a word.  If there is only one possibility, @value{GDBN} fills in the
-word, and waits for you to finish the command (or press @key{RET} to
-enter it).  For example, if you type
-
-@c FIXME "@key" does not distinguish its argument sufficiently to permit
-@c complete accuracy in these examples; space introduced for clarity.
-@c If texinfo enhancements make it unnecessary, it would be nice to
-@c replace " @key" by "@key" in the following...
-@smallexample
-(@value{GDBP}) info bre @key{TAB}
-@end smallexample
-
-@noindent
-@value{GDBN} fills in the rest of the word @samp{breakpoints}, since that is
-the only @code{info} subcommand beginning with @samp{bre}:
-
-@smallexample
-(@value{GDBP}) info breakpoints
-@end smallexample
-
-@noindent
-You can either press @key{RET} at this point, to run the @code{info
-breakpoints} command, or backspace and enter something else, if
-@samp{breakpoints} does not look like the command you expected.  (If you
-were sure you wanted @code{info breakpoints} in the first place, you
-might as well just type @key{RET} immediately after @samp{info bre},
-to exploit command abbreviations rather than command completion).
-
-If there is more than one possibility for the next word when you press
-@key{TAB}, @value{GDBN} sounds a bell.  You can either supply more
-characters and try again, or just press @key{TAB} a second time;
-@value{GDBN} displays all the possible completions for that word.  For
-example, you might want to set a breakpoint on a subroutine whose name
-begins with @samp{make_}, but when you type @kbd{b make_@key{TAB}} @value{GDBN}
-just sounds the bell.  Typing @key{TAB} again displays all the
-function names in your program that begin with those characters, for
-example:
-
-@smallexample
-(@value{GDBP}) b make_ @key{TAB}
-@exdent @value{GDBN} sounds bell; press @key{TAB} again, to see:
-make_a_section_from_file     make_environ
-make_abs_section             make_function_type
-make_blockvector             make_pointer_type
-make_cleanup                 make_reference_type
-make_command                 make_symbol_completion_list
-(@value{GDBP}) b make_
-@end smallexample
-
-@noindent
-After displaying the available possibilities, @value{GDBN} copies your
-partial input (@samp{b make_} in the example) so you can finish the
-command.
-
-If you just want to see the list of alternatives in the first place, you
-can press @kbd{M-?} rather than pressing @key{TAB} twice.  @kbd{M-?}
-means @kbd{@key{META} ?}.  You can type this either by holding down a
-key designated as the @key{META} shift on your keyboard (if there is
-one) while typing @kbd{?}, or as @key{ESC} followed by @kbd{?}.
-
-@cindex quotes in commands
-@cindex completion of quoted strings
-Sometimes the string you need, while logically a ``word'', may contain
-parentheses or other characters that @value{GDBN} normally excludes from
-its notion of a word.  To permit word completion to work in this
-situation, you may enclose words in @code{'} (single quote marks) in
-@value{GDBN} commands.
-
-The most likely situation where you might need this is in typing the
-name of a C@t{++} function.  This is because C@t{++} allows function
-overloading (multiple definitions of the same function, distinguished
-by argument type).  For example, when you want to set a breakpoint you
-may need to distinguish whether you mean the version of @code{name}
-that takes an @code{int} parameter, @code{name(int)}, or the version
-that takes a @code{float} parameter, @code{name(float)}.  To use the
-word-completion facilities in this situation, type a single quote
-@code{'} at the beginning of the function name.  This alerts
-@value{GDBN} that it may need to consider more information than usual
-when you press @key{TAB} or @kbd{M-?} to request word completion:
-
-@smallexample
-(@value{GDBP}) b 'bubble( @kbd{M-?}
-bubble(double,double)    bubble(int,int)
-(@value{GDBP}) b 'bubble(
-@end smallexample
-
-In some cases, @value{GDBN} can tell that completing a name requires using
-quotes.  When this happens, @value{GDBN} inserts the quote for you (while
-completing as much as it can) if you do not type the quote in the first
-place:
-
-@smallexample
-(@value{GDBP}) b bub @key{TAB}
-@exdent @value{GDBN} alters your input line to the following, and rings a bell:
-(@value{GDBP}) b 'bubble(
-@end smallexample
-
-@noindent
-In general, @value{GDBN} can tell that a quote is needed (and inserts it) if
-you have not yet started typing the argument list when you ask for
-completion on an overloaded symbol.
-
-For more information about overloaded functions, see @ref{C Plus Plus
-Expressions, ,C@t{++} Expressions}.  You can use the command @code{set
-overload-resolution off} to disable overload resolution;
-see @ref{Debugging C Plus Plus, ,@value{GDBN} Features for C@t{++}}.
-
-@cindex completion of structure field names
-@cindex structure field name completion
-@cindex completion of union field names
-@cindex union field name completion
-When completing in an expression which looks up a field in a
-structure, @value{GDBN} also tries@footnote{The completer can be
-confused by certain kinds of invalid expressions.  Also, it only
-examines the static type of the expression, not the dynamic type.} to
-limit completions to the field names available in the type of the
-left-hand-side:
-
-@smallexample
-(@value{GDBP}) p gdb_stdout.@kbd{M-?}
-magic                to_fputs             to_rewind
-to_data              to_isatty            to_write
-to_delete            to_put               to_write_async_safe
-to_flush             to_read
-@end smallexample
-
-@noindent
-This is because the @code{gdb_stdout} is a variable of the type
-@code{struct ui_file} that is defined in @value{GDBN} sources as
-follows:
-
-@smallexample
-struct ui_file
-@{
-   int *magic;
-   ui_file_flush_ftype *to_flush;
-   ui_file_write_ftype *to_write;
-   ui_file_write_async_safe_ftype *to_write_async_safe;
-   ui_file_fputs_ftype *to_fputs;
-   ui_file_read_ftype *to_read;
-   ui_file_delete_ftype *to_delete;
-   ui_file_isatty_ftype *to_isatty;
-   ui_file_rewind_ftype *to_rewind;
-   ui_file_put_ftype *to_put;
-   void *to_data;
-@}
-@end smallexample
-
-
-@node Help
-@section Getting Help
-@cindex online documentation
-@kindex help
-
-You can always ask @value{GDBN} itself for information on its commands,
-using the command @code{help}.
-
-@table @code
-@kindex h @r{(@code{help})}
-@item help
-@itemx h
-You can use @code{help} (abbreviated @code{h}) with no arguments to
-display a short list of named classes of commands:
-
-@smallexample
-(@value{GDBP}) help
-List of classes of commands:
-
-aliases -- Aliases of other commands
-breakpoints -- Making program stop at certain points
-data -- Examining data
-files -- Specifying and examining files
-internals -- Maintenance commands
-obscure -- Obscure features
-running -- Running the program
-stack -- Examining the stack
-status -- Status inquiries
-support -- Support facilities
-tracepoints -- Tracing of program execution without
-               stopping the program
-user-defined -- User-defined commands
-
-Type "help" followed by a class name for a list of
-commands in that class.
-Type "help" followed by command name for full
-documentation.
-Command name abbreviations are allowed if unambiguous.
-(@value{GDBP})
-@end smallexample
-@c the above line break eliminates huge line overfull...
-
-@item help @var{class}
-Using one of the general help classes as an argument, you can get a
-list of the individual commands in that class.  For example, here is the
-help display for the class @code{status}:
-
-@smallexample
-(@value{GDBP}) help status
-Status inquiries.
-
-List of commands:
-
-@c Line break in "show" line falsifies real output, but needed
-@c to fit in smallbook page size.
-info -- Generic command for showing things
-        about the program being debugged
-show -- Generic command for showing things
-        about the debugger
-
-Type "help" followed by command name for full
-documentation.
-Command name abbreviations are allowed if unambiguous.
-(@value{GDBP})
-@end smallexample
-
-@item help @var{command}
-With a command name as @code{help} argument, @value{GDBN} displays a
-short paragraph on how to use that command.
-
-@kindex apropos
-@item apropos @var{args}
-The @code{apropos} command searches through all of the @value{GDBN}
-commands, and their documentation, for the regular expression specified in
-@var{args}.  It prints out all matches found.  For example:
-
-@smallexample
-apropos alias
-@end smallexample
-
-@noindent
-results in:
-
-@smallexample
-@c @group
-alias -- Define a new command that is an alias of an existing command
-aliases -- Aliases of other commands
-d -- Delete some breakpoints or auto-display expressions
-del -- Delete some breakpoints or auto-display expressions
-delete -- Delete some breakpoints or auto-display expressions
-@c @end group
-@end smallexample
-
-@kindex complete
-@item complete @var{args}
-The @code{complete @var{args}} command lists all the possible completions
-for the beginning of a command.  Use @var{args} to specify the beginning of the
-command you want completed.  For example:
-
-@smallexample
-complete i
-@end smallexample
-
-@noindent results in:
-
-@smallexample
-@group
-if
-ignore
-info
-inspect
-@end group
-@end smallexample
-
-@noindent This is intended for use by @sc{gnu} Emacs.
-@end table
-
-In addition to @code{help}, you can use the @value{GDBN} commands @code{info}
-and @code{show} to inquire about the state of your program, or the state
-of @value{GDBN} itself.  Each command supports many topics of inquiry; this
-manual introduces each of them in the appropriate context.  The listings
-under @code{info} and under @code{show} in the Command, Variable, and
-Function Index point to all the sub-commands.  @xref{Command and Variable
-Index}.
-
-@c @group
-@table @code
-@kindex info
-@kindex i @r{(@code{info})}
-@item info
-This command (abbreviated @code{i}) is for describing the state of your
-program.  For example, you can show the arguments passed to a function
-with @code{info args}, list the registers currently in use with @code{info
-registers}, or list the breakpoints you have set with @code{info breakpoints}.
-You can get a complete list of the @code{info} sub-commands with
-@w{@code{help info}}.
-
-@kindex set
-@item set
-You can assign the result of an expression to an environment variable with
-@code{set}.  For example, you can set the @value{GDBN} prompt to a $-sign with
-@code{set prompt $}.
-
-@kindex show
-@item show
-In contrast to @code{info}, @code{show} is for describing the state of
-@value{GDBN} itself.
-You can change most of the things you can @code{show}, by using the
-related command @code{set}; for example, you can control what number
-system is used for displays with @code{set radix}, or simply inquire
-which is currently in use with @code{show radix}.
-
-@kindex info set
-To display all the settable parameters and their current
-values, you can use @code{show} with no arguments; you may also use
-@code{info set}.  Both commands produce the same display.
-@c FIXME: "info set" violates the rule that "info" is for state of
-@c FIXME...program.  Ck w/ GNU: "info set" to be called something else,
-@c FIXME...or change desc of rule---eg "state of prog and debugging session"?
-@end table
-@c @end group
-
-Here are three miscellaneous @code{show} subcommands, all of which are
-exceptional in lacking corresponding @code{set} commands:
-
-@table @code
-@kindex show version
-@cindex @value{GDBN} version number
-@item show version
-Show what version of @value{GDBN} is running.  You should include this
-information in @value{GDBN} bug-reports.  If multiple versions of
-@value{GDBN} are in use at your site, you may need to determine which
-version of @value{GDBN} you are running; as @value{GDBN} evolves, new
-commands are introduced, and old ones may wither away.  Also, many
-system vendors ship variant versions of @value{GDBN}, and there are
-variant versions of @value{GDBN} in @sc{gnu}/Linux distributions as well.
-The version number is the same as the one announced when you start
-@value{GDBN}.
-
-@kindex show copying
-@kindex info copying
-@cindex display @value{GDBN} copyright
-@item show copying
-@itemx info copying
-Display information about permission for copying @value{GDBN}.
-
-@kindex show warranty
-@kindex info warranty
-@item show warranty
-@itemx info warranty
-Display the @sc{gnu} ``NO WARRANTY'' statement, or a warranty,
-if your version of @value{GDBN} comes with one.
-
-@end table
-
-@node Running
-@chapter Running Programs Under @value{GDBN}
-
-When you run a program under @value{GDBN}, you must first generate
-debugging information when you compile it.
-
-You may start @value{GDBN} with its arguments, if any, in an environment
-of your choice.  If you are doing native debugging, you may redirect
-your program's input and output, debug an already running process, or
-kill a child process.
-
-@menu
-* Compilation::                 Compiling for debugging
-* Starting::                    Starting your program
-* Arguments::                   Your program's arguments
-* Environment::                 Your program's environment
-
-* Working Directory::           Your program's working directory
-* Input/Output::                Your program's input and output
-* Attach::                      Debugging an already-running process
-* Kill Process::                Killing the child process
-
-* Inferiors and Programs::      Debugging multiple inferiors and programs
-* Threads::                     Debugging programs with multiple threads
-* Forks::                       Debugging forks
-* Checkpoint/Restart::          Setting a @emph{bookmark} to return to later
-@end menu
-
-@node Compilation
-@section Compiling for Debugging
-
-In order to debug a program effectively, you need to generate
-debugging information when you compile it.  This debugging information
-is stored in the object file; it describes the data type of each
-variable or function and the correspondence between source line numbers
-and addresses in the executable code.
-
-To request debugging information, specify the @samp{-g} option when you run
-the compiler.
-
-Programs that are to be shipped to your customers are compiled with
-optimizations, using the @samp{-O} compiler option.  However, some
-compilers are unable to handle the @samp{-g} and @samp{-O} options
-together.  Using those compilers, you cannot generate optimized
-executables containing debugging information.
-
-@value{NGCC}, the @sc{gnu} C/C@t{++} compiler, supports @samp{-g} with or
-without @samp{-O}, making it possible to debug optimized code.  We
-recommend that you @emph{always} use @samp{-g} whenever you compile a
-program.  You may think your program is correct, but there is no sense
-in pushing your luck.  For more information, see @ref{Optimized Code}.
-
-Older versions of the @sc{gnu} C compiler permitted a variant option
-@w{@samp{-gg}} for debugging information.  @value{GDBN} no longer supports this
-format; if your @sc{gnu} C compiler has this option, do not use it.
-
-@value{GDBN} knows about preprocessor macros and can show you their
-expansion (@pxref{Macros}).  Most compilers do not include information
-about preprocessor macros in the debugging information if you specify
-the @option{-g} flag alone.  Version 3.1 and later of @value{NGCC},
-the @sc{gnu} C compiler, provides macro information if you are using
-the DWARF debugging format, and specify the option @option{-g3}.
-
-@xref{Debugging Options,,Options for Debugging Your Program or GCC,
-gcc.info, Using the @sc{gnu} Compiler Collection (GCC)}, for more
-information on @value{NGCC} options affecting debug information.
-
-You will have the best debugging experience if you use the latest
-version of the DWARF debugging format that your compiler supports.
-DWARF is currently the most expressive and best supported debugging
-format in @value{GDBN}.
-
-@need 2000
-@node Starting
-@section Starting your Program
-@cindex starting
-@cindex running
-
-@table @code
-@kindex run
-@kindex r @r{(@code{run})}
-@item run
-@itemx r
-Use the @code{run} command to start your program under @value{GDBN}.
-You must first specify the program name (except on VxWorks) with an
-argument to @value{GDBN} (@pxref{Invocation, ,Getting In and Out of
-@value{GDBN}}), or by using the @code{file} or @code{exec-file} command
-(@pxref{Files, ,Commands to Specify Files}).
-
-@end table
-
-If you are running your program in an execution environment that
-supports processes, @code{run} creates an inferior process and makes
-that process run your program.  In some environments without processes,
-@code{run} jumps to the start of your program.  Other targets,
-like @samp{remote}, are always running.  If you get an error
-message like this one:
-
-@smallexample
-The "remote" target does not support "run".
-Try "help target" or "continue".
-@end smallexample
-
-@noindent
-then use @code{continue} to run your program.  You may need @code{load}
-first (@pxref{load}).
-
-The execution of a program is affected by certain information it
-receives from its superior.  @value{GDBN} provides ways to specify this
-information, which you must do @emph{before} starting your program.  (You
-can change it after starting your program, but such changes only affect
-your program the next time you start it.)  This information may be
-divided into four categories:
-
-@table @asis
-@item The @emph{arguments.}
-Specify the arguments to give your program as the arguments of the
-@code{run} command.  If a shell is available on your target, the shell
-is used to pass the arguments, so that you may use normal conventions
-(such as wildcard expansion or variable substitution) in describing
-the arguments.
-In Unix systems, you can control which shell is used with the
-@code{SHELL} environment variable.
-@xref{Arguments, ,Your Program's Arguments}.
-
-@item The @emph{environment.}
-Your program normally inherits its environment from @value{GDBN}, but you can
-use the @value{GDBN} commands @code{set environment} and @code{unset
-environment} to change parts of the environment that affect
-your program.  @xref{Environment, ,Your Program's Environment}.
-
-@item The @emph{working directory.}
-Your program inherits its working directory from @value{GDBN}.  You can set
-the @value{GDBN} working directory with the @code{cd} command in @value{GDBN}.
-@xref{Working Directory, ,Your Program's Working Directory}.
-
-@item The @emph{standard input and output.}
-Your program normally uses the same device for standard input and
-standard output as @value{GDBN} is using.  You can redirect input and output
-in the @code{run} command line, or you can use the @code{tty} command to
-set a different device for your program.
-@xref{Input/Output, ,Your Program's Input and Output}.
-
-@cindex pipes
-@emph{Warning:} While input and output redirection work, you cannot use
-pipes to pass the output of the program you are debugging to another
-program; if you attempt this, @value{GDBN} is likely to wind up debugging the
-wrong program.
-@end table
-
-When you issue the @code{run} command, your program begins to execute
-immediately.  @xref{Stopping, ,Stopping and Continuing}, for discussion
-of how to arrange for your program to stop.  Once your program has
-stopped, you may call functions in your program, using the @code{print}
-or @code{call} commands.  @xref{Data, ,Examining Data}.
-
-If the modification time of your symbol file has changed since the last
-time @value{GDBN} read its symbols, @value{GDBN} discards its symbol
-table, and reads it again.  When it does this, @value{GDBN} tries to retain
-your current breakpoints.
-
-@table @code
-@kindex start
-@item start
-@cindex run to main procedure
-The name of the main procedure can vary from language to language.
-With C or C@t{++}, the main procedure name is always @code{main}, but
-other languages such as Ada do not require a specific name for their
-main procedure.  The debugger provides a convenient way to start the
-execution of the program and to stop at the beginning of the main
-procedure, depending on the language used.
-
-The @samp{start} command does the equivalent of setting a temporary
-breakpoint at the beginning of the main procedure and then invoking
-the @samp{run} command.
-
-@cindex elaboration phase
-Some programs contain an @dfn{elaboration} phase where some startup code is
-executed before the main procedure is called.  This depends on the
-languages used to write your program.  In C@t{++}, for instance,
-constructors for static and global objects are executed before
-@code{main} is called.  It is therefore possible that the debugger stops
-before reaching the main procedure.  However, the temporary breakpoint
-will remain to halt execution.
-
-Specify the arguments to give to your program as arguments to the
-@samp{start} command.  These arguments will be given verbatim to the
-underlying @samp{run} command.  Note that the same arguments will be
-reused if no argument is provided during subsequent calls to
-@samp{start} or @samp{run}.
-
-It is sometimes necessary to debug the program during elaboration.  In
-these cases, using the @code{start} command would stop the execution of
-your program too late, as the program would have already completed the
-elaboration phase.  Under these circumstances, insert breakpoints in your
-elaboration code before running your program.
-
-@kindex set exec-wrapper
-@item set exec-wrapper @var{wrapper}
-@itemx show exec-wrapper
-@itemx unset exec-wrapper
-When @samp{exec-wrapper} is set, the specified wrapper is used to
-launch programs for debugging.  @value{GDBN} starts your program
-with a shell command of the form @kbd{exec @var{wrapper}
-@var{program}}.  Quoting is added to @var{program} and its
-arguments, but not to @var{wrapper}, so you should add quotes if
-appropriate for your shell.  The wrapper runs until it executes
-your program, and then @value{GDBN} takes control.
-
-You can use any program that eventually calls @code{execve} with
-its arguments as a wrapper.  Several standard Unix utilities do
-this, e.g.@: @code{env} and @code{nohup}.  Any Unix shell script ending
-with @code{exec "$@@"} will also work.
-
-For example, you can use @code{env} to pass an environment variable to
-the debugged program, without setting the variable in your shell's
-environment:
-
-@smallexample
-(@value{GDBP}) set exec-wrapper env 'LD_PRELOAD=libtest.so'
-(@value{GDBP}) run
-@end smallexample
-
-This command is available when debugging locally on most targets, excluding
-@sc{djgpp}, Cygwin, MS Windows, and QNX Neutrino.
-
-@kindex set disable-randomization
-@item set disable-randomization
-@itemx set disable-randomization on
-This option (enabled by default in @value{GDBN}) will turn off the native
-randomization of the virtual address space of the started program.  This option
-is useful for multiple debugging sessions to make the execution better
-reproducible and memory addresses reusable across debugging sessions.
-
-This feature is implemented only on certain targets, including @sc{gnu}/Linux.
-On @sc{gnu}/Linux you can get the same behavior using
-
-@smallexample
-(@value{GDBP}) set exec-wrapper setarch `uname -m` -R
-@end smallexample
-
-@item set disable-randomization off
-Leave the behavior of the started executable unchanged.  Some bugs rear their
-ugly heads only when the program is loaded at certain addresses.  If your bug
-disappears when you run the program under @value{GDBN}, that might be because
-@value{GDBN} by default disables the address randomization on platforms, such
-as @sc{gnu}/Linux, which do that for stand-alone programs.  Use @kbd{set
-disable-randomization off} to try to reproduce such elusive bugs.
-
-On targets where it is available, virtual address space randomization
-protects the programs against certain kinds of security attacks.  In these
-cases the attacker needs to know the exact location of a concrete executable
-code.  Randomizing its location makes it impossible to inject jumps misusing
-a code at its expected addresses.
-
-Prelinking shared libraries provides a startup performance advantage but it
-makes addresses in these libraries predictable for privileged processes by
-having just unprivileged access at the target system.  Reading the shared
-library binary gives enough information for assembling the malicious code
-misusing it.  Still even a prelinked shared library can get loaded at a new
-random address just requiring the regular relocation process during the
-startup.  Shared libraries not already prelinked are always loaded at
-a randomly chosen address.
-
-Position independent executables (PIE) contain position independent code
-similar to the shared libraries and therefore such executables get loaded at
-a randomly chosen address upon startup.  PIE executables always load even
-already prelinked shared libraries at a random address.  You can build such
-executable using @command{gcc -fPIE -pie}.
-
-Heap (malloc storage), stack and custom mmap areas are always placed randomly
-(as long as the randomization is enabled).
-
-@item show disable-randomization
-Show the current setting of the explicit disable of the native randomization of
-the virtual address space of the started program.
-
-@end table
-
-@node Arguments
-@section Your Program's Arguments
-
-@cindex arguments (to your program)
-The arguments to your program can be specified by the arguments of the
-@code{run} command.
-They are passed to a shell, which expands wildcard characters and
-performs redirection of I/O, and thence to your program.  Your
-@code{SHELL} environment variable (if it exists) specifies what shell
-@value{GDBN} uses.  If you do not define @code{SHELL}, @value{GDBN} uses
-the default shell (@file{/bin/sh} on Unix).
-
-On non-Unix systems, the program is usually invoked directly by
-@value{GDBN}, which emulates I/O redirection via the appropriate system
-calls, and the wildcard characters are expanded by the startup code of
-the program, not by the shell.
-
-@code{run} with no arguments uses the same arguments used by the previous
-@code{run}, or those set by the @code{set args} command.
-
-@table @code
-@kindex set args
-@item set args
-Specify the arguments to be used the next time your program is run.  If
-@code{set args} has no arguments, @code{run} executes your program
-with no arguments.  Once you have run your program with arguments,
-using @code{set args} before the next @code{run} is the only way to run
-it again without arguments.
-
-@kindex show args
-@item show args
-Show the arguments to give your program when it is started.
-@end table
-
-@node Environment
-@section Your Program's Environment
-
-@cindex environment (of your program)
-The @dfn{environment} consists of a set of environment variables and
-their values.  Environment variables conventionally record such things as
-your user name, your home directory, your terminal type, and your search
-path for programs to run.  Usually you set up environment variables with
-the shell and they are inherited by all the other programs you run.  When
-debugging, it can be useful to try running your program with a modified
-environment without having to start @value{GDBN} over again.
-
-@table @code
-@kindex path
-@item path @var{directory}
-Add @var{directory} to the front of the @code{PATH} environment variable
-(the search path for executables) that will be passed to your program.
-The value of @code{PATH} used by @value{GDBN} does not change.
-You may specify several directory names, separated by whitespace or by a
-system-dependent separator character (@samp{:} on Unix, @samp{;} on
-MS-DOS and MS-Windows).  If @var{directory} is already in the path, it
-is moved to the front, so it is searched sooner.
-
-You can use the string @samp{$cwd} to refer to whatever is the current
-working directory at the time @value{GDBN} searches the path.  If you
-use @samp{.} instead, it refers to the directory where you executed the
-@code{path} command.  @value{GDBN} replaces @samp{.} in the
-@var{directory} argument (with the current path) before adding
-@var{directory} to the search path.
-@c 'path' is explicitly nonrepeatable, but RMS points out it is silly to
-@c document that, since repeating it would be a no-op.
-
-@kindex show paths
-@item show paths
-Display the list of search paths for executables (the @code{PATH}
-environment variable).
-
-@kindex show environment
-@item show environment @r{[}@var{varname}@r{]}
-Print the value of environment variable @var{varname} to be given to
-your program when it starts.  If you do not supply @var{varname},
-print the names and values of all environment variables to be given to
-your program.  You can abbreviate @code{environment} as @code{env}.
-
-@kindex set environment
-@item set environment @var{varname} @r{[}=@var{value}@r{]}
-Set environment variable @var{varname} to @var{value}.  The value
-changes for your program only, not for @value{GDBN} itself.  @var{value} may
-be any string; the values of environment variables are just strings, and
-any interpretation is supplied by your program itself.  The @var{value}
-parameter is optional; if it is eliminated, the variable is set to a
-null value.
-@c "any string" here does not include leading, trailing
-@c blanks. Gnu asks: does anyone care?
-
-For example, this command:
-
-@smallexample
-set env USER = foo
-@end smallexample
-
-@noindent
-tells the debugged program, when subsequently run, that its user is named
-@samp{foo}.  (The spaces around @samp{=} are used for clarity here; they
-are not actually required.)
-
-@kindex unset environment
-@item unset environment @var{varname}
-Remove variable @var{varname} from the environment to be passed to your
-program.  This is different from @samp{set env @var{varname} =};
-@code{unset environment} removes the variable from the environment,
-rather than assigning it an empty value.
-@end table
-
-@emph{Warning:} On Unix systems, @value{GDBN} runs your program using
-the shell indicated
-by your @code{SHELL} environment variable if it exists (or
-@code{/bin/sh} if not).  If your @code{SHELL} variable names a shell
-that runs an initialization file---such as @file{.cshrc} for C-shell, or
-@file{.bashrc} for BASH---any variables you set in that file affect
-your program.  You may wish to move setting of environment variables to
-files that are only run when you sign on, such as @file{.login} or
-@file{.profile}.
-
-@node Working Directory
-@section Your Program's Working Directory
-
-@cindex working directory (of your program)
-Each time you start your program with @code{run}, it inherits its
-working directory from the current working directory of @value{GDBN}.
-The @value{GDBN} working directory is initially whatever it inherited
-from its parent process (typically the shell), but you can specify a new
-working directory in @value{GDBN} with the @code{cd} command.
-
-The @value{GDBN} working directory also serves as a default for the commands
-that specify files for @value{GDBN} to operate on.  @xref{Files, ,Commands to
-Specify Files}.
-
-@table @code
-@kindex cd
-@cindex change working directory
-@item cd @r{[}@var{directory}@r{]}
-Set the @value{GDBN} working directory to @var{directory}.  If not
-given, @var{directory} uses @file{'~'}.
-
-@kindex pwd
-@item pwd
-Print the @value{GDBN} working directory.
-@end table
-
-It is generally impossible to find the current working directory of
-the process being debugged (since a program can change its directory
-during its run).  If you work on a system where @value{GDBN} is
-configured with the @file{/proc} support, you can use the @code{info
-proc} command (@pxref{SVR4 Process Information}) to find out the
-current working directory of the debuggee.
-
-@node Input/Output
-@section Your Program's Input and Output
-
-@cindex redirection
-@cindex i/o
-@cindex terminal
-By default, the program you run under @value{GDBN} does input and output to
-the same terminal that @value{GDBN} uses.  @value{GDBN} switches the terminal
-to its own terminal modes to interact with you, but it records the terminal
-modes your program was using and switches back to them when you continue
-running your program.
-
-@table @code
-@kindex info terminal
-@item info terminal
-Displays information recorded by @value{GDBN} about the terminal modes your
-program is using.
-@end table
-
-You can redirect your program's input and/or output using shell
-redirection with the @code{run} command.  For example,
-
-@smallexample
-run > outfile
-@end smallexample
-
-@noindent
-starts your program, diverting its output to the file @file{outfile}.
-
-@kindex tty
-@cindex controlling terminal
-Another way to specify where your program should do input and output is
-with the @code{tty} command.  This command accepts a file name as
-argument, and causes this file to be the default for future @code{run}
-commands.  It also resets the controlling terminal for the child
-process, for future @code{run} commands.  For example,
-
-@smallexample
-tty /dev/ttyb
-@end smallexample
-
-@noindent
-directs that processes started with subsequent @code{run} commands
-default to do input and output on the terminal @file{/dev/ttyb} and have
-that as their controlling terminal.
-
-An explicit redirection in @code{run} overrides the @code{tty} command's
-effect on the input/output device, but not its effect on the controlling
-terminal.
-
-When you use the @code{tty} command or redirect input in the @code{run}
-command, only the input @emph{for your program} is affected.  The input
-for @value{GDBN} still comes from your terminal.  @code{tty} is an alias
-for @code{set inferior-tty}.
-
-@cindex inferior tty
-@cindex set inferior controlling terminal
-You can use the @code{show inferior-tty} command to tell @value{GDBN} to
-display the name of the terminal that will be used for future runs of your
-program.
-
-@table @code
-@item set inferior-tty /dev/ttyb
-@kindex set inferior-tty
-Set the tty for the program being debugged to /dev/ttyb.
-
-@item show inferior-tty
-@kindex show inferior-tty
-Show the current tty for the program being debugged.
-@end table
-
-@node Attach
-@section Debugging an Already-running Process
-@kindex attach
-@cindex attach
-
-@table @code
-@item attach @var{process-id}
-This command attaches to a running process---one that was started
-outside @value{GDBN}.  (@code{info files} shows your active
-targets.)  The command takes as argument a process ID.  The usual way to
-find out the @var{process-id} of a Unix process is with the @code{ps} utility,
-or with the @samp{jobs -l} shell command.
-
-@code{attach} does not repeat if you press @key{RET} a second time after
-executing the command.
-@end table
-
-To use @code{attach}, your program must be running in an environment
-which supports processes; for example, @code{attach} does not work for
-programs on bare-board targets that lack an operating system.  You must
-also have permission to send the process a signal.
-
-When you use @code{attach}, the debugger finds the program running in
-the process first by looking in the current working directory, then (if
-the program is not found) by using the source file search path
-(@pxref{Source Path, ,Specifying Source Directories}).  You can also use
-the @code{file} command to load the program.  @xref{Files, ,Commands to
-Specify Files}.
-
-The first thing @value{GDBN} does after arranging to debug the specified
-process is to stop it.  You can examine and modify an attached process
-with all the @value{GDBN} commands that are ordinarily available when
-you start processes with @code{run}.  You can insert breakpoints; you
-can step and continue; you can modify storage.  If you would rather the
-process continue running, you may use the @code{continue} command after
-attaching @value{GDBN} to the process.
-
-@table @code
-@kindex detach
-@item detach
-When you have finished debugging the attached process, you can use the
-@code{detach} command to release it from @value{GDBN} control.  Detaching
-the process continues its execution.  After the @code{detach} command,
-that process and @value{GDBN} become completely independent once more, and you
-are ready to @code{attach} another process or start one with @code{run}.
-@code{detach} does not repeat if you press @key{RET} again after
-executing the command.
-@end table
-
-If you exit @value{GDBN} while you have an attached process, you detach
-that process.  If you use the @code{run} command, you kill that process.
-By default, @value{GDBN} asks for confirmation if you try to do either of these
-things; you can control whether or not you need to confirm by using the
-@code{set confirm} command (@pxref{Messages/Warnings, ,Optional Warnings and
-Messages}).
-
-@node Kill Process
-@section Killing the Child Process
-
-@table @code
-@kindex kill
-@item kill
-Kill the child process in which your program is running under @value{GDBN}.
-@end table
-
-This command is useful if you wish to debug a core dump instead of a
-running process.  @value{GDBN} ignores any core dump file while your program
-is running.
-
-On some operating systems, a program cannot be executed outside @value{GDBN}
-while you have breakpoints set on it inside @value{GDBN}.  You can use the
-@code{kill} command in this situation to permit running your program
-outside the debugger.
-
-The @code{kill} command is also useful if you wish to recompile and
-relink your program, since on many systems it is impossible to modify an
-executable file while it is running in a process.  In this case, when you
-next type @code{run}, @value{GDBN} notices that the file has changed, and
-reads the symbol table again (while trying to preserve your current
-breakpoint settings).
-
-@node Inferiors and Programs
-@section Debugging Multiple Inferiors and Programs
-
-@value{GDBN} lets you run and debug multiple programs in a single
-session.  In addition, @value{GDBN} on some systems may let you run
-several programs simultaneously (otherwise you have to exit from one
-before starting another).  In the most general case, you can have
-multiple threads of execution in each of multiple processes, launched
-from multiple executables.
-
-@cindex inferior
-@value{GDBN} represents the state of each program execution with an
-object called an @dfn{inferior}.  An inferior typically corresponds to
-a process, but is more general and applies also to targets that do not
-have processes.  Inferiors may be created before a process runs, and
-may be retained after a process exits.  Inferiors have unique
-identifiers that are different from process ids.  Usually each
-inferior will also have its own distinct address space, although some
-embedded targets may have several inferiors running in different parts
-of a single address space.  Each inferior may in turn have multiple
-threads running in it.
-
-To find out what inferiors exist at any moment, use @w{@code{info
-inferiors}}:
-
-@table @code
-@kindex info inferiors
-@item info inferiors
-Print a list of all inferiors currently being managed by @value{GDBN}.
-
-@value{GDBN} displays for each inferior (in this order):
-
-@enumerate
-@item
-the inferior number assigned by @value{GDBN}
-
-@item
-the target system's inferior identifier
-
-@item
-the name of the executable the inferior is running.
-
-@end enumerate
-
-@noindent
-An asterisk @samp{*} preceding the @value{GDBN} inferior number
-indicates the current inferior.
-
-For example,
-@end table
-@c end table here to get a little more width for example
-
-@smallexample
-(@value{GDBP}) info inferiors
-  Num  Description       Executable
-  2    process 2307      hello
-* 1    process 3401      goodbye
-@end smallexample
-
-To switch focus between inferiors, use the @code{inferior} command:
-
-@table @code
-@kindex inferior @var{infno}
-@item inferior @var{infno}
-Make inferior number @var{infno} the current inferior.  The argument
-@var{infno} is the inferior number assigned by @value{GDBN}, as shown
-in the first field of the @samp{info inferiors} display.
-@end table
-
-
-You can get multiple executables into a debugging session via the
-@code{add-inferior} and @w{@code{clone-inferior}} commands.  On some
-systems @value{GDBN} can add inferiors to the debug session
-automatically by following calls to @code{fork} and @code{exec}.  To
-remove inferiors from the debugging session use the
-@w{@code{remove-inferiors}} command.
-
-@table @code
-@kindex add-inferior
-@item add-inferior [ -copies @var{n} ] [ -exec @var{executable} ]
-Adds @var{n} inferiors to be run using @var{executable} as the
-executable.  @var{n} defaults to 1.  If no executable is specified,
-the inferiors begins empty, with no program.  You can still assign or
-change the program assigned to the inferior at any time by using the
-@code{file} command with the executable name as its argument.
-
-@kindex clone-inferior
-@item clone-inferior [ -copies @var{n} ] [ @var{infno} ]
-Adds @var{n} inferiors ready to execute the same program as inferior
-@var{infno}.  @var{n} defaults to 1.  @var{infno} defaults to the
-number of the current inferior.  This is a convenient command when you
-want to run another instance of the inferior you are debugging.
-
-@smallexample
-(@value{GDBP}) info inferiors
-  Num  Description       Executable
-* 1    process 29964     helloworld
-(@value{GDBP}) clone-inferior
-Added inferior 2.
-1 inferiors added.
-(@value{GDBP}) info inferiors
-  Num  Description       Executable
-  2    <null>            helloworld
-* 1    process 29964     helloworld
-@end smallexample
-
-You can now simply switch focus to inferior 2 and run it.
-
-@kindex remove-inferiors
-@item remove-inferiors @var{infno}@dots{}
-Removes the inferior or inferiors @var{infno}@dots{}.  It is not
-possible to remove an inferior that is running with this command.  For
-those, use the @code{kill} or @code{detach} command first.
-
-@end table
-
-To quit debugging one of the running inferiors that is not the current
-inferior, you can either detach from it by using the @w{@code{detach
-inferior}} command (allowing it to run independently), or kill it
-using the @w{@code{kill inferiors}} command:
-
-@table @code
-@kindex detach inferiors @var{infno}@dots{}
-@item detach inferior @var{infno}@dots{}
-Detach from the inferior or inferiors identified by @value{GDBN}
-inferior number(s) @var{infno}@dots{}.  Note that the inferior's entry
-still stays on the list of inferiors shown by @code{info inferiors},
-but its Description will show @samp{<null>}.
-
-@kindex kill inferiors @var{infno}@dots{}
-@item kill inferiors @var{infno}@dots{}
-Kill the inferior or inferiors identified by @value{GDBN} inferior
-number(s) @var{infno}@dots{}.  Note that the inferior's entry still
-stays on the list of inferiors shown by @code{info inferiors}, but its
-Description will show @samp{<null>}.
-@end table
-
-After the successful completion of a command such as @code{detach},
-@code{detach inferiors}, @code{kill} or @code{kill inferiors}, or after
-a normal process exit, the inferior is still valid and listed with
-@code{info inferiors}, ready to be restarted.
-
-
-To be notified when inferiors are started or exit under @value{GDBN}'s
-control use @w{@code{set print inferior-events}}:
-
-@table @code
-@kindex set print inferior-events
-@cindex print messages on inferior start and exit
-@item set print inferior-events
-@itemx set print inferior-events on
-@itemx set print inferior-events off
-The @code{set print inferior-events} command allows you to enable or
-disable printing of messages when @value{GDBN} notices that new
-inferiors have started or that inferiors have exited or have been
-detached.  By default, these messages will not be printed.
-
-@kindex show print inferior-events
-@item show print inferior-events
-Show whether messages will be printed when @value{GDBN} detects that
-inferiors have started, exited or have been detached.
-@end table
-
-Many commands will work the same with multiple programs as with a
-single program: e.g., @code{print myglobal} will simply display the
-value of @code{myglobal} in the current inferior.
-
-
-Occasionaly, when debugging @value{GDBN} itself, it may be useful to
-get more info about the relationship of inferiors, programs, address
-spaces in a debug session.  You can do that with the @w{@code{maint
-info program-spaces}} command.
-
-@table @code
-@kindex maint info program-spaces
-@item maint info program-spaces
-Print a list of all program spaces currently being managed by
-@value{GDBN}.
-
-@value{GDBN} displays for each program space (in this order):
-
-@enumerate
-@item
-the program space number assigned by @value{GDBN}
-
-@item
-the name of the executable loaded into the program space, with e.g.,
-the @code{file} command.
-
-@end enumerate
-
-@noindent
-An asterisk @samp{*} preceding the @value{GDBN} program space number
-indicates the current program space.
-
-In addition, below each program space line, @value{GDBN} prints extra
-information that isn't suitable to display in tabular form.  For
-example, the list of inferiors bound to the program space.
-
-@smallexample
-(@value{GDBP}) maint info program-spaces
-  Id   Executable
-  2    goodbye
-        Bound inferiors: ID 1 (process 21561)
-* 1    hello
-@end smallexample
-
-Here we can see that no inferior is running the program @code{hello},
-while @code{process 21561} is running the program @code{goodbye}.  On
-some targets, it is possible that multiple inferiors are bound to the
-same program space.  The most common example is that of debugging both
-the parent and child processes of a @code{vfork} call.  For example,
-
-@smallexample
-(@value{GDBP}) maint info program-spaces
-  Id   Executable
-* 1    vfork-test
-        Bound inferiors: ID 2 (process 18050), ID 1 (process 18045)
-@end smallexample
-
-Here, both inferior 2 and inferior 1 are running in the same program
-space as a result of inferior 1 having executed a @code{vfork} call.
-@end table
-
-@node Threads
-@section Debugging Programs with Multiple Threads
-
-@cindex threads of execution
-@cindex multiple threads
-@cindex switching threads
-In some operating systems, such as HP-UX and Solaris, a single program
-may have more than one @dfn{thread} of execution.  The precise semantics
-of threads differ from one operating system to another, but in general
-the threads of a single program are akin to multiple processes---except
-that they share one address space (that is, they can all examine and
-modify the same variables).  On the other hand, each thread has its own
-registers and execution stack, and perhaps private memory.
-
-@value{GDBN} provides these facilities for debugging multi-thread
-programs:
-
-@itemize @bullet
-@item automatic notification of new threads
-@item @samp{thread @var{threadno}}, a command to switch among threads
-@item @samp{info threads}, a command to inquire about existing threads
-@item @samp{thread apply [@var{threadno}] [@var{all}] @var{args}},
-a command to apply a command to a list of threads
-@item thread-specific breakpoints
-@item @samp{set print thread-events}, which controls printing of 
-messages on thread start and exit.
-@item @samp{set libthread-db-search-path @var{path}}, which lets
-the user specify which @code{libthread_db} to use if the default choice
-isn't compatible with the program.
-@end itemize
-
-@quotation
-@emph{Warning:} These facilities are not yet available on every
-@value{GDBN} configuration where the operating system supports threads.
-If your @value{GDBN} does not support threads, these commands have no
-effect.  For example, a system without thread support shows no output
-from @samp{info threads}, and always rejects the @code{thread} command,
-like this:
-
-@smallexample
-(@value{GDBP}) info threads
-(@value{GDBP}) thread 1
-Thread ID 1 not known.  Use the "info threads" command to
-see the IDs of currently known threads.
-@end smallexample
-@c FIXME to implementors: how hard would it be to say "sorry, this GDB
-@c                        doesn't support threads"?
-@end quotation
-
-@cindex focus of debugging
-@cindex current thread
-The @value{GDBN} thread debugging facility allows you to observe all
-threads while your program runs---but whenever @value{GDBN} takes
-control, one thread in particular is always the focus of debugging.
-This thread is called the @dfn{current thread}.  Debugging commands show
-program information from the perspective of the current thread.
-
-@cindex @code{New} @var{systag} message
-@cindex thread identifier (system)
-@c FIXME-implementors!! It would be more helpful if the [New...] message
-@c included GDB's numeric thread handle, so you could just go to that
-@c thread without first checking `info threads'.
-Whenever @value{GDBN} detects a new thread in your program, it displays
-the target system's identification for the thread with a message in the
-form @samp{[New @var{systag}]}.  @var{systag} is a thread identifier
-whose form varies depending on the particular system.  For example, on
-@sc{gnu}/Linux, you might see
-
-@smallexample
-[New Thread 0x41e02940 (LWP 25582)]
-@end smallexample
-
-@noindent
-when @value{GDBN} notices a new thread.  In contrast, on an SGI system,
-the @var{systag} is simply something like @samp{process 368}, with no
-further qualifier.
-
-@c FIXME!! (1) Does the [New...] message appear even for the very first
-@c         thread of a program, or does it only appear for the
-@c         second---i.e.@: when it becomes obvious we have a multithread
-@c         program?
-@c         (2) *Is* there necessarily a first thread always?  Or do some
-@c         multithread systems permit starting a program with multiple
-@c         threads ab initio?
-
-@cindex thread number
-@cindex thread identifier (GDB)
-For debugging purposes, @value{GDBN} associates its own thread
-number---always a single integer---with each thread in your program.
-
-@table @code
-@kindex info threads
-@item info threads @r{[}@var{id}@dots{}@r{]}
-Display a summary of all threads currently in your program.  Optional 
-argument @var{id}@dots{} is one or more thread ids separated by spaces, and
-means to print information only about the specified thread or threads.
-@value{GDBN} displays for each thread (in this order):
-
-@enumerate
-@item
-the thread number assigned by @value{GDBN}
-
-@item
-the target system's thread identifier (@var{systag})
-
-@item
-the thread's name, if one is known.  A thread can either be named by
-the user (see @code{thread name}, below), or, in some cases, by the
-program itself.
-
-@item
-the current stack frame summary for that thread
-@end enumerate
-
-@noindent
-An asterisk @samp{*} to the left of the @value{GDBN} thread number
-indicates the current thread.
-
-For example,
-@end table
-@c end table here to get a little more width for example
-
-@smallexample
-(@value{GDBP}) info threads
-  Id   Target Id         Frame
-  3    process 35 thread 27  0x34e5 in sigpause ()
-  2    process 35 thread 23  0x34e5 in sigpause ()
-* 1    process 35 thread 13  main (argc=1, argv=0x7ffffff8)
-    at threadtest.c:68
-@end smallexample
-
-On Solaris, you can display more information about user threads with a
-Solaris-specific command:
-
-@table @code
-@item maint info sol-threads
-@kindex maint info sol-threads
-@cindex thread info (Solaris)
-Display info on Solaris user threads.
-@end table
-
-@table @code
-@kindex thread @var{threadno}
-@item thread @var{threadno}
-Make thread number @var{threadno} the current thread.  The command
-argument @var{threadno} is the internal @value{GDBN} thread number, as
-shown in the first field of the @samp{info threads} display.
-@value{GDBN} responds by displaying the system identifier of the thread
-you selected, and its current stack frame summary:
-
-@smallexample
-(@value{GDBP}) thread 2
-[Switching to thread 2 (Thread 0xb7fdab70 (LWP 12747))]
-#0  some_function (ignore=0x0) at example.c:8
-8          printf ("hello\n");
-@end smallexample
-
-@noindent
-As with the @samp{[New @dots{}]} message, the form of the text after
-@samp{Switching to} depends on your system's conventions for identifying
-threads.
-
-@vindex $_thread@r{, convenience variable}
-The debugger convenience variable @samp{$_thread} contains the number
-of the current thread.  You may find this useful in writing breakpoint
-conditional expressions, command scripts, and so forth.  See
-@xref{Convenience Vars,, Convenience Variables}, for general
-information on convenience variables.
-
-@kindex thread apply
-@cindex apply command to several threads
-@item thread apply [@var{threadno} | all] @var{command}
-The @code{thread apply} command allows you to apply the named
-@var{command} to one or more threads.  Specify the numbers of the
-threads that you want affected with the command argument
-@var{threadno}.  It can be a single thread number, one of the numbers
-shown in the first field of the @samp{info threads} display; or it
-could be a range of thread numbers, as in @code{2-4}.  To apply a
-command to all threads, type @kbd{thread apply all @var{command}}.
-
-@kindex thread name
-@cindex name a thread
-@item thread name [@var{name}]
-This command assigns a name to the current thread.  If no argument is
-given, any existing user-specified name is removed.  The thread name
-appears in the @samp{info threads} display.
-
-On some systems, such as @sc{gnu}/Linux, @value{GDBN} is able to
-determine the name of the thread as given by the OS.  On these
-systems, a name specified with @samp{thread name} will override the
-system-give name, and removing the user-specified name will cause
-@value{GDBN} to once again display the system-specified name.
-
-@kindex thread find
-@cindex search for a thread
-@item thread find [@var{regexp}]
-Search for and display thread ids whose name or @var{systag}
-matches the supplied regular expression.
-
-As well as being the complement to the @samp{thread name} command, 
-this command also allows you to identify a thread by its target 
-@var{systag}.  For instance, on @sc{gnu}/Linux, the target @var{systag}
-is the LWP id.
-
-@smallexample
-(@value{GDBN}) thread find 26688
-Thread 4 has target id 'Thread 0x41e02940 (LWP 26688)'
-(@value{GDBN}) info thread 4
-  Id   Target Id         Frame 
-  4    Thread 0x41e02940 (LWP 26688) 0x00000031ca6cd372 in select ()
-@end smallexample
-
-@kindex set print thread-events
-@cindex print messages on thread start and exit
-@item set print thread-events
-@itemx set print thread-events on
-@itemx set print thread-events off
-The @code{set print thread-events} command allows you to enable or
-disable printing of messages when @value{GDBN} notices that new threads have
-started or that threads have exited.  By default, these messages will
-be printed if detection of these events is supported by the target.
-Note that these messages cannot be disabled on all targets.
-
-@kindex show print thread-events
-@item show print thread-events
-Show whether messages will be printed when @value{GDBN} detects that threads
-have started and exited.
-@end table
-
-@xref{Thread Stops,,Stopping and Starting Multi-thread Programs}, for
-more information about how @value{GDBN} behaves when you stop and start
-programs with multiple threads.
-
-@xref{Set Watchpoints,,Setting Watchpoints}, for information about
-watchpoints in programs with multiple threads.
-
-@anchor{set libthread-db-search-path}
-@table @code
-@kindex set libthread-db-search-path
-@cindex search path for @code{libthread_db}
-@item set libthread-db-search-path @r{[}@var{path}@r{]}
-If this variable is set, @var{path} is a colon-separated list of
-directories @value{GDBN} will use to search for @code{libthread_db}.
-If you omit @var{path}, @samp{libthread-db-search-path} will be reset to
-its default value (@code{$sdir:$pdir} on @sc{gnu}/Linux and Solaris systems).
-Internally, the default value comes from the @code{LIBTHREAD_DB_SEARCH_PATH}
-macro.
-
-On @sc{gnu}/Linux and Solaris systems, @value{GDBN} uses a ``helper''
-@code{libthread_db} library to obtain information about threads in the
-inferior process.  @value{GDBN} will use @samp{libthread-db-search-path}
-to find @code{libthread_db}.  @value{GDBN} also consults first if inferior
-specific thread debugging library loading is enabled
-by @samp{set auto-load libthread-db} (@pxref{libthread_db.so.1 file}).
-
-A special entry @samp{$sdir} for @samp{libthread-db-search-path}
-refers to the default system directories that are
-normally searched for loading shared libraries.  The @samp{$sdir} entry
-is the only kind not needing to be enabled by @samp{set auto-load libthread-db}
-(@pxref{libthread_db.so.1 file}).
-
-A special entry @samp{$pdir} for @samp{libthread-db-search-path}
-refers to the directory from which @code{libpthread}
-was loaded in the inferior process.
-
-For any @code{libthread_db} library @value{GDBN} finds in above directories,
-@value{GDBN} attempts to initialize it with the current inferior process.
-If this initialization fails (which could happen because of a version
-mismatch between @code{libthread_db} and @code{libpthread}), @value{GDBN}
-will unload @code{libthread_db}, and continue with the next directory.
-If none of @code{libthread_db} libraries initialize successfully,
-@value{GDBN} will issue a warning and thread debugging will be disabled.
-
-Setting @code{libthread-db-search-path} is currently implemented
-only on some platforms.
-
-@kindex show libthread-db-search-path 
-@item show libthread-db-search-path 
-Display current libthread_db search path.
-
-@kindex set debug libthread-db
-@kindex show debug libthread-db
-@cindex debugging @code{libthread_db}
-@item set debug libthread-db
-@itemx show debug libthread-db
-Turns on or off display of @code{libthread_db}-related events.
-Use @code{1} to enable, @code{0} to disable.
-@end table
-
-@node Forks
-@section Debugging Forks
-
-@cindex fork, debugging programs which call
-@cindex multiple processes
-@cindex processes, multiple
-On most systems, @value{GDBN} has no special support for debugging
-programs which create additional processes using the @code{fork}
-function.  When a program forks, @value{GDBN} will continue to debug the
-parent process and the child process will run unimpeded.  If you have
-set a breakpoint in any code which the child then executes, the child
-will get a @code{SIGTRAP} signal which (unless it catches the signal)
-will cause it to terminate.
-
-However, if you want to debug the child process there is a workaround
-which isn't too painful.  Put a call to @code{sleep} in the code which
-the child process executes after the fork.  It may be useful to sleep
-only if a certain environment variable is set, or a certain file exists,
-so that the delay need not occur when you don't want to run @value{GDBN}
-on the child.  While the child is sleeping, use the @code{ps} program to
-get its process ID.  Then tell @value{GDBN} (a new invocation of
-@value{GDBN} if you are also debugging the parent process) to attach to
-the child process (@pxref{Attach}).  From that point on you can debug
-the child process just like any other process which you attached to.
-
-On some systems, @value{GDBN} provides support for debugging programs that
-create additional processes using the @code{fork} or @code{vfork} functions.
-Currently, the only platforms with this feature are HP-UX (11.x and later
-only?) and @sc{gnu}/Linux (kernel version 2.5.60 and later).
-
-By default, when a program forks, @value{GDBN} will continue to debug
-the parent process and the child process will run unimpeded.
-
-If you want to follow the child process instead of the parent process,
-use the command @w{@code{set follow-fork-mode}}.
-
-@table @code
-@kindex set follow-fork-mode
-@item set follow-fork-mode @var{mode}
-Set the debugger response to a program call of @code{fork} or
-@code{vfork}.  A call to @code{fork} or @code{vfork} creates a new
-process.  The @var{mode} argument can be:
-
-@table @code
-@item parent
-The original process is debugged after a fork.  The child process runs
-unimpeded.  This is the default.
-
-@item child
-The new process is debugged after a fork.  The parent process runs
-unimpeded.
-
-@end table
-
-@kindex show follow-fork-mode
-@item show follow-fork-mode
-Display the current debugger response to a @code{fork} or @code{vfork} call.
-@end table
-
-@cindex debugging multiple processes
-On Linux, if you want to debug both the parent and child processes, use the
-command @w{@code{set detach-on-fork}}.
-
-@table @code
-@kindex set detach-on-fork
-@item set detach-on-fork @var{mode}
-Tells gdb whether to detach one of the processes after a fork, or
-retain debugger control over them both.
-
-@table @code
-@item on
-The child process (or parent process, depending on the value of
-@code{follow-fork-mode}) will be detached and allowed to run 
-independently.  This is the default.
-
-@item off
-Both processes will be held under the control of @value{GDBN}.
-One process (child or parent, depending on the value of 
-@code{follow-fork-mode}) is debugged as usual, while the other
-is held suspended.  
-
-@end table
-
-@kindex show detach-on-fork
-@item show detach-on-fork
-Show whether detach-on-fork mode is on/off.
-@end table
-
-If you choose to set @samp{detach-on-fork} mode off, then @value{GDBN}
-will retain control of all forked processes (including nested forks).
-You can list the forked processes under the control of @value{GDBN} by
-using the @w{@code{info inferiors}} command, and switch from one fork
-to another by using the @code{inferior} command (@pxref{Inferiors and
-Programs, ,Debugging Multiple Inferiors and Programs}).
-
-To quit debugging one of the forked processes, you can either detach
-from it by using the @w{@code{detach inferiors}} command (allowing it
-to run independently), or kill it using the @w{@code{kill inferiors}}
-command.  @xref{Inferiors and Programs, ,Debugging Multiple Inferiors
-and Programs}.
-
-If you ask to debug a child process and a @code{vfork} is followed by an
-@code{exec}, @value{GDBN} executes the new target up to the first
-breakpoint in the new target.  If you have a breakpoint set on
-@code{main} in your original program, the breakpoint will also be set on
-the child process's @code{main}.
-
-On some systems, when a child process is spawned by @code{vfork}, you
-cannot debug the child or parent until an @code{exec} call completes.
-
-If you issue a @code{run} command to @value{GDBN} after an @code{exec}
-call executes, the new target restarts.  To restart the parent
-process, use the @code{file} command with the parent executable name
-as its argument.  By default, after an @code{exec} call executes,
-@value{GDBN} discards the symbols of the previous executable image.
-You can change this behaviour with the @w{@code{set follow-exec-mode}}
-command.
-
-@table @code
-@kindex set follow-exec-mode
-@item set follow-exec-mode @var{mode}
-
-Set debugger response to a program call of @code{exec}.  An
-@code{exec} call replaces the program image of a process.
-
-@code{follow-exec-mode} can be:
-
-@table @code
-@item new
-@value{GDBN} creates a new inferior and rebinds the process to this
-new inferior.  The program the process was running before the
-@code{exec} call can be restarted afterwards by restarting the
-original inferior.
-
-For example:
-
-@smallexample
-(@value{GDBP}) info inferiors
-(gdb) info inferior
-  Id   Description   Executable
-* 1    <null>        prog1
-(@value{GDBP}) run
-process 12020 is executing new program: prog2
-Program exited normally.
-(@value{GDBP}) info inferiors
-  Id   Description   Executable
-* 2    <null>        prog2
-  1    <null>        prog1
-@end smallexample
-
-@item same
-@value{GDBN} keeps the process bound to the same inferior.  The new
-executable image replaces the previous executable loaded in the
-inferior.  Restarting the inferior after the @code{exec} call, with
-e.g., the @code{run} command, restarts the executable the process was
-running after the @code{exec} call.  This is the default mode.
-
-For example:
-
-@smallexample
-(@value{GDBP}) info inferiors
-  Id   Description   Executable
-* 1    <null>        prog1
-(@value{GDBP}) run
-process 12020 is executing new program: prog2
-Program exited normally.
-(@value{GDBP}) info inferiors
-  Id   Description   Executable
-* 1    <null>        prog2
-@end smallexample
-
-@end table
-@end table
-
-You can use the @code{catch} command to make @value{GDBN} stop whenever
-a @code{fork}, @code{vfork}, or @code{exec} call is made.  @xref{Set
-Catchpoints, ,Setting Catchpoints}.
-
-@node Checkpoint/Restart
-@section Setting a @emph{Bookmark} to Return to Later
-
-@cindex checkpoint
-@cindex restart
-@cindex bookmark
-@cindex snapshot of a process
-@cindex rewind program state
-
-On certain operating systems@footnote{Currently, only
-@sc{gnu}/Linux.}, @value{GDBN} is able to save a @dfn{snapshot} of a
-program's state, called a @dfn{checkpoint}, and come back to it
-later.
-
-Returning to a checkpoint effectively undoes everything that has
-happened in the program since the @code{checkpoint} was saved.  This
-includes changes in memory, registers, and even (within some limits)
-system state.  Effectively, it is like going back in time to the
-moment when the checkpoint was saved.
-
-Thus, if you're stepping thru a program and you think you're 
-getting close to the point where things go wrong, you can save
-a checkpoint.  Then, if you accidentally go too far and miss
-the critical statement, instead of having to restart your program
-from the beginning, you can just go back to the checkpoint and
-start again from there.
-
-This can be especially useful if it takes a lot of time or 
-steps to reach the point where you think the bug occurs.  
-
-To use the @code{checkpoint}/@code{restart} method of debugging:
-
-@table @code
-@kindex checkpoint
-@item checkpoint
-Save a snapshot of the debugged program's current execution state.
-The @code{checkpoint} command takes no arguments, but each checkpoint
-is assigned a small integer id, similar to a breakpoint id.
-
-@kindex info checkpoints
-@item info checkpoints
-List the checkpoints that have been saved in the current debugging
-session.  For each checkpoint, the following information will be
-listed:
-
-@table @code
-@item Checkpoint ID
-@item Process ID
-@item Code Address
-@item Source line, or label
-@end table
-
-@kindex restart @var{checkpoint-id}
-@item restart @var{checkpoint-id}
-Restore the program state that was saved as checkpoint number
-@var{checkpoint-id}.  All program variables, registers, stack frames
-etc.@:  will be returned to the values that they had when the checkpoint
-was saved.  In essence, gdb will ``wind back the clock'' to the point
-in time when the checkpoint was saved.
-
-Note that breakpoints, @value{GDBN} variables, command history etc.
-are not affected by restoring a checkpoint.  In general, a checkpoint
-only restores things that reside in the program being debugged, not in
-the debugger.
-
-@kindex delete checkpoint @var{checkpoint-id}
-@item delete checkpoint @var{checkpoint-id}
-Delete the previously-saved checkpoint identified by @var{checkpoint-id}.
-
-@end table
-
-Returning to a previously saved checkpoint will restore the user state
-of the program being debugged, plus a significant subset of the system
-(OS) state, including file pointers.  It won't ``un-write'' data from
-a file, but it will rewind the file pointer to the previous location,
-so that the previously written data can be overwritten.  For files
-opened in read mode, the pointer will also be restored so that the
-previously read data can be read again.
-
-Of course, characters that have been sent to a printer (or other
-external device) cannot be ``snatched back'', and characters received
-from eg.@: a serial device can be removed from internal program buffers,
-but they cannot be ``pushed back'' into the serial pipeline, ready to
-be received again.  Similarly, the actual contents of files that have
-been changed cannot be restored (at this time).
-
-However, within those constraints, you actually can ``rewind'' your
-program to a previously saved point in time, and begin debugging it
-again --- and you can change the course of events so as to debug a
-different execution path this time.
-
-@cindex checkpoints and process id
-Finally, there is one bit of internal program state that will be
-different when you return to a checkpoint --- the program's process
-id.  Each checkpoint will have a unique process id (or @var{pid}), 
-and each will be different from the program's original @var{pid}.
-If your program has saved a local copy of its process id, this could
-potentially pose a problem.
-
-@subsection A Non-obvious Benefit of Using Checkpoints
-
-On some systems such as @sc{gnu}/Linux, address space randomization
-is performed on new processes for security reasons.  This makes it 
-difficult or impossible to set a breakpoint, or watchpoint, on an
-absolute address if you have to restart the program, since the 
-absolute location of a symbol will change from one execution to the
-next.
-
-A checkpoint, however, is an @emph{identical} copy of a process. 
-Therefore if you create a checkpoint at (eg.@:) the start of main, 
-and simply return to that checkpoint instead of restarting the 
-process, you can avoid the effects of address randomization and
-your symbols will all stay in the same place.
-
-@node Stopping
-@chapter Stopping and Continuing
-
-The principal purposes of using a debugger are so that you can stop your
-program before it terminates; or so that, if your program runs into
-trouble, you can investigate and find out why.
-
-Inside @value{GDBN}, your program may stop for any of several reasons,
-such as a signal, a breakpoint, or reaching a new line after a
-@value{GDBN} command such as @code{step}.  You may then examine and
-change variables, set new breakpoints or remove old ones, and then
-continue execution.  Usually, the messages shown by @value{GDBN} provide
-ample explanation of the status of your program---but you can also
-explicitly request this information at any time.
-
-@table @code
-@kindex info program
-@item info program
-Display information about the status of your program: whether it is
-running or not, what process it is, and why it stopped.
-@end table
-
-@menu
-* Breakpoints::                 Breakpoints, watchpoints, and catchpoints
-* Continuing and Stepping::     Resuming execution
-* Skipping Over Functions and Files::
-                                Skipping over functions and files
-* Signals::                     Signals
-* Thread Stops::                Stopping and starting multi-thread programs
-@end menu
-
-@node Breakpoints
-@section Breakpoints, Watchpoints, and Catchpoints
-
-@cindex breakpoints
-A @dfn{breakpoint} makes your program stop whenever a certain point in
-the program is reached.  For each breakpoint, you can add conditions to
-control in finer detail whether your program stops.  You can set
-breakpoints with the @code{break} command and its variants (@pxref{Set
-Breaks, ,Setting Breakpoints}), to specify the place where your program
-should stop by line number, function name or exact address in the
-program.
-
-On some systems, you can set breakpoints in shared libraries before
-the executable is run.  There is a minor limitation on HP-UX systems:
-you must wait until the executable is run in order to set breakpoints
-in shared library routines that are not called directly by the program
-(for example, routines that are arguments in a @code{pthread_create}
-call).
-
-@cindex watchpoints
-@cindex data breakpoints
-@cindex memory tracing
-@cindex breakpoint on memory address
-@cindex breakpoint on variable modification
-A @dfn{watchpoint} is a special breakpoint that stops your program
-when the value of an expression changes.  The expression may be a value
-of a variable, or it could involve values of one or more variables
-combined by operators, such as @samp{a + b}.  This is sometimes called
-@dfn{data breakpoints}.  You must use a different command to set
-watchpoints (@pxref{Set Watchpoints, ,Setting Watchpoints}), but aside
-from that, you can manage a watchpoint like any other breakpoint: you
-enable, disable, and delete both breakpoints and watchpoints using the
-same commands.
-
-You can arrange to have values from your program displayed automatically
-whenever @value{GDBN} stops at a breakpoint.  @xref{Auto Display,,
-Automatic Display}.
-
-@cindex catchpoints
-@cindex breakpoint on events
-A @dfn{catchpoint} is another special breakpoint that stops your program
-when a certain kind of event occurs, such as the throwing of a C@t{++}
-exception or the loading of a library.  As with watchpoints, you use a
-different command to set a catchpoint (@pxref{Set Catchpoints, ,Setting
-Catchpoints}), but aside from that, you can manage a catchpoint like any
-other breakpoint.  (To stop when your program receives a signal, use the
-@code{handle} command; see @ref{Signals, ,Signals}.)
-
-@cindex breakpoint numbers
-@cindex numbers for breakpoints
-@value{GDBN} assigns a number to each breakpoint, watchpoint, or
-catchpoint when you create it; these numbers are successive integers
-starting with one.  In many of the commands for controlling various
-features of breakpoints you use the breakpoint number to say which
-breakpoint you want to change.  Each breakpoint may be @dfn{enabled} or
-@dfn{disabled}; if disabled, it has no effect on your program until you
-enable it again.
-
-@cindex breakpoint ranges
-@cindex ranges of breakpoints
-Some @value{GDBN} commands accept a range of breakpoints on which to
-operate.  A breakpoint range is either a single breakpoint number, like
-@samp{5}, or two such numbers, in increasing order, separated by a
-hyphen, like @samp{5-7}.  When a breakpoint range is given to a command,
-all breakpoints in that range are operated on.
-
-@menu
-* Set Breaks::                  Setting breakpoints
-* Set Watchpoints::             Setting watchpoints
-* Set Catchpoints::             Setting catchpoints
-* Delete Breaks::               Deleting breakpoints
-* Disabling::                   Disabling breakpoints
-* Conditions::                  Break conditions
-* Break Commands::              Breakpoint command lists
-* Dynamic Printf::              Dynamic printf
-* Save Breakpoints::            How to save breakpoints in a file
-* Static Probe Points::         Listing static probe points
-* Error in Breakpoints::        ``Cannot insert breakpoints''
-* Breakpoint-related Warnings:: ``Breakpoint address adjusted...''
-@end menu
-
-@node Set Breaks
-@subsection Setting Breakpoints
-
-@c FIXME LMB what does GDB do if no code on line of breakpt?
-@c       consider in particular declaration with/without initialization.
-@c
-@c FIXME 2 is there stuff on this already? break at fun start, already init?
-
-@kindex break
-@kindex b @r{(@code{break})}
-@vindex $bpnum@r{, convenience variable}
-@cindex latest breakpoint
-Breakpoints are set with the @code{break} command (abbreviated
-@code{b}).  The debugger convenience variable @samp{$bpnum} records the
-number of the breakpoint you've set most recently; see @ref{Convenience
-Vars,, Convenience Variables}, for a discussion of what you can do with
-convenience variables.
-
-@table @code
-@item break @var{location}
-Set a breakpoint at the given @var{location}, which can specify a
-function name, a line number, or an address of an instruction.
-(@xref{Specify Location}, for a list of all the possible ways to
-specify a @var{location}.)  The breakpoint will stop your program just
-before it executes any of the code in the specified @var{location}.
-
-When using source languages that permit overloading of symbols, such as
-C@t{++}, a function name may refer to more than one possible place to break.
-@xref{Ambiguous Expressions,,Ambiguous Expressions}, for a discussion of
-that situation.
-
-It is also possible to insert a breakpoint that will stop the program
-only if a specific thread (@pxref{Thread-Specific Breakpoints})
-or a specific task (@pxref{Ada Tasks}) hits that breakpoint.
-
-@item break
-When called without any arguments, @code{break} sets a breakpoint at
-the next instruction to be executed in the selected stack frame
-(@pxref{Stack, ,Examining the Stack}).  In any selected frame but the
-innermost, this makes your program stop as soon as control
-returns to that frame.  This is similar to the effect of a
-@code{finish} command in the frame inside the selected frame---except
-that @code{finish} does not leave an active breakpoint.  If you use
-@code{break} without an argument in the innermost frame, @value{GDBN} stops
-the next time it reaches the current location; this may be useful
-inside loops.
-
-@value{GDBN} normally ignores breakpoints when it resumes execution, until at
-least one instruction has been executed.  If it did not do this, you
-would be unable to proceed past a breakpoint without first disabling the
-breakpoint.  This rule applies whether or not the breakpoint already
-existed when your program stopped.
-
-@item break @dots{} if @var{cond}
-Set a breakpoint with condition @var{cond}; evaluate the expression
-@var{cond} each time the breakpoint is reached, and stop only if the
-value is nonzero---that is, if @var{cond} evaluates as true.
-@samp{@dots{}} stands for one of the possible arguments described
-above (or no argument) specifying where to break.  @xref{Conditions,
-,Break Conditions}, for more information on breakpoint conditions.
-
-@kindex tbreak
-@item tbreak @var{args}
-Set a breakpoint enabled only for one stop.  @var{args} are the
-same as for the @code{break} command, and the breakpoint is set in the same
-way, but the breakpoint is automatically deleted after the first time your
-program stops there.  @xref{Disabling, ,Disabling Breakpoints}.
-
-@kindex hbreak
-@cindex hardware breakpoints
-@item hbreak @var{args}
-Set a hardware-assisted breakpoint.  @var{args} are the same as for the
-@code{break} command and the breakpoint is set in the same way, but the
-breakpoint requires hardware support and some target hardware may not
-have this support.  The main purpose of this is EPROM/ROM code
-debugging, so you can set a breakpoint at an instruction without
-changing the instruction.  This can be used with the new trap-generation
-provided by SPARClite DSU and most x86-based targets.  These targets
-will generate traps when a program accesses some data or instruction
-address that is assigned to the debug registers.  However the hardware
-breakpoint registers can take a limited number of breakpoints.  For
-example, on the DSU, only two data breakpoints can be set at a time, and
-@value{GDBN} will reject this command if more than two are used.  Delete
-or disable unused hardware breakpoints before setting new ones
-(@pxref{Disabling, ,Disabling Breakpoints}).
-@xref{Conditions, ,Break Conditions}.
-For remote targets, you can restrict the number of hardware
-breakpoints @value{GDBN} will use, see @ref{set remote
-hardware-breakpoint-limit}.
-
-@kindex thbreak
-@item thbreak @var{args}
-Set a hardware-assisted breakpoint enabled only for one stop.  @var{args}
-are the same as for the @code{hbreak} command and the breakpoint is set in
-the same way.  However, like the @code{tbreak} command,
-the breakpoint is automatically deleted after the
-first time your program stops there.  Also, like the @code{hbreak}
-command, the breakpoint requires hardware support and some target hardware
-may not have this support.  @xref{Disabling, ,Disabling Breakpoints}.
-See also @ref{Conditions, ,Break Conditions}.
-
-@kindex rbreak
-@cindex regular expression
-@cindex breakpoints at functions matching a regexp
-@cindex set breakpoints in many functions
-@item rbreak @var{regex}
-Set breakpoints on all functions matching the regular expression
-@var{regex}.  This command sets an unconditional breakpoint on all
-matches, printing a list of all breakpoints it set.  Once these
-breakpoints are set, they are treated just like the breakpoints set with
-the @code{break} command.  You can delete them, disable them, or make
-them conditional the same way as any other breakpoint.
-
-The syntax of the regular expression is the standard one used with tools
-like @file{grep}.  Note that this is different from the syntax used by
-shells, so for instance @code{foo*} matches all functions that include
-an @code{fo} followed by zero or more @code{o}s.  There is an implicit
-@code{.*} leading and trailing the regular expression you supply, so to
-match only functions that begin with @code{foo}, use @code{^foo}.
-
-@cindex non-member C@t{++} functions, set breakpoint in
-When debugging C@t{++} programs, @code{rbreak} is useful for setting
-breakpoints on overloaded functions that are not members of any special
-classes.
-
-@cindex set breakpoints on all functions
-The @code{rbreak} command can be used to set breakpoints in
-@strong{all} the functions in a program, like this:
-
-@smallexample
-(@value{GDBP}) rbreak .
-@end smallexample
-
-@item rbreak @var{file}:@var{regex}
-If @code{rbreak} is called with a filename qualification, it limits
-the search for functions matching the given regular expression to the
-specified @var{file}.  This can be used, for example, to set breakpoints on
-every function in a given file:
-
-@smallexample
-(@value{GDBP}) rbreak file.c:.
-@end smallexample
-
-The colon separating the filename qualifier from the regex may
-optionally be surrounded by spaces.
-
-@kindex info breakpoints
-@cindex @code{$_} and @code{info breakpoints}
-@item info breakpoints @r{[}@var{n}@dots{}@r{]}
-@itemx info break @r{[}@var{n}@dots{}@r{]}
-Print a table of all breakpoints, watchpoints, and catchpoints set and
-not deleted.  Optional argument @var{n} means print information only
-about the specified breakpoint(s) (or watchpoint(s) or catchpoint(s)).
-For each breakpoint, following columns are printed:
-
-@table @emph
-@item Breakpoint Numbers
-@item Type
-Breakpoint, watchpoint, or catchpoint.
-@item Disposition
-Whether the breakpoint is marked to be disabled or deleted when hit.
-@item Enabled or Disabled
-Enabled breakpoints are marked with @samp{y}.  @samp{n} marks breakpoints
-that are not enabled.
-@item Address
-Where the breakpoint is in your program, as a memory address.  For a
-pending breakpoint whose address is not yet known, this field will
-contain @samp{<PENDING>}.  Such breakpoint won't fire until a shared
-library that has the symbol or line referred by breakpoint is loaded.
-See below for details.  A breakpoint with several locations will
-have @samp{<MULTIPLE>} in this field---see below for details.
-@item What
-Where the breakpoint is in the source for your program, as a file and
-line number.  For a pending breakpoint, the original string passed to
-the breakpoint command will be listed as it cannot be resolved until
-the appropriate shared library is loaded in the future.
-@end table
-
-@noindent
-If a breakpoint is conditional, there are two evaluation modes: ``host'' and
-``target''.  If mode is ``host'', breakpoint condition evaluation is done by
-@value{GDBN} on the host's side.  If it is ``target'', then the condition
-is evaluated by the target.  The @code{info break} command shows
-the condition on the line following the affected breakpoint, together with
-its condition evaluation mode in between parentheses.
-
-Breakpoint commands, if any, are listed after that.  A pending breakpoint is
-allowed to have a condition specified for it.  The condition is not parsed for
-validity until a shared library is loaded that allows the pending
-breakpoint to resolve to a valid location.
-
-@noindent
-@code{info break} with a breakpoint
-number @var{n} as argument lists only that breakpoint.  The
-convenience variable @code{$_} and the default examining-address for
-the @code{x} command are set to the address of the last breakpoint
-listed (@pxref{Memory, ,Examining Memory}).
-
-@noindent
-@code{info break} displays a count of the number of times the breakpoint
-has been hit.  This is especially useful in conjunction with the
-@code{ignore} command.  You can ignore a large number of breakpoint
-hits, look at the breakpoint info to see how many times the breakpoint
-was hit, and then run again, ignoring one less than that number.  This
-will get you quickly to the last hit of that breakpoint.
-
-@noindent
-For a breakpoints with an enable count (xref) greater than 1,
-@code{info break} also displays that count.
-
-@end table
-
-@value{GDBN} allows you to set any number of breakpoints at the same place in
-your program.  There is nothing silly or meaningless about this.  When
-the breakpoints are conditional, this is even useful
-(@pxref{Conditions, ,Break Conditions}).
-
-@cindex multiple locations, breakpoints
-@cindex breakpoints, multiple locations
-It is possible that a breakpoint corresponds to several locations
-in your program.  Examples of this situation are:
-
-@itemize @bullet
-@item
-Multiple functions in the program may have the same name.
-
-@item
-For a C@t{++} constructor, the @value{NGCC} compiler generates several
-instances of the function body, used in different cases.
-
-@item
-For a C@t{++} template function, a given line in the function can
-correspond to any number of instantiations.
-
-@item
-For an inlined function, a given source line can correspond to
-several places where that function is inlined.
-@end itemize
-
-In all those cases, @value{GDBN} will insert a breakpoint at all
-the relevant locations.
-
-A breakpoint with multiple locations is displayed in the breakpoint
-table using several rows---one header row, followed by one row for
-each breakpoint location.  The header row has @samp{<MULTIPLE>} in the
-address column.  The rows for individual locations contain the actual
-addresses for locations, and show the functions to which those
-locations belong.  The number column for a location is of the form
-@var{breakpoint-number}.@var{location-number}.
-
-For example:
-
-@smallexample
-Num     Type           Disp Enb  Address    What
-1       breakpoint     keep y    <MULTIPLE>
-        stop only if i==1
-        breakpoint already hit 1 time
-1.1                         y    0x080486a2 in void foo<int>() at t.cc:8
-1.2                         y    0x080486ca in void foo<double>() at t.cc:8
-@end smallexample
-
-Each location can be individually enabled or disabled by passing
-@var{breakpoint-number}.@var{location-number} as argument to the
-@code{enable} and @code{disable} commands.  Note that you cannot
-delete the individual locations from the list, you can only delete the
-entire list of locations that belong to their parent breakpoint (with
-the @kbd{delete @var{num}} command, where @var{num} is the number of
-the parent breakpoint, 1 in the above example).  Disabling or enabling
-the parent breakpoint (@pxref{Disabling}) affects all of the locations
-that belong to that breakpoint.
-
-@cindex pending breakpoints
-It's quite common to have a breakpoint inside a shared library.
-Shared libraries can be loaded and unloaded explicitly,
-and possibly repeatedly, as the program is executed.  To support
-this use case, @value{GDBN} updates breakpoint locations whenever
-any shared library is loaded or unloaded.  Typically, you would
-set a breakpoint in a shared library at the beginning of your
-debugging session, when the library is not loaded, and when the
-symbols from the library are not available.  When you try to set
-breakpoint, @value{GDBN} will ask you if you want to set
-a so called @dfn{pending breakpoint}---breakpoint whose address
-is not yet resolved.
-
-After the program is run, whenever a new shared library is loaded,
-@value{GDBN} reevaluates all the breakpoints.  When a newly loaded
-shared library contains the symbol or line referred to by some
-pending breakpoint, that breakpoint is resolved and becomes an
-ordinary breakpoint.  When a library is unloaded, all breakpoints
-that refer to its symbols or source lines become pending again.
-
-This logic works for breakpoints with multiple locations, too.  For
-example, if you have a breakpoint in a C@t{++} template function, and
-a newly loaded shared library has an instantiation of that template,
-a new location is added to the list of locations for the breakpoint.
-
-Except for having unresolved address, pending breakpoints do not
-differ from regular breakpoints.  You can set conditions or commands,
-enable and disable them and perform other breakpoint operations.
-
-@value{GDBN} provides some additional commands for controlling what
-happens when the @samp{break} command cannot resolve breakpoint
-address specification to an address:
-
-@kindex set breakpoint pending
-@kindex show breakpoint pending
-@table @code
-@item set breakpoint pending auto
-This is the default behavior.  When @value{GDBN} cannot find the breakpoint
-location, it queries you whether a pending breakpoint should be created.
-
-@item set breakpoint pending on
-This indicates that an unrecognized breakpoint location should automatically
-result in a pending breakpoint being created.
-
-@item set breakpoint pending off
-This indicates that pending breakpoints are not to be created.  Any
-unrecognized breakpoint location results in an error.  This setting does
-not affect any pending breakpoints previously created.
-
-@item show breakpoint pending
-Show the current behavior setting for creating pending breakpoints.
-@end table
-
-The settings above only affect the @code{break} command and its
-variants.  Once breakpoint is set, it will be automatically updated
-as shared libraries are loaded and unloaded.
-
-@cindex automatic hardware breakpoints
-For some targets, @value{GDBN} can automatically decide if hardware or
-software breakpoints should be used, depending on whether the
-breakpoint address is read-only or read-write.  This applies to
-breakpoints set with the @code{break} command as well as to internal
-breakpoints set by commands like @code{next} and @code{finish}.  For
-breakpoints set with @code{hbreak}, @value{GDBN} will always use hardware
-breakpoints.
-
-You can control this automatic behaviour with the following commands::
-
-@kindex set breakpoint auto-hw
-@kindex show breakpoint auto-hw
-@table @code
-@item set breakpoint auto-hw on
-This is the default behavior.  When @value{GDBN} sets a breakpoint, it
-will try to use the target memory map to decide if software or hardware
-breakpoint must be used.
-
-@item set breakpoint auto-hw off
-This indicates @value{GDBN} should not automatically select breakpoint
-type.  If the target provides a memory map, @value{GDBN} will warn when
-trying to set software breakpoint at a read-only address.
-@end table
-
-@value{GDBN} normally implements breakpoints by replacing the program code
-at the breakpoint address with a special instruction, which, when
-executed, given control to the debugger.  By default, the program
-code is so modified only when the program is resumed.  As soon as
-the program stops, @value{GDBN} restores the original instructions.  This
-behaviour guards against leaving breakpoints inserted in the
-target should gdb abrubptly disconnect.  However, with slow remote
-targets, inserting and removing breakpoint can reduce the performance.
-This behavior can be controlled with the following commands::
-
-@kindex set breakpoint always-inserted
-@kindex show breakpoint always-inserted
-@table @code
-@item set breakpoint always-inserted off
-All breakpoints, including newly added by the user, are inserted in
-the target only when the target is resumed.  All breakpoints are
-removed from the target when it stops.
-
-@item set breakpoint always-inserted on
-Causes all breakpoints to be inserted in the target at all times.  If
-the user adds a new breakpoint, or changes an existing breakpoint, the
-breakpoints in the target are updated immediately.  A breakpoint is
-removed from the target only when breakpoint itself is removed.
-
-@cindex non-stop mode, and @code{breakpoint always-inserted}
-@item set breakpoint always-inserted auto
-This is the default mode.  If @value{GDBN} is controlling the inferior
-in non-stop mode (@pxref{Non-Stop Mode}), gdb behaves as if
-@code{breakpoint always-inserted} mode is on.  If @value{GDBN} is
-controlling the inferior in all-stop mode, @value{GDBN} behaves as if
-@code{breakpoint always-inserted} mode is off.
-@end table
-
-@value{GDBN} handles conditional breakpoints by evaluating these conditions
-when a breakpoint breaks.  If the condition is true, then the process being
-debugged stops, otherwise the process is resumed.
-
-If the target supports evaluating conditions on its end, @value{GDBN} may
-download the breakpoint, together with its conditions, to it.
-
-This feature can be controlled via the following commands:
-
-@kindex set breakpoint condition-evaluation
-@kindex show breakpoint condition-evaluation
-@table @code
-@item set breakpoint condition-evaluation host
-This option commands @value{GDBN} to evaluate the breakpoint
-conditions on the host's side.  Unconditional breakpoints are sent to
-the target which in turn receives the triggers and reports them back to GDB
-for condition evaluation.  This is the standard evaluation mode.
-
-@item set breakpoint condition-evaluation target
-This option commands @value{GDBN} to download breakpoint conditions
-to the target at the moment of their insertion.  The target
-is responsible for evaluating the conditional expression and reporting
-breakpoint stop events back to @value{GDBN} whenever the condition
-is true.  Due to limitations of target-side evaluation, some conditions
-cannot be evaluated there, e.g., conditions that depend on local data
-that is only known to the host.  Examples include
-conditional expressions involving convenience variables, complex types
-that cannot be handled by the agent expression parser and expressions
-that are too long to be sent over to the target, specially when the
-target is a remote system.  In these cases, the conditions will be
-evaluated by @value{GDBN}.
-
-@item set breakpoint condition-evaluation auto
-This is the default mode.  If the target supports evaluating breakpoint
-conditions on its end, @value{GDBN} will download breakpoint conditions to
-the target (limitations mentioned previously apply).  If the target does
-not support breakpoint condition evaluation, then @value{GDBN} will fallback
-to evaluating all these conditions on the host's side.
-@end table
-
-
-@cindex negative breakpoint numbers
-@cindex internal @value{GDBN} breakpoints
-@value{GDBN} itself sometimes sets breakpoints in your program for
-special purposes, such as proper handling of @code{longjmp} (in C
-programs).  These internal breakpoints are assigned negative numbers,
-starting with @code{-1}; @samp{info breakpoints} does not display them.
-You can see these breakpoints with the @value{GDBN} maintenance command
-@samp{maint info breakpoints} (@pxref{maint info breakpoints}).
-
-
-@node Set Watchpoints
-@subsection Setting Watchpoints
-
-@cindex setting watchpoints
-You can use a watchpoint to stop execution whenever the value of an
-expression changes, without having to predict a particular place where
-this may happen.  (This is sometimes called a @dfn{data breakpoint}.)
-The expression may be as simple as the value of a single variable, or
-as complex as many variables combined by operators.  Examples include:
-
-@itemize @bullet
-@item
-A reference to the value of a single variable.
-
-@item
-An address cast to an appropriate data type.  For example,
-@samp{*(int *)0x12345678} will watch a 4-byte region at the specified
-address (assuming an @code{int} occupies 4 bytes).
-
-@item
-An arbitrarily complex expression, such as @samp{a*b + c/d}.  The
-expression can use any operators valid in the program's native
-language (@pxref{Languages}).
-@end itemize
-
-You can set a watchpoint on an expression even if the expression can
-not be evaluated yet.  For instance, you can set a watchpoint on
-@samp{*global_ptr} before @samp{global_ptr} is initialized.
-@value{GDBN} will stop when your program sets @samp{global_ptr} and
-the expression produces a valid value.  If the expression becomes
-valid in some other way than changing a variable (e.g.@: if the memory
-pointed to by @samp{*global_ptr} becomes readable as the result of a
-@code{malloc} call), @value{GDBN} may not stop until the next time
-the expression changes.
-
-@cindex software watchpoints
-@cindex hardware watchpoints
-Depending on your system, watchpoints may be implemented in software or
-hardware.  @value{GDBN} does software watchpointing by single-stepping your
-program and testing the variable's value each time, which is hundreds of
-times slower than normal execution.  (But this may still be worth it, to
-catch errors where you have no clue what part of your program is the
-culprit.)
-
-On some systems, such as HP-UX, PowerPC, @sc{gnu}/Linux and most other
-x86-based targets, @value{GDBN} includes support for hardware
-watchpoints, which do not slow down the running of your program.
-
-@table @code
-@kindex watch
-@item watch @r{[}-l@r{|}-location@r{]} @var{expr} @r{[}thread @var{threadnum}@r{]} @r{[}mask @var{maskvalue}@r{]}
-Set a watchpoint for an expression.  @value{GDBN} will break when the
-expression @var{expr} is written into by the program and its value
-changes.  The simplest (and the most popular) use of this command is
-to watch the value of a single variable:
-
-@smallexample
-(@value{GDBP}) watch foo
-@end smallexample
-
-If the command includes a @code{@r{[}thread @var{threadnum}@r{]}}
-argument, @value{GDBN} breaks only when the thread identified by
-@var{threadnum} changes the value of @var{expr}.  If any other threads
-change the value of @var{expr}, @value{GDBN} will not break.  Note
-that watchpoints restricted to a single thread in this way only work
-with Hardware Watchpoints.
-
-Ordinarily a watchpoint respects the scope of variables in @var{expr}
-(see below).  The @code{-location} argument tells @value{GDBN} to
-instead watch the memory referred to by @var{expr}.  In this case,
-@value{GDBN} will evaluate @var{expr}, take the address of the result,
-and watch the memory at that address.  The type of the result is used
-to determine the size of the watched memory.  If the expression's
-result does not have an address, then @value{GDBN} will print an
-error.
-
-The @code{@r{[}mask @var{maskvalue}@r{]}} argument allows creation
-of masked watchpoints, if the current architecture supports this
-feature (e.g., PowerPC Embedded architecture, see @ref{PowerPC
-Embedded}.)  A @dfn{masked watchpoint} specifies a mask in addition
-to an address to watch.  The mask specifies that some bits of an address
-(the bits which are reset in the mask) should be ignored when matching
-the address accessed by the inferior against the watchpoint address.
-Thus, a masked watchpoint watches many addresses simultaneously---those
-addresses whose unmasked bits are identical to the unmasked bits in the
-watchpoint address.  The @code{mask} argument implies @code{-location}.
-Examples:
-
-@smallexample
-(@value{GDBP}) watch foo mask 0xffff00ff
-(@value{GDBP}) watch *0xdeadbeef mask 0xffffff00
-@end smallexample
-
-@kindex rwatch
-@item rwatch @r{[}-l@r{|}-location@r{]} @var{expr} @r{[}thread @var{threadnum}@r{]} @r{[}mask @var{maskvalue}@r{]}
-Set a watchpoint that will break when the value of @var{expr} is read
-by the program.
-
-@kindex awatch
-@item awatch @r{[}-l@r{|}-location@r{]} @var{expr} @r{[}thread @var{threadnum}@r{]} @r{[}mask @var{maskvalue}@r{]}
-Set a watchpoint that will break when @var{expr} is either read from
-or written into by the program.
-
-@kindex info watchpoints @r{[}@var{n}@dots{}@r{]}
-@item info watchpoints @r{[}@var{n}@dots{}@r{]}
-This command prints a list of watchpoints, using the same format as
-@code{info break} (@pxref{Set Breaks}).
-@end table
-
-If you watch for a change in a numerically entered address you need to
-dereference it, as the address itself is just a constant number which will
-never change.  @value{GDBN} refuses to create a watchpoint that watches
-a never-changing value:
-
-@smallexample
-(@value{GDBP}) watch 0x600850
-Cannot watch constant value 0x600850.
-(@value{GDBP}) watch *(int *) 0x600850
-Watchpoint 1: *(int *) 6293584
-@end smallexample
-
-@value{GDBN} sets a @dfn{hardware watchpoint} if possible.  Hardware
-watchpoints execute very quickly, and the debugger reports a change in
-value at the exact instruction where the change occurs.  If @value{GDBN}
-cannot set a hardware watchpoint, it sets a software watchpoint, which
-executes more slowly and reports the change in value at the next
-@emph{statement}, not the instruction, after the change occurs.
-
-@cindex use only software watchpoints
-You can force @value{GDBN} to use only software watchpoints with the
-@kbd{set can-use-hw-watchpoints 0} command.  With this variable set to
-zero, @value{GDBN} will never try to use hardware watchpoints, even if
-the underlying system supports them.  (Note that hardware-assisted
-watchpoints that were set @emph{before} setting
-@code{can-use-hw-watchpoints} to zero will still use the hardware
-mechanism of watching expression values.)
-
-@table @code
-@item set can-use-hw-watchpoints
-@kindex set can-use-hw-watchpoints
-Set whether or not to use hardware watchpoints.
-
-@item show can-use-hw-watchpoints
-@kindex show can-use-hw-watchpoints
-Show the current mode of using hardware watchpoints.
-@end table
-
-For remote targets, you can restrict the number of hardware
-watchpoints @value{GDBN} will use, see @ref{set remote
-hardware-breakpoint-limit}.
-
-When you issue the @code{watch} command, @value{GDBN} reports
-
-@smallexample
-Hardware watchpoint @var{num}: @var{expr}
-@end smallexample
-
-@noindent
-if it was able to set a hardware watchpoint.
-
-Currently, the @code{awatch} and @code{rwatch} commands can only set
-hardware watchpoints, because accesses to data that don't change the
-value of the watched expression cannot be detected without examining
-every instruction as it is being executed, and @value{GDBN} does not do
-that currently.  If @value{GDBN} finds that it is unable to set a
-hardware breakpoint with the @code{awatch} or @code{rwatch} command, it
-will print a message like this:
-
-@smallexample
-Expression cannot be implemented with read/access watchpoint.
-@end smallexample
-
-Sometimes, @value{GDBN} cannot set a hardware watchpoint because the
-data type of the watched expression is wider than what a hardware
-watchpoint on the target machine can handle.  For example, some systems
-can only watch regions that are up to 4 bytes wide; on such systems you
-cannot set hardware watchpoints for an expression that yields a
-double-precision floating-point number (which is typically 8 bytes
-wide).  As a work-around, it might be possible to break the large region
-into a series of smaller ones and watch them with separate watchpoints.
-
-If you set too many hardware watchpoints, @value{GDBN} might be unable
-to insert all of them when you resume the execution of your program.
-Since the precise number of active watchpoints is unknown until such
-time as the program is about to be resumed, @value{GDBN} might not be
-able to warn you about this when you set the watchpoints, and the
-warning will be printed only when the program is resumed:
-
-@smallexample
-Hardware watchpoint @var{num}: Could not insert watchpoint
-@end smallexample
-
-@noindent
-If this happens, delete or disable some of the watchpoints.
-
-Watching complex expressions that reference many variables can also
-exhaust the resources available for hardware-assisted watchpoints.
-That's because @value{GDBN} needs to watch every variable in the
-expression with separately allocated resources.
-
-If you call a function interactively using @code{print} or @code{call},
-any watchpoints you have set will be inactive until @value{GDBN} reaches another
-kind of breakpoint or the call completes.
-
-@value{GDBN} automatically deletes watchpoints that watch local
-(automatic) variables, or expressions that involve such variables, when
-they go out of scope, that is, when the execution leaves the block in
-which these variables were defined.  In particular, when the program
-being debugged terminates, @emph{all} local variables go out of scope,
-and so only watchpoints that watch global variables remain set.  If you
-rerun the program, you will need to set all such watchpoints again.  One
-way of doing that would be to set a code breakpoint at the entry to the
-@code{main} function and when it breaks, set all the watchpoints.
-
-@cindex watchpoints and threads
-@cindex threads and watchpoints
-In multi-threaded programs, watchpoints will detect changes to the
-watched expression from every thread.
-
-@quotation
-@emph{Warning:} In multi-threaded programs, software watchpoints
-have only limited usefulness.  If @value{GDBN} creates a software
-watchpoint, it can only watch the value of an expression @emph{in a
-single thread}.  If you are confident that the expression can only
-change due to the current thread's activity (and if you are also
-confident that no other thread can become current), then you can use
-software watchpoints as usual.  However, @value{GDBN} may not notice
-when a non-current thread's activity changes the expression.  (Hardware
-watchpoints, in contrast, watch an expression in all threads.)
-@end quotation
-
-@xref{set remote hardware-watchpoint-limit}.
-
-@node Set Catchpoints
-@subsection Setting Catchpoints
-@cindex catchpoints, setting
-@cindex exception handlers
-@cindex event handling
-
-You can use @dfn{catchpoints} to cause the debugger to stop for certain
-kinds of program events, such as C@t{++} exceptions or the loading of a
-shared library.  Use the @code{catch} command to set a catchpoint.
-
-@table @code
-@kindex catch
-@item catch @var{event}
-Stop when @var{event} occurs.  @var{event} can be any of the following:
-@table @code
-@item throw
-@cindex stop on C@t{++} exceptions
-The throwing of a C@t{++} exception.
-
-@item catch
-The catching of a C@t{++} exception.
-
-@item exception
-@cindex Ada exception catching
-@cindex catch Ada exceptions
-An Ada exception being raised.  If an exception name is specified
-at the end of the command (eg @code{catch exception Program_Error}),
-the debugger will stop only when this specific exception is raised.
-Otherwise, the debugger stops execution when any Ada exception is raised.
-
-When inserting an exception catchpoint on a user-defined exception whose
-name is identical to one of the exceptions defined by the language, the
-fully qualified name must be used as the exception name.  Otherwise,
-@value{GDBN} will assume that it should stop on the pre-defined exception
-rather than the user-defined one.  For instance, assuming an exception
-called @code{Constraint_Error} is defined in package @code{Pck}, then
-the command to use to catch such exceptions is @kbd{catch exception
-Pck.Constraint_Error}.
-
-@item exception unhandled
-An exception that was raised but is not handled by the program.
-
-@item assert
-A failed Ada assertion.
-
-@item exec
-@cindex break on fork/exec
-A call to @code{exec}.  This is currently only available for HP-UX
-and @sc{gnu}/Linux.
-
-@item syscall
-@itemx syscall @r{[}@var{name} @r{|} @var{number}@r{]} @dots{} 
-@cindex break on a system call.
-A call to or return from a system call, a.k.a.@: @dfn{syscall}.  A
-syscall is a mechanism for application programs to request a service
-from the operating system (OS) or one of the OS system services.
-@value{GDBN} can catch some or all of the syscalls issued by the
-debuggee, and show the related information for each syscall.  If no
-argument is specified, calls to and returns from all system calls
-will be caught.
-
-@var{name} can be any system call name that is valid for the
-underlying OS.  Just what syscalls are valid depends on the OS.  On
-GNU and Unix systems, you can find the full list of valid syscall
-names on @file{/usr/include/asm/unistd.h}.
-
-@c For MS-Windows, the syscall names and the corresponding numbers
-@c can be found, e.g., on this URL:
-@c http://www.metasploit.com/users/opcode/syscalls.html
-@c but we don't support Windows syscalls yet.
-
-Normally, @value{GDBN} knows in advance which syscalls are valid for
-each OS, so you can use the @value{GDBN} command-line completion
-facilities (@pxref{Completion,, command completion}) to list the
-available choices.
-
-You may also specify the system call numerically.  A syscall's
-number is the value passed to the OS's syscall dispatcher to
-identify the requested service.  When you specify the syscall by its
-name, @value{GDBN} uses its database of syscalls to convert the name
-into the corresponding numeric code, but using the number directly
-may be useful if @value{GDBN}'s database does not have the complete
-list of syscalls on your system (e.g., because @value{GDBN} lags
-behind the OS upgrades).
-
-The example below illustrates how this command works if you don't provide
-arguments to it:
-
-@smallexample
-(@value{GDBP}) catch syscall
-Catchpoint 1 (syscall)
-(@value{GDBP}) r
-Starting program: /tmp/catch-syscall
-
-Catchpoint 1 (call to syscall 'close'), \
-          0xffffe424 in __kernel_vsyscall ()
-(@value{GDBP}) c
-Continuing.
-
-Catchpoint 1 (returned from syscall 'close'), \
-       0xffffe424 in __kernel_vsyscall ()
-(@value{GDBP})
-@end smallexample
-
-Here is an example of catching a system call by name:
-
-@smallexample
-(@value{GDBP}) catch syscall chroot
-Catchpoint 1 (syscall 'chroot' [61])
-(@value{GDBP}) r
-Starting program: /tmp/catch-syscall
-
-Catchpoint 1 (call to syscall 'chroot'), \
-                  0xffffe424 in __kernel_vsyscall ()
-(@value{GDBP}) c
-Continuing.
-
-Catchpoint 1 (returned from syscall 'chroot'), \
-       0xffffe424 in __kernel_vsyscall ()
-(@value{GDBP})
-@end smallexample
-
-An example of specifying a system call numerically.  In the case
-below, the syscall number has a corresponding entry in the XML
-file, so @value{GDBN} finds its name and prints it:
-
-@smallexample
-(@value{GDBP}) catch syscall 252
-Catchpoint 1 (syscall(s) 'exit_group')
-(@value{GDBP}) r
-Starting program: /tmp/catch-syscall
-
-Catchpoint 1 (call to syscall 'exit_group'), \
-                  0xffffe424 in __kernel_vsyscall ()
-(@value{GDBP}) c
-Continuing.
-
-Program exited normally.
-(@value{GDBP})
-@end smallexample
-
-However, there can be situations when there is no corresponding name
-in XML file for that syscall number.  In this case, @value{GDBN} prints
-a warning message saying that it was not able to find the syscall name,
-but the catchpoint will be set anyway.  See the example below:
-
-@smallexample
-(@value{GDBP}) catch syscall 764
-warning: The number '764' does not represent a known syscall.
-Catchpoint 2 (syscall 764)
-(@value{GDBP})
-@end smallexample
-
-If you configure @value{GDBN} using the @samp{--without-expat} option,
-it will not be able to display syscall names.  Also, if your
-architecture does not have an XML file describing its system calls,
-you will not be able to see the syscall names.  It is important to
-notice that these two features are used for accessing the syscall
-name database.  In either case, you will see a warning like this:
-
-@smallexample
-(@value{GDBP}) catch syscall
-warning: Could not open "syscalls/i386-linux.xml"
-warning: Could not load the syscall XML file 'syscalls/i386-linux.xml'.
-GDB will not be able to display syscall names.
-Catchpoint 1 (syscall)
-(@value{GDBP})
-@end smallexample
-
-Of course, the file name will change depending on your architecture and system.
-
-Still using the example above, you can also try to catch a syscall by its
-number.  In this case, you would see something like:
-
-@smallexample
-(@value{GDBP}) catch syscall 252
-Catchpoint 1 (syscall(s) 252)
-@end smallexample
-
-Again, in this case @value{GDBN} would not be able to display syscall's names.
-
-@item fork
-A call to @code{fork}.  This is currently only available for HP-UX
-and @sc{gnu}/Linux.
-
-@item vfork
-A call to @code{vfork}.  This is currently only available for HP-UX
-and @sc{gnu}/Linux.
-
-@item load @r{[}regexp@r{]}
-@itemx unload @r{[}regexp@r{]}
-The loading or unloading of a shared library.  If @var{regexp} is
-given, then the catchpoint will stop only if the regular expression
-matches one of the affected libraries.
-
-@item signal @r{[}@var{signal}@dots{} @r{|} @samp{all}@r{]}
-The delivery of a signal.
-
-With no arguments, this catchpoint will catch any signal that is not
-used internally by @value{GDBN}, specifically, all signals except
-@samp{SIGTRAP} and @samp{SIGINT}.
-
-With the argument @samp{all}, all signals, including those used by
-@value{GDBN}, will be caught.  This argument cannot be used with other
-signal names.
-
-Otherwise, the arguments are a list of signal names as given to
-@code{handle} (@pxref{Signals}).  Only signals specified in this list
-will be caught.
-
-One reason that @code{catch signal} can be more useful than
-@code{handle} is that you can attach commands and conditions to the
-catchpoint.
-
-When a signal is caught by a catchpoint, the signal's @code{stop} and
-@code{print} settings, as specified by @code{handle}, are ignored.
-However, whether the signal is still delivered to the inferior depends
-on the @code{pass} setting; this can be changed in the catchpoint's
-commands.
-
-@end table
-
-@item tcatch @var{event}
-Set a catchpoint that is enabled only for one stop.  The catchpoint is
-automatically deleted after the first time the event is caught.
-
-@end table
-
-Use the @code{info break} command to list the current catchpoints.
-
-There are currently some limitations to C@t{++} exception handling
-(@code{catch throw} and @code{catch catch}) in @value{GDBN}:
-
-@itemize @bullet
-@item
-If you call a function interactively, @value{GDBN} normally returns
-control to you when the function has finished executing.  If the call
-raises an exception, however, the call may bypass the mechanism that
-returns control to you and cause your program either to abort or to
-simply continue running until it hits a breakpoint, catches a signal
-that @value{GDBN} is listening for, or exits.  This is the case even if
-you set a catchpoint for the exception; catchpoints on exceptions are
-disabled within interactive calls.
-
-@item
-You cannot raise an exception interactively.
-
-@item
-You cannot install an exception handler interactively.
-@end itemize
-
-@cindex raise exceptions
-Sometimes @code{catch} is not the best way to debug exception handling:
-if you need to know exactly where an exception is raised, it is better to
-stop @emph{before} the exception handler is called, since that way you
-can see the stack before any unwinding takes place.  If you set a
-breakpoint in an exception handler instead, it may not be easy to find
-out where the exception was raised.
-
-To stop just before an exception handler is called, you need some
-knowledge of the implementation.  In the case of @sc{gnu} C@t{++}, exceptions are
-raised by calling a library function named @code{__raise_exception}
-which has the following ANSI C interface:
-
-@smallexample
-    /* @var{addr} is where the exception identifier is stored.
-       @var{id} is the exception identifier.  */
-    void __raise_exception (void **addr, void *id);
-@end smallexample
-
-@noindent
-To make the debugger catch all exceptions before any stack
-unwinding takes place, set a breakpoint on @code{__raise_exception}
-(@pxref{Breakpoints, ,Breakpoints; Watchpoints; and Exceptions}).
-
-With a conditional breakpoint (@pxref{Conditions, ,Break Conditions})
-that depends on the value of @var{id}, you can stop your program when
-a specific exception is raised.  You can use multiple conditional
-breakpoints to stop your program when any of a number of exceptions are
-raised.
-
-
-@node Delete Breaks
-@subsection Deleting Breakpoints
-
-@cindex clearing breakpoints, watchpoints, catchpoints
-@cindex deleting breakpoints, watchpoints, catchpoints
-It is often necessary to eliminate a breakpoint, watchpoint, or
-catchpoint once it has done its job and you no longer want your program
-to stop there.  This is called @dfn{deleting} the breakpoint.  A
-breakpoint that has been deleted no longer exists; it is forgotten.
-
-With the @code{clear} command you can delete breakpoints according to
-where they are in your program.  With the @code{delete} command you can
-delete individual breakpoints, watchpoints, or catchpoints by specifying
-their breakpoint numbers.
-
-It is not necessary to delete a breakpoint to proceed past it.  @value{GDBN}
-automatically ignores breakpoints on the first instruction to be executed
-when you continue execution without changing the execution address.
-
-@table @code
-@kindex clear
-@item clear
-Delete any breakpoints at the next instruction to be executed in the
-selected stack frame (@pxref{Selection, ,Selecting a Frame}).  When
-the innermost frame is selected, this is a good way to delete a
-breakpoint where your program just stopped.
-
-@item clear @var{location}
-Delete any breakpoints set at the specified @var{location}.
-@xref{Specify Location}, for the various forms of @var{location}; the
-most useful ones are listed below:
-
-@table @code
-@item clear @var{function}
-@itemx clear @var{filename}:@var{function}
-Delete any breakpoints set at entry to the named @var{function}.
-
-@item clear @var{linenum}
-@itemx clear @var{filename}:@var{linenum}
-Delete any breakpoints set at or within the code of the specified
-@var{linenum} of the specified @var{filename}.
-@end table
-
-@cindex delete breakpoints
-@kindex delete
-@kindex d @r{(@code{delete})}
-@item delete @r{[}breakpoints@r{]} @r{[}@var{range}@dots{}@r{]}
-Delete the breakpoints, watchpoints, or catchpoints of the breakpoint
-ranges specified as arguments.  If no argument is specified, delete all
-breakpoints (@value{GDBN} asks confirmation, unless you have @code{set
-confirm off}).  You can abbreviate this command as @code{d}.
-@end table
-
-@node Disabling
-@subsection Disabling Breakpoints
-
-@cindex enable/disable a breakpoint
-Rather than deleting a breakpoint, watchpoint, or catchpoint, you might
-prefer to @dfn{disable} it.  This makes the breakpoint inoperative as if
-it had been deleted, but remembers the information on the breakpoint so
-that you can @dfn{enable} it again later.
-
-You disable and enable breakpoints, watchpoints, and catchpoints with
-the @code{enable} and @code{disable} commands, optionally specifying
-one or more breakpoint numbers as arguments.  Use @code{info break} to
-print a list of all breakpoints, watchpoints, and catchpoints if you
-do not know which numbers to use.
-
-Disabling and enabling a breakpoint that has multiple locations
-affects all of its locations.
-
-A breakpoint, watchpoint, or catchpoint can have any of several
-different states of enablement:
-
-@itemize @bullet
-@item
-Enabled.  The breakpoint stops your program.  A breakpoint set
-with the @code{break} command starts out in this state.
-@item
-Disabled.  The breakpoint has no effect on your program.
-@item
-Enabled once.  The breakpoint stops your program, but then becomes
-disabled.
-@item
-Enabled for a count.  The breakpoint stops your program for the next
-N times, then becomes disabled.
-@item
-Enabled for deletion.  The breakpoint stops your program, but
-immediately after it does so it is deleted permanently.  A breakpoint
-set with the @code{tbreak} command starts out in this state.
-@end itemize
-
-You can use the following commands to enable or disable breakpoints,
-watchpoints, and catchpoints:
-
-@table @code
-@kindex disable
-@kindex dis @r{(@code{disable})}
-@item disable @r{[}breakpoints@r{]} @r{[}@var{range}@dots{}@r{]}
-Disable the specified breakpoints---or all breakpoints, if none are
-listed.  A disabled breakpoint has no effect but is not forgotten.  All
-options such as ignore-counts, conditions and commands are remembered in
-case the breakpoint is enabled again later.  You may abbreviate
-@code{disable} as @code{dis}.
-
-@kindex enable
-@item enable @r{[}breakpoints@r{]} @r{[}@var{range}@dots{}@r{]}
-Enable the specified breakpoints (or all defined breakpoints).  They
-become effective once again in stopping your program.
-
-@item enable @r{[}breakpoints@r{]} once @var{range}@dots{}
-Enable the specified breakpoints temporarily.  @value{GDBN} disables any
-of these breakpoints immediately after stopping your program.
-
-@item enable @r{[}breakpoints@r{]} count @var{count} @var{range}@dots{}
-Enable the specified breakpoints temporarily.  @value{GDBN} records
-@var{count} with each of the specified breakpoints, and decrements a
-breakpoint's count when it is hit.  When any count reaches 0,
-@value{GDBN} disables that breakpoint.  If a breakpoint has an ignore
-count (@pxref{Conditions, ,Break Conditions}), that will be
-decremented to 0 before @var{count} is affected.
-
-@item enable @r{[}breakpoints@r{]} delete @var{range}@dots{}
-Enable the specified breakpoints to work once, then die.  @value{GDBN}
-deletes any of these breakpoints as soon as your program stops there.
-Breakpoints set by the @code{tbreak} command start out in this state.
-@end table
-
-@c FIXME: I think the following ``Except for [...] @code{tbreak}'' is
-@c confusing: tbreak is also initially enabled.
-Except for a breakpoint set with @code{tbreak} (@pxref{Set Breaks,
-,Setting Breakpoints}), breakpoints that you set are initially enabled;
-subsequently, they become disabled or enabled only when you use one of
-the commands above.  (The command @code{until} can set and delete a
-breakpoint of its own, but it does not change the state of your other
-breakpoints; see @ref{Continuing and Stepping, ,Continuing and
-Stepping}.)
-
-@node Conditions
-@subsection Break Conditions
-@cindex conditional breakpoints
-@cindex breakpoint conditions
-
-@c FIXME what is scope of break condition expr?  Context where wanted?
-@c      in particular for a watchpoint?
-The simplest sort of breakpoint breaks every time your program reaches a
-specified place.  You can also specify a @dfn{condition} for a
-breakpoint.  A condition is just a Boolean expression in your
-programming language (@pxref{Expressions, ,Expressions}).  A breakpoint with
-a condition evaluates the expression each time your program reaches it,
-and your program stops only if the condition is @emph{true}.
-
-This is the converse of using assertions for program validation; in that
-situation, you want to stop when the assertion is violated---that is,
-when the condition is false.  In C, if you want to test an assertion expressed
-by the condition @var{assert}, you should set the condition
-@samp{! @var{assert}} on the appropriate breakpoint.
-
-Conditions are also accepted for watchpoints; you may not need them,
-since a watchpoint is inspecting the value of an expression anyhow---but
-it might be simpler, say, to just set a watchpoint on a variable name,
-and specify a condition that tests whether the new value is an interesting
-one.
-
-Break conditions can have side effects, and may even call functions in
-your program.  This can be useful, for example, to activate functions
-that log program progress, or to use your own print functions to
-format special data structures.  The effects are completely predictable
-unless there is another enabled breakpoint at the same address.  (In
-that case, @value{GDBN} might see the other breakpoint first and stop your
-program without checking the condition of this one.)  Note that
-breakpoint commands are usually more convenient and flexible than break
-conditions for the
-purpose of performing side effects when a breakpoint is reached
-(@pxref{Break Commands, ,Breakpoint Command Lists}).
-
-Breakpoint conditions can also be evaluated on the target's side if
-the target supports it.  Instead of evaluating the conditions locally,
-@value{GDBN} encodes the expression into an agent expression
-(@pxref{Agent Expressions}) suitable for execution on the target,
-independently of @value{GDBN}.  Global variables become raw memory
-locations, locals become stack accesses, and so forth.
-
-In this case, @value{GDBN} will only be notified of a breakpoint trigger
-when its condition evaluates to true.  This mechanism may provide faster
-response times depending on the performance characteristics of the target
-since it does not need to keep @value{GDBN} informed about
-every breakpoint trigger, even those with false conditions.
-
-Break conditions can be specified when a breakpoint is set, by using
-@samp{if} in the arguments to the @code{break} command.  @xref{Set
-Breaks, ,Setting Breakpoints}.  They can also be changed at any time
-with the @code{condition} command.
-
-You can also use the @code{if} keyword with the @code{watch} command.
-The @code{catch} command does not recognize the @code{if} keyword;
-@code{condition} is the only way to impose a further condition on a
-catchpoint.
-
-@table @code
-@kindex condition
-@item condition @var{bnum} @var{expression}
-Specify @var{expression} as the break condition for breakpoint,
-watchpoint, or catchpoint number @var{bnum}.  After you set a condition,
-breakpoint @var{bnum} stops your program only if the value of
-@var{expression} is true (nonzero, in C).  When you use
-@code{condition}, @value{GDBN} checks @var{expression} immediately for
-syntactic correctness, and to determine whether symbols in it have
-referents in the context of your breakpoint.  If @var{expression} uses
-symbols not referenced in the context of the breakpoint, @value{GDBN}
-prints an error message:
-
-@smallexample
-No symbol "foo" in current context.
-@end smallexample
-
-@noindent
-@value{GDBN} does
-not actually evaluate @var{expression} at the time the @code{condition}
-command (or a command that sets a breakpoint with a condition, like
-@code{break if @dots{}}) is given, however.  @xref{Expressions, ,Expressions}.
-
-@item condition @var{bnum}
-Remove the condition from breakpoint number @var{bnum}.  It becomes
-an ordinary unconditional breakpoint.
-@end table
-
-@cindex ignore count (of breakpoint)
-A special case of a breakpoint condition is to stop only when the
-breakpoint has been reached a certain number of times.  This is so
-useful that there is a special way to do it, using the @dfn{ignore
-count} of the breakpoint.  Every breakpoint has an ignore count, which
-is an integer.  Most of the time, the ignore count is zero, and
-therefore has no effect.  But if your program reaches a breakpoint whose
-ignore count is positive, then instead of stopping, it just decrements
-the ignore count by one and continues.  As a result, if the ignore count
-value is @var{n}, the breakpoint does not stop the next @var{n} times
-your program reaches it.
-
-@table @code
-@kindex ignore
-@item ignore @var{bnum} @var{count}
-Set the ignore count of breakpoint number @var{bnum} to @var{count}.
-The next @var{count} times the breakpoint is reached, your program's
-execution does not stop; other than to decrement the ignore count, @value{GDBN}
-takes no action.
-
-To make the breakpoint stop the next time it is reached, specify
-a count of zero.
-
-When you use @code{continue} to resume execution of your program from a
-breakpoint, you can specify an ignore count directly as an argument to
-@code{continue}, rather than using @code{ignore}.  @xref{Continuing and
-Stepping,,Continuing and Stepping}.
-
-If a breakpoint has a positive ignore count and a condition, the
-condition is not checked.  Once the ignore count reaches zero,
-@value{GDBN} resumes checking the condition.
-
-You could achieve the effect of the ignore count with a condition such
-as @w{@samp{$foo-- <= 0}} using a debugger convenience variable that
-is decremented each time.  @xref{Convenience Vars, ,Convenience
-Variables}.
-@end table
-
-Ignore counts apply to breakpoints, watchpoints, and catchpoints.
-
-
-@node Break Commands
-@subsection Breakpoint Command Lists
-
-@cindex breakpoint commands
-You can give any breakpoint (or watchpoint or catchpoint) a series of
-commands to execute when your program stops due to that breakpoint.  For
-example, you might want to print the values of certain expressions, or
-enable other breakpoints.
-
-@table @code
-@kindex commands
-@kindex end@r{ (breakpoint commands)}
-@item commands @r{[}@var{range}@dots{}@r{]}
-@itemx @dots{} @var{command-list} @dots{}
-@itemx end
-Specify a list of commands for the given breakpoints.  The commands
-themselves appear on the following lines.  Type a line containing just
-@code{end} to terminate the commands.
-
-To remove all commands from a breakpoint, type @code{commands} and
-follow it immediately with @code{end}; that is, give no commands.
-
-With no argument, @code{commands} refers to the last breakpoint,
-watchpoint, or catchpoint set (not to the breakpoint most recently
-encountered).  If the most recent breakpoints were set with a single
-command, then the @code{commands} will apply to all the breakpoints
-set by that command.  This applies to breakpoints set by
-@code{rbreak}, and also applies when a single @code{break} command
-creates multiple breakpoints (@pxref{Ambiguous Expressions,,Ambiguous
-Expressions}).
-@end table
-
-Pressing @key{RET} as a means of repeating the last @value{GDBN} command is
-disabled within a @var{command-list}.
-
-You can use breakpoint commands to start your program up again.  Simply
-use the @code{continue} command, or @code{step}, or any other command
-that resumes execution.
-
-Any other commands in the command list, after a command that resumes
-execution, are ignored.  This is because any time you resume execution
-(even with a simple @code{next} or @code{step}), you may encounter
-another breakpoint---which could have its own command list, leading to
-ambiguities about which list to execute.
-
-@kindex silent
-If the first command you specify in a command list is @code{silent}, the
-usual message about stopping at a breakpoint is not printed.  This may
-be desirable for breakpoints that are to print a specific message and
-then continue.  If none of the remaining commands print anything, you
-see no sign that the breakpoint was reached.  @code{silent} is
-meaningful only at the beginning of a breakpoint command list.
-
-The commands @code{echo}, @code{output}, and @code{printf} allow you to
-print precisely controlled output, and are often useful in silent
-breakpoints.  @xref{Output, ,Commands for Controlled Output}.
-
-For example, here is how you could use breakpoint commands to print the
-value of @code{x} at entry to @code{foo} whenever @code{x} is positive.
-
-@smallexample
-break foo if x>0
-commands
-silent
-printf "x is %d\n",x
-cont
-end
-@end smallexample
-
-One application for breakpoint commands is to compensate for one bug so
-you can test for another.  Put a breakpoint just after the erroneous line
-of code, give it a condition to detect the case in which something
-erroneous has been done, and give it commands to assign correct values
-to any variables that need them.  End with the @code{continue} command
-so that your program does not stop, and start with the @code{silent}
-command so that no output is produced.  Here is an example:
-
-@smallexample
-break 403
-commands
-silent
-set x = y + 4
-cont
-end
-@end smallexample
-
-@node Dynamic Printf
-@subsection Dynamic Printf
-
-@cindex dynamic printf
-@cindex dprintf
-The dynamic printf command @code{dprintf} combines a breakpoint with
-formatted printing of your program's data to give you the effect of
-inserting @code{printf} calls into your program on-the-fly, without
-having to recompile it.
-
-In its most basic form, the output goes to the GDB console.  However,
-you can set the variable @code{dprintf-style} for alternate handling.
-For instance, you can ask to format the output by calling your
-program's @code{printf} function.  This has the advantage that the
-characters go to the program's output device, so they can recorded in
-redirects to files and so forth.
-
-If you are doing remote debugging with a stub or agent, you can also
-ask to have the printf handled by the remote agent.  In addition to
-ensuring that the output goes to the remote program's device along
-with any other output the program might produce, you can also ask that
-the dprintf remain active even after disconnecting from the remote
-target.  Using the stub/agent is also more efficient, as it can do
-everything without needing to communicate with @value{GDBN}.
-
-@table @code
-@kindex dprintf
-@item dprintf @var{location},@var{template},@var{expression}[,@var{expression}@dots{}]
-Whenever execution reaches @var{location}, print the values of one or
-more @var{expressions} under the control of the string @var{template}.
-To print several values, separate them with commas.
-
-@item set dprintf-style @var{style}
-Set the dprintf output to be handled in one of several different
-styles enumerated below.  A change of style affects all existing
-dynamic printfs immediately.  (If you need individual control over the
-print commands, simply define normal breakpoints with
-explicitly-supplied command lists.)
-
-@item gdb
-@kindex dprintf-style gdb
-Handle the output using the @value{GDBN} @code{printf} command.
-
-@item call
-@kindex dprintf-style call
-Handle the output by calling a function in your program (normally
-@code{printf}).
-
-@item agent
-@kindex dprintf-style agent
-Have the remote debugging agent (such as @code{gdbserver}) handle
-the output itself.  This style is only available for agents that
-support running commands on the target.
-
-@item set dprintf-function @var{function}
-Set the function to call if the dprintf style is @code{call}.  By
-default its value is @code{printf}.  You may set it to any expression.
-that @value{GDBN} can evaluate to a function, as per the @code{call}
-command.
-
-@item set dprintf-channel @var{channel}
-Set a ``channel'' for dprintf.  If set to a non-empty value,
-@value{GDBN} will evaluate it as an expression and pass the result as
-a first argument to the @code{dprintf-function}, in the manner of
-@code{fprintf} and similar functions.  Otherwise, the dprintf format
-string will be the first argument, in the manner of @code{printf}.
-
-As an example, if you wanted @code{dprintf} output to go to a logfile
-that is a standard I/O stream assigned to the variable @code{mylog},
-you could do the following:
-
-@example
-(gdb) set dprintf-style call
-(gdb) set dprintf-function fprintf
-(gdb) set dprintf-channel mylog
-(gdb) dprintf 25,"at line 25, glob=%d\n",glob
-Dprintf 1 at 0x123456: file main.c, line 25.
-(gdb) info break
-1       dprintf        keep y   0x00123456 in main at main.c:25
-        call (void) fprintf (mylog,"at line 25, glob=%d\n",glob)
-        continue
-(gdb)
-@end example
-
-Note that the @code{info break} displays the dynamic printf commands
-as normal breakpoint commands; you can thus easily see the effect of
-the variable settings.
-
-@item set disconnected-dprintf on
-@itemx set disconnected-dprintf off
-@kindex set disconnected-dprintf
-Choose whether @code{dprintf} commands should continue to run if
-@value{GDBN} has disconnected from the target.  This only applies
-if the @code{dprintf-style} is @code{agent}.
-
-@item show disconnected-dprintf off
-@kindex show disconnected-dprintf
-Show the current choice for disconnected @code{dprintf}.
-
-@end table
-
-@value{GDBN} does not check the validity of function and channel,
-relying on you to supply values that are meaningful for the contexts
-in which they are being used.  For instance, the function and channel
-may be the values of local variables, but if that is the case, then
-all enabled dynamic prints must be at locations within the scope of
-those locals.  If evaluation fails, @value{GDBN} will report an error.
-
-@node Save Breakpoints
-@subsection How to save breakpoints to a file
-
-To save breakpoint definitions to a file use the @w{@code{save
-breakpoints}} command.
-
-@table @code
-@kindex save breakpoints
-@cindex save breakpoints to a file for future sessions
-@item save breakpoints [@var{filename}]
-This command saves all current breakpoint definitions together with
-their commands and ignore counts, into a file @file{@var{filename}}
-suitable for use in a later debugging session.  This includes all
-types of breakpoints (breakpoints, watchpoints, catchpoints,
-tracepoints).  To read the saved breakpoint definitions, use the
-@code{source} command (@pxref{Command Files}).  Note that watchpoints
-with expressions involving local variables may fail to be recreated
-because it may not be possible to access the context where the
-watchpoint is valid anymore.  Because the saved breakpoint definitions
-are simply a sequence of @value{GDBN} commands that recreate the
-breakpoints, you can edit the file in your favorite editing program,
-and remove the breakpoint definitions you're not interested in, or
-that can no longer be recreated.
-@end table
-
-@node Static Probe Points
-@subsection Static Probe Points
-
-@cindex static probe point, SystemTap
-@value{GDBN} supports @dfn{SDT} probes in the code.  @acronym{SDT} stands
-for Statically Defined Tracing, and the probes are designed to have a tiny
-runtime code and data footprint, and no dynamic relocations.  They are
-usable from assembly, C and C@t{++} languages.  See
-@uref{http://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation}
-for a good reference on how the @acronym{SDT} probes are implemented.
-
-Currently, @code{SystemTap} (@uref{http://sourceware.org/systemtap/})
-@acronym{SDT} probes are supported on ELF-compatible systems.  See
-@uref{http://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps}
-for more information on how to add @code{SystemTap} @acronym{SDT} probes
-in your applications.
-
-@cindex semaphores on static probe points
-Some probes have an associated semaphore variable; for instance, this
-happens automatically if you defined your probe using a DTrace-style
-@file{.d} file.  If your probe has a semaphore, @value{GDBN} will
-automatically enable it when you specify a breakpoint using the
-@samp{-probe-stap} notation.  But, if you put a breakpoint at a probe's
-location by some other method (e.g., @code{break file:line}), then
-@value{GDBN} will not automatically set the semaphore.
-
-You can examine the available static static probes using @code{info
-probes}, with optional arguments:
-
-@table @code
-@kindex info probes
-@item info probes stap @r{[}@var{provider} @r{[}@var{name} @r{[}@var{objfile}@r{]}@r{]}@r{]}
-If given, @var{provider} is a regular expression used to match against provider
-names when selecting which probes to list.  If omitted, probes by all
-probes from all providers are listed.
-
-If given, @var{name} is a regular expression to match against probe names
-when selecting which probes to list.  If omitted, probe names are not
-considered when deciding whether to display them.
-
-If given, @var{objfile} is a regular expression used to select which
-object files (executable or shared libraries) to examine.  If not
-given, all object files are considered.
-
-@item info probes all
-List the available static probes, from all types.
-@end table
-
-@vindex $_probe_arg@r{, convenience variable}
-A probe may specify up to twelve arguments.  These are available at the
-point at which the probe is defined---that is, when the current PC is
-at the probe's location.  The arguments are available using the
-convenience variables (@pxref{Convenience Vars})
-@code{$_probe_arg0}@dots{}@code{$_probe_arg11}.  Each probe argument is
-an integer of the appropriate size; types are not preserved.  The
-convenience variable @code{$_probe_argc} holds the number of arguments
-at the current probe point.
-
-These variables are always available, but attempts to access them at
-any location other than a probe point will cause @value{GDBN} to give
-an error message.
-
-
-@c  @ifclear BARETARGET
-@node Error in Breakpoints
-@subsection ``Cannot insert breakpoints''
-
-If you request too many active hardware-assisted breakpoints and
-watchpoints, you will see this error message:
-
-@c FIXME: the precise wording of this message may change; the relevant
-@c source change is not committed yet (Sep 3, 1999).
-@smallexample
-Stopped; cannot insert breakpoints.
-You may have requested too many hardware breakpoints and watchpoints.
-@end smallexample
-
-@noindent
-This message is printed when you attempt to resume the program, since
-only then @value{GDBN} knows exactly how many hardware breakpoints and
-watchpoints it needs to insert.
-
-When this message is printed, you need to disable or remove some of the
-hardware-assisted breakpoints and watchpoints, and then continue.
-
-@node Breakpoint-related Warnings
-@subsection ``Breakpoint address adjusted...''
-@cindex breakpoint address adjusted
-
-Some processor architectures place constraints on the addresses at
-which breakpoints may be placed.  For architectures thus constrained,
-@value{GDBN} will attempt to adjust the breakpoint's address to comply
-with the constraints dictated by the architecture.
-
-One example of such an architecture is the Fujitsu FR-V.  The FR-V is
-a VLIW architecture in which a number of RISC-like instructions may be
-bundled together for parallel execution.  The FR-V architecture
-constrains the location of a breakpoint instruction within such a
-bundle to the instruction with the lowest address.  @value{GDBN}
-honors this constraint by adjusting a breakpoint's address to the
-first in the bundle.
-
-It is not uncommon for optimized code to have bundles which contain
-instructions from different source statements, thus it may happen that
-a breakpoint's address will be adjusted from one source statement to
-another.  Since this adjustment may significantly alter @value{GDBN}'s
-breakpoint related behavior from what the user expects, a warning is
-printed when the breakpoint is first set and also when the breakpoint
-is hit.
-
-A warning like the one below is printed when setting a breakpoint
-that's been subject to address adjustment:
-
-@smallexample
-warning: Breakpoint address adjusted from 0x00010414 to 0x00010410.
-@end smallexample
-
-Such warnings are printed both for user settable and @value{GDBN}'s
-internal breakpoints.  If you see one of these warnings, you should
-verify that a breakpoint set at the adjusted address will have the
-desired affect.  If not, the breakpoint in question may be removed and
-other breakpoints may be set which will have the desired behavior.
-E.g., it may be sufficient to place the breakpoint at a later
-instruction.  A conditional breakpoint may also be useful in some
-cases to prevent the breakpoint from triggering too often.
-
-@value{GDBN} will also issue a warning when stopping at one of these
-adjusted breakpoints:
-
-@smallexample
-warning: Breakpoint 1 address previously adjusted from 0x00010414
-to 0x00010410.
-@end smallexample
-
-When this warning is encountered, it may be too late to take remedial
-action except in cases where the breakpoint is hit earlier or more
-frequently than expected.
-
-@node Continuing and Stepping
-@section Continuing and Stepping
-
-@cindex stepping
-@cindex continuing
-@cindex resuming execution
-@dfn{Continuing} means resuming program execution until your program
-completes normally.  In contrast, @dfn{stepping} means executing just
-one more ``step'' of your program, where ``step'' may mean either one
-line of source code, or one machine instruction (depending on what
-particular command you use).  Either when continuing or when stepping,
-your program may stop even sooner, due to a breakpoint or a signal.  (If
-it stops due to a signal, you may want to use @code{handle}, or use
-@samp{signal 0} to resume execution.  @xref{Signals, ,Signals}.)
-
-@table @code
-@kindex continue
-@kindex c @r{(@code{continue})}
-@kindex fg @r{(resume foreground execution)}
-@item continue @r{[}@var{ignore-count}@r{]}
-@itemx c @r{[}@var{ignore-count}@r{]}
-@itemx fg @r{[}@var{ignore-count}@r{]}
-Resume program execution, at the address where your program last stopped;
-any breakpoints set at that address are bypassed.  The optional argument
-@var{ignore-count} allows you to specify a further number of times to
-ignore a breakpoint at this location; its effect is like that of
-@code{ignore} (@pxref{Conditions, ,Break Conditions}).
-
-The argument @var{ignore-count} is meaningful only when your program
-stopped due to a breakpoint.  At other times, the argument to
-@code{continue} is ignored.
-
-The synonyms @code{c} and @code{fg} (for @dfn{foreground}, as the
-debugged program is deemed to be the foreground program) are provided
-purely for convenience, and have exactly the same behavior as
-@code{continue}.
-@end table
-
-To resume execution at a different place, you can use @code{return}
-(@pxref{Returning, ,Returning from a Function}) to go back to the
-calling function; or @code{jump} (@pxref{Jumping, ,Continuing at a
-Different Address}) to go to an arbitrary location in your program.
-
-A typical technique for using stepping is to set a breakpoint
-(@pxref{Breakpoints, ,Breakpoints; Watchpoints; and Catchpoints}) at the
-beginning of the function or the section of your program where a problem
-is believed to lie, run your program until it stops at that breakpoint,
-and then step through the suspect area, examining the variables that are
-interesting, until you see the problem happen.
-
-@table @code
-@kindex step
-@kindex s @r{(@code{step})}
-@item step
-Continue running your program until control reaches a different source
-line, then stop it and return control to @value{GDBN}.  This command is
-abbreviated @code{s}.
-
-@quotation
-@c "without debugging information" is imprecise; actually "without line
-@c numbers in the debugging information".  (gcc -g1 has debugging info but
-@c not line numbers).  But it seems complex to try to make that
-@c distinction here.
-@emph{Warning:} If you use the @code{step} command while control is
-within a function that was compiled without debugging information,
-execution proceeds until control reaches a function that does have
-debugging information.  Likewise, it will not step into a function which
-is compiled without debugging information.  To step through functions
-without debugging information, use the @code{stepi} command, described
-below.
-@end quotation
-
-The @code{step} command only stops at the first instruction of a source
-line.  This prevents the multiple stops that could otherwise occur in
-@code{switch} statements, @code{for} loops, etc.  @code{step} continues
-to stop if a function that has debugging information is called within
-the line.  In other words, @code{step} @emph{steps inside} any functions
-called within the line.
-
-Also, the @code{step} command only enters a function if there is line
-number information for the function.  Otherwise it acts like the
-@code{next} command.  This avoids problems when using @code{cc -gl}
-on @acronym{MIPS} machines.  Previously, @code{step} entered subroutines if there
-was any debugging information about the routine.
-
-@item step @var{count}
-Continue running as in @code{step}, but do so @var{count} times.  If a
-breakpoint is reached, or a signal not related to stepping occurs before
-@var{count} steps, stepping stops right away.
-
-@kindex next
-@kindex n @r{(@code{next})}
-@item next @r{[}@var{count}@r{]}
-Continue to the next source line in the current (innermost) stack frame.
-This is similar to @code{step}, but function calls that appear within
-the line of code are executed without stopping.  Execution stops when
-control reaches a different line of code at the original stack level
-that was executing when you gave the @code{next} command.  This command
-is abbreviated @code{n}.
-
-An argument @var{count} is a repeat count, as for @code{step}.
-
-
-@c  FIX ME!!  Do we delete this, or is there a way it fits in with
-@c  the following paragraph?   ---  Vctoria
-@c
-@c  @code{next} within a function that lacks debugging information acts like
-@c  @code{step}, but any function calls appearing within the code of the
-@c  function are executed without stopping.
-
-The @code{next} command only stops at the first instruction of a
-source line.  This prevents multiple stops that could otherwise occur in
-@code{switch} statements, @code{for} loops, etc.
-
-@kindex set step-mode
-@item set step-mode
-@cindex functions without line info, and stepping
-@cindex stepping into functions with no line info
-@itemx set step-mode on
-The @code{set step-mode on} command causes the @code{step} command to
-stop at the first instruction of a function which contains no debug line
-information rather than stepping over it.
-
-This is useful in cases where you may be interested in inspecting the
-machine instructions of a function which has no symbolic info and do not
-want @value{GDBN} to automatically skip over this function.
-
-@item set step-mode off
-Causes the @code{step} command to step over any functions which contains no
-debug information.  This is the default.
-
-@item show step-mode
-Show whether @value{GDBN} will stop in or step over functions without
-source line debug information.
-
-@kindex finish
-@kindex fin @r{(@code{finish})}
-@item finish
-Continue running until just after function in the selected stack frame
-returns.  Print the returned value (if any).  This command can be
-abbreviated as @code{fin}.
-
-Contrast this with the @code{return} command (@pxref{Returning,
-,Returning from a Function}).
-
-@kindex until
-@kindex u @r{(@code{until})}
-@cindex run until specified location
-@item until
-@itemx u
-Continue running until a source line past the current line, in the
-current stack frame, is reached.  This command is used to avoid single
-stepping through a loop more than once.  It is like the @code{next}
-command, except that when @code{until} encounters a jump, it
-automatically continues execution until the program counter is greater
-than the address of the jump.
-
-This means that when you reach the end of a loop after single stepping
-though it, @code{until} makes your program continue execution until it
-exits the loop.  In contrast, a @code{next} command at the end of a loop
-simply steps back to the beginning of the loop, which forces you to step
-through the next iteration.
-
-@code{until} always stops your program if it attempts to exit the current
-stack frame.
-
-@code{until} may produce somewhat counterintuitive results if the order
-of machine code does not match the order of the source lines.  For
-example, in the following excerpt from a debugging session, the @code{f}
-(@code{frame}) command shows that execution is stopped at line
-@code{206}; yet when we use @code{until}, we get to line @code{195}:
-
-@smallexample
-(@value{GDBP}) f
-#0  main (argc=4, argv=0xf7fffae8) at m4.c:206
-206                 expand_input();
-(@value{GDBP}) until
-195             for ( ; argc > 0; NEXTARG) @{
-@end smallexample
-
-This happened because, for execution efficiency, the compiler had
-generated code for the loop closure test at the end, rather than the
-start, of the loop---even though the test in a C @code{for}-loop is
-written before the body of the loop.  The @code{until} command appeared
-to step back to the beginning of the loop when it advanced to this
-expression; however, it has not really gone to an earlier
-statement---not in terms of the actual machine code.
-
-@code{until} with no argument works by means of single
-instruction stepping, and hence is slower than @code{until} with an
-argument.
-
-@item until @var{location}
-@itemx u @var{location}
-Continue running your program until either the specified location is
-reached, or the current stack frame returns.  @var{location} is any of
-the forms described in @ref{Specify Location}.
-This form of the command uses temporary breakpoints, and
-hence is quicker than @code{until} without an argument.  The specified
-location is actually reached only if it is in the current frame.  This
-implies that @code{until} can be used to skip over recursive function
-invocations.  For instance in the code below, if the current location is
-line @code{96}, issuing @code{until 99} will execute the program up to
-line @code{99} in the same invocation of factorial, i.e., after the inner
-invocations have returned.
-
-@smallexample
-94     int factorial (int value)
-95     @{
-96         if (value > 1) @{
-97            value *= factorial (value - 1);
-98         @}
-99         return (value);
-100     @}
-@end smallexample
-
-
-@kindex advance @var{location}
-@item advance @var{location}
-Continue running the program up to the given @var{location}.  An argument is
-required, which should be of one of the forms described in
-@ref{Specify Location}.
-Execution will also stop upon exit from the current stack
-frame.  This command is similar to @code{until}, but @code{advance} will
-not skip over recursive function calls, and the target location doesn't
-have to be in the same frame as the current one.
-
-
-@kindex stepi
-@kindex si @r{(@code{stepi})}
-@item stepi
-@itemx stepi @var{arg}
-@itemx si
-Execute one machine instruction, then stop and return to the debugger.
-
-It is often useful to do @samp{display/i $pc} when stepping by machine
-instructions.  This makes @value{GDBN} automatically display the next
-instruction to be executed, each time your program stops.  @xref{Auto
-Display,, Automatic Display}.
-
-An argument is a repeat count, as in @code{step}.
-
-@need 750
-@kindex nexti
-@kindex ni @r{(@code{nexti})}
-@item nexti
-@itemx nexti @var{arg}
-@itemx ni
-Execute one machine instruction, but if it is a function call,
-proceed until the function returns.
-
-An argument is a repeat count, as in @code{next}.
-@end table
-
-@node Skipping Over Functions and Files
-@section Skipping Over Functions and Files
-@cindex skipping over functions and files
-
-The program you are debugging may contain some functions which are
-uninteresting to debug.  The @code{skip} comand lets you tell @value{GDBN} to
-skip a function or all functions in a file when stepping.
-
-For example, consider the following C function:
-
-@smallexample
-101     int func()
-102     @{
-103         foo(boring());
-104         bar(boring());
-105     @}
-@end smallexample
-
-@noindent
-Suppose you wish to step into the functions @code{foo} and @code{bar}, but you
-are not interested in stepping through @code{boring}.  If you run @code{step}
-at line 103, you'll enter @code{boring()}, but if you run @code{next}, you'll
-step over both @code{foo} and @code{boring}!
-
-One solution is to @code{step} into @code{boring} and use the @code{finish}
-command to immediately exit it.  But this can become tedious if @code{boring}
-is called from many places.
-
-A more flexible solution is to execute @kbd{skip boring}.  This instructs
-@value{GDBN} never to step into @code{boring}.  Now when you execute
-@code{step} at line 103, you'll step over @code{boring} and directly into
-@code{foo}.
-
-You can also instruct @value{GDBN} to skip all functions in a file, with, for
-example, @code{skip file boring.c}.
-
-@table @code
-@kindex skip function
-@item skip @r{[}@var{linespec}@r{]}
-@itemx skip function @r{[}@var{linespec}@r{]}
-After running this command, the function named by @var{linespec} or the
-function containing the line named by @var{linespec} will be skipped over when
-stepping.  @xref{Specify Location}.
-
-If you do not specify @var{linespec}, the function you're currently debugging
-will be skipped.
-
-(If you have a function called @code{file} that you want to skip, use
-@kbd{skip function file}.)
-
-@kindex skip file
-@item skip file @r{[}@var{filename}@r{]}
-After running this command, any function whose source lives in @var{filename}
-will be skipped over when stepping.
-
-If you do not specify @var{filename}, functions whose source lives in the file
-you're currently debugging will be skipped.
-@end table
-
-Skips can be listed, deleted, disabled, and enabled, much like breakpoints.
-These are the commands for managing your list of skips:
-
-@table @code
-@kindex info skip
-@item info skip @r{[}@var{range}@r{]}
-Print details about the specified skip(s).  If @var{range} is not specified,
-print a table with details about all functions and files marked for skipping.
-@code{info skip} prints the following information about each skip:
-
-@table @emph
-@item Identifier
-A number identifying this skip.
-@item Type
-The type of this skip, either @samp{function} or @samp{file}.
-@item Enabled or Disabled
-Enabled skips are marked with @samp{y}.  Disabled skips are marked with @samp{n}.
-@item Address
-For function skips, this column indicates the address in memory of the function
-being skipped.  If you've set a function skip on a function which has not yet
-been loaded, this field will contain @samp{<PENDING>}.  Once a shared library
-which has the function is loaded, @code{info skip} will show the function's
-address here.
-@item What
-For file skips, this field contains the filename being skipped.  For functions
-skips, this field contains the function name and its line number in the file
-where it is defined.
-@end table
-
-@kindex skip delete
-@item skip delete @r{[}@var{range}@r{]}
-Delete the specified skip(s).  If @var{range} is not specified, delete all
-skips.
-
-@kindex skip enable
-@item skip enable @r{[}@var{range}@r{]}
-Enable the specified skip(s).  If @var{range} is not specified, enable all
-skips.
-
-@kindex skip disable
-@item skip disable @r{[}@var{range}@r{]}
-Disable the specified skip(s).  If @var{range} is not specified, disable all
-skips.
-
-@end table
-
-@node Signals
-@section Signals
-@cindex signals
-
-A signal is an asynchronous event that can happen in a program.  The
-operating system defines the possible kinds of signals, and gives each
-kind a name and a number.  For example, in Unix @code{SIGINT} is the
-signal a program gets when you type an interrupt character (often @kbd{Ctrl-c});
-@code{SIGSEGV} is the signal a program gets from referencing a place in
-memory far away from all the areas in use; @code{SIGALRM} occurs when
-the alarm clock timer goes off (which happens only if your program has
-requested an alarm).
-
-@cindex fatal signals
-Some signals, including @code{SIGALRM}, are a normal part of the
-functioning of your program.  Others, such as @code{SIGSEGV}, indicate
-errors; these signals are @dfn{fatal} (they kill your program immediately) if the
-program has not specified in advance some other way to handle the signal.
-@code{SIGINT} does not indicate an error in your program, but it is normally
-fatal so it can carry out the purpose of the interrupt: to kill the program.
-
-@value{GDBN} has the ability to detect any occurrence of a signal in your
-program.  You can tell @value{GDBN} in advance what to do for each kind of
-signal.
-
-@cindex handling signals
-Normally, @value{GDBN} is set up to let the non-erroneous signals like
-@code{SIGALRM} be silently passed to your program
-(so as not to interfere with their role in the program's functioning)
-but to stop your program immediately whenever an error signal happens.
-You can change these settings with the @code{handle} command.
-
-@table @code
-@kindex info signals
-@kindex info handle
-@item info signals
-@itemx info handle
-Print a table of all the kinds of signals and how @value{GDBN} has been told to
-handle each one.  You can use this to see the signal numbers of all
-the defined types of signals.
-
-@item info signals @var{sig}
-Similar, but print information only about the specified signal number.
-
-@code{info handle} is an alias for @code{info signals}.
-
-@item catch signal @r{[}@var{signal}@dots{} @r{|} @samp{all}@r{]}
-Set a catchpoint for the indicated signals.  @xref{Set Catchpoints},
-for details about this command.
-
-@kindex handle
-@item handle @var{signal} @r{[}@var{keywords}@dots{}@r{]}
-Change the way @value{GDBN} handles signal @var{signal}.  @var{signal}
-can be the number of a signal or its name (with or without the
-@samp{SIG} at the beginning); a list of signal numbers of the form
-@samp{@var{low}-@var{high}}; or the word @samp{all}, meaning all the
-known signals.  Optional arguments @var{keywords}, described below,
-say what change to make.
-@end table
-
-@c @group
-The keywords allowed by the @code{handle} command can be abbreviated.
-Their full names are:
-
-@table @code
-@item nostop
-@value{GDBN} should not stop your program when this signal happens.  It may
-still print a message telling you that the signal has come in.
-
-@item stop
-@value{GDBN} should stop your program when this signal happens.  This implies
-the @code{print} keyword as well.
-
-@item print
-@value{GDBN} should print a message when this signal happens.
-
-@item noprint
-@value{GDBN} should not mention the occurrence of the signal at all.  This
-implies the @code{nostop} keyword as well.
-
-@item pass
-@itemx noignore
-@value{GDBN} should allow your program to see this signal; your program
-can handle the signal, or else it may terminate if the signal is fatal
-and not handled.  @code{pass} and @code{noignore} are synonyms.
-
-@item nopass
-@itemx ignore
-@value{GDBN} should not allow your program to see this signal.
-@code{nopass} and @code{ignore} are synonyms.
-@end table
-@c @end group
-
-When a signal stops your program, the signal is not visible to the
-program until you
-continue.  Your program sees the signal then, if @code{pass} is in
-effect for the signal in question @emph{at that time}.  In other words,
-after @value{GDBN} reports a signal, you can use the @code{handle}
-command with @code{pass} or @code{nopass} to control whether your
-program sees that signal when you continue.
-
-The default is set to @code{nostop}, @code{noprint}, @code{pass} for
-non-erroneous signals such as @code{SIGALRM}, @code{SIGWINCH} and
-@code{SIGCHLD}, and to @code{stop}, @code{print}, @code{pass} for the
-erroneous signals.
-
-You can also use the @code{signal} command to prevent your program from
-seeing a signal, or cause it to see a signal it normally would not see,
-or to give it any signal at any time.  For example, if your program stopped
-due to some sort of memory reference error, you might store correct
-values into the erroneous variables and continue, hoping to see more
-execution; but your program would probably terminate immediately as
-a result of the fatal signal once it saw the signal.  To prevent this,
-you can continue with @samp{signal 0}.  @xref{Signaling, ,Giving your
-Program a Signal}.
-
-@cindex extra signal information
-@anchor{extra signal information}
-
-On some targets, @value{GDBN} can inspect extra signal information
-associated with the intercepted signal, before it is actually
-delivered to the program being debugged.  This information is exported
-by the convenience variable @code{$_siginfo}, and consists of data
-that is passed by the kernel to the signal handler at the time of the
-receipt of a signal.  The data type of the information itself is
-target dependent.  You can see the data type using the @code{ptype
-$_siginfo} command.  On Unix systems, it typically corresponds to the
-standard @code{siginfo_t} type, as defined in the @file{signal.h}
-system header.
-
-Here's an example, on a @sc{gnu}/Linux system, printing the stray
-referenced address that raised a segmentation fault.
-
-@smallexample
-@group
-(@value{GDBP}) continue
-Program received signal SIGSEGV, Segmentation fault.
-0x0000000000400766 in main ()
-69        *(int *)p = 0;
-(@value{GDBP}) ptype $_siginfo
-type = struct @{
-    int si_signo;
-    int si_errno;
-    int si_code;
-    union @{
-        int _pad[28];
-        struct @{...@} _kill;
-        struct @{...@} _timer;
-        struct @{...@} _rt;
-        struct @{...@} _sigchld;
-        struct @{...@} _sigfault;
-        struct @{...@} _sigpoll;
-    @} _sifields;
-@}
-(@value{GDBP}) ptype $_siginfo._sifields._sigfault
-type = struct @{
-    void *si_addr;
-@}
-(@value{GDBP}) p $_siginfo._sifields._sigfault.si_addr
-$1 = (void *) 0x7ffff7ff7000
-@end group
-@end smallexample
-
-Depending on target support, @code{$_siginfo} may also be writable.
-
-@node Thread Stops
-@section Stopping and Starting Multi-thread Programs
-
-@cindex stopped threads
-@cindex threads, stopped
-
-@cindex continuing threads
-@cindex threads, continuing
-
-@value{GDBN} supports debugging programs with multiple threads
-(@pxref{Threads,, Debugging Programs with Multiple Threads}).  There
-are two modes of controlling execution of your program within the
-debugger.  In the default mode, referred to as @dfn{all-stop mode},
-when any thread in your program stops (for example, at a breakpoint 
-or while being stepped), all other threads in the program are also stopped by 
-@value{GDBN}.  On some targets, @value{GDBN} also supports 
-@dfn{non-stop mode}, in which other threads can continue to run freely while
-you examine the stopped thread in the debugger.
-
-@menu
-* All-Stop Mode::              All threads stop when GDB takes control
-* Non-Stop Mode::              Other threads continue to execute
-* Background Execution::       Running your program asynchronously
-* Thread-Specific Breakpoints::        Controlling breakpoints
-* Interrupted System Calls::   GDB may interfere with system calls
-* Observer Mode::               GDB does not alter program behavior
-@end menu
-
-@node All-Stop Mode
-@subsection All-Stop Mode
-
-@cindex all-stop mode
-
-In all-stop mode, whenever your program stops under @value{GDBN} for any reason,
-@emph{all} threads of execution stop, not just the current thread.  This
-allows you to examine the overall state of the program, including
-switching between threads, without worrying that things may change
-underfoot.
-
-Conversely, whenever you restart the program, @emph{all} threads start
-executing.  @emph{This is true even when single-stepping} with commands
-like @code{step} or @code{next}.
-
-In particular, @value{GDBN} cannot single-step all threads in lockstep.
-Since thread scheduling is up to your debugging target's operating
-system (not controlled by @value{GDBN}), other threads may
-execute more than one statement while the current thread completes a
-single step.  Moreover, in general other threads stop in the middle of a
-statement, rather than at a clean statement boundary, when the program
-stops.
-
-You might even find your program stopped in another thread after
-continuing or even single-stepping.  This happens whenever some other
-thread runs into a breakpoint, a signal, or an exception before the
-first thread completes whatever you requested.
-
-@cindex automatic thread selection
-@cindex switching threads automatically
-@cindex threads, automatic switching
-Whenever @value{GDBN} stops your program, due to a breakpoint or a
-signal, it automatically selects the thread where that breakpoint or
-signal happened.  @value{GDBN} alerts you to the context switch with a
-message such as @samp{[Switching to Thread @var{n}]} to identify the
-thread.  
-
-On some OSes, you can modify @value{GDBN}'s default behavior by
-locking the OS scheduler to allow only a single thread to run.
-
-@table @code
-@item set scheduler-locking @var{mode}
-@cindex scheduler locking mode
-@cindex lock scheduler
-Set the scheduler locking mode.  If it is @code{off}, then there is no
-locking and any thread may run at any time.  If @code{on}, then only the
-current thread may run when the inferior is resumed.  The @code{step}
-mode optimizes for single-stepping; it prevents other threads 
-from preempting the current thread while you are stepping, so that 
-the focus of debugging does not change unexpectedly.
-Other threads only rarely (or never) get a chance to run
-when you step.  They are more likely to run when you @samp{next} over a
-function call, and they are completely free to run when you use commands
-like @samp{continue}, @samp{until}, or @samp{finish}.  However, unless another
-thread hits a breakpoint during its timeslice, @value{GDBN} does not change
-the current thread away from the thread that you are debugging.
-
-@item show scheduler-locking
-Display the current scheduler locking mode.
-@end table
-
-@cindex resume threads of multiple processes simultaneously
-By default, when you issue one of the execution commands such as
-@code{continue}, @code{next} or @code{step}, @value{GDBN} allows only
-threads of the current inferior to run.  For example, if @value{GDBN}
-is attached to two inferiors, each with two threads, the
-@code{continue} command resumes only the two threads of the current
-inferior.  This is useful, for example, when you debug a program that
-forks and you want to hold the parent stopped (so that, for instance,
-it doesn't run to exit), while you debug the child.  In other
-situations, you may not be interested in inspecting the current state
-of any of the processes @value{GDBN} is attached to, and you may want
-to resume them all until some breakpoint is hit.  In the latter case,
-you can instruct @value{GDBN} to allow all threads of all the
-inferiors to run with the @w{@code{set schedule-multiple}} command.
-
-@table @code
-@kindex set schedule-multiple
-@item set schedule-multiple
-Set the mode for allowing threads of multiple processes to be resumed
-when an execution command is issued.  When @code{on}, all threads of
-all processes are allowed to run.  When @code{off}, only the threads
-of the current process are resumed.  The default is @code{off}.  The
-@code{scheduler-locking} mode takes precedence when set to @code{on},
-or while you are stepping and set to @code{step}.
-
-@item show schedule-multiple
-Display the current mode for resuming the execution of threads of
-multiple processes.
-@end table
-
-@node Non-Stop Mode
-@subsection Non-Stop Mode
-
-@cindex non-stop mode
-
-@c This section is really only a place-holder, and needs to be expanded
-@c with more details.  
-
-For some multi-threaded targets, @value{GDBN} supports an optional
-mode of operation in which you can examine stopped program threads in
-the debugger while other threads continue to execute freely.  This
-minimizes intrusion when debugging live systems, such as programs 
-where some threads have real-time constraints or must continue to 
-respond to external events.  This is referred to as @dfn{non-stop} mode.
-
-In non-stop mode, when a thread stops to report a debugging event,
-@emph{only} that thread is stopped; @value{GDBN} does not stop other
-threads as well, in contrast to the all-stop mode behavior.  Additionally,
-execution commands such as @code{continue} and @code{step} apply by default
-only to the current thread in non-stop mode, rather than all threads as
-in all-stop mode.  This allows you to control threads explicitly in
-ways that are not possible in all-stop mode --- for example, stepping 
-one thread while allowing others to run freely, stepping
-one thread while holding all others stopped, or stepping several threads 
-independently and simultaneously.
-
-To enter non-stop mode, use this sequence of commands before you run
-or attach to your program:
-
-@smallexample
-# Enable the async interface.  
-set target-async 1
-
-# If using the CLI, pagination breaks non-stop.
-set pagination off
-
-# Finally, turn it on!
-set non-stop on
-@end smallexample
-
-You can use these commands to manipulate the non-stop mode setting:
-
-@table @code
-@kindex set non-stop
-@item set non-stop on
-Enable selection of non-stop mode.
-@item set non-stop off
-Disable selection of non-stop mode.
-@kindex show non-stop
-@item show non-stop
-Show the current non-stop enablement setting.
-@end table
-
-Note these commands only reflect whether non-stop mode is enabled,
-not whether the currently-executing program is being run in non-stop mode.  
-In particular, the @code{set non-stop} preference is only consulted when
-@value{GDBN} starts or connects to the target program, and it is generally 
-not possible to switch modes once debugging has started.  Furthermore,
-since not all targets support non-stop mode, even when you have enabled
-non-stop mode, @value{GDBN} may still fall back to all-stop operation by
-default.
-
-In non-stop mode, all execution commands apply only to the current thread
-by default.  That is, @code{continue} only continues one thread.  
-To continue all threads, issue @code{continue -a} or @code{c -a}.
-
-You can use @value{GDBN}'s background execution commands 
-(@pxref{Background Execution}) to run some threads in the background
-while you continue to examine or step others from @value{GDBN}.  
-The MI execution commands (@pxref{GDB/MI Program Execution}) are
-always executed asynchronously in non-stop mode.
-
-Suspending execution is done with the @code{interrupt} command when
-running in the background, or @kbd{Ctrl-c} during foreground execution.  
-In all-stop mode, this stops the whole process; 
-but in non-stop mode the interrupt applies only to the current thread.  
-To stop the whole program, use @code{interrupt -a}.
-
-Other execution commands do not currently support the @code{-a} option.
-
-In non-stop mode, when a thread stops, @value{GDBN} doesn't automatically make
-that thread current, as it does in all-stop mode.  This is because the
-thread stop notifications are asynchronous with respect to @value{GDBN}'s 
-command interpreter, and it would be confusing if @value{GDBN} unexpectedly
-changed to a different thread just as you entered a command to operate on the
-previously current thread.
-
-@node Background Execution
-@subsection Background Execution
-
-@cindex foreground execution
-@cindex background execution
-@cindex asynchronous execution
-@cindex execution, foreground, background and asynchronous
-
-@value{GDBN}'s execution commands have two variants:  the normal
-foreground (synchronous) behavior, and a background
-(asynchronous) behavior.  In foreground execution, @value{GDBN} waits for 
-the program to report that some thread has stopped before prompting for
-another command.  In background execution, @value{GDBN} immediately gives
-a command prompt so that you can issue other commands while your program runs.
-
-You need to explicitly enable asynchronous mode before you can use
-background execution commands.  You can use these commands to
-manipulate the asynchronous mode setting:
-
-@table @code
-@kindex set target-async
-@item set target-async on
-Enable asynchronous mode.
-@item set target-async off
-Disable asynchronous mode.
-@kindex show target-async
-@item show target-async
-Show the current target-async setting.
-@end table
-
-If the target doesn't support async mode, @value{GDBN} issues an error
-message if you attempt to use the background execution commands.
-
-To specify background execution, add a @code{&} to the command.  For example,
-the background form of the @code{continue} command is @code{continue&}, or
-just @code{c&}.  The execution commands that accept background execution
-are:
-
-@table @code
-@kindex run&
-@item run
-@xref{Starting, , Starting your Program}.
-
-@item attach
-@kindex attach&
-@xref{Attach, , Debugging an Already-running Process}.
-
-@item step
-@kindex step&
-@xref{Continuing and Stepping, step}.
-
-@item stepi
-@kindex stepi&
-@xref{Continuing and Stepping, stepi}.
-
-@item next
-@kindex next&
-@xref{Continuing and Stepping, next}.
-
-@item nexti
-@kindex nexti&
-@xref{Continuing and Stepping, nexti}.
-
-@item continue
-@kindex continue&
-@xref{Continuing and Stepping, continue}.
-
-@item finish
-@kindex finish&
-@xref{Continuing and Stepping, finish}.
-
-@item until
-@kindex until&
-@xref{Continuing and Stepping, until}.
-
-@end table
-
-Background execution is especially useful in conjunction with non-stop
-mode for debugging programs with multiple threads; see @ref{Non-Stop Mode}.
-However, you can also use these commands in the normal all-stop mode with
-the restriction that you cannot issue another execution command until the
-previous one finishes.  Examples of commands that are valid in all-stop
-mode while the program is running include @code{help} and @code{info break}.
-
-You can interrupt your program while it is running in the background by
-using the @code{interrupt} command.
-
-@table @code
-@kindex interrupt
-@item interrupt
-@itemx interrupt -a
-
-Suspend execution of the running program.  In all-stop mode, 
-@code{interrupt} stops the whole process, but in non-stop mode, it stops
-only the current thread.  To stop the whole program in non-stop mode, 
-use @code{interrupt -a}.
-@end table
-
-@node Thread-Specific Breakpoints
-@subsection Thread-Specific Breakpoints
-
-When your program has multiple threads (@pxref{Threads,, Debugging
-Programs with Multiple Threads}), you can choose whether to set
-breakpoints on all threads, or on a particular thread.
-
-@table @code
-@cindex breakpoints and threads
-@cindex thread breakpoints
-@kindex break @dots{} thread @var{threadno}
-@item break @var{linespec} thread @var{threadno}
-@itemx break @var{linespec} thread @var{threadno} if @dots{}
-@var{linespec} specifies source lines; there are several ways of
-writing them (@pxref{Specify Location}), but the effect is always to
-specify some source line.
-
-Use the qualifier @samp{thread @var{threadno}} with a breakpoint command
-to specify that you only want @value{GDBN} to stop the program when a
-particular thread reaches this breakpoint.  @var{threadno} is one of the
-numeric thread identifiers assigned by @value{GDBN}, shown in the first
-column of the @samp{info threads} display.
-
-If you do not specify @samp{thread @var{threadno}} when you set a
-breakpoint, the breakpoint applies to @emph{all} threads of your
-program.
-
-You can use the @code{thread} qualifier on conditional breakpoints as
-well; in this case, place @samp{thread @var{threadno}} before or
-after the breakpoint condition, like this:
-
-@smallexample
-(@value{GDBP}) break frik.c:13 thread 28 if bartab > lim
-@end smallexample
-
-@end table
-
-@node Interrupted System Calls
-@subsection Interrupted System Calls 
-
-@cindex thread breakpoints and system calls
-@cindex system calls and thread breakpoints
-@cindex premature return from system calls
-There is an unfortunate side effect when using @value{GDBN} to debug
-multi-threaded programs.  If one thread stops for a
-breakpoint, or for some other reason, and another thread is blocked in a
-system call, then the system call may return prematurely.  This is a
-consequence of the interaction between multiple threads and the signals
-that @value{GDBN} uses to implement breakpoints and other events that
-stop execution.
-
-To handle this problem, your program should check the return value of
-each system call and react appropriately.  This is good programming
-style anyways.
-
-For example, do not write code like this:
-
-@smallexample
-  sleep (10);
-@end smallexample
-
-The call to @code{sleep} will return early if a different thread stops
-at a breakpoint or for some other reason.
-
-Instead, write this:
-
-@smallexample
-  int unslept = 10;
-  while (unslept > 0)
-    unslept = sleep (unslept);
-@end smallexample
-
-A system call is allowed to return early, so the system is still
-conforming to its specification.  But @value{GDBN} does cause your
-multi-threaded program to behave differently than it would without
-@value{GDBN}.
-
-Also, @value{GDBN} uses internal breakpoints in the thread library to
-monitor certain events such as thread creation and thread destruction.
-When such an event happens, a system call in another thread may return
-prematurely, even though your program does not appear to stop.
-
-@node Observer Mode
-@subsection Observer Mode
-
-If you want to build on non-stop mode and observe program behavior
-without any chance of disruption by @value{GDBN}, you can set
-variables to disable all of the debugger's attempts to modify state,
-whether by writing memory, inserting breakpoints, etc.  These operate
-at a low level, intercepting operations from all commands.
-
-When all of these are set to @code{off}, then @value{GDBN} is said to
-be @dfn{observer mode}.  As a convenience, the variable
-@code{observer} can be set to disable these, plus enable non-stop
-mode.
-
-Note that @value{GDBN} will not prevent you from making nonsensical
-combinations of these settings. For instance, if you have enabled
-@code{may-insert-breakpoints} but disabled @code{may-write-memory},
-then breakpoints that work by writing trap instructions into the code
-stream will still not be able to be placed.
-
-@table @code
-
-@kindex observer
-@item set observer on
-@itemx set observer off
-When set to @code{on}, this disables all the permission variables
-below (except for @code{insert-fast-tracepoints}), plus enables
-non-stop debugging.  Setting this to @code{off} switches back to
-normal debugging, though remaining in non-stop mode.
-
-@item show observer
-Show whether observer mode is on or off.
-
-@kindex may-write-registers
-@item set may-write-registers on
-@itemx set may-write-registers off
-This controls whether @value{GDBN} will attempt to alter the values of
-registers, such as with assignment expressions in @code{print}, or the
-@code{jump} command.  It defaults to @code{on}.
-
-@item show may-write-registers
-Show the current permission to write registers.
-
-@kindex may-write-memory
-@item set may-write-memory on
-@itemx set may-write-memory off
-This controls whether @value{GDBN} will attempt to alter the contents
-of memory, such as with assignment expressions in @code{print}.  It
-defaults to @code{on}.
-
-@item show may-write-memory
-Show the current permission to write memory.
-
-@kindex may-insert-breakpoints
-@item set may-insert-breakpoints on
-@itemx set may-insert-breakpoints off
-This controls whether @value{GDBN} will attempt to insert breakpoints.
-This affects all breakpoints, including internal breakpoints defined
-by @value{GDBN}.  It defaults to @code{on}.
-
-@item show may-insert-breakpoints
-Show the current permission to insert breakpoints.
-
-@kindex may-insert-tracepoints
-@item set may-insert-tracepoints on
-@itemx set may-insert-tracepoints off
-This controls whether @value{GDBN} will attempt to insert (regular)
-tracepoints at the beginning of a tracing experiment.  It affects only
-non-fast tracepoints, fast tracepoints being under the control of
-@code{may-insert-fast-tracepoints}.  It defaults to @code{on}.
-
-@item show may-insert-tracepoints
-Show the current permission to insert tracepoints.
-
-@kindex may-insert-fast-tracepoints
-@item set may-insert-fast-tracepoints on
-@itemx set may-insert-fast-tracepoints off
-This controls whether @value{GDBN} will attempt to insert fast
-tracepoints at the beginning of a tracing experiment.  It affects only
-fast tracepoints, regular (non-fast) tracepoints being under the
-control of @code{may-insert-tracepoints}.  It defaults to @code{on}.
-
-@item show may-insert-fast-tracepoints
-Show the current permission to insert fast tracepoints.
-
-@kindex may-interrupt
-@item set may-interrupt on
-@itemx set may-interrupt off
-This controls whether @value{GDBN} will attempt to interrupt or stop
-program execution.  When this variable is @code{off}, the
-@code{interrupt} command will have no effect, nor will
-@kbd{Ctrl-c}. It defaults to @code{on}.
-
-@item show may-interrupt
-Show the current permission to interrupt or stop the program.
-
-@end table
-
-@node Reverse Execution
-@chapter Running programs backward
-@cindex reverse execution
-@cindex running programs backward
-
-When you are debugging a program, it is not unusual to realize that
-you have gone too far, and some event of interest has already happened.
-If the target environment supports it, @value{GDBN} can allow you to
-``rewind'' the program by running it backward.
-
-A target environment that supports reverse execution should be able
-to ``undo'' the changes in machine state that have taken place as the
-program was executing normally.  Variables, registers etc.@: should
-revert to their previous values.  Obviously this requires a great
-deal of sophistication on the part of the target environment; not
-all target environments can support reverse execution.
-
-When a program is executed in reverse, the instructions that
-have most recently been executed are ``un-executed'', in reverse
-order.  The program counter runs backward, following the previous
-thread of execution in reverse.  As each instruction is ``un-executed'',
-the values of memory and/or registers that were changed by that
-instruction are reverted to their previous states.  After executing
-a piece of source code in reverse, all side effects of that code
-should be ``undone'', and all variables should be returned to their
-prior values@footnote{
-Note that some side effects are easier to undo than others.  For instance,
-memory and registers are relatively easy, but device I/O is hard.  Some
-targets may be able undo things like device I/O, and some may not.
-
-The contract between @value{GDBN} and the reverse executing target
-requires only that the target do something reasonable when
-@value{GDBN} tells it to execute backwards, and then report the 
-results back to @value{GDBN}.  Whatever the target reports back to
-@value{GDBN}, @value{GDBN} will report back to the user.  @value{GDBN}
-assumes that the memory and registers that the target reports are in a
-consistant state, but @value{GDBN} accepts whatever it is given.
-}.
-
-If you are debugging in a target environment that supports
-reverse execution, @value{GDBN} provides the following commands.
-
-@table @code
-@kindex reverse-continue
-@kindex rc @r{(@code{reverse-continue})}
-@item reverse-continue @r{[}@var{ignore-count}@r{]}
-@itemx rc @r{[}@var{ignore-count}@r{]}
-Beginning at the point where your program last stopped, start executing
-in reverse.  Reverse execution will stop for breakpoints and synchronous
-exceptions (signals), just like normal execution.  Behavior of
-asynchronous signals depends on the target environment.
-
-@kindex reverse-step
-@kindex rs @r{(@code{step})}
-@item reverse-step @r{[}@var{count}@r{]}
-Run the program backward until control reaches the start of a
-different source line; then stop it, and return control to @value{GDBN}.
-
-Like the @code{step} command, @code{reverse-step} will only stop
-at the beginning of a source line.  It ``un-executes'' the previously
-executed source line.  If the previous source line included calls to
-debuggable functions, @code{reverse-step} will step (backward) into
-the called function, stopping at the beginning of the @emph{last}
-statement in the called function (typically a return statement).
-
-Also, as with the @code{step} command, if non-debuggable functions are
-called, @code{reverse-step} will run thru them backward without stopping.
-
-@kindex reverse-stepi
-@kindex rsi @r{(@code{reverse-stepi})}
-@item reverse-stepi @r{[}@var{count}@r{]}
-Reverse-execute one machine instruction.  Note that the instruction
-to be reverse-executed is @emph{not} the one pointed to by the program
-counter, but the instruction executed prior to that one.  For instance,
-if the last instruction was a jump, @code{reverse-stepi} will take you
-back from the destination of the jump to the jump instruction itself.
-
-@kindex reverse-next
-@kindex rn @r{(@code{reverse-next})}
-@item reverse-next @r{[}@var{count}@r{]}
-Run backward to the beginning of the previous line executed in
-the current (innermost) stack frame.  If the line contains function
-calls, they will be ``un-executed'' without stopping.  Starting from
-the first line of a function, @code{reverse-next} will take you back
-to the caller of that function, @emph{before} the function was called,
-just as the normal @code{next} command would take you from the last 
-line of a function back to its return to its caller
-@footnote{Unless the code is too heavily optimized.}.
-
-@kindex reverse-nexti
-@kindex rni @r{(@code{reverse-nexti})}
-@item reverse-nexti @r{[}@var{count}@r{]}
-Like @code{nexti}, @code{reverse-nexti} executes a single instruction
-in reverse, except that called functions are ``un-executed'' atomically.
-That is, if the previously executed instruction was a return from
-another function, @code{reverse-nexti} will continue to execute
-in reverse until the call to that function (from the current stack
-frame) is reached.
-
-@kindex reverse-finish
-@item reverse-finish
-Just as the @code{finish} command takes you to the point where the
-current function returns, @code{reverse-finish} takes you to the point
-where it was called.  Instead of ending up at the end of the current
-function invocation, you end up at the beginning.
-
-@kindex set exec-direction
-@item set exec-direction
-Set the direction of target execution.
-@item set exec-direction reverse
-@cindex execute forward or backward in time
-@value{GDBN} will perform all execution commands in reverse, until the
-exec-direction mode is changed to ``forward''.  Affected commands include
-@code{step, stepi, next, nexti, continue, and finish}.  The @code{return}
-command cannot be used in reverse mode.
-@item set exec-direction forward
-@value{GDBN} will perform all execution commands in the normal fashion.
-This is the default.
-@end table
-
-
-@node Process Record and Replay
-@chapter Recording Inferior's Execution and Replaying It
-@cindex process record and replay
-@cindex recording inferior's execution and replaying it
-
-On some platforms, @value{GDBN} provides a special @dfn{process record
-and replay} target that can record a log of the process execution, and
-replay it later with both forward and reverse execution commands.
-
-@cindex replay mode
-When this target is in use, if the execution log includes the record
-for the next instruction, @value{GDBN} will debug in @dfn{replay
-mode}.  In the replay mode, the inferior does not really execute code
-instructions.  Instead, all the events that normally happen during
-code execution are taken from the execution log.  While code is not
-really executed in replay mode, the values of registers (including the
-program counter register) and the memory of the inferior are still
-changed as they normally would.  Their contents are taken from the
-execution log.
-
-@cindex record mode
-If the record for the next instruction is not in the execution log,
-@value{GDBN} will debug in @dfn{record mode}.  In this mode, the
-inferior executes normally, and @value{GDBN} records the execution log
-for future replay.
-
-The process record and replay target supports reverse execution
-(@pxref{Reverse Execution}), even if the platform on which the
-inferior runs does not.  However, the reverse execution is limited in
-this case by the range of the instructions recorded in the execution
-log.  In other words, reverse execution on platforms that don't
-support it directly can only be done in the replay mode.
-
-When debugging in the reverse direction, @value{GDBN} will work in
-replay mode as long as the execution log includes the record for the
-previous instruction; otherwise, it will work in record mode, if the
-platform supports reverse execution, or stop if not.
-
-For architecture environments that support process record and replay,
-@value{GDBN} provides the following commands:
-
-@table @code
-@kindex target record
-@kindex target record-full
-@kindex target record-btrace
-@kindex record
-@kindex record full
-@kindex record btrace
-@kindex rec
-@kindex rec full
-@kindex rec btrace
-@item record @var{method}
-This command starts the process record and replay target.  The
-recording method can be specified as parameter.  Without a parameter
-the command uses the @code{full} recording method.  The following
-recording methods are available:
-
-@table @code
-@item full
-Full record/replay recording using @value{GDBN}'s software record and
-replay implementation.  This method allows replaying and reverse
-execution.
-
-@item btrace
-Hardware-supported instruction recording.  This method does not allow
-replaying and reverse execution.
-
-This recording method may not be available on all processors.
-@end table
-
-The process record and replay target can only debug a process that is
-already running.  Therefore, you need first to start the process with
-the @kbd{run} or @kbd{start} commands, and then start the recording
-with the @kbd{record @var{method}} command.
-
-Both @code{record @var{method}} and @code{rec @var{method}} are
-aliases of @code{target record-@var{method}}.
-
-@cindex displaced stepping, and process record and replay
-Displaced stepping (@pxref{Maintenance Commands,, displaced stepping})
-will be automatically disabled when process record and replay target
-is started.  That's because the process record and replay target
-doesn't support displaced stepping.
-
-@cindex non-stop mode, and process record and replay
-@cindex asynchronous execution, and process record and replay
-If the inferior is in the non-stop mode (@pxref{Non-Stop Mode}) or in
-the asynchronous execution mode (@pxref{Background Execution}), not
-all recording methods are available.  The @code{full} recording method
-does not support these two modes.
-
-@kindex record stop
-@kindex rec s
-@item record stop
-Stop the process record and replay target.  When process record and
-replay target stops, the entire execution log will be deleted and the
-inferior will either be terminated, or will remain in its final state.
-
-When you stop the process record and replay target in record mode (at
-the end of the execution log), the inferior will be stopped at the
-next instruction that would have been recorded.  In other words, if
-you record for a while and then stop recording, the inferior process
-will be left in the same state as if the recording never happened.
-
-On the other hand, if the process record and replay target is stopped
-while in replay mode (that is, not at the end of the execution log,
-but at some earlier point), the inferior process will become ``live''
-at that earlier state, and it will then be possible to continue the
-usual ``live'' debugging of the process from that state.
-
-When the inferior process exits, or @value{GDBN} detaches from it,
-process record and replay target will automatically stop itself.
-
-@kindex record save
-@item record save @var{filename}
-Save the execution log to a file @file{@var{filename}}.
-Default filename is @file{gdb_record.@var{process_id}}, where
-@var{process_id} is the process ID of the inferior.
-
-This command may not be available for all recording methods.
-
-@kindex record restore
-@item record restore @var{filename}
-Restore the execution log from a file @file{@var{filename}}.
-File must have been created with @code{record save}.
-
-@kindex set record full
-@item set record full insn-number-max @var{limit}
-Set the limit of instructions to be recorded for the @code{full}
-recording method.  Default value is 200000.
-
-If @var{limit} is a positive number, then @value{GDBN} will start
-deleting instructions from the log once the number of the record
-instructions becomes greater than @var{limit}.  For every new recorded
-instruction, @value{GDBN} will delete the earliest recorded
-instruction to keep the number of recorded instructions at the limit.
-(Since deleting recorded instructions loses information, @value{GDBN}
-lets you control what happens when the limit is reached, by means of
-the @code{stop-at-limit} option, described below.)
-
-If @var{limit} is zero, @value{GDBN} will never delete recorded
-instructions from the execution log.  The number of recorded
-instructions is unlimited in this case.
-
-@kindex show record full
-@item show record full insn-number-max
-Show the limit of instructions to be recorded with the @code{full}
-recording method.
-
-@item set record full stop-at-limit
-Control the behavior of the  @code{full} recording method when the
-number of recorded instructions reaches the limit.  If ON (the
-default), @value{GDBN} will stop when the limit is reached for the
-first time and ask you whether you want to stop the inferior or
-continue running it and recording the execution log.  If you decide
-to continue recording, each new recorded instruction will cause the
-oldest one to be deleted.
-
-If this option is OFF, @value{GDBN} will automatically delete the
-oldest record to make room for each new one, without asking.
-
-@item show record full stop-at-limit
-Show the current setting of @code{stop-at-limit}.
-
-@item set record full memory-query
-Control the behavior when @value{GDBN} is unable to record memory
-changes caused by an instruction for the @code{full} recording method.
-If ON, @value{GDBN} will query whether to stop the inferior in that
-case.
-
-If this option is OFF (the default), @value{GDBN} will automatically
-ignore the effect of such instructions on memory.  Later, when
-@value{GDBN} replays this execution log, it will mark the log of this
-instruction as not accessible, and it will not affect the replay
-results.
-
-@item show record full memory-query
-Show the current setting of @code{memory-query}.
-
-@kindex info record
-@item info record
-Show various statistics about the recording depending on the recording
-method:
-
-@table @code
-@item full
-For the @code{full} recording method, it shows the state of process
-record and its in-memory execution log buffer, including:
-
-@itemize @bullet
-@item
-Whether in record mode or replay mode.
-@item
-Lowest recorded instruction number (counting from when the current execution log started recording instructions).
-@item
-Highest recorded instruction number.
-@item
-Current instruction about to be replayed (if in replay mode).
-@item
-Number of instructions contained in the execution log.
-@item
-Maximum number of instructions that may be contained in the execution log.
-@end itemize
-
-@item btrace
-For the @code{btrace} recording method, it shows the number of
-instructions that have been recorded and the number of blocks of
-sequential control-flow that is formed by the recorded instructions.
-@end table
-
-@kindex record delete
-@kindex rec del
-@item record delete
-When record target runs in replay mode (``in the past''), delete the
-subsequent execution log and begin to record a new execution log starting
-from the current address.  This means you will abandon the previously
-recorded ``future'' and begin recording a new ``future''.
-
-@kindex record instruction-history
-@kindex rec instruction-history
-@item record instruction-history
-Disassembles instructions from the recorded execution log.  By
-default, ten instructions are disassembled.  This can be changed using
-the @code{set record instruction-history-size} command.  Instructions
-are printed in execution order.  There are several ways to specify
-what part of the execution log to disassemble:
-
-@table @code
-@item record instruction-history @var{insn}
-Disassembles ten instructions starting from instruction number
-@var{insn}.
-
-@item record instruction-history @var{insn}, +/-@var{n}
-Disassembles @var{n} instructions around instruction number
-@var{insn}.  If @var{n} is preceded with @code{+}, disassembles
-@var{n} instructions after instruction number @var{insn}.  If
-@var{n} is preceded with @code{-}, disassembles @var{n}
-instructions before instruction number @var{insn}.
-
-@item record instruction-history
-Disassembles ten more instructions after the last disassembly.
-
-@item record instruction-history -
-Disassembles ten more instructions before the last disassembly.
-
-@item record instruction-history @var{begin} @var{end}
-Disassembles instructions beginning with instruction number
-@var{begin} until instruction number @var{end}.  The instruction
-number @var{end} is not included.
-@end table
-
-This command may not be available for all recording methods.
-
-@kindex set record
-@item set record instruction-history-size
-Define how many instructions to disassemble in the @code{record
-instruction-history} command.  The default value is 10.
-
-@kindex show record
-@item show record instruction-history-size
-Show how many instructions to disassemble in the @code{record
-instruction-history} command.
-
-@kindex record function-call-history
-@kindex rec function-call-history
-@item record function-call-history
-Prints the execution history at function granularity. It prints one
-line for each sequence of instructions that belong to the same
-function giving the name of that function, the source lines
-for this instruction sequence (if the @code{/l} modifier is
-specified), and the instructions numbers that form the sequence (if
-the @code{/i} modifier is specified).
-
-@smallexample
-(@value{GDBP}) @b{list 1, 10}
-1   void foo (void)
-2   @{
-3   @}
-4
-5   void bar (void)
-6   @{
-7     ...
-8     foo ();
-9     ...
-10  @}
-(@value{GDBP}) @b{record function-call-history /l}
-1  foo.c:6-8   bar
-2  foo.c:2-3   foo
-3  foo.c:9-10  bar
-@end smallexample
-
-By default, ten lines are printed.  This can be changed using the
-@code{set record function-call-history-size} command.  Functions are
-printed in execution order.  There are several ways to specify what
-to print:
-
-@table @code
-@item record function-call-history @var{func}
-Prints ten functions starting from function number @var{func}.
-
-@item record function-call-history @var{func}, +/-@var{n}
-Prints @var{n} functions around function number @var{func}.  If
-@var{n} is preceded with @code{+}, prints @var{n} functions after
-function number @var{func}.  If @var{n} is preceded with @code{-},
-prints @var{n} functions before function number @var{func}.
-
-@item record function-call-history
-Prints ten more functions after the last ten-line print.
-
-@item record function-call-history -
-Prints ten more functions before the last ten-line print.
-
-@item record function-call-history @var{begin} @var{end}
-Prints functions beginning with function number @var{begin} until
-function number @var{end}.  The function number @var{end} is not
-included.
-@end table
-
-This command may not be available for all recording methods.
-
-@item set record function-call-history-size
-Define how many lines to print in the
-@code{record function-call-history} command.  The default value is 10.
-
-@item show record function-call-history-size
-Show how many lines to print in the
-@code{record function-call-history} command.
-@end table
-
-
-@node Stack
-@chapter Examining the Stack
-
-When your program has stopped, the first thing you need to know is where it
-stopped and how it got there.
-
-@cindex call stack
-Each time your program performs a function call, information about the call
-is generated.
-That information includes the location of the call in your program,
-the arguments of the call,
-and the local variables of the function being called.
-The information is saved in a block of data called a @dfn{stack frame}.
-The stack frames are allocated in a region of memory called the @dfn{call
-stack}.
-
-When your program stops, the @value{GDBN} commands for examining the
-stack allow you to see all of this information.
-
-@cindex selected frame
-One of the stack frames is @dfn{selected} by @value{GDBN} and many
-@value{GDBN} commands refer implicitly to the selected frame.  In
-particular, whenever you ask @value{GDBN} for the value of a variable in
-your program, the value is found in the selected frame.  There are
-special @value{GDBN} commands to select whichever frame you are
-interested in.  @xref{Selection, ,Selecting a Frame}.
-
-When your program stops, @value{GDBN} automatically selects the
-currently executing frame and describes it briefly, similar to the
-@code{frame} command (@pxref{Frame Info, ,Information about a Frame}).
-
-@menu
-* Frames::                      Stack frames
-* Backtrace::                   Backtraces
-* Selection::                   Selecting a frame
-* Frame Info::                  Information on a frame
-
-@end menu
-
-@node Frames
-@section Stack Frames
-
-@cindex frame, definition
-@cindex stack frame
-The call stack is divided up into contiguous pieces called @dfn{stack
-frames}, or @dfn{frames} for short; each frame is the data associated
-with one call to one function.  The frame contains the arguments given
-to the function, the function's local variables, and the address at
-which the function is executing.
-
-@cindex initial frame
-@cindex outermost frame
-@cindex innermost frame
-When your program is started, the stack has only one frame, that of the
-function @code{main}.  This is called the @dfn{initial} frame or the
-@dfn{outermost} frame.  Each time a function is called, a new frame is
-made.  Each time a function returns, the frame for that function invocation
-is eliminated.  If a function is recursive, there can be many frames for
-the same function.  The frame for the function in which execution is
-actually occurring is called the @dfn{innermost} frame.  This is the most
-recently created of all the stack frames that still exist.
-
-@cindex frame pointer
-Inside your program, stack frames are identified by their addresses.  A
-stack frame consists of many bytes, each of which has its own address; each
-kind of computer has a convention for choosing one byte whose
-address serves as the address of the frame.  Usually this address is kept
-in a register called the @dfn{frame pointer register}
-(@pxref{Registers, $fp}) while execution is going on in that frame.
-
-@cindex frame number
-@value{GDBN} assigns numbers to all existing stack frames, starting with
-zero for the innermost frame, one for the frame that called it,
-and so on upward.  These numbers do not really exist in your program;
-they are assigned by @value{GDBN} to give you a way of designating stack
-frames in @value{GDBN} commands.
-
-@c The -fomit-frame-pointer below perennially causes hbox overflow
-@c underflow problems.
-@cindex frameless execution
-Some compilers provide a way to compile functions so that they operate
-without stack frames.  (For example, the @value{NGCC} option
-@smallexample
-@samp{-fomit-frame-pointer}
-@end smallexample
-generates functions without a frame.)
-This is occasionally done with heavily used library functions to save
-the frame setup time.  @value{GDBN} has limited facilities for dealing
-with these function invocations.  If the innermost function invocation
-has no stack frame, @value{GDBN} nevertheless regards it as though
-it had a separate frame, which is numbered zero as usual, allowing
-correct tracing of the function call chain.  However, @value{GDBN} has
-no provision for frameless functions elsewhere in the stack.
-
-@table @code
-@kindex frame@r{, command}
-@cindex current stack frame
-@item frame @var{args}
-The @code{frame} command allows you to move from one stack frame to another,
-and to print the stack frame you select.  @var{args} may be either the
-address of the frame or the stack frame number.  Without an argument,
-@code{frame} prints the current stack frame.
-
-@kindex select-frame
-@cindex selecting frame silently
-@item select-frame
-The @code{select-frame} command allows you to move from one stack frame
-to another without printing the frame.  This is the silent version of
-@code{frame}.
-@end table
-
-@node Backtrace
-@section Backtraces
-
-@cindex traceback
-@cindex call stack traces
-A backtrace is a summary of how your program got where it is.  It shows one
-line per frame, for many frames, starting with the currently executing
-frame (frame zero), followed by its caller (frame one), and on up the
-stack.
-
-@table @code
-@kindex backtrace
-@kindex bt @r{(@code{backtrace})}
-@item backtrace
-@itemx bt
-Print a backtrace of the entire stack: one line per frame for all
-frames in the stack.
-
-You can stop the backtrace at any time by typing the system interrupt
-character, normally @kbd{Ctrl-c}.
-
-@item backtrace @var{n}
-@itemx bt @var{n}
-Similar, but print only the innermost @var{n} frames.
-
-@item backtrace -@var{n}
-@itemx bt -@var{n}
-Similar, but print only the outermost @var{n} frames.
-
-@item backtrace full
-@itemx bt full
-@itemx bt full @var{n}
-@itemx bt full -@var{n}
-Print the values of the local variables also.  @var{n} specifies the
-number of frames to print, as described above.
-@end table
-
-@kindex where
-@kindex info stack
-The names @code{where} and @code{info stack} (abbreviated @code{info s})
-are additional aliases for @code{backtrace}.
-
-@cindex multiple threads, backtrace
-In a multi-threaded program, @value{GDBN} by default shows the
-backtrace only for the current thread.  To display the backtrace for
-several or all of the threads, use the command @code{thread apply}
-(@pxref{Threads, thread apply}).  For example, if you type @kbd{thread
-apply all backtrace}, @value{GDBN} will display the backtrace for all
-the threads; this is handy when you debug a core dump of a
-multi-threaded program.
-
-Each line in the backtrace shows the frame number and the function name.
-The program counter value is also shown---unless you use @code{set
-print address off}.  The backtrace also shows the source file name and
-line number, as well as the arguments to the function.  The program
-counter value is omitted if it is at the beginning of the code for that
-line number.
-
-Here is an example of a backtrace.  It was made with the command
-@samp{bt 3}, so it shows the innermost three frames.
-
-@smallexample
-@group
-#0  m4_traceon (obs=0x24eb0, argc=1, argv=0x2b8c8)
-    at builtin.c:993
-#1  0x6e38 in expand_macro (sym=0x2b600, data=...) at macro.c:242
-#2  0x6840 in expand_token (obs=0x0, t=177664, td=0xf7fffb08)
-    at macro.c:71
-(More stack frames follow...)
-@end group
-@end smallexample
-
-@noindent
-The display for frame zero does not begin with a program counter
-value, indicating that your program has stopped at the beginning of the
-code for line @code{993} of @code{builtin.c}.
-
-@noindent
-The value of parameter @code{data} in frame 1 has been replaced by
-@code{@dots{}}.  By default, @value{GDBN} prints the value of a parameter
-only if it is a scalar (integer, pointer, enumeration, etc).  See command
-@kbd{set print frame-arguments} in @ref{Print Settings} for more details
-on how to configure the way function parameter values are printed.
-
-@cindex optimized out, in backtrace
-@cindex function call arguments, optimized out
-If your program was compiled with optimizations, some compilers will
-optimize away arguments passed to functions if those arguments are
-never used after the call.  Such optimizations generate code that
-passes arguments through registers, but doesn't store those arguments
-in the stack frame.  @value{GDBN} has no way of displaying such
-arguments in stack frames other than the innermost one.  Here's what
-such a backtrace might look like:
-
-@smallexample
-@group
-#0  m4_traceon (obs=0x24eb0, argc=1, argv=0x2b8c8)
-    at builtin.c:993
-#1  0x6e38 in expand_macro (sym=<optimized out>) at macro.c:242
-#2  0x6840 in expand_token (obs=0x0, t=<optimized out>, td=0xf7fffb08)
-    at macro.c:71
-(More stack frames follow...)
-@end group
-@end smallexample
-
-@noindent
-The values of arguments that were not saved in their stack frames are
-shown as @samp{<optimized out>}.
-
-If you need to display the values of such optimized-out arguments,
-either deduce that from other variables whose values depend on the one
-you are interested in, or recompile without optimizations.
-
-@cindex backtrace beyond @code{main} function
-@cindex program entry point
-@cindex startup code, and backtrace
-Most programs have a standard user entry point---a place where system
-libraries and startup code transition into user code.  For C this is
-@code{main}@footnote{
-Note that embedded programs (the so-called ``free-standing''
-environment) are not required to have a @code{main} function as the
-entry point.  They could even have multiple entry points.}.
-When @value{GDBN} finds the entry function in a backtrace
-it will terminate the backtrace, to avoid tracing into highly
-system-specific (and generally uninteresting) code.
-
-If you need to examine the startup code, or limit the number of levels
-in a backtrace, you can change this behavior:
-
-@table @code
-@item set backtrace past-main
-@itemx set backtrace past-main on
-@kindex set backtrace
-Backtraces will continue past the user entry point.
-
-@item set backtrace past-main off
-Backtraces will stop when they encounter the user entry point.  This is the
-default.
-
-@item show backtrace past-main
-@kindex show backtrace
-Display the current user entry point backtrace policy.
-
-@item set backtrace past-entry
-@itemx set backtrace past-entry on
-Backtraces will continue past the internal entry point of an application.
-This entry point is encoded by the linker when the application is built,
-and is likely before the user entry point @code{main} (or equivalent) is called.
-
-@item set backtrace past-entry off
-Backtraces will stop when they encounter the internal entry point of an
-application.  This is the default.
-
-@item show backtrace past-entry
-Display the current internal entry point backtrace policy.
-
-@item set backtrace limit @var{n}
-@itemx set backtrace limit 0
-@cindex backtrace limit
-Limit the backtrace to @var{n} levels.  A value of zero means
-unlimited.
-
-@item show backtrace limit
-Display the current limit on backtrace levels.
-@end table
-
-You can control how file names are displayed.
-
-@table @code
-@item set filename-display
-@itemx set filename-display relative
-@cindex filename-display
-Display file names relative to the compilation directory.  This is the default.
-
-@item set filename-display basename
-Display only basename of a filename.
-
-@item set filename-display absolute
-Display an absolute filename.
-
-@item show filename-display
-Show the current way to display filenames.
-@end table
-
-@node Selection
-@section Selecting a Frame
-
-Most commands for examining the stack and other data in your program work on
-whichever stack frame is selected at the moment.  Here are the commands for
-selecting a stack frame; all of them finish by printing a brief description
-of the stack frame just selected.
-
-@table @code
-@kindex frame@r{, selecting}
-@kindex f @r{(@code{frame})}
-@item frame @var{n}
-@itemx f @var{n}
-Select frame number @var{n}.  Recall that frame zero is the innermost
-(currently executing) frame, frame one is the frame that called the
-innermost one, and so on.  The highest-numbered frame is the one for
-@code{main}.
-
-@item frame @var{addr}
-@itemx f @var{addr}
-Select the frame at address @var{addr}.  This is useful mainly if the
-chaining of stack frames has been damaged by a bug, making it
-impossible for @value{GDBN} to assign numbers properly to all frames.  In
-addition, this can be useful when your program has multiple stacks and
-switches between them.
-
-On the SPARC architecture, @code{frame} needs two addresses to
-select an arbitrary frame: a frame pointer and a stack pointer.
-
-On the @acronym{MIPS} and Alpha architecture, it needs two addresses: a stack
-pointer and a program counter.
-
-On the 29k architecture, it needs three addresses: a register stack
-pointer, a program counter, and a memory stack pointer.
-
-@kindex up
-@item up @var{n}
-Move @var{n} frames up the stack.  For positive numbers @var{n}, this
-advances toward the outermost frame, to higher frame numbers, to frames
-that have existed longer.  @var{n} defaults to one.
-
-@kindex down
-@kindex do @r{(@code{down})}
-@item down @var{n}
-Move @var{n} frames down the stack.  For positive numbers @var{n}, this
-advances toward the innermost frame, to lower frame numbers, to frames
-that were created more recently.  @var{n} defaults to one.  You may
-abbreviate @code{down} as @code{do}.
-@end table
-
-All of these commands end by printing two lines of output describing the
-frame.  The first line shows the frame number, the function name, the
-arguments, and the source file and line number of execution in that
-frame.  The second line shows the text of that source line.
-
-@need 1000
-For example:
-
-@smallexample
-@group
-(@value{GDBP}) up
-#1  0x22f0 in main (argc=1, argv=0xf7fffbf4, env=0xf7fffbfc)
-    at env.c:10
-10              read_input_file (argv[i]);
-@end group
-@end smallexample
-
-After such a printout, the @code{list} command with no arguments
-prints ten lines centered on the point of execution in the frame.
-You can also edit the program at the point of execution with your favorite
-editing program by typing @code{edit}.
-@xref{List, ,Printing Source Lines},
-for details.
-
-@table @code
-@kindex down-silently
-@kindex up-silently
-@item up-silently @var{n}
-@itemx down-silently @var{n}
-These two commands are variants of @code{up} and @code{down},
-respectively; they differ in that they do their work silently, without
-causing display of the new frame.  They are intended primarily for use
-in @value{GDBN} command scripts, where the output might be unnecessary and
-distracting.
-@end table
-
-@node Frame Info
-@section Information About a Frame
-
-There are several other commands to print information about the selected
-stack frame.
-
-@table @code
-@item frame
-@itemx f
-When used without any argument, this command does not change which
-frame is selected, but prints a brief description of the currently
-selected stack frame.  It can be abbreviated @code{f}.  With an
-argument, this command is used to select a stack frame.
-@xref{Selection, ,Selecting a Frame}.
-
-@kindex info frame
-@kindex info f @r{(@code{info frame})}
-@item info frame
-@itemx info f
-This command prints a verbose description of the selected stack frame,
-including:
-
-@itemize @bullet
-@item
-the address of the frame
-@item
-the address of the next frame down (called by this frame)
-@item
-the address of the next frame up (caller of this frame)
-@item
-the language in which the source code corresponding to this frame is written
-@item
-the address of the frame's arguments
-@item
-the address of the frame's local variables
-@item
-the program counter saved in it (the address of execution in the caller frame)
-@item
-which registers were saved in the frame
-@end itemize
-
-@noindent The verbose description is useful when
-something has gone wrong that has made the stack format fail to fit
-the usual conventions.
-
-@item info frame @var{addr}
-@itemx info f @var{addr}
-Print a verbose description of the frame at address @var{addr}, without
-selecting that frame.  The selected frame remains unchanged by this
-command.  This requires the same kind of address (more than one for some
-architectures) that you specify in the @code{frame} command.
-@xref{Selection, ,Selecting a Frame}.
-
-@kindex info args
-@item info args
-Print the arguments of the selected frame, each on a separate line.
-
-@item info locals
-@kindex info locals
-Print the local variables of the selected frame, each on a separate
-line.  These are all variables (declared either static or automatic)
-accessible at the point of execution of the selected frame.
-
-@end table
-
-
-@node Source
-@chapter Examining Source Files
-
-@value{GDBN} can print parts of your program's source, since the debugging
-information recorded in the program tells @value{GDBN} what source files were
-used to build it.  When your program stops, @value{GDBN} spontaneously prints
-the line where it stopped.  Likewise, when you select a stack frame
-(@pxref{Selection, ,Selecting a Frame}), @value{GDBN} prints the line where
-execution in that frame has stopped.  You can print other portions of
-source files by explicit command.
-
-If you use @value{GDBN} through its @sc{gnu} Emacs interface, you may
-prefer to use Emacs facilities to view source; see @ref{Emacs, ,Using
-@value{GDBN} under @sc{gnu} Emacs}.
-
-@menu
-* List::                        Printing source lines
-* Specify Location::            How to specify code locations
-* Edit::                        Editing source files
-* Search::                      Searching source files
-* Source Path::                 Specifying source directories
-* Machine Code::                Source and machine code
-@end menu
-
-@node List
-@section Printing Source Lines
-
-@kindex list
-@kindex l @r{(@code{list})}
-To print lines from a source file, use the @code{list} command
-(abbreviated @code{l}).  By default, ten lines are printed.
-There are several ways to specify what part of the file you want to
-print; see @ref{Specify Location}, for the full list.
-
-Here are the forms of the @code{list} command most commonly used:
-
-@table @code
-@item list @var{linenum}
-Print lines centered around line number @var{linenum} in the
-current source file.
-
-@item list @var{function}
-Print lines centered around the beginning of function
-@var{function}.
-
-@item list
-Print more lines.  If the last lines printed were printed with a
-@code{list} command, this prints lines following the last lines
-printed; however, if the last line printed was a solitary line printed
-as part of displaying a stack frame (@pxref{Stack, ,Examining the
-Stack}), this prints lines centered around that line.
-
-@item list -
-Print lines just before the lines last printed.
-@end table
-
-@cindex @code{list}, how many lines to display
-By default, @value{GDBN} prints ten source lines with any of these forms of
-the @code{list} command.  You can change this using @code{set listsize}:
-
-@table @code
-@kindex set listsize
-@item set listsize @var{count}
-Make the @code{list} command display @var{count} source lines (unless
-the @code{list} argument explicitly specifies some other number).
-Setting @var{count} to 0 means there's no limit.
-
-@kindex show listsize
-@item show listsize
-Display the number of lines that @code{list} prints.
-@end table
-
-Repeating a @code{list} command with @key{RET} discards the argument,
-so it is equivalent to typing just @code{list}.  This is more useful
-than listing the same lines again.  An exception is made for an
-argument of @samp{-}; that argument is preserved in repetition so that
-each repetition moves up in the source file.
-
-In general, the @code{list} command expects you to supply zero, one or two
-@dfn{linespecs}.  Linespecs specify source lines; there are several ways
-of writing them (@pxref{Specify Location}), but the effect is always
-to specify some source line.
-
-Here is a complete description of the possible arguments for @code{list}:
-
-@table @code
-@item list @var{linespec}
-Print lines centered around the line specified by @var{linespec}.
-
-@item list @var{first},@var{last}
-Print lines from @var{first} to @var{last}.  Both arguments are
-linespecs.  When a @code{list} command has two linespecs, and the
-source file of the second linespec is omitted, this refers to
-the same source file as the first linespec.
-
-@item list ,@var{last}
-Print lines ending with @var{last}.
-
-@item list @var{first},
-Print lines starting with @var{first}.
-
-@item list +
-Print lines just after the lines last printed.
-
-@item list -
-Print lines just before the lines last printed.
-
-@item list
-As described in the preceding table.
-@end table
-
-@node Specify Location
-@section Specifying a Location
-@cindex specifying location
-@cindex linespec
-
-Several @value{GDBN} commands accept arguments that specify a location
-of your program's code.  Since @value{GDBN} is a source-level
-debugger, a location usually specifies some line in the source code;
-for that reason, locations are also known as @dfn{linespecs}.
-
-Here are all the different ways of specifying a code location that
-@value{GDBN} understands:
-
-@table @code
-@item @var{linenum}
-Specifies the line number @var{linenum} of the current source file.
-
-@item -@var{offset}
-@itemx +@var{offset}
-Specifies the line @var{offset} lines before or after the @dfn{current
-line}.  For the @code{list} command, the current line is the last one
-printed; for the breakpoint commands, this is the line at which
-execution stopped in the currently selected @dfn{stack frame}
-(@pxref{Frames, ,Frames}, for a description of stack frames.)  When
-used as the second of the two linespecs in a @code{list} command,
-this specifies the line @var{offset} lines up or down from the first
-linespec.
-
-@item @var{filename}:@var{linenum}
-Specifies the line @var{linenum} in the source file @var{filename}.
-If @var{filename} is a relative file name, then it will match any
-source file name with the same trailing components.  For example, if
-@var{filename} is @samp{gcc/expr.c}, then it will match source file
-name of @file{/build/trunk/gcc/expr.c}, but not
-@file{/build/trunk/libcpp/expr.c} or @file{/build/trunk/gcc/x-expr.c}.
-
-@item @var{function}
-Specifies the line that begins the body of the function @var{function}.
-For example, in C, this is the line with the open brace.
-
-@item @var{function}:@var{label}
-Specifies the line where @var{label} appears in @var{function}.
-
-@item @var{filename}:@var{function}
-Specifies the line that begins the body of the function @var{function}
-in the file @var{filename}.  You only need the file name with a
-function name to avoid ambiguity when there are identically named
-functions in different source files.
-
-@item @var{label}
-Specifies the line at which the label named @var{label} appears.
-@value{GDBN} searches for the label in the function corresponding to
-the currently selected stack frame.  If there is no current selected
-stack frame (for instance, if the inferior is not running), then
-@value{GDBN} will not search for a label.
-
-@item *@var{address}
-Specifies the program address @var{address}.  For line-oriented
-commands, such as @code{list} and @code{edit}, this specifies a source
-line that contains @var{address}.  For @code{break} and other
-breakpoint oriented commands, this can be used to set breakpoints in
-parts of your program which do not have debugging information or
-source files.
-
-Here @var{address} may be any expression valid in the current working
-language (@pxref{Languages, working language}) that specifies a code
-address.  In addition, as a convenience, @value{GDBN} extends the
-semantics of expressions used in locations to cover the situations
-that frequently happen during debugging.  Here are the various forms
-of @var{address}:
-
-@table @code
-@item @var{expression}
-Any expression valid in the current working language.
-
-@item @var{funcaddr}
-An address of a function or procedure derived from its name.  In C,
-C@t{++}, Java, Objective-C, Fortran, minimal, and assembly, this is
-simply the function's name @var{function} (and actually a special case
-of a valid expression).  In Pascal and Modula-2, this is
-@code{&@var{function}}.  In Ada, this is @code{@var{function}'Address}
-(although the Pascal form also works).
-
-This form specifies the address of the function's first instruction,
-before the stack frame and arguments have been set up.
-
-@item '@var{filename}'::@var{funcaddr}
-Like @var{funcaddr} above, but also specifies the name of the source
-file explicitly.  This is useful if the name of the function does not
-specify the function unambiguously, e.g., if there are several
-functions with identical names in different source files.
-@end table
-
-@cindex breakpoint at static probe point
-@item -pstap|-probe-stap @r{[}@var{objfile}:@r{[}@var{provider}:@r{]}@r{]}@var{name}
-The @sc{gnu}/Linux tool @code{SystemTap} provides a way for
-applications to embed static probes.  @xref{Static Probe Points}, for more
-information on finding and using static probes.  This form of linespec
-specifies the location of such a static probe.
-
-If @var{objfile} is given, only probes coming from that shared library
-or executable matching @var{objfile} as a regular expression are considered.
-If @var{provider} is given, then only probes from that provider are considered.
-If several probes match the spec, @value{GDBN} will insert a breakpoint at
-each one of those probes.
-
-@end table
-
-
-@node Edit
-@section Editing Source Files
-@cindex editing source files
-
-@kindex edit
-@kindex e @r{(@code{edit})}
-To edit the lines in a source file, use the @code{edit} command.
-The editing program of your choice
-is invoked with the current line set to
-the active line in the program.
-Alternatively, there are several ways to specify what part of the file you
-want to print if you want to see other parts of the program:
-
-@table @code
-@item edit @var{location}
-Edit the source file specified by @code{location}.  Editing starts at
-that @var{location}, e.g., at the specified source line of the
-specified file.  @xref{Specify Location}, for all the possible forms
-of the @var{location} argument; here are the forms of the @code{edit}
-command most commonly used:
-
-@table @code
-@item edit @var{number}
-Edit the current source file with @var{number} as the active line number.
-
-@item edit @var{function}
-Edit the file containing @var{function} at the beginning of its definition.
-@end table
-
-@end table
-
-@subsection Choosing your Editor
-You can customize @value{GDBN} to use any editor you want
-@footnote{
-The only restriction is that your editor (say @code{ex}), recognizes the
-following command-line syntax:
-@smallexample
-ex +@var{number} file
-@end smallexample
-The optional numeric value +@var{number} specifies the number of the line in
-the file where to start editing.}.
-By default, it is @file{@value{EDITOR}}, but you can change this
-by setting the environment variable @code{EDITOR} before using
-@value{GDBN}.  For example, to configure @value{GDBN} to use the
-@code{vi} editor, you could use these commands with the @code{sh} shell:
-@smallexample
-EDITOR=/usr/bin/vi
-export EDITOR
-gdb @dots{}
-@end smallexample
-or in the @code{csh} shell,
-@smallexample
-setenv EDITOR /usr/bin/vi
-gdb @dots{}
-@end smallexample
-
-@node Search
-@section Searching Source Files
-@cindex searching source files
-
-There are two commands for searching through the current source file for a
-regular expression.
-
-@table @code
-@kindex search
-@kindex forward-search
-@kindex fo @r{(@code{forward-search})}
-@item forward-search @var{regexp}
-@itemx search @var{regexp}
-The command @samp{forward-search @var{regexp}} checks each line,
-starting with the one following the last line listed, for a match for
-@var{regexp}.  It lists the line that is found.  You can use the
-synonym @samp{search @var{regexp}} or abbreviate the command name as
-@code{fo}.
-
-@kindex reverse-search
-@item reverse-search @var{regexp}
-The command @samp{reverse-search @var{regexp}} checks each line, starting
-with the one before the last line listed and going backward, for a match
-for @var{regexp}.  It lists the line that is found.  You can abbreviate
-this command as @code{rev}.
-@end table
-
-@node Source Path
-@section Specifying Source Directories
-
-@cindex source path
-@cindex directories for source files
-Executable programs sometimes do not record the directories of the source
-files from which they were compiled, just the names.  Even when they do,
-the directories could be moved between the compilation and your debugging
-session.  @value{GDBN} has a list of directories to search for source files;
-this is called the @dfn{source path}.  Each time @value{GDBN} wants a source file,
-it tries all the directories in the list, in the order they are present
-in the list, until it finds a file with the desired name.
-
-For example, suppose an executable references the file
-@file{/usr/src/foo-1.0/lib/foo.c}, and our source path is
-@file{/mnt/cross}.  The file is first looked up literally; if this
-fails, @file{/mnt/cross/usr/src/foo-1.0/lib/foo.c} is tried; if this
-fails, @file{/mnt/cross/foo.c} is opened; if this fails, an error
-message is printed.  @value{GDBN} does not look up the parts of the
-source file name, such as @file{/mnt/cross/src/foo-1.0/lib/foo.c}.
-Likewise, the subdirectories of the source path are not searched: if
-the source path is @file{/mnt/cross}, and the binary refers to
-@file{foo.c}, @value{GDBN} would not find it under
-@file{/mnt/cross/usr/src/foo-1.0/lib}.
-
-Plain file names, relative file names with leading directories, file
-names containing dots, etc.@: are all treated as described above; for
-instance, if the source path is @file{/mnt/cross}, and the source file
-is recorded as @file{../lib/foo.c}, @value{GDBN} would first try
-@file{../lib/foo.c}, then @file{/mnt/cross/../lib/foo.c}, and after
-that---@file{/mnt/cross/foo.c}.
-
-Note that the executable search path is @emph{not} used to locate the
-source files.
-
-Whenever you reset or rearrange the source path, @value{GDBN} clears out
-any information it has cached about where source files are found and where
-each line is in the file.
-
-@kindex directory
-@kindex dir
-When you start @value{GDBN}, its source path includes only @samp{cdir}
-and @samp{cwd}, in that order.
-To add other directories, use the @code{directory} command.
-
-The search path is used to find both program source files and @value{GDBN}
-script files (read using the @samp{-command} option and @samp{source} command).
-
-In addition to the source path, @value{GDBN} provides a set of commands
-that manage a list of source path substitution rules.  A @dfn{substitution
-rule} specifies how to rewrite source directories stored in the program's
-debug information in case the sources were moved to a different
-directory between compilation and debugging.  A rule is made of
-two strings, the first specifying what needs to be rewritten in
-the path, and the second specifying how it should be rewritten.
-In @ref{set substitute-path}, we name these two parts @var{from} and
-@var{to} respectively.  @value{GDBN} does a simple string replacement
-of @var{from} with @var{to} at the start of the directory part of the
-source file name, and uses that result instead of the original file
-name to look up the sources.
-
-Using the previous example, suppose the @file{foo-1.0} tree has been
-moved from @file{/usr/src} to @file{/mnt/cross}, then you can tell
-@value{GDBN} to replace @file{/usr/src} in all source path names with
-@file{/mnt/cross}.  The first lookup will then be
-@file{/mnt/cross/foo-1.0/lib/foo.c} in place of the original location
-of @file{/usr/src/foo-1.0/lib/foo.c}.  To define a source path
-substitution rule, use the @code{set substitute-path} command
-(@pxref{set substitute-path}).
-
-To avoid unexpected substitution results, a rule is applied only if the
-@var{from} part of the directory name ends at a directory separator.
-For instance, a rule substituting  @file{/usr/source} into
-@file{/mnt/cross} will be applied to @file{/usr/source/foo-1.0} but
-not to @file{/usr/sourceware/foo-2.0}.  And because the substitution
-is applied only at the beginning of the directory name, this rule will
-not be applied to @file{/root/usr/source/baz.c} either.
-
-In many cases, you can achieve the same result using the @code{directory}
-command.  However, @code{set substitute-path} can be more efficient in
-the case where the sources are organized in a complex tree with multiple
-subdirectories.  With the @code{directory} command, you need to add each
-subdirectory of your project.  If you moved the entire tree while
-preserving its internal organization, then @code{set substitute-path}
-allows you to direct the debugger to all the sources with one single
-command.
-
-@code{set substitute-path} is also more than just a shortcut command.
-The source path is only used if the file at the original location no
-longer exists.  On the other hand, @code{set substitute-path} modifies
-the debugger behavior to look at the rewritten location instead.  So, if
-for any reason a source file that is not relevant to your executable is
-located at the original location, a substitution rule is the only
-method available to point @value{GDBN} at the new location.
-
-@cindex @samp{--with-relocated-sources}
-@cindex default source path substitution
-You can configure a default source path substitution rule by
-configuring @value{GDBN} with the
-@samp{--with-relocated-sources=@var{dir}} option.  The @var{dir}
-should be the name of a directory under @value{GDBN}'s configured
-prefix (set with @samp{--prefix} or @samp{--exec-prefix}), and
-directory names in debug information under @var{dir} will be adjusted
-automatically if the installed @value{GDBN} is moved to a new
-location.  This is useful if @value{GDBN}, libraries or executables
-with debug information and corresponding source code are being moved
-together.
-
-@table @code
-@item directory @var{dirname} @dots{}
-@item dir @var{dirname} @dots{}
-Add directory @var{dirname} to the front of the source path.  Several
-directory names may be given to this command, separated by @samp{:}
-(@samp{;} on MS-DOS and MS-Windows, where @samp{:} usually appears as
-part of absolute file names) or
-whitespace.  You may specify a directory that is already in the source
-path; this moves it forward, so @value{GDBN} searches it sooner.
-
-@kindex cdir
-@kindex cwd
-@vindex $cdir@r{, convenience variable}
-@vindex $cwd@r{, convenience variable}
-@cindex compilation directory
-@cindex current directory
-@cindex working directory
-@cindex directory, current
-@cindex directory, compilation
-You can use the string @samp{$cdir} to refer to the compilation
-directory (if one is recorded), and @samp{$cwd} to refer to the current
-working directory.  @samp{$cwd} is not the same as @samp{.}---the former
-tracks the current working directory as it changes during your @value{GDBN}
-session, while the latter is immediately expanded to the current
-directory at the time you add an entry to the source path.
-
-@item directory
-Reset the source path to its default value (@samp{$cdir:$cwd} on Unix systems).  This requires confirmation.
-
-@c RET-repeat for @code{directory} is explicitly disabled, but since
-@c repeating it would be a no-op we do not say that.  (thanks to RMS)
-
-@item set directories @var{path-list}
-@kindex set directories
-Set the source path to @var{path-list}.
-@samp{$cdir:$cwd} are added if missing.
-
-@item show directories
-@kindex show directories
-Print the source path: show which directories it contains.
-
-@anchor{set substitute-path}
-@item set substitute-path @var{from} @var{to}
-@kindex set substitute-path
-Define a source path substitution rule, and add it at the end of the
-current list of existing substitution rules.  If a rule with the same
-@var{from} was already defined, then the old rule is also deleted.
-
-For example, if the file @file{/foo/bar/baz.c} was moved to
-@file{/mnt/cross/baz.c}, then the command
-
-@smallexample
-(@value{GDBP}) set substitute-path /usr/src /mnt/cross
-@end smallexample
-
-@noindent
-will tell @value{GDBN} to replace @samp{/usr/src} with
-@samp{/mnt/cross}, which will allow @value{GDBN} to find the file
-@file{baz.c} even though it was moved.
-
-In the case when more than one substitution rule have been defined,
-the rules are evaluated one by one in the order where they have been
-defined.  The first one matching, if any, is selected to perform
-the substitution.
-
-For instance, if we had entered the following commands:
-
-@smallexample
-(@value{GDBP}) set substitute-path /usr/src/include /mnt/include
-(@value{GDBP}) set substitute-path /usr/src /mnt/src
-@end smallexample
-
-@noindent
-@value{GDBN} would then rewrite @file{/usr/src/include/defs.h} into
-@file{/mnt/include/defs.h} by using the first rule.  However, it would
-use the second rule to rewrite @file{/usr/src/lib/foo.c} into
-@file{/mnt/src/lib/foo.c}.
-
-
-@item unset substitute-path [path]
-@kindex unset substitute-path
-If a path is specified, search the current list of substitution rules
-for a rule that would rewrite that path.  Delete that rule if found.
-A warning is emitted by the debugger if no rule could be found.
-
-If no path is specified, then all substitution rules are deleted.
-
-@item show substitute-path [path]
-@kindex show substitute-path
-If a path is specified, then print the source path substitution rule
-which would rewrite that path, if any.
-
-If no path is specified, then print all existing source path substitution
-rules.
-
-@end table
-
-If your source path is cluttered with directories that are no longer of
-interest, @value{GDBN} may sometimes cause confusion by finding the wrong
-versions of source.  You can correct the situation as follows:
-
-@enumerate
-@item
-Use @code{directory} with no argument to reset the source path to its default value.
-
-@item
-Use @code{directory} with suitable arguments to reinstall the
-directories you want in the source path.  You can add all the
-directories in one command.
-@end enumerate
-
-@node Machine Code
-@section Source and Machine Code
-@cindex source line and its code address
-
-You can use the command @code{info line} to map source lines to program
-addresses (and vice versa), and the command @code{disassemble} to display
-a range of addresses as machine instructions.  You can use the command
-@code{set disassemble-next-line} to set whether to disassemble next
-source line when execution stops.  When run under @sc{gnu} Emacs
-mode, the @code{info line} command causes the arrow to point to the
-line specified.  Also, @code{info line} prints addresses in symbolic form as
-well as hex.
-
-@table @code
-@kindex info line
-@item info line @var{linespec}
-Print the starting and ending addresses of the compiled code for
-source line @var{linespec}.  You can specify source lines in any of
-the ways documented in @ref{Specify Location}.
-@end table
-
-For example, we can use @code{info line} to discover the location of
-the object code for the first line of function
-@code{m4_changequote}:
-
-@c FIXME: I think this example should also show the addresses in
-@c symbolic form, as they usually would be displayed.
-@smallexample
-(@value{GDBP}) info line m4_changequote
-Line 895 of "builtin.c" starts at pc 0x634c and ends at 0x6350.
-@end smallexample
-
-@noindent
-@cindex code address and its source line
-We can also inquire (using @code{*@var{addr}} as the form for
-@var{linespec}) what source line covers a particular address:
-@smallexample
-(@value{GDBP}) info line *0x63ff
-Line 926 of "builtin.c" starts at pc 0x63e4 and ends at 0x6404.
-@end smallexample
-
-@cindex @code{$_} and @code{info line}
-@cindex @code{x} command, default address
-@kindex x@r{(examine), and} info line
-After @code{info line}, the default address for the @code{x} command
-is changed to the starting address of the line, so that @samp{x/i} is
-sufficient to begin examining the machine code (@pxref{Memory,
-,Examining Memory}).  Also, this address is saved as the value of the
-convenience variable @code{$_} (@pxref{Convenience Vars, ,Convenience
-Variables}).
-
-@table @code
-@kindex disassemble
-@cindex assembly instructions
-@cindex instructions, assembly
-@cindex machine instructions
-@cindex listing machine instructions
-@item disassemble
-@itemx disassemble /m
-@itemx disassemble /r
-This specialized command dumps a range of memory as machine
-instructions.  It can also print mixed source+disassembly by specifying
-the @code{/m} modifier and print the raw instructions in hex as well as
-in symbolic form by specifying the @code{/r}.
-The default memory range is the function surrounding the
-program counter of the selected frame.  A single argument to this
-command is a program counter value; @value{GDBN} dumps the function
-surrounding this value.  When two arguments are given, they should
-be separated by a comma, possibly surrounded by whitespace.  The
-arguments specify a range of addresses to dump, in one of two forms:
-
-@table @code
-@item @var{start},@var{end}
-the addresses from @var{start} (inclusive) to @var{end} (exclusive)
-@item @var{start},+@var{length}
-the addresses from @var{start} (inclusive) to
-@code{@var{start}+@var{length}} (exclusive).
-@end table
-
-@noindent
-When 2 arguments are specified, the name of the function is also
-printed (since there could be several functions in the given range).
-
-The argument(s) can be any expression yielding a numeric value, such as
-@samp{0x32c4}, @samp{&main+10} or @samp{$pc - 8}.
-
-If the range of memory being disassembled contains current program counter,
-the instruction at that location is shown with a @code{=>} marker.
-@end table
-
-The following example shows the disassembly of a range of addresses of
-HP PA-RISC 2.0 code:
-
-@smallexample
-(@value{GDBP}) disas 0x32c4, 0x32e4
-Dump of assembler code from 0x32c4 to 0x32e4:
-   0x32c4 <main+204>:      addil 0,dp
-   0x32c8 <main+208>:      ldw 0x22c(sr0,r1),r26
-   0x32cc <main+212>:      ldil 0x3000,r31
-   0x32d0 <main+216>:      ble 0x3f8(sr4,r31)
-   0x32d4 <main+220>:      ldo 0(r31),rp
-   0x32d8 <main+224>:      addil -0x800,dp
-   0x32dc <main+228>:      ldo 0x588(r1),r26
-   0x32e0 <main+232>:      ldil 0x3000,r31
-End of assembler dump.
-@end smallexample
-
-Here is an example showing mixed source+assembly for Intel x86, when the
-program is stopped just after function prologue:
-
-@smallexample
-(@value{GDBP}) disas /m main
-Dump of assembler code for function main:
-5       @{
-   0x08048330 <+0>:    push   %ebp
-   0x08048331 <+1>:    mov    %esp,%ebp
-   0x08048333 <+3>:    sub    $0x8,%esp
-   0x08048336 <+6>:    and    $0xfffffff0,%esp
-   0x08048339 <+9>:    sub    $0x10,%esp
-
-6         printf ("Hello.\n");
-=> 0x0804833c <+12>:   movl   $0x8048440,(%esp)
-   0x08048343 <+19>:   call   0x8048284 <puts@@plt>
-
-7         return 0;
-8       @}
-   0x08048348 <+24>:   mov    $0x0,%eax
-   0x0804834d <+29>:   leave
-   0x0804834e <+30>:   ret
-
-End of assembler dump.
-@end smallexample
-
-Here is another example showing raw instructions in hex for AMD x86-64,
-
-@smallexample
-(gdb) disas /r 0x400281,+10
-Dump of assembler code from 0x400281 to 0x40028b:
-   0x0000000000400281:  38 36  cmp    %dh,(%rsi)
-   0x0000000000400283:  2d 36 34 2e 73 sub    $0x732e3436,%eax
-   0x0000000000400288:  6f     outsl  %ds:(%rsi),(%dx)
-   0x0000000000400289:  2e 32 00       xor    %cs:(%rax),%al
-End of assembler dump.
-@end smallexample
-
-Addresses cannot be specified as a linespec (@pxref{Specify Location}).
-So, for example, if you want to disassemble function @code{bar}
-in file @file{foo.c}, you must type @samp{disassemble 'foo.c'::bar}
-and not @samp{disassemble foo.c:bar}.
-
-Some architectures have more than one commonly-used set of instruction
-mnemonics or other syntax.
-
-For programs that were dynamically linked and use shared libraries,
-instructions that call functions or branch to locations in the shared
-libraries might show a seemingly bogus location---it's actually a
-location of the relocation table.  On some architectures, @value{GDBN}
-might be able to resolve these to actual function names.
-
-@table @code
-@kindex set disassembly-flavor
-@cindex Intel disassembly flavor
-@cindex AT&T disassembly flavor
-@item set disassembly-flavor @var{instruction-set}
-Select the instruction set to use when disassembling the
-program via the @code{disassemble} or @code{x/i} commands.
-
-Currently this command is only defined for the Intel x86 family.  You
-can set @var{instruction-set} to either @code{intel} or @code{att}.
-The default is @code{att}, the AT&T flavor used by default by Unix
-assemblers for x86-based targets.
-
-@kindex show disassembly-flavor
-@item show disassembly-flavor
-Show the current setting of the disassembly flavor.
-@end table
-
-@table @code
-@kindex set disassemble-next-line
-@kindex show disassemble-next-line
-@item set disassemble-next-line
-@itemx show disassemble-next-line
-Control whether or not @value{GDBN} will disassemble the next source
-line or instruction when execution stops.  If ON, @value{GDBN} will
-display disassembly of the next source line when execution of the
-program being debugged stops.  This is @emph{in addition} to
-displaying the source line itself, which @value{GDBN} always does if
-possible.  If the next source line cannot be displayed for some reason
-(e.g., if @value{GDBN} cannot find the source file, or there's no line
-info in the debug info), @value{GDBN} will display disassembly of the
-next @emph{instruction} instead of showing the next source line.  If
-AUTO, @value{GDBN} will display disassembly of next instruction only
-if the source line cannot be displayed.  This setting causes
-@value{GDBN} to display some feedback when you step through a function
-with no line info or whose source file is unavailable.  The default is
-OFF, which means never display the disassembly of the next line or
-instruction.
-@end table
-
-
-@node Data
-@chapter Examining Data
-
-@cindex printing data
-@cindex examining data
-@kindex print
-@kindex inspect
-The usual way to examine data in your program is with the @code{print}
-command (abbreviated @code{p}), or its synonym @code{inspect}.  It
-evaluates and prints the value of an expression of the language your
-program is written in (@pxref{Languages, ,Using @value{GDBN} with
-Different Languages}).  It may also print the expression using a
-Python-based pretty-printer (@pxref{Pretty Printing}).
-
-@table @code
-@item print @var{expr}
-@itemx print /@var{f} @var{expr}
-@var{expr} is an expression (in the source language).  By default the
-value of @var{expr} is printed in a format appropriate to its data type;
-you can choose a different format by specifying @samp{/@var{f}}, where
-@var{f} is a letter specifying the format; see @ref{Output Formats,,Output
-Formats}.
-
-@item print
-@itemx print /@var{f}
-@cindex reprint the last value
-If you omit @var{expr}, @value{GDBN} displays the last value again (from the
-@dfn{value history}; @pxref{Value History, ,Value History}).  This allows you to
-conveniently inspect the same value in an alternative format.
-@end table
-
-A more low-level way of examining data is with the @code{x} command.
-It examines data in memory at a specified address and prints it in a
-specified format.  @xref{Memory, ,Examining Memory}.
-
-If you are interested in information about types, or about how the
-fields of a struct or a class are declared, use the @code{ptype @var{exp}}
-command rather than @code{print}.  @xref{Symbols, ,Examining the Symbol
-Table}.
-
-@cindex exploring hierarchical data structures
-@kindex explore
-Another way of examining values of expressions and type information is
-through the Python extension command @code{explore} (available only if
-the @value{GDBN} build is configured with @code{--with-python}).  It
-offers an interactive way to start at the highest level (or, the most
-abstract level) of the data type of an expression (or, the data type
-itself) and explore all the way down to leaf scalar values/fields
-embedded in the higher level data types.
-
-@table @code
-@item explore @var{arg}
-@var{arg} is either an expression (in the source language), or a type
-visible in the current context of the program being debugged.
-@end table
-
-The working of the @code{explore} command can be illustrated with an
-example.  If a data type @code{struct ComplexStruct} is defined in your
-C program as
-
-@smallexample
-struct SimpleStruct
-@{
-  int i;
-  double d;
-@};
-
-struct ComplexStruct
-@{
-  struct SimpleStruct *ss_p;
-  int arr[10];
-@};
-@end smallexample
-
-@noindent
-followed by variable declarations as
-
-@smallexample
-struct SimpleStruct ss = @{ 10, 1.11 @};
-struct ComplexStruct cs = @{ &ss, @{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 @} @};
-@end smallexample
-
-@noindent
-then, the value of the variable @code{cs} can be explored using the
-@code{explore} command as follows.
-
-@smallexample
-(gdb) explore cs
-The value of `cs' is a struct/class of type `struct ComplexStruct' with
-the following fields:
-
-  ss_p = <Enter 0 to explore this field of type `struct SimpleStruct *'>
-   arr = <Enter 1 to explore this field of type `int [10]'>
-
-Enter the field number of choice:
-@end smallexample
-
-@noindent
-Since the fields of @code{cs} are not scalar values, you are being
-prompted to chose the field you want to explore.  Let's say you choose
-the field @code{ss_p} by entering @code{0}.  Then, since this field is a
-pointer, you will be asked if it is pointing to a single value.  From
-the declaration of @code{cs} above, it is indeed pointing to a single
-value, hence you enter @code{y}.  If you enter @code{n}, then you will
-be asked if it were pointing to an array of values, in which case this
-field will be explored as if it were an array.
-
-@smallexample
-`cs.ss_p' is a pointer to a value of type `struct SimpleStruct'
-Continue exploring it as a pointer to a single value [y/n]: y
-The value of `*(cs.ss_p)' is a struct/class of type `struct
-SimpleStruct' with the following fields:
-
-  i = 10 .. (Value of type `int')
-  d = 1.1100000000000001 .. (Value of type `double')
-
-Press enter to return to parent value:
-@end smallexample
-
-@noindent
-If the field @code{arr} of @code{cs} was chosen for exploration by
-entering @code{1} earlier, then since it is as array, you will be
-prompted to enter the index of the element in the array that you want
-to explore.
-
-@smallexample
-`cs.arr' is an array of `int'.
-Enter the index of the element you want to explore in `cs.arr': 5
-
-`(cs.arr)[5]' is a scalar value of type `int'.
-
-(cs.arr)[5] = 4
-
-Press enter to return to parent value: 
-@end smallexample
-
-In general, at any stage of exploration, you can go deeper towards the
-leaf values by responding to the prompts appropriately, or hit the
-return key to return to the enclosing data structure (the @i{higher}
-level data structure).
-
-Similar to exploring values, you can use the @code{explore} command to
-explore types.  Instead of specifying a value (which is typically a
-variable name or an expression valid in the current context of the
-program being debugged), you specify a type name.  If you consider the
-same example as above, your can explore the type
-@code{struct ComplexStruct} by passing the argument
-@code{struct ComplexStruct} to the @code{explore} command.
-
-@smallexample
-(gdb) explore struct ComplexStruct
-@end smallexample
-
-@noindent
-By responding to the prompts appropriately in the subsequent interactive
-session, you can explore the type @code{struct ComplexStruct} in a
-manner similar to how the value @code{cs} was explored in the above
-example.
-
-The @code{explore} command also has two sub-commands,
-@code{explore value} and @code{explore type}. The former sub-command is
-a way to explicitly specify that value exploration of the argument is
-being invoked, while the latter is a way to explicitly specify that type
-exploration of the argument is being invoked.
-
-@table @code
-@item explore value @var{expr}
-@cindex explore value
-This sub-command of @code{explore} explores the value of the
-expression @var{expr} (if @var{expr} is an expression valid in the
-current context of the program being debugged).  The behavior of this
-command is identical to that of the behavior of the @code{explore}
-command being passed the argument @var{expr}.
-
-@item explore type @var{arg}
-@cindex explore type
-This sub-command of @code{explore} explores the type of @var{arg} (if
-@var{arg} is a type visible in the current context of program being
-debugged), or the type of the value/expression @var{arg} (if @var{arg}
-is an expression valid in the current context of the program being
-debugged).  If @var{arg} is a type, then the behavior of this command is
-identical to that of the @code{explore} command being passed the
-argument @var{arg}.  If @var{arg} is an expression, then the behavior of
-this command will be identical to that of the @code{explore} command
-being passed the type of @var{arg} as the argument.
-@end table
-
-@menu
-* Expressions::                 Expressions
-* Ambiguous Expressions::       Ambiguous Expressions
-* Variables::                   Program variables
-* Arrays::                      Artificial arrays
-* Output Formats::              Output formats
-* Memory::                      Examining memory
-* Auto Display::                Automatic display
-* Print Settings::              Print settings
-* Pretty Printing::             Python pretty printing
-* Value History::               Value history
-* Convenience Vars::            Convenience variables
-* Convenience Funs::            Convenience functions
-* Registers::                   Registers
-* Floating Point Hardware::     Floating point hardware
-* Vector Unit::                 Vector Unit
-* OS Information::              Auxiliary data provided by operating system
-* Memory Region Attributes::    Memory region attributes
-* Dump/Restore Files::          Copy between memory and a file
-* Core File Generation::        Cause a program dump its core
-* Character Sets::              Debugging programs that use a different
-                                character set than GDB does
-* Caching Remote Data::         Data caching for remote targets
-* Searching Memory::            Searching memory for a sequence of bytes
-@end menu
-
-@node Expressions
-@section Expressions
-
-@cindex expressions
-@code{print} and many other @value{GDBN} commands accept an expression and
-compute its value.  Any kind of constant, variable or operator defined
-by the programming language you are using is valid in an expression in
-@value{GDBN}.  This includes conditional expressions, function calls,
-casts, and string constants.  It also includes preprocessor macros, if
-you compiled your program to include this information; see
-@ref{Compilation}.
-
-@cindex arrays in expressions
-@value{GDBN} supports array constants in expressions input by
-the user.  The syntax is @{@var{element}, @var{element}@dots{}@}.  For example,
-you can use the command @code{print @{1, 2, 3@}} to create an array
-of three integers.  If you pass an array to a function or assign it
-to a program variable, @value{GDBN} copies the array to memory that
-is @code{malloc}ed in the target program.
-
-Because C is so widespread, most of the expressions shown in examples in
-this manual are in C.  @xref{Languages, , Using @value{GDBN} with Different
-Languages}, for information on how to use expressions in other
-languages.
-
-In this section, we discuss operators that you can use in @value{GDBN}
-expressions regardless of your programming language.
-
-@cindex casts, in expressions
-Casts are supported in all languages, not just in C, because it is so
-useful to cast a number into a pointer in order to examine a structure
-at that address in memory.
-@c FIXME: casts supported---Mod2 true?
-
-@value{GDBN} supports these operators, in addition to those common
-to programming languages:
-
-@table @code
-@item @@
-@samp{@@} is a binary operator for treating parts of memory as arrays.
-@xref{Arrays, ,Artificial Arrays}, for more information.
-
-@item ::
-@samp{::} allows you to specify a variable in terms of the file or
-function where it is defined.  @xref{Variables, ,Program Variables}.
-
-@cindex @{@var{type}@}
-@cindex type casting memory
-@cindex memory, viewing as typed object
-@cindex casts, to view memory
-@item @{@var{type}@} @var{addr}
-Refers to an object of type @var{type} stored at address @var{addr} in
-memory.  @var{addr} may be any expression whose value is an integer or
-pointer (but parentheses are required around binary operators, just as in
-a cast).  This construct is allowed regardless of what kind of data is
-normally supposed to reside at @var{addr}.
-@end table
-
-@node Ambiguous Expressions
-@section Ambiguous Expressions
-@cindex ambiguous expressions
-
-Expressions can sometimes contain some ambiguous elements.  For instance,
-some programming languages (notably Ada, C@t{++} and Objective-C) permit
-a single function name to be defined several times, for application in
-different contexts.  This is called @dfn{overloading}.  Another example
-involving Ada is generics.  A @dfn{generic package} is similar to C@t{++}
-templates and is typically instantiated several times, resulting in
-the same function name being defined in different contexts.
-
-In some cases and depending on the language, it is possible to adjust
-the expression to remove the ambiguity.  For instance in C@t{++}, you
-can specify the signature of the function you want to break on, as in
-@kbd{break @var{function}(@var{types})}.  In Ada, using the fully
-qualified name of your function often makes the expression unambiguous
-as well.
-
-When an ambiguity that needs to be resolved is detected, the debugger
-has the capability to display a menu of numbered choices for each
-possibility, and then waits for the selection with the prompt @samp{>}.
-The first option is always @samp{[0] cancel}, and typing @kbd{0 @key{RET}}
-aborts the current command.  If the command in which the expression was
-used allows more than one choice to be selected, the next option in the
-menu is @samp{[1] all}, and typing @kbd{1 @key{RET}} selects all possible
-choices.
-
-For example, the following session excerpt shows an attempt to set a
-breakpoint at the overloaded symbol @code{String::after}.
-We choose three particular definitions of that function name:
-
-@c FIXME! This is likely to change to show arg type lists, at least
-@smallexample
-@group
-(@value{GDBP}) b String::after
-[0] cancel
-[1] all
-[2] file:String.cc; line number:867
-[3] file:String.cc; line number:860
-[4] file:String.cc; line number:875
-[5] file:String.cc; line number:853
-[6] file:String.cc; line number:846
-[7] file:String.cc; line number:735
-> 2 4 6
-Breakpoint 1 at 0xb26c: file String.cc, line 867.
-Breakpoint 2 at 0xb344: file String.cc, line 875.
-Breakpoint 3 at 0xafcc: file String.cc, line 846.
-Multiple breakpoints were set.
-Use the "delete" command to delete unwanted
- breakpoints.
-(@value{GDBP})
-@end group
-@end smallexample
-
-@table @code
-@kindex set multiple-symbols
-@item set multiple-symbols @var{mode}
-@cindex multiple-symbols menu
-
-This option allows you to adjust the debugger behavior when an expression
-is ambiguous.
-
-By default, @var{mode} is set to @code{all}.  If the command with which
-the expression is used allows more than one choice, then @value{GDBN}
-automatically selects all possible choices.  For instance, inserting
-a breakpoint on a function using an ambiguous name results in a breakpoint
-inserted on each possible match.  However, if a unique choice must be made,
-then @value{GDBN} uses the menu to help you disambiguate the expression.
-For instance, printing the address of an overloaded function will result
-in the use of the menu.
-
-When @var{mode} is set to @code{ask}, the debugger always uses the menu
-when an ambiguity is detected.
-
-Finally, when @var{mode} is set to @code{cancel}, the debugger reports
-an error due to the ambiguity and the command is aborted.
-
-@kindex show multiple-symbols
-@item show multiple-symbols
-Show the current value of the @code{multiple-symbols} setting.
-@end table
-
-@node Variables
-@section Program Variables
-
-The most common kind of expression to use is the name of a variable
-in your program.
-
-Variables in expressions are understood in the selected stack frame
-(@pxref{Selection, ,Selecting a Frame}); they must be either:
-
-@itemize @bullet
-@item
-global (or file-static)
-@end itemize
-
-@noindent or
-
-@itemize @bullet
-@item
-visible according to the scope rules of the
-programming language from the point of execution in that frame
-@end itemize
-
-@noindent This means that in the function
-
-@smallexample
-foo (a)
-     int a;
-@{
-  bar (a);
-  @{
-    int b = test ();
-    bar (b);
-  @}
-@}
-@end smallexample
-
-@noindent
-you can examine and use the variable @code{a} whenever your program is
-executing within the function @code{foo}, but you can only use or
-examine the variable @code{b} while your program is executing inside
-the block where @code{b} is declared.
-
-@cindex variable name conflict
-There is an exception: you can refer to a variable or function whose
-scope is a single source file even if the current execution point is not
-in this file.  But it is possible to have more than one such variable or
-function with the same name (in different source files).  If that
-happens, referring to that name has unpredictable effects.  If you wish,
-you can specify a static variable in a particular function or file by
-using the colon-colon (@code{::}) notation:
-
-@cindex colon-colon, context for variables/functions
-@ifnotinfo
-@c info cannot cope with a :: index entry, but why deprive hard copy readers?
-@cindex @code{::}, context for variables/functions
-@end ifnotinfo
-@smallexample
-@var{file}::@var{variable}
-@var{function}::@var{variable}
-@end smallexample
-
-@noindent
-Here @var{file} or @var{function} is the name of the context for the
-static @var{variable}.  In the case of file names, you can use quotes to
-make sure @value{GDBN} parses the file name as a single word---for example,
-to print a global value of @code{x} defined in @file{f2.c}:
-
-@smallexample
-(@value{GDBP}) p 'f2.c'::x
-@end smallexample
-
-The @code{::} notation is normally used for referring to
-static variables, since you typically disambiguate uses of local variables
-in functions by selecting the appropriate frame and using the
-simple name of the variable.  However, you may also use this notation
-to refer to local variables in frames enclosing the selected frame:
-
-@smallexample
-void
-foo (int a)
-@{
-  if (a < 10)
-    bar (a);
-  else
-    process (a);    /* Stop here */
-@}
-
-int
-bar (int a)
-@{
-  foo (a + 5);
-@}
-@end smallexample
-
-@noindent
-For example, if there is a breakpoint at the commented line,
-here is what you might see
-when the program stops after executing the call @code{bar(0)}:
-
-@smallexample
-(@value{GDBP}) p a
-$1 = 10
-(@value{GDBP}) p bar::a
-$2 = 5
-(@value{GDBP}) up 2
-#2  0x080483d0 in foo (a=5) at foobar.c:12
-(@value{GDBP}) p a
-$3 = 5
-(@value{GDBP}) p bar::a
-$4 = 0
-@end smallexample
-
-@cindex C@t{++} scope resolution
-These uses of @samp{::} are very rarely in conflict with the very similar
-use of the same notation in C@t{++}.  @value{GDBN} also supports use of the C@t{++}
-scope resolution operator in @value{GDBN} expressions.
-@c FIXME: Um, so what happens in one of those rare cases where it's in
-@c conflict??  --mew
-
-@cindex wrong values
-@cindex variable values, wrong
-@cindex function entry/exit, wrong values of variables
-@cindex optimized code, wrong values of variables
-@quotation
-@emph{Warning:} Occasionally, a local variable may appear to have the
-wrong value at certain points in a function---just after entry to a new
-scope, and just before exit.
-@end quotation
-You may see this problem when you are stepping by machine instructions.
-This is because, on most machines, it takes more than one instruction to
-set up a stack frame (including local variable definitions); if you are
-stepping by machine instructions, variables may appear to have the wrong
-values until the stack frame is completely built.  On exit, it usually
-also takes more than one machine instruction to destroy a stack frame;
-after you begin stepping through that group of instructions, local
-variable definitions may be gone.
-
-This may also happen when the compiler does significant optimizations.
-To be sure of always seeing accurate values, turn off all optimization
-when compiling.
-
-@cindex ``No symbol "foo" in current context''
-Another possible effect of compiler optimizations is to optimize
-unused variables out of existence, or assign variables to registers (as
-opposed to memory addresses).  Depending on the support for such cases
-offered by the debug info format used by the compiler, @value{GDBN}
-might not be able to display values for such local variables.  If that
-happens, @value{GDBN} will print a message like this:
-
-@smallexample
-No symbol "foo" in current context.
-@end smallexample
-
-To solve such problems, either recompile without optimizations, or use a
-different debug info format, if the compiler supports several such
-formats.  @xref{Compilation}, for more information on choosing compiler
-options.  @xref{C, ,C and C@t{++}}, for more information about debug
-info formats that are best suited to C@t{++} programs.
-
-If you ask to print an object whose contents are unknown to
-@value{GDBN}, e.g., because its data type is not completely specified
-by the debug information, @value{GDBN} will say @samp{<incomplete
-type>}.  @xref{Symbols, incomplete type}, for more about this.
-
-If you append @kbd{@@entry} string to a function parameter name you get its
-value at the time the function got called.  If the value is not available an
-error message is printed.  Entry values are available only with some compilers.
-Entry values are normally also printed at the function parameter list according
-to @ref{set print entry-values}.
-
-@smallexample
-Breakpoint 1, d (i=30) at gdb.base/entry-value.c:29
-29       i++;
-(gdb) next
-30       e (i);
-(gdb) print i
-$1 = 31
-(gdb) print i@@entry
-$2 = 30
-@end smallexample
-
-Strings are identified as arrays of @code{char} values without specified
-signedness.  Arrays of either @code{signed char} or @code{unsigned char} get
-printed as arrays of 1 byte sized integers.  @code{-fsigned-char} or
-@code{-funsigned-char} @value{NGCC} options have no effect as @value{GDBN}
-defines literal string type @code{"char"} as @code{char} without a sign.
-For program code
-
-@smallexample
-char var0[] = "A";
-signed char var1[] = "A";
-@end smallexample
-
-You get during debugging
-@smallexample
-(gdb) print var0
-$1 = "A"
-(gdb) print var1
-$2 = @{65 'A', 0 '\0'@}
-@end smallexample
-
-@node Arrays
-@section Artificial Arrays
-
-@cindex artificial array
-@cindex arrays
-@kindex @@@r{, referencing memory as an array}
-It is often useful to print out several successive objects of the
-same type in memory; a section of an array, or an array of
-dynamically determined size for which only a pointer exists in the
-program.
-
-You can do this by referring to a contiguous span of memory as an
-@dfn{artificial array}, using the binary operator @samp{@@}.  The left
-operand of @samp{@@} should be the first element of the desired array
-and be an individual object.  The right operand should be the desired length
-of the array.  The result is an array value whose elements are all of
-the type of the left argument.  The first element is actually the left
-argument; the second element comes from bytes of memory immediately
-following those that hold the first element, and so on.  Here is an
-example.  If a program says
-
-@smallexample
-int *array = (int *) malloc (len * sizeof (int));
-@end smallexample
-
-@noindent
-you can print the contents of @code{array} with
-
-@smallexample
-p *array@@len
-@end smallexample
-
-The left operand of @samp{@@} must reside in memory.  Array values made
-with @samp{@@} in this way behave just like other arrays in terms of
-subscripting, and are coerced to pointers when used in expressions.
-Artificial arrays most often appear in expressions via the value history
-(@pxref{Value History, ,Value History}), after printing one out.
-
-Another way to create an artificial array is to use a cast.
-This re-interprets a value as if it were an array.
-The value need not be in memory:
-@smallexample
-(@value{GDBP}) p/x (short[2])0x12345678
-$1 = @{0x1234, 0x5678@}
-@end smallexample
-
-As a convenience, if you leave the array length out (as in
-@samp{(@var{type}[])@var{value}}) @value{GDBN} calculates the size to fill
-the value (as @samp{sizeof(@var{value})/sizeof(@var{type})}:
-@smallexample
-(@value{GDBP}) p/x (short[])0x12345678
-$2 = @{0x1234, 0x5678@}
-@end smallexample
-
-Sometimes the artificial array mechanism is not quite enough; in
-moderately complex data structures, the elements of interest may not
-actually be adjacent---for example, if you are interested in the values
-of pointers in an array.  One useful work-around in this situation is
-to use a convenience variable (@pxref{Convenience Vars, ,Convenience
-Variables}) as a counter in an expression that prints the first
-interesting value, and then repeat that expression via @key{RET}.  For
-instance, suppose you have an array @code{dtab} of pointers to
-structures, and you are interested in the values of a field @code{fv}
-in each structure.  Here is an example of what you might type:
-
-@smallexample
-set $i = 0
-p dtab[$i++]->fv
-@key{RET}
-@key{RET}
-@dots{}
-@end smallexample
-
-@node Output Formats
-@section Output Formats
-
-@cindex formatted output
-@cindex output formats
-By default, @value{GDBN} prints a value according to its data type.  Sometimes
-this is not what you want.  For example, you might want to print a number
-in hex, or a pointer in decimal.  Or you might want to view data in memory
-at a certain address as a character string or as an instruction.  To do
-these things, specify an @dfn{output format} when you print a value.
-
-The simplest use of output formats is to say how to print a value
-already computed.  This is done by starting the arguments of the
-@code{print} command with a slash and a format letter.  The format
-letters supported are:
-
-@table @code
-@item x
-Regard the bits of the value as an integer, and print the integer in
-hexadecimal.
-
-@item d
-Print as integer in signed decimal.
-
-@item u
-Print as integer in unsigned decimal.
-
-@item o
-Print as integer in octal.
-
-@item t
-Print as integer in binary.  The letter @samp{t} stands for ``two''.
-@footnote{@samp{b} cannot be used because these format letters are also
-used with the @code{x} command, where @samp{b} stands for ``byte'';
-see @ref{Memory,,Examining Memory}.}
-
-@item a
-@cindex unknown address, locating
-@cindex locate address
-Print as an address, both absolute in hexadecimal and as an offset from
-the nearest preceding symbol.  You can use this format used to discover
-where (in what function) an unknown address is located:
-
-@smallexample
-(@value{GDBP}) p/a 0x54320
-$3 = 0x54320 <_initialize_vx+396>
-@end smallexample
-
-@noindent
-The command @code{info symbol 0x54320} yields similar results.
-@xref{Symbols, info symbol}.
-
-@item c
-Regard as an integer and print it as a character constant.  This
-prints both the numerical value and its character representation.  The
-character representation is replaced with the octal escape @samp{\nnn}
-for characters outside the 7-bit @sc{ascii} range.
-
-Without this format, @value{GDBN} displays @code{char},
-@w{@code{unsigned char}}, and @w{@code{signed char}} data as character
-constants.  Single-byte members of vectors are displayed as integer
-data.
-
-@item f
-Regard the bits of the value as a floating point number and print
-using typical floating point syntax.
-
-@item s
-@cindex printing strings
-@cindex printing byte arrays
-Regard as a string, if possible.  With this format, pointers to single-byte
-data are displayed as null-terminated strings and arrays of single-byte data
-are displayed as fixed-length strings.  Other values are displayed in their
-natural types.
-
-Without this format, @value{GDBN} displays pointers to and arrays of
-@code{char}, @w{@code{unsigned char}}, and @w{@code{signed char}} as
-strings.  Single-byte members of a vector are displayed as an integer
-array.
-
-@item r
-@cindex raw printing
-Print using the @samp{raw} formatting.  By default, @value{GDBN} will
-use a Python-based pretty-printer, if one is available (@pxref{Pretty
-Printing}).  This typically results in a higher-level display of the
-value's contents.  The @samp{r} format bypasses any Python
-pretty-printer which might exist.
-@end table
-
-For example, to print the program counter in hex (@pxref{Registers}), type
-
-@smallexample
-p/x $pc
-@end smallexample
-
-@noindent
-Note that no space is required before the slash; this is because command
-names in @value{GDBN} cannot contain a slash.
-
-To reprint the last value in the value history with a different format,
-you can use the @code{print} command with just a format and no
-expression.  For example, @samp{p/x} reprints the last value in hex.
-
-@node Memory
-@section Examining Memory
-
-You can use the command @code{x} (for ``examine'') to examine memory in
-any of several formats, independently of your program's data types.
-
-@cindex examining memory
-@table @code
-@kindex x @r{(examine memory)}
-@item x/@var{nfu} @var{addr}