HP 3000 Manuals HP 3000 Manuals
Limitations and Hints
* CNTRLY should be a trap that performs like the hardware traps.
That is, if the child process is running, it should be forced to
stop with control transferred to the debugger. This allows
infinite loops to be temporarily broken without aborting the
debugger. However, the MPE/iX operating system currently handles
CNTRLY as a special case and unless the child explicitly requests
its own handler, the CNTRLY trap will only be detected by the
debugger when it occurs during execution of the debugger's own
code.
* Do not modify any file while the debugger has it open. If you do,
the debugger gets confused and might display garbage.
* Some statements do not emit code where you would expect it. For
example, assume:
99: for (i=0; i<9; i++) {
100: xyz (i);
101: }
A breakpoint placed on line 99 will be hit only once in some
cases. The code for incrementing is placed at line 101. Each
compiler is a little different; you must get used to what your
particular compiler does. A good way of finding out is to use
single stepping to see in what order the source lines are
executed.
* Some compilers only issue source line symbols at the end of each
logical statement or physical line, whichever is greater. This
means that, if you are in the habit of saying a=0; b=1; on one
line, there is no way to put a breakpoint after the assignment to
a but before the assignment to b.
* The debugger does not support identically-named procedures, except
in HP Pascal if the procedures are in different scopes. The
debugger will always use the first procedure with the given name.
* There is no support for HP Pascal packed arrays where the element
size is not a whole number of bytes. Any reference into such an
array might produce garbage or a bad access.
* Assignments into objects greater than four bytes in size from
debugger special variables, result in errors or invalid results.
* The debugger supports call-by-reference only for known parameters
of known (debuggable) procedures. If the object to pass lives in
the child process, you can fake such a call by passing &object,
for example, the address of the object.
* Only the first number of a complex pair is passed as a parameter.
Functions which return complex numbers are not called correctly;
insufficient stack space is allocated for the return area, which
can lead to overwriting the parameter values.