164 lines
6.8 KiB
Plaintext
164 lines
6.8 KiB
Plaintext
|
|
@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}.
|