+@c OBSOLETE
+@c OBSOLETE @node Convex,,, Top
+@c OBSOLETE @appendix Convex-specific info
+@c OBSOLETE @cindex Convex notes
+@c OBSOLETE
+@c OBSOLETE Scalar registers are 64 bits long, which is a pain since
+@c OBSOLETE left half of an S register frequently contains noise.
+@c OBSOLETE Therefore there are two ways to obtain the value of an S register.
+@c OBSOLETE
+@c OBSOLETE @table @kbd
+@c OBSOLETE @item $s0
+@c OBSOLETE returns the low half of the register as an int
+@c OBSOLETE
+@c OBSOLETE @item $S0
+@c OBSOLETE returns the whole register as a long long
+@c OBSOLETE @end table
+@c OBSOLETE
+@c OBSOLETE You can print the value in floating point by using @samp{p/f $s0} or @samp{p/f $S0}
+@c OBSOLETE to print a single or double precision value.
+@c OBSOLETE
+@c OBSOLETE @cindex vector registers
+@c OBSOLETE Vector registers are handled similarly, with @samp{$V0} denoting the whole
+@c OBSOLETE 64-bit register and @kbd{$v0} denoting the 32-bit low half; @samp{p/f $v0}
+@c OBSOLETE or @samp{p/f $V0} can be used to examine the register in floating point.
+@c OBSOLETE The length of the vector registers is taken from @samp{$vl}.
+@c OBSOLETE
+@c OBSOLETE Individual elements of a vector register are denoted in the obvious way;
+@c OBSOLETE @samp{print $v3[9]} prints the tenth element of register @kbd{v3}, and
+@c OBSOLETE @samp{set $v3[9] = 1234} alters it.
+@c OBSOLETE
+@c OBSOLETE @kbd{$vl} and @kbd{$vs} are int, and @kbd{$vm} is an int vector.
+@c OBSOLETE Elements of @kbd{$vm} can't be assigned to.
+@c OBSOLETE
+@c OBSOLETE @cindex communication registers
+@c OBSOLETE @kindex info comm-registers
+@c OBSOLETE Communication registers have names @kbd{$C0 .. $C63}, with @kbd{$c0 .. $c63}
+@c OBSOLETE denoting the low-order halves. @samp{info comm-registers} will print them
+@c OBSOLETE all out, and tell which are locked. (A communication register is
+@c OBSOLETE locked when a value is sent to it, and unlocked when the value is
+@c OBSOLETE received.) Communication registers are, of course, global to all
+@c OBSOLETE threads, so it does not matter what the currently selected thread is.
+@c OBSOLETE @samp{info comm-reg @var{name}} prints just that one communication
+@c OBSOLETE register; @samp{name} may also be a communication register number
+@c OBSOLETE @samp{nn} or @samp{0xnn}.
+@c OBSOLETE @samp{info comm-reg @var{address}} prints the contents of the resource
+@c OBSOLETE structure at that address.
+@c OBSOLETE
+@c OBSOLETE @kindex info psw
+@c OBSOLETE The command @samp{info psw} prints the processor status word @kbd{$ps}
+@c OBSOLETE bit by bit.
+@c OBSOLETE
+@c OBSOLETE @kindex set base
+@c OBSOLETE GDB normally prints all integers in base 10, but the leading
+@c OBSOLETE @kbd{0x80000000} of pointers is intolerable in decimal, so the default
+@c OBSOLETE output radix has been changed to try to print addresses appropriately.
+@c OBSOLETE The @samp{set base} command can be used to change this.
+@c OBSOLETE
+@c OBSOLETE @table @code
+@c OBSOLETE @item set base 10
+@c OBSOLETE Integer values always print in decimal.
+@c OBSOLETE
+@c OBSOLETE @item set base 16
+@c OBSOLETE Integer values always print in hex.
+@c OBSOLETE
+@c OBSOLETE @item set base
+@c OBSOLETE Go back to the initial state, which prints integer values in hex if they
+@c OBSOLETE look like pointers (specifically, if they start with 0x8 or 0xf in the
+@c OBSOLETE stack), otherwise in decimal.
+@c OBSOLETE @end table
+@c OBSOLETE
+@c OBSOLETE @kindex set pipeline
+@c OBSOLETE When an exception such as a bus error or overflow happens, usually the PC
+@c OBSOLETE is several instructions ahead by the time the exception is detected.
+@c OBSOLETE The @samp{set pipe} command will disable this.
+@c OBSOLETE
+@c OBSOLETE @table @code
+@c OBSOLETE @item set pipeline off
+@c OBSOLETE Forces serial execution of instructions; no vector chaining and no
+@c OBSOLETE scalar instruction overlap. With this, exceptions are detected with
+@c OBSOLETE the PC pointing to the instruction after the one in error.
+@c OBSOLETE
+@c OBSOLETE @item set pipeline on
+@c OBSOLETE Returns to normal, fast, execution. This is the default.
+@c OBSOLETE @end table
+@c OBSOLETE
+@c OBSOLETE @cindex parallel
+@c OBSOLETE In a parallel program, multiple threads may be executing, each
+@c OBSOLETE with its own registers, stack, and local memory. When one of them
+@c OBSOLETE hits a breakpoint, that thread is selected. Other threads do
+@c OBSOLETE not run while the thread is in the breakpoint.
+@c OBSOLETE
+@c OBSOLETE @kindex 1cont
+@c OBSOLETE The selected thread can be single-stepped, given signals, and so
+@c OBSOLETE on. Any other threads remain stopped. When a @samp{cont} command is given,
+@c OBSOLETE all threads are resumed. To resume just the selected thread, use
+@c OBSOLETE the command @samp{1cont}.
+@c OBSOLETE
+@c OBSOLETE @kindex thread
+@c OBSOLETE The @samp{thread} command will show the active threads and the
+@c OBSOLETE instruction they are about to execute. The selected thread is marked
+@c OBSOLETE with an asterisk. The command @samp{thread @var{n}} will select thread @var{n},
+@c OBSOLETE shifting the debugger's attention to it for single-stepping,
+@c OBSOLETE registers, local memory, and so on.
+@c OBSOLETE
+@c OBSOLETE @kindex info threads
+@c OBSOLETE The @samp{info threads} command will show what threads, if any, have
+@c OBSOLETE invisibly hit breakpoints or signals and are waiting to be noticed.
+@c OBSOLETE
+@c OBSOLETE @kindex set parallel
+@c OBSOLETE The @samp{set parallel} command controls how many threads can be active.
+@c OBSOLETE
+@c OBSOLETE @table @code
+@c OBSOLETE @item set parallel off
+@c OBSOLETE One thread. Requests by the program that other threads join in
+@c OBSOLETE (spawn and pfork instructions) do not cause other threads to start up.
+@c OBSOLETE This does the same thing as the @samp{limit concurrency 1} command.
+@c OBSOLETE
+@c OBSOLETE @item set parallel fixed
+@c OBSOLETE All CPUs are assigned to your program whenever it runs. When it
+@c OBSOLETE executes a pfork or spawn instruction, it begins parallel execution
+@c OBSOLETE immediately. This does the same thing as the @samp{mpa -f} command.
+@c OBSOLETE
+@c OBSOLETE @item set parallel on
+@c OBSOLETE One or more threads. Spawn and pfork cause CPUs to join in when and if
+@c OBSOLETE they are free. This is the default. It is very good for system
+@c OBSOLETE throughput, but not very good for finding bugs in parallel code. If you
+@c OBSOLETE suspect a bug in parallel code, you probably want @samp{set parallel fixed.}
+@c OBSOLETE @end table
+@c OBSOLETE
+@c OBSOLETE @subsection Limitations
+@c OBSOLETE
+@c OBSOLETE WARNING: Convex GDB evaluates expressions in long long, because S
+@c OBSOLETE registers are 64 bits long. However, GDB expression semantics are not
+@c OBSOLETE exactly C semantics. This is a bug, strictly speaking, but it's not one I
+@c OBSOLETE know how to fix. If @samp{x} is a program variable of type int, then it
+@c OBSOLETE is also type int to GDB, but @samp{x + 1} is long long, as is @samp{x + y}
+@c OBSOLETE or any other expression requiring computation. So is the expression
+@c OBSOLETE @samp{1}, or any other constant. You only really have to watch out for
+@c OBSOLETE calls. The innocuous expression @samp{list_node (0x80001234)} has an
+@c OBSOLETE argument of type long long. You must explicitly cast it to int.
+@c OBSOLETE
+@c OBSOLETE It is not possible to continue after an uncaught fatal signal by using
+@c OBSOLETE @samp{signal 0}, @samp{return}, @samp{jump}, or anything else. The difficulty is with
+@c OBSOLETE Unix, not GDB.
+@c OBSOLETE
+@c OBSOLETE I have made no big effort to make such things as single-stepping a
+@c OBSOLETE @kbd{join} instruction do something reasonable. If the program seems to
+@c OBSOLETE hang when doing this, type @kbd{ctrl-c} and @samp{cont}, or use
+@c OBSOLETE @samp{thread} to shift to a live thread. Single-stepping a @kbd{spawn}
+@c OBSOLETE instruction apparently causes new threads to be born with their T bit set;
+@c OBSOLETE this is not handled gracefully. When a thread has hit a breakpoint, other
+@c OBSOLETE threads may have invisibly hit the breakpoint in the background; if you
+@c OBSOLETE clear the breakpoint gdb will be surprised when threads seem to continue
+@c OBSOLETE to stop at it. All of these situations produce spurious signal 5 traps;
+@c OBSOLETE if this happens, just type @samp{cont}. If it becomes a nuisance, use
+@c OBSOLETE @samp{handle 5 nostop}. (It will ask if you are sure. You are.)
+@c OBSOLETE
+@c OBSOLETE There is no way in GDB to store a float in a register, as with
+@c OBSOLETE @kbd{set $s0 = 3.1416}. The identifier @kbd{$s0} denotes an integer,
+@c OBSOLETE and like any C expression which assigns to an integer variable, the
+@c OBSOLETE right-hand side is casted to type int. If you should need to do
+@c OBSOLETE something like this, you can assign the value to @kbd{@{float@} ($sp-4)}
+@c OBSOLETE and then do @kbd{set $s0 = $sp[-4]}. Same deal with @kbd{set $v0[69] = 6.9}.
-@node Convex,,, Top
-@appendix Convex-specific info
-@cindex Convex notes
-
-Scalar registers are 64 bits long, which is a pain since
-left half of an S register frequently contains noise.
-Therefore there are two ways to obtain the value of an S register.
-
-@table @kbd
-@item $s0
-returns the low half of the register as an int
-
-@item $S0
-returns the whole register as a long long
-@end table
-
-You can print the value in floating point by using @samp{p/f $s0} or @samp{p/f $S0}
-to print a single or double precision value.
-
-@cindex vector registers
-Vector registers are handled similarly, with @samp{$V0} denoting the whole
-64-bit register and @kbd{$v0} denoting the 32-bit low half; @samp{p/f $v0}
-or @samp{p/f $V0} can be used to examine the register in floating point.
-The length of the vector registers is taken from @samp{$vl}.
-
-Individual elements of a vector register are denoted in the obvious way;
-@samp{print $v3[9]} prints the tenth element of register @kbd{v3}, and
-@samp{set $v3[9] = 1234} alters it.
-
-@kbd{$vl} and @kbd{$vs} are int, and @kbd{$vm} is an int vector.
-Elements of @kbd{$vm} can't be assigned to.
-
-@cindex communication registers
-@kindex info comm-registers
-Communication registers have names @kbd{$C0 .. $C63}, with @kbd{$c0 .. $c63}
-denoting the low-order halves. @samp{info comm-registers} will print them
-all out, and tell which are locked. (A communication register is
-locked when a value is sent to it, and unlocked when the value is
-received.) Communication registers are, of course, global to all
-threads, so it does not matter what the currently selected thread is.
-@samp{info comm-reg @var{name}} prints just that one communication
-register; @samp{name} may also be a communication register number
-@samp{nn} or @samp{0xnn}.
-@samp{info comm-reg @var{address}} prints the contents of the resource
-structure at that address.
-
-@kindex info psw
-The command @samp{info psw} prints the processor status word @kbd{$ps}
-bit by bit.
-
-@kindex set base
-GDB normally prints all integers in base 10, but the leading
-@kbd{0x80000000} of pointers is intolerable in decimal, so the default
-output radix has been changed to try to print addresses appropriately.
-The @samp{set base} command can be used to change this.
-
-@table @code
-@item set base 10
-Integer values always print in decimal.
-
-@item set base 16
-Integer values always print in hex.
-
-@item set base
-Go back to the initial state, which prints integer values in hex if they
-look like pointers (specifically, if they start with 0x8 or 0xf in the
-stack), otherwise in decimal.
-@end table
-
-@kindex set pipeline
-When an exception such as a bus error or overflow happens, usually the PC
-is several instructions ahead by the time the exception is detected.
-The @samp{set pipe} command will disable this.
-
-@table @code
-@item set pipeline off
-Forces serial execution of instructions; no vector chaining and no
-scalar instruction overlap. With this, exceptions are detected with
-the PC pointing to the instruction after the one in error.
-
-@item set pipeline on
-Returns to normal, fast, execution. This is the default.
-@end table
-
-@cindex parallel
-In a parallel program, multiple threads may be executing, each
-with its own registers, stack, and local memory. When one of them
-hits a breakpoint, that thread is selected. Other threads do
-not run while the thread is in the breakpoint.
-
-@kindex 1cont
-The selected thread can be single-stepped, given signals, and so
-on. Any other threads remain stopped. When a @samp{cont} command is given,
-all threads are resumed. To resume just the selected thread, use
-the command @samp{1cont}.
-
-@kindex thread
-The @samp{thread} command will show the active threads and the
-instruction they are about to execute. The selected thread is marked
-with an asterisk. The command @samp{thread @var{n}} will select thread @var{n},
-shifting the debugger's attention to it for single-stepping,
-registers, local memory, and so on.
-
-@kindex info threads
-The @samp{info threads} command will show what threads, if any, have
-invisibly hit breakpoints or signals and are waiting to be noticed.
-
-@kindex set parallel
-The @samp{set parallel} command controls how many threads can be active.
-
-@table @code
-@item set parallel off
-One thread. Requests by the program that other threads join in
-(spawn and pfork instructions) do not cause other threads to start up.
-This does the same thing as the @samp{limit concurrency 1} command.
-
-@item set parallel fixed
-All CPUs are assigned to your program whenever it runs. When it
-executes a pfork or spawn instruction, it begins parallel execution
-immediately. This does the same thing as the @samp{mpa -f} command.
-
-@item set parallel on
-One or more threads. Spawn and pfork cause CPUs to join in when and if
-they are free. This is the default. It is very good for system
-throughput, but not very good for finding bugs in parallel code. If you
-suspect a bug in parallel code, you probably want @samp{set parallel fixed.}
-@end table
-
-@subsection Limitations
-
-WARNING: Convex GDB evaluates expressions in long long, because S
-registers are 64 bits long. However, GDB expression semantics are not
-exactly C semantics. This is a bug, strictly speaking, but it's not one I
-know how to fix. If @samp{x} is a program variable of type int, then it
-is also type int to GDB, but @samp{x + 1} is long long, as is @samp{x + y}
-or any other expression requiring computation. So is the expression
-@samp{1}, or any other constant. You only really have to watch out for
-calls. The innocuous expression @samp{list_node (0x80001234)} has an
-argument of type long long. You must explicitly cast it to int.
-
-It is not possible to continue after an uncaught fatal signal by using
-@samp{signal 0}, @samp{return}, @samp{jump}, or anything else. The difficulty is with
-Unix, not GDB.
-
-I have made no big effort to make such things as single-stepping a
-@kbd{join} instruction do something reasonable. If the program seems to
-hang when doing this, type @kbd{ctrl-c} and @samp{cont}, or use
-@samp{thread} to shift to a live thread. Single-stepping a @kbd{spawn}
-instruction apparently causes new threads to be born with their T bit set;
-this is not handled gracefully. When a thread has hit a breakpoint, other
-threads may have invisibly hit the breakpoint in the background; if you
-clear the breakpoint gdb will be surprised when threads seem to continue
-to stop at it. All of these situations produce spurious signal 5 traps;
-if this happens, just type @samp{cont}. If it becomes a nuisance, use
-@samp{handle 5 nostop}. (It will ask if you are sure. You are.)
-
-There is no way in GDB to store a float in a register, as with
-@kbd{set $s0 = 3.1416}. The identifier @kbd{$s0} denotes an integer,
-and like any C expression which assigns to an integer variable, the
-right-hand side is casted to type int. If you should need to do
-something like this, you can assign the value to @kbd{@{float@} ($sp-4)}
-and then do @kbd{set $s0 = $sp[-4]}. Same deal with @kbd{set $v0[69] = 6.9}.
projects / deliverable / binutils-gdb.git / blobdiff