X-Git-Url: http://git.efficios.com/?a=blobdiff_plain;f=gdb%2Fdoc%2Fagentexpr.texi;h=c40259d1bac25e894e5bd90b85a5ad2208e4b1cc;hb=030f20e19e7c5d2d8d26030c83cc2387a9e04c1d;hp=4b790f56af2e7be8f91a7b8412c076601d080642;hpb=5b64ad42d36e6d487e1f7287d37fbc243a178e72;p=deliverable%2Fbinutils-gdb.git diff --git a/gdb/doc/agentexpr.texi b/gdb/doc/agentexpr.texi index 4b790f56af..c40259d1ba 100644 --- a/gdb/doc/agentexpr.texi +++ b/gdb/doc/agentexpr.texi @@ -1,14 +1,14 @@ -\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 Revision: $Id$ -@node The GDB Agent Expression Mechanism -@chapter The GDB Agent Expression Mechanism +@node Agent Expressions +@appendix The GDB Agent Expression Mechanism In some applications, it is not feasable for the debugger to interrupt the program's execution long enough for the developer to learn anything @@ -299,7 +299,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 +397,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 +431,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 +798,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 +835,3 @@ opcode 0x30 reserved, to remain compatible with the customer who added it. @end table - -@bye