gdb/

[deliverable/binutils-gdb.git] / gdb / doc / agentexpr.texi

diff --git a/gdb/doc/agentexpr.texi b/gdb/doc/agentexpr.texi
index 4b790f56af2e7be8f91a7b8412c076601d080642..1b893d5a7bbeb1504803d4a9f106ff51db961621 100644 (file)
--- a/gdb/doc/agentexpr.texi
+++ b/gdb/doc/agentexpr.texi
@@ -1,16 +1,23 @@
-\input texinfo
+@c \input texinfo
 @c %**start of header
-@setfilename agentexpr.info
-@settitle GDB Agent Expressions
-@setchapternewpage off
+@c @setfilename agentexpr.info
+@c @settitle GDB Agent Expressions
+@c @setchapternewpage off
 @c %**end of header
 
-Revision: $Id$
+@c This file is part of the GDB manual.
+@c
+@c Copyright (C) 2003, 2004, 2005, 2006
+@c               Free Software Foundation, Inc.
+@c
+@c See the file gdb.texinfo for copying conditions.
 
-@node The GDB Agent Expression Mechanism
-@chapter The GDB Agent Expression Mechanism
+@c Revision: $Id$
 
-In some applications, it is not feasable for the debugger to interrupt
+@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
@@ -214,7 +221,7 @@ their sum, as an integer.
 
 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
-hexidecimal.  The phrase ``@var{a} @var{b} @result{} @var{a+b}'' shows
+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
@@ -299,7 +306,7 @@ 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{} @var{@code{(signed)}a>>b}
+@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.
@@ -397,7 +404,7 @@ 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 signficant byte first, regardless of the target's normal
+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
@@ -431,7 +438,7 @@ 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
-signficant byte first, regardless of the target's normal endianness.
+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
@@ -798,7 +805,7 @@ When we add side-effects, we should add this.
 
 @item Why does the @code{reg} bytecode take a 16-bit register number?
 
-Intel's IA64-architecture, Merced, has 128 general-purpose registers,
+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.
 
@@ -835,5 +842,3 @@ opcode 0x30 reserved, to remain compatible with the customer who added
 it.
 
 @end table
-
-@bye