This chapter provides a hands-on tutorial on the use of the SpOTLIGHT debugger. This tutorial illustrates how the debugger can be used to control and monitor a pSOS+ multitasking application. NOTE: You should complete the pSOSystem Tutorial for PCs in Chapter 3 before you complete this tutorial.
The SpOTLIGHT debugger is part of the pRISM Integrated Development Environment. The debugger has the following features:
For additional information about the pRISM Integrated Development Environment (IDE), see the pRISM Integrated Development Environment User's Guide.
The apps directory in the pSOSystem software has a subdirectory named sldemo, with sample application files demo.c and data.c. This tutorial uses these files for the sample demo application.
The demo application is a C program that contains code for 9 tasks. The ROOT task automatically receives control from the pSOS+ kernel after startup, creates the other 8 tasks, and then deletes itself. The 8 other tasks function as follows:
NOTE: The `IO1¯ ' and `IO2¯ ' tasks consist of 4-character names where the fourth character is a required space. Similarly, the `SS ¯ ¯ ' queue name includes two required spaces; the breve symbol (¯ ) indicates a required space.
Before you begin this tutorial, you should create your own copy of the SpOTLIGHT debugger demo application. To do this, go to the pRISM command line interpreter, as described in Chapter 3, ``pSOSystem Tutorial for PCs," and enter the following commands:
mkdir c:/workdir
cd c:/workdir
cp /pss/apps/sldemo/* .
where workdir is the name of a working directory and pss is the directory where pSOSystem is loaded.
This new directory contains the following files:
README drv_conf.c sys_conf.h
default.bld data.c demo.c
demo.h userapp.bld
Some of these files have the same names as the hello application files. You need to modify the default.bld file to specify the BSP you plan to use. If you completed this step for the hello application in Section 3.2, you need to use a text editor again to modify the default.bld in your new working directory by replacing PSS_BSP in the :target line:
:target=PSS_BSP/psosmips.bld
with the full path name of the BSP you plan to use for PSS_BSP. For example, if the board is an IDT 79S465 and the pSOSystem root directory is /usr/psosmips, you change the line to:
:target=/usr/psosmips/bsps/idt79465/psosmips.bld
This tutorial requires pSOS+ or pSOS+m, pROBE+, and the pROBE+ RBUG module in the application. The sys_conf.h file is set up to include the pSOS+ kernel and the pROBE+ debugger. If you are using pSOS+m and not pSOS+, you need to modify the following lines in the sys_conf.h. file:
#define SC_PSOS YES #define SC_PSOSM NO
To show YES for the pSOS+m kernel parameter, SC_PSOSM, and NO for the pSOS+ kernel parameter, SC_PSOS.
To include the pROBE+ RBUG module in pSOSystem, set the SC_PROBE_DEBUG parameter to YES as follows:
#define SC_PROBE_DEBUG YES
If you plan to connect the SpOTLIGHT debugger and the target across an Ethernet network using User Datagram Protocol (UDP), then include the pNA+ network manager in your application. To do this, modify sys_conf.h so that the SC_PNA parameter is set to YES:
#define SC_PNA YES
You are now ready to build the executable. In Chapter 3, ``pSOSystem Tutorial for PCs," you used the pRISM Builder window to build the application. This tutorial illustrates an alternate way of using the Build Utility. In the pRISM command-line interpreter, enter the following command:
build default.bld ram.bld
This command causes the Build Utility to build your application. It is similar to clicking the builder button in the main pRISM window as described in Section 3, ``pSOSystem Tutorial for PCs." After entering the build command, the Build Utility displays messages as each module is analyzed and compiled. The final message Done should appear to indicate that the executable has finished building.
The executable image contains the SpOTLIGHT demo application and the pSOSystem software for the selected hardware.
After the build completes, verify that it created the following files:
If you encounter an error message during the build process, check to see if you performed the work directory setup and build tasks correctly. If you cannot resolve the problem, contact Integrated Systems Technical Support.
The examples in this chapter use the pSOSystem Boot ROMs, although the pSOSystem environment itself does not require them. This tutorial requires the Boot ROMs to set up the pROBE+ debugger to operate in one of the following modes:
Refer to Section 3.7.5, ``Reconfiguring the ROMs for a Serial Channel," and Section 3.8.6, ``Reconfiguring the ROMs for Ethernet," for information on how to set up your Boot ROMs for these modes.
If you are planning to use an Ethernet connection between the SpOTLIGHT and pROBE+ debuggers, you must install a TCP/IP networking package on your PC or verify that your PC already has one of the supported TCP/IP networking packages installed. Integrated Systems supports the following versions of TCP/IP:
All of these TCP/IP packages contain a WINSOCK.DLL file. For additional information on setting up your host, see the SpOTLIGHT Debug Server User's Manual.
The examples in this chapter may differ slightly from what you see when you run the tutorial. Differences occur for the following reasons:
The System Debug Mode is the default mode in the SpOTLIGHT Debugger. In this mode you debug the entire application.
To invoke the SpOTLIGHT debugger with the executable file ram.elf, enter the following command in the command line interpreter:
multi ram.elf &
The Main Debugger Window appears. You can now connect to the debug server using the remote spotlight command.
In the debugger window, enter the following command if you are connecting to the target with an Ethernet connection:
remote spotlight -c u[target]
where the -c option indicates a communication channel, the u is for UDP, and target is either the host name of your target or its IP address.
If you are connecting to the target with a serial connection, enter the following command:
remote spotlight -c s[device]
where the s is for serial and device is the name of the serial port you are using.
If communication to the target is established successfully, three additional windows appear: the Task Roster Window, the In/Out Window, and the Target Window. These windows are described later.
The Main Debugger Window title bar changes to indicate Global: (as shown in Figure 5-1 on page 5-8). The Global Window displays the context of the current task. The Global Window and its counterpart, the Task Window, are described later in this tutorial.
The next three steps are similar to the ones you followed during the pSOSystem Tutorial for PCs. For a more complete description of these steps, refer to Section 3.7.7, Section 3.7.8, and Section 3.7.9.
The Task Roster Window, shown in Figure 5-2, displays a complete list of tasks. The display includes each task's ID, name, entry address (if known), status, and priority. This window is updated after every command execution has completed. The window should currently show the following tasks: IDLE, ROOT, pMNG, pINP, pOUT, pROC, and PNAD. IDLE and ROOT are automatically created by the pSOS+ kernel. pMNG, pINP, pOUT, and pROC are created by the pROBE+ debugger. PNAD is created by the pNA+ network manager. If you are using a serial channel for communication, you don't have this task.
To see the Task Roster Window being updated, set an instruction breakpoint at the first call to t_create in the ROOT task. You may need to scroll the source subwindow to see the first call to t_create. To scroll, click the mouse on the scroll bar located on the left side and drag down. Setting an instruction breakpoint can easily be accomplished by moving the mouse to one of the dots to the left of a source line in the Global Window. These break dots indicate where an instruction breakpoint can be set. Once the mouse is positioned over a break dot, click once and the break dot changes to a STOP sign. This STOP sign indicates that a breakpoint is set at this source line. Because the breakpoint was set from the Global Window, it is a global breakpoint, which means that any task or ISR that hits the breakpoint causes execution to stop. Global breakpoints are different from task-qualified breakpoints where execution does not stop unless a particular task hits the breakpoint. Task-qualified breaks are described later in this tutorial.
Now that the breakpoint is set, execute up to the first t_create call by clicking the go button. Instead of using the mouse, you can also enter the Continue command by typing c in the Global Window. Execution halts before the source line with the breakpoint is executed, as shown in Figure 5-3 on page 5-11.
Now single-step the source lines as each task is created and started. The easiest way to do this is to click the step or next buttons. The step button single-steps a source line, stepping into source level functions. The next button also single-steps a source line, but it steps over source level functions. Because the t_create call is an assembly language function, both step and next behave the same way and cause the source line to execute.
As you step a line that calls t_create, notice that the Task Roster Window is updated with the newly created task. The status of this task is "Created." The Entry routine is left blank because this information is not known until the task is started. See Figure 5-4 for a sample of newly created tasks such as MEM1 and MEM2.
After stepping all the t_create calls, single-step the t_start calls. Notice that the entry in the Task Roster Window is updated after each line is executed. The status of the task changes from Created to READY. The Entry routine is also filled in with the name of the routine the task executes. Figure 5-5 shows additional status changes.
Single-step all the t_start calls. You should now be stopped at an instruction to create the `SS¯ ¯ ' queue.
An important feature of the SpOTLIGHT debugger is its ability to display pSOS+ object information. The SpOTLIGHT debugger has complete knowledge of the pSOS+ objects such as tasks, queues, semaphores, regions, and partitions. Task information is automatically updated in the Task Roster Window. Now you can examine three other types of pSOS+ objects: queues, partitions, and semaphores.
To display information on queues, you can enter the qq (Query Queue) command. If you enter this command now, you find that no queues are in the system. You can quickly change this by stepping the next source line and creating the `SS¯ ¯ ' queue. This queue is used by the SRCE and SINK tasks to send and receive messages. After stepping this line, enter the qq (Query Queue) command. You should now see the `SS¯ ¯ ' queue object. This display is similar to Figure 5-6 on page 5-15.
A few source lines down is the code to create a partition to be used by the `IO1¯ ' and `IO2¯ ' tasks. The command to see partition object information is qp (Query Partition). After stepping the pt_create line, enter the qp command and you see a display similar to Figure 5-7.
A few lines down is the call to create a semaphore to be used by the
NUMS and CHAR tasks. Unlike the other two objects, depending on the BSP
used, one or more semaphore objects already exist in the application. The
RELW semaphore was created by the pROBE+ debugger. Create another semaphore
by stepping the line that calls sm_create. If you enter the qs (Query
Semaphore) command, you see a display similar to Figure
5-8.
The ROOT task, as it approaches completion, creates another queue and region, then it calls t_delete to delete itself. This introduces a different type of breakpoint that the SpOTLIGHT debugger recognizes, the service break. Service breaks occur when a particular pSOS+ system call is made. These types of breaks can be further qualified by which task or tasks make the system call and whether a particular object is involved.
Set a service break on a call by ROOT to t_delete any task. To set this service break, enter the following command in the Global Window:
db se t_delete `ROOT' *
The asterisk (*) in the command refers to any task.
Now continue execution by clicking the go button. The SpOTLIGHT debugger reports a service break has been hit by ROOT executing t_delete. The Global Window is updated to show assembly language code. You can see what source code caused this assembly language code to be called by going to the Display menu and choosing the UpStackToSource option. The display is updated to show the source line in the root routine that called t_delete.
To view files or functions, you can use the e command; e followed by the name of a file or the name of a function changes the source subwindow to show the file or function. Now set a breakpoint inside the mem1 routine. To see the mem1 function, enter the following command:
e mem1
The mem1 routine creates a circular linked list of messages using a variable called msgarray. Set a breakpoint at this code (the C source line) by clicking the corresponding break dot. Then, execute to this point by clicking the go button.
The msgarray structure is an array of messages. The code sets up the array as a circular linked list. To see the value of a variable, you can click once or twice on the name of the variable in the source subwindow. If you click once, the values of the variable are displayed in the command subwindow. If you click twice on msgarray, a new popup window opens showing the variable. This new window, shown in Figure 5-9, is called a Data Explorer Window.
Notice that a Data Explorer Window has a menu icon (a small inverted triangle) and a go-away box (a square) in the title bar.
The first few fields of each structure in the array are shown. To see the complete structure, move the mouse to the first line in the window and double-click. Another Data Explorer Window appears showing only msgarray[0].
If you click the menu icon with the mouse, a format menu appears, allowing you to modify the format of the display. An example is shown in Figure 5-10.
A small dot next to an option indicates it is currently set. Change the display by highlighting the Hex option. The values are now displayed in hex.
Double-click on the other lines in the msgarray Data Explorer Window to open separate windows for each member of the array. You now have Data Explorer Windows for msgarray, msgarray[0], msgarray[1],..., msgarray[MAX_MSG].
Single-step the source lines that set up the circular linked list. Click the step or next button several times and notice that the values in msgarray that change during execution are highlighted in the Data Explorer Windows. This highlighting helps you identify which variables have changed as a result of executing a line of source code.
To modify a variable, you can move the mouse over the value you want to change. Enter the new value and a dialog box appears with this new value. Click Enter to change the variable or Cancel to leave the variable unchanged.
You can now close the Data Explorer Windows by clicking the box on the far right side of the title bar. This box is called the go-away box.
Data Explorer Windows are very useful for looking at linked lists. Continue to single-step until execution is inside the for loop. The variable msgarray should now be set up as a circular linked list. The variable current_msg points to the first element in the linked list. Double-click on current_msg to see its value. You should see a Data Explorer Window that shows the first element of msgarray. Now access the menu icon to turn on the Hex option and the ShowAddress option. The ShowAddress option shows the address of the variable instead of the variable name in the title bar.
To see the next element in the linked list, double-click on the item next in the Data Explorer Window. A new window appears showing the next element in the linked list. You can continue to see the subsequent elements in the linked list by double-clicking the next item.
The list has six elements. Therefore, the seventh Data Explorer Window points back to the first element in the list. You can check this by comparing the addresses in the title bars. The first and seventh windows display the same values and addresses, as shown in Figure 5-11.
Now single-step so current_msg is changed. Notice again how the SpOTLIGHT debugger highlights the variables that change.
You can now close these windows by clicking the go-away boxes.
One of the SpOTLIGHT debugger's most important features is its ability to debug multiple tasks. A common occurrence in multitasking applications is to have code shared by two or more tasks. To see how the SpOTLIGHT debugger can be used to debug shared code, set an instruction breakpoint at the routine process_data. This routine is called by both the `IO1¯ ' and `IO2¯ ' tasks. To see this routine, enter the following command:
e process_data
The process_data routine is located in a separate source file than the one you were viewing before. The SpOTLIGHT debugger automatically switches to the correct source file when displaying a routine. Now that the process_data code is displayed, set an instruction breakpoint at the first instruction in this routine.
Click the go button 4 times. Notice that execution stops when either `IO1¯ ' or `IO2¯ ' hits the global breakpoint. This occurs because you set the breakpoint in the Global Window. Global breaks can be hit by any task or ISR. If you want to stop execution when only a particular task hits a breakpoint (that is, set a task-qualified break), you can use a Task Window. First remove the global breakpoint by clicking the STOP sign in the Global Window.
Now, go to the Task Roster Window and click on the line for the `IO1¯ ' task. A new window appears called a Task Window. This window is different from the Global Window in several ways. The Global Window always displays the context of the last task or ISR to hit a breakpoint or encounter an exception. So, the context in the Global Window changes during a debug session. A Task Window, however, always displays the context of a particular task. In this case, the window always shows the context of the `IO1¯ ' task. The title bar of a Task Window always indicates what task it is displaying. When a Task Window displays the current task, the Global Window and the Task Window display the same context. To see the registers for the `IO1¯ ' task, you can click the regs button in its Task Window.
Task Windows can also be used to set and clear task-qualified breaks. Set a task-qualified break on routine process_data for the `IO1¯ ' task. In the Task Window for the `IO1¯ ' task, enter the following command:
e process_data
Click on the first break dot in process_data and notice the STOP sign displayed. The STOP sign is in reverse video from the STOP sign displayed in the Global Window when a global break was set. The difference is used to distinguish between global breaks and task-qualified breaks as shown in Figure 5-12.
Now, if you click the go button, you see that execution only stops when `IO1¯ ' hits the breakpoint. Although `IO2¯ ' continues to execute the same routine, the breakpoint is set only for the `IO1¯ ' task.
The SpOTLIGHT debugger has a convenient mechanism to display an application's
stack trace and local variables. The stack trace indicates the procedure
call chain (that is, what routines were called). To display the stack trace,
you can click on the calls button. A new window, similar to Figure
5-13, appears showing the procedure call chain. It shows that process_data
was called from the `IO1¯ ' routine.
As you enter new routines, the local variables change from the previous routine. To display the local variables, you can click the locals button. A new window appears showing the local variables in the process_data routine. This window is a Data Explorer Window and it highlights any variable that changes value during execution.
Click on the STOP sign in process_data to clear the breakpoint. Single-step the process_data routine and follow the called functions. To do this, click the step button until the calc_sum routine is called. The stack trace window is updated to show the calc_sum routine being called from process_data. The local variable window also changes to show the local variables for the calc_sum routine instead of process_data. If you repeatedly click the step button, another routine named myequate is called; myequate, in turn, calls a routine named cube. As each new routine is called, the stack trace and local variable windows are updated to display new information. If you continue to single-step, you return to calc_sum. If you want to stop single-stepping calc_sum, you can return to its calling routine (process_data) by clicking the return button. This button causes execution to continue until the current routine returns back to its caller.
You have completed the example of debugging shared code. You can leave the `IO1¯ ' Task Window open or close it by clicking the quit button. Delete all the active breakpoints by entering the d command.
Type the following command to disable profiling:
fl profile off
To clear the timer break, type the following command:
cb ti
The SpOTLIGHT debugger allows you to invoke pSOS+ system calls interactively so that you can conveniently modify and control the application's behavior. For example, you can send and receive messages from a queue in the application. Enter the following command to display the information in the `SS¯ ¯ ' queue:
qq `SS¯ ¯ '
The output is similar to Figure 5-14 on page -27.
The display shows that the queue contains eight unread messages. Because the message limit is also eight, the queue is full. To receive a message from the `SS¯ ¯ ' queue, invoke the pSOS+ system call q_receive using the sc (System Call) command:
sc q_receive `SS¯ ¯ '
The contents of the received message are printed as four longs along
with the system call return code. Enter the qq `SS¯ ¯ ' command
again and observe that the first message that was previously in the queue
has been removed. The display that you will see is similar to Figure
5-15.
System Calls and Target Output - Subsequent Display sc q_receive `SS ` Return code: 0x0 Message: 0x13CB 0x0 0x0 0x0 qq `SS ` Name QID TQ Len MQ Len MQ Limit Mgb Qtype Variable ---------------------------------------------------------------------------- `SS ` -#00120000 00000000 00000007 00000008 Sys-pool Prio No ---------------------------------------------------------------------------- Task Queue: EMPTY ---------------------------------------------------------------------------- Message Queue: Message Number 1 of 16 bytes, address 000860FC: 00 00 13 CC 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 2 of 16 bytes, address 000860E8: 00 00 13 CD 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 3 of 16 bytes, address 000860D4: 00 00 13 CE 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 4 of 16 bytes, address 000860C0: 00 00 13 CF 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 5 of 16 bytes, address 000860AC: 00 00 13 D0 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 6 of 16 bytes, address 00086098: 00 00 13 D1 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 7 of 16 bytes, address 00086084: 00 00 13 D2 00 00 00 00 00 00 00 00 00 00 00 00
To send a message to the queue, invoke the pSOS+ system call q_send by entering the following command:
sc q_send `SS¯ ¯ ' `ABCD' `EFGH' `IJKL' `MNOP'
Instead of entering all the parameters to the sc command as shown above,
you can leave them out and let SpOTLIGHT prompt for each parameter. If
you enter the qq `SS¯ ¯ ' command now, you will observe
that this message has been added to the end of the queue. The display you
see will be similar to Figure 5-16.
q_send command sc q_send `SS ` `ABCD' `EFGH' `IJKL' `MNOP' Return code: 0x0 qq `SS ` Name QID TQ Len MQ Len MQ Limit Mgb Qtype Variable ---------------------------------------------------------------------------- `SS ` -#00120000 00000000 00000008 00000008 Sys-pool Prio No ---------------------------------------------------------------------------- Task Queue: EMPTY ---------------------------------------------------------------------------- Message Queue: Message Number 1 of 16 bytes, address 000860FC: 00 00 13 CC 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 2 of 16 bytes, address 000860E8: 00 00 13 CD 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 3 of 16 bytes, address 000860D4: 00 00 13 CE 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 4 of 16 bytes, address 000860C0: 00 00 13 CF 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 5 of 16 bytes, address 000860AC: 00 00 13 D0 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 6 of 16 bytes, address 00086098: 00 00 13 D1 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 7 of 16 bytes, address 00086084: 00 00 13 D2 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 8 of 16 bytes, address 00086110: 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 sc q_receive `SS ` Return code: 0x0 Message: 0x13CB 0x0 0x0 0x0 qq `SS ` Name QID TQ Len MQ Len MQ Limit Mgb Qtype Variable ---------------------------------------------------------------------------- `SS ` -#00120000 00000000 00000007 00000008 Sys-pool Prio No ---------------------------------------------------------------------------- Task Queue: EMPTY ---------------------------------------------------------------------------- Message Queue: Message Number 1 of 16 bytes, address 000860FC: 00 00 13 CC 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 2 of 16 bytes, address 000860E8: 00 00 13 CD 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 3 of 16 bytes, address 000860D4: 00 00 13 CE 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 4 of 16 bytes, address 000860C0: 00 00 13 CF 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 5 of 16 bytes, address 000860AC: 00 00 13 D0 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 6 of 16 bytes, address 00086098: 00 00 13 D1 00 00 00 00 00 00 00 00 00 00 00 00 Message Number 7 of 16 bytes, address 00086084: 00 00 13 D2 00 00 00 00 00 00 00 00 00 00 00 00
In the sample application, task SINK receives the messages from the queue `SS¯ ¯ '. Also, if the first byte of the message is non zero, it writes out the contents of the message in ASCII characters. This demonstrates the power of SpOTLIGHT debugger to support target output. The debugger provides an In/Out window through which the pSOS+ task can display its output.
The output will be displayed when the task SINK runs. To let this task
run, continue execution of the application by clicking the go button or
entering the c command. The In/Out window is similar to Figure
5-17.
The application continues to run after the output has been displayed because no breakpoints have been set. To stop execution, click the halt button or enter the halt command. Depending on the task that is running when the execution is stopped, the Global Window will display a message similar to the following:
halting process... Manual break Running: [task name] -#[ID]
where task name and ID are the name and ID of the running task at the time the halt command was processed.
This concludes the System Debug Mode portion of the tutorial. You can now perform the Task Debug Mode tutorial.
In System Debug Mode, which is the default mode, you debug the entire application. The SpOTLIGHT debugger also offers a special mode called Task Debug Mode (TDM) that provides the flexibility of debugging only a particular set of tasks. These tasks, called debug tasks, can be controlled and monitored from the debugger. The other tasks, called background tasks, are always running and cannot be controlled.
Before entering task debug mode, you should identify the debug tasks and bring their Task Windows up. Note that this is not mandatory. Task Debug Mode can also be entered before the debug tasks are identified. For this example, let `IO1¯ ' and `IO2¯ ' be the debug tasks. Bring up the Task Windows for `IO1¯ ' (if not already up) and `IO2¯ ' by clicking on their corresponding lines in the Task Roster Window. To enter the Task Debug Mode, enter the following command either in the Global Window or any of the Task Windows:
tdm on
Observe the following changes in the display:
The Global Window display is similar to Figure 5-18.
In Task Debug Mode, the Global Window is not used, but you can minimize it to save screen space.
While in Task Debug Mode, you can add or delete tasks from the debug set. To add the task SRCE to the debug set, go to the Task Roster Window (shown in Figure 5-19) and click on the line for SRCE. A Task Window for SRCE comes up, with the source subwindow displaying the task's current context. Note that the task SRCE was previously a background task, and therefore was running. pSOS+ stopped execution of the task when it was added to the debug set. The source subwindow displays the exact place where the execution of the task was stopped.
To remove the task SRCE from the debug set, click the detach button in its Task Window. The Task Window disappears, and the SRCE task changes from a debug task to a background task.
Set a breakpoint which will be hit when any task invokes any pSOS+ service call. To set this service break, enter the following command in any Task Window:
db se * task
To continue execution, click the go button. The SpOTLIGHT debugger reports that the service breakpoint has been hit by the `IO1¯ ' or `IO2¯ ' tasks. Click the go button a few more times. You will see that the service breakpoint is hit only by the `IO1¯ ' and `IO2¯ ' tasks. None of the background tasks hit the breakpoint even though they make pSOS+ service calls all the time.
Now remove the task `IO2¯ ' from the debug set by clicking the detach button in its Task Window. Click the go button a number of times. Observe that the service breakpoint is no longer hit by the `IO2¯ ' task because it is now a background task.
In general, breakpoints stop the execution of debug tasks only. The background tasks continue to run unaffected by the breakpoints. Clear the service breakpoint by entering the following command:
cb se *
Also, you cannot set a task-qualified breakpoint on a background task. For example, the debugger prints an error message if you enter the following command to set a dispatch breakpoint on the SRCE background task
db di 'SRCE'
Press the go button to continue execution. After a few seconds, press the halt button. The Task Window for `IO1¯ ' is updated to show its context when it was stopped. The background tasks continue to run.
If the Task Window for `IO1¯ ' displays assembly language code, click the return button to return to its calling routine. Now single-step the source code by pressing the step button several times. Notice that you can step only through debug tasks. Background tasks may not be single-stepped.
In Task Debug Mode, the execution command c, continues. The step, next, and halt commands affect only the debug set; the background tasks are not affected.
Enter the osboot command to reboot the operating system. After the command completes, the Task Window for `IO1¯ ' disappears because no tasks exist until pSOS+ is initialized. The Global Window is brought up automatically to the front of the screen.
In the Global Window, enter the gs command to initialize pSOS+. When the command is completed, a Task Window for ROOT comes up. Also, the Task Roster Window displays an asterisk (*) next to ROOT. The SpOTLIGHT debugger has automatically added ROOT to the debug set because it is the only application task that exists after initializing the pSOS+ kernel.
To exit the Task Debug Mode, enter the following command:
tdm off
All the background tasks stop executing now. The source subwindow of the Global Window displays the context of the task that was executing when TDM was switched off. Also notice that the asterisk (*) next to ROOT in the Task Roster Window is removed. This indicates that the debug set has been cleared.
You have now completed the SpOTLIGHT debugger tutorial. To quit the SpOTLIGHT debugger, you can click the quit button in the Global Window. If your ROOT Task Window is still open, then the SpOTLIGHT debugger print an error messages. You must first quit all Task Windows before the SpOTLIGHT debugger allows you to quit the Global Window. To close a Task Window, click the quit button. You can now return to the Global Window and quit your debugging session.
For additional information about the SpOTLIGHT debugger, see the SpOTLIGHT Debug Server User's Manual.
Copyright © 1996, Integrated Systems, Inc. All rights reserved.
