5 Operational Considerations

This chapter discusses special operational considerations. This information can help you use the pROBE+ debugger more effectively.

Daemon timing information is available from Integrated Systems.

5.1 Manual Breaks

The pROBE+ debugger supports two types of manually induced breakpoints:

A console-induced manual break occurs when the pROBE+ debugger calls the user-supplied td_drv procedure and that procedure indicates that it has detected a break condition. This condition is user-defined and is typically an RS-232 break or a control key.

An interrupt-induced manual break occurs when either an interrupt handler or an exception handler calls the manual break entry (see Section 4.5, ``pROBE+ Entry Points"). Normally, you would load an interrupt vector with this entry address, so when an interrupt occurs, the pROBE+ debugger receives control.

An interrupt-induced, manual break forces the pROBE+ debugger to take control unless execution is at a higher interrupt mask level. A console-induced break depends on polling by the pROBE+ debugger, which in turn depends on callouts from the pSOS+ kernel. If an application is stuck in a path that does not make pSOS+ system calls, or no interrupts occur, console-induced breaks are not effective. Similarly, when the pROBE+ debugger is running in standalone mode without the pSOS+ kernel or query services, this break is inoperable.

5.2 Bus Errors

As noted in Section 4.5, ``pROBE+ Entry Points," all Address Error, Bus Error and TLB Exception vectors should be set to point to the Fault entry. After any of these exceptions, the pROBE+ debugger reports the error by showing the address that caused the error by showing the address that caused the error along with the register display.

Example: 

Bus Error                                          Running:  ***  NO pSOS  *** 
------------------------------------------------------------------------------
R0/ZERO=00000000 R1/AT  =00000000 R2/V0  =81002345 R3/V1  =00000000
R4/A0  =81002345 R5/A1  =00000000 R6/A2  =00000000 R7/A3  =00000000
R8/T0  =00000000 R9/T1  =00000000 R10/T2 =00000000 R11/T3 =00000000
R12/T4 =00000000 R13/T5 =00000000 R14/T6 =00000000 R15/T7 =00000000
R16/S0 =00000000 R17/S1 =00000000 R18/S2 =00000000 R19/S3 =00000000
R20/S4 =00000000 R21/S5 =00000000 R22/S6 =00000000 R23/S7 =00000000
R24/T8 =00000000 R25/T9 =00000000 R26/K0 =8004FBA0 R27/K1 =DEADDEAD
R28/GP =800526A0 R29/SP =80051380 R30/FP =00000000 R31/RA =00000000
MDHI   =00000000 MDLO   =00000000 SR     =20000000
IP     =800200A8:90580000  lbu  t8,00000000(v0)

5.3 Other Exception Errors

You can optionally set all the other exception vectors, including unused interrupt vectors, to point to the pROBE+ reserved entry point. On such an exception, for example, the pROBE+ debugger displays something similar to the following:

Example:

You can use the reserved exception entry, rsrv_entry, in any vector table entries that the application or processor does not support. By using rsrv_entry, the state of the processor is saved, and the exception is reported.

5.4 Fatal Errors

A pSOS+ application can halt with a fatal error if any of the following occurs:

If you have not provided a fatal error handler through the pSOS+ Configuration Table entry kc_fatal, the pSOS+ kernel passes control to the pROBE+ fatal error handler.

When the pROBE+ debugger reports a fatal error, flags contains the fatal-error code. If the error was generated internally by the pSOS+ kernel, flags contains one of the fatal error codes, as documented in the pSOSystem Programmer's Reference. Otherwise, it contains a user-defined error code. In multiprocessor systems, node indicates where the fatal error originated, as follows:

node = 0              This means the fatal error originated on the local node, either from the pSOS+ kernel directly, or from a                                  k_fatal call with the GLOBAL flag clear.

node nonzero       The fatal error came from a k_fatal call with the GLO-
 (multiproces-       BAL flag set, either on the local node or a remote node.
sor systems)         In this case, node refers to the node where the k_fatal originated.

Example: 

pSOS Fatal Error       - User Errors: err_code = DEADBABE  flags = 00000000
------------------------------------------------------------------------------
R0/ZERO=00000000 R1/AT  =80028BD8 R2/V0  =00000000 R3/V1  =00000000
R4/A0  =DEADBABE R5/A1  =00000000 R6/A2  =00000000 R7/A3  =00000000
R8/T0  =00000000 R9/T1  =801FED10 R10/T2 =00000000 R11/T3 =00000000
R12/T4 =801FED10 R13/T5 =00000000 R14/T6 =00000020 R15/T7 =0000FF04
R16/S0 =801FEDA0 R17/S1 =801FED9C R18/S2 =00000000 R19/S3 =00000000
R20/S4 =00000000 R21/S5 =00000000 R22/S6 =00000000 R23/S7 =00000000
R24/T8 =80022B70 R25/T9 =801FED40 R26/K0 =8004FBC0 R27/K1 =DEADDEAD
R28/GP =800526C0 R29/SP =801FED50 R30/FP =00000000 R31/RA =80022C88
MDHI   =801FED20 MDLO   =801FED50 SR     =0000FF01
IP     =80028C44:8FBF0004  lw   ra,00000004(sp)

5.5 pROBE+ Daemons

pROBE+ daemons are short pROBE+ routines called by the pSOS+ kernel at specific points within the kernel. Daemons do the following:

Although physically part of the pROBE+ debugger, the pROBE+ daemons are logical extensions of the kernel and therefore may slightly affect the application because pROBE+ daemons "steal" a small amount of CPU time from an application. Although daemon CPU usage is minimal, if you have a particularly time-critical application, you can do several things to further reduce these considerations, as follows:

Daemon timing information is available from Integrated Systems, Inc.

If no system, dispatch, or timed breaks are set and profiling and console-induced manual break detection is disabled, the pROBE+ debugger causes no intrusion whatsoever. This means the timing of an application is the same with or without the presence of the pROBE+ debugger.



psos_support@isi.com

Copyright © 1996, Integrated Systems, Inc. All rights reserved.