![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
In such cases, you can use the EXAMINE/FLOAT command to display the decoded exception message in the associated register element. This technique enables you to identify a floating-point exception that is still pending delivery, as shown in Section 15.8. The following example shows that a vector instruction caused a floating divide-by-zero exception in element 2 of register V5:
DBG> EXAMINE/FLOAT %V5
0\%V5
(0): 297.2800
(1): 87.41499
(2): Reserved operand, encoded as floating divide by zero
(3): 173.8650
DBG>
If the program copies values from vector registers into memory, you can apply the EXAMINE/FLOAT command to the memory location and display the decoded information, as you would for a vector register.
The following table identifies the decoded debugger message for each type of vector floating-point exception:
| Exception | Debugger Message |
|---|---|
| Floating underflow | Reserved operand, encoded as floating underflow |
| Floating divide by zero | Reserved operand, encoded as floating divide by zero |
| Floating reserved operand | Reserved operand, encoded as floating reserved operand |
| Floating overflow | Reserved operand, encoded as floating overflow |
To achieve high performance, the VAX scalar and vector processors operate concurrently as much as possible. The scalar processor passes any vector instructions to the vector processor and then continues executing scalar instructions while the vector processor executes vector instructions.
In some cases, the operation of the two processors must be synchronized to ensure correct program results. By using synchronizing instructions such as SYNC, MSYNC, and VSYNC, the program forces certain operations to complete before others are initiated. See the OpenVMS MACRO and Instruction Set Reference Manual for more information about these instructions and scalar-vector synchronization.
If the program has been vectorized by the compiler (for example, the Digital Fortran compiler), the necessary synchronizing instructions are automatically generated. However, MACRO programmers need to code synchronizing instructions explicitly.
By default, the debugger does not force scalar-vector synchronization during program execution except for its own internal purposes. The program executes as if it were running without debugger control, and synchronization is controlled entirely by the program. This default mode of operation is established by the SET VECTOR_MODE NOSYNCHRONIZED command.
When you use the debugger in the default, nonsynchronized vector mode, certain vector operations might be in an interrupted state when program execution is suspended at a breakpoint, watchpoint, or at the completion of a STEP command. For example:
To eliminate potential confusion in such cases, enter the command SYNCHRONIZE VECTOR_MODE. It forces immediate synchronization between the scalar and vector processors. Entering this command is equivalent to entering a SYNC and an MSYNC instruction at the location in the program at which execution is paused. The effect is as follows:
The following MACRO example shows the effect of the SYNCHRONIZE VECTOR_MODE command:
DBG> STEP (1)
stepped to .MAIN.\SUB\%LINE 99
99: VVDIVD V1,V0,V2
DBG> STEP (2)
stepped to .MAIN.\SUB\%LINE 100
100: CLRL R0
DBG> EXAMINE/FLOAT %V2 (3)
0\%V2
[0]: 13.53400
[1]: Reserved operand, encoded as floating divide by zero
[2]: 247.2450
.
.
.
DBG> SYNCHRONIZE VECTOR_MODE (4)
%SYSTEM-F-VARITH, vector arithmetic fault, summary=00000002,
mask=00000004, PC=000002E1, PSL=03C00010
break on unhandled exception preceding .MAIN.\SUB\%LINE 100
100: CLRL R0
DBG>
The following comments refer to the callouts in the previous example:
An alternative to using the SYNCHRONIZE VECTOR_MODE command is to operate the debugger in the synchronized vector mode by entering the SET VECTOR_MODE SYNCHRONIZED command. This command causes the debugger to force automatic synchronization between the scalar and vector processors whenever a vector instruction is executed. Specifically, the debugger issues a SYNC instruction after every vector instruction and, in addition, an MSYNC instruction after any vector instruction that accesses memory. This forces the completion of all activities associated with the vector instruction that is being synchronized as follows:
The following example shows the effect of the SET VECTOR_MODE SYNCHRONIZED command on the same instruction stream that was used in the previous example:
DBG> SHOW VECTOR_MODE
Vector mode is nonsynchronized
DBG> SET VECTOR_MODE SYNCHRONIZED (1)
DBG> SHOW VECTOR_MODE
Vector mode is synchronized
DBG> STEP (2)
stepped to .MAIN.\SUB\%LINE 99
99: VVDIVD V1,V0,V2
DBG> STEP (3)
%SYSTEM-F-VARITH, vector arithmetic fault, summary=00000002,
mask=00000004, PC=000002E1, PSL=03C00010
break on unhandled exception preceding .MAIN.\SUB\%LINE 100
100: CLRL R0
DBG>
The following comments refer to the callouts in the previous example:
In addition to SYNCHRONIZE VECTOR_MODE and SET VECTOR_MODE SYNCHRONIZED, a few other debugger commands can affect synchronization---for example, SET WATCH.
The CALL command's /[NO]SAVE_VECTOR_STATE qualifiers enable you to control whether the current state of the vector processor is saved and then restored when a routine is called.
The state of the VAX vector processor comprises the following:
When you use the CALL command to execute a routine, execution of the routine might change the state of the vector processor as follows:
The CALL/SAVE_VECTOR_STATE command specifies that the state of the vector processor that exists before the CALL command is entered be restored by the debugger after the called routine has completed execution. This ensures that, after the called routine has completed execution:
The CALL/NOSAVE_VECTOR_STATE command, which is the default, specifies that the state of the vector processor that exists before the CALL command is entered is not restored by the debugger after the called routine has completed execution. In this case, the state of the vector processor after the routine call depends on the effect (if any) of the called routine.
The /[NO]SAVE_VECTOR_STATE qualifiers have no effect on the VAX general (scalar) registers. The values of these registers are always saved and restored when you execute a routine with the CALL command.
In screen mode, a register display shows the current values of the VAX general registers (see Section 7.4.5).
To display data contained in vector registers or vector control registers in screen mode, use a DO display (see Section 7.2.1).
For example, the following command creates a DO display named V2_DISP that shows the contents of elements 4 to 7 of register V2 (Fortran array syntax). The display is automatically updated whenever the debugger gains control from your program.
DBG> DISPLAY V2_DISP AT RQ2 DO (EXAMINE %V2(4:7))
The following lists problems and restrictions with the debugger's support for vectorized programs:
DEPOSIT/QUADWORD %VMR = %HEX 0FFFFFFFF
This chapter describes features of the debugger that are specific to tasking programs (also called multithread programs). Tasking programs consist of multiple tasks, or threads, executing concurrently in a single process. These programs include the following:
Within the debugger, the term task denotes such a flow of control regardless of the language or implementation. The debugger's tasking support applies to all such programs.
In this chapter, any DECthreads-specific or language-specific information is identified as such. Section 16.1 provides a cross-reference between DECthreads terminology and Ada tasking terminology.
The features described in this chapter enable you to perform functions such as:
When using these features, remember that the debugger might alter the behavior of a tasking program from run to run. For example, while you are suspending execution of the currently active task at a breakpoint, the delivery of an asynchronous system trap (AST) or a POSIX signal as some input/output (I/O) completes might make some other task eligible to run as soon as you allow execution to continue.
For more information about DECthreads or POSIX threads, see the Guide to DECthreads. For more information about Ada tasks, see the DEC Ada documentation.
The debugging of multiprocess programs (programs that run in more than one process) is described in Chapter 14.
Table 16-1 compares DECthreads and Ada terminology and concepts.
| DECthreads Terminology | Ada Terminology | Description |
|---|---|---|
| Thread | Task | The flow of control within a process |
| Thread object | Task object | The data item that represents the flow of control |
| Object name or expression | Task name or expression | The data item that represents the flow of control |
| Start routine | Task body | The code that is executed by the flow of control |
| Not applicable | Master task | A parent flow of control |
| Not applicable | Dependent task | A child flow of control that is controlled by some parent |
| Synchronization object (mutex, condition variable) | Rendezvous construct such as an entry call or accept statement | Method of synchronizing flows of control |
| Scheduling policy and scheduling priority | Task priority | Method of scheduling execution |
| Alert operation | Abort statement | Method of canceling a flow of control |
| Thread state | Task state | Execution state (waiting, ready, running, terminated) |
| Thread creation attribute (priority, scheduling policy, and so on) | Pragma | Attributes of the parallel entity |
The following sections present sample tasking programs with common errors that you might encounter when debugging tasking programs:
Some other examples in this chapter are derived from these programs.
Example 16-1 is a multithread C program that shows incorrect use of condition variables, which results in blocking.
Explanatory notes are included after the example. Following these notes are instructions showing how to use the debugger to diagnose the blocking by controlling the relative execution of the threads.
In Example 16-1, the initial thread creates two worker threads that do some computational work. After the worker threads are created, a SHOW TASK/ALL command will show three tasks, each corresponding to a thread (Section 16.4 explains how to use the SHOW TASK command).
In Example 16-1, a synchronization point (a condition wait) has been placed in the workers' path at line 3893. (The comment starting at line 3877 indicates that a straight call such as this one is incorrect programming and shows the correct code.)
When the program executes, the worker threads are busy computing when the initial thread broadcasts on the condition variable. The first thread to wait on the condition variable detects the initial thread's broadcast and clears it, which leaves any remaining threads stranded. Execution is blocked and the program cannot terminate.
Example 16-1 Sample C Multithread Program
3777 /* DEFINES */
3778 #define NUM_WORKERS 2 /* Number of worker threads */
3779
3780 /* MACROS */
3781 #define check(status,string) \
3782 if (status == -1) perror (string); \
3783
3784 /* GLOBALS */
3785 int cv_pred1; /* Condition Variable predicate */
3786 pthread_mutex_t cv_mutex; /* Condition Variable mutex */
3787 pthread_cond_t cv; /* Condition Variable */
3788 pthread_mutex_t print_mutex; /* Print mutex */
3799
3790 /* ROUTINES */
3791 static pthread_startroutine_t
3792 worker_routine (pthread_addr_t arg);
3793
3794 main ()
3795 {
3796 pthread_t threads[NUM_WORKERS]; /* Worker threads */
3787 int status; /* Return statuses */
3798 int exit; /* Join exit status */
3799 int result; /* Join result value */
3800 int i; /* Loop index */
3801
3802 /* Initialize mutexes */
3803 status = pthread_mutex_init (&cv_mutex, pthread_mutexattr_default);
3804 check (status, "cv_mutex initialization bad status");
3805 status = pthread_mutex_init (&print_mutex, pthread_mutexattr_default);
3806 check (status, "print_mutex intialization bad status");
3807
3808 /* Initialize condition variable */
3809 status = pthread_cond_init (&cv, pthread_condattr_default);
3810 check (status, "cv condition init bad status");
3811
3812 /* Initialize condition variable predicate. */
3813 cv_pred1 = 1; (1)
3814
3815 /* Create worker threads */
3816 for (i = 0; i < NUM_WORKERS; i++) { (2)
3817 status = pthread_create (
3818 &threads[i],
3819 pthread_attr_default,
3820 worker_routine,
3821 0);
3822 check (status, "threads create bad status");
3823 }
3824
3825 /* Set cv_pred1 to false; do this inside the lock to insure visibility. */
3826
3827 status = pthread_mutex_lock (&cv_mutex);
3828 check (status, "cv_mutex lock bad status");
3829
3830 cv_pred1 = 0; (3)
3831
3832 status = pthread_mutex_unlock (&cv_mutex);
3833 check (status, "cv_mutex unlock bad status");
3834
3835 /* Broadcast. */
3836 status = pthread_cond_broadcast (&cv); (4)
3837 check (status, "cv broadcast bad status");
3838
3839 /* Attempt to join both of the worker threads. */
3840 for (i = 0; i < NUM_WORKERS; i++) { (5)
3841 exit = pthread_join (threads[i], (pthread_addr_t*)&result);
3842 check (exit, "threads join bad status");
3843 }
3844 }
3845
3846 static pthread_startroutine_t
3847 worker_routine(arg)
3848 pthread_addr_t arg; (6)
3849 {
3850 int sum;
3851 int iterations;
3852 int count;
3853 int status;
3854
3855 /* Do many calculations */
3856 for (iterations = 1; iterations < 10001; iterations++) {
3857 sum = 1;
3858 for (count = 1; count < 10001; count++) {
3859 sum = sum + count;
3860 }
3861 }
3862
3863 /* Printf may not be reentrant, so allow 1 thread at a time */
3864
3865 status = pthread_mutex_lock (&print_mutex);
3866 check (status, "print_mutex lock bad status");
3867 printf (" The sum is %d \n", sum);
3868 status = pthread_mutex_unlock (&print_mutex);
3869 check (status, "print_mutex unlock bad status");
3870
3871 /* Lock the mutex associated with this condition variable. pthread_cond_wait will */
3872 /* unlock the mutex if the thread blocks on the condition variable. */
3873
3874 status = pthread_mutex_lock (&cv_mutex);
3875 check (status, "cv_mutex lock bad status");
3876
3877 /* In the next statement, the correct condition-wait syntax would be to loop */
3878 /* around the condition-wait call, checking the predicate associated with the */
3879 /* condition variable. This would guard against condition waiting on a condition */
3880 /* variable that may have already been broadcast upon, as well as spurious wake */
3881 /* ups. Execution would resume when the thread is woken AND the predicate is */
3882 /* false. The call would look like this: */
3883 /* */
3884 /* while (cv_pred1) { */
3885 /* status = pthread_cond_wait (&cv, &cv_mutex); */
3886 /* check (status, "cv condition wait bad status"); */
3887 /* } */
3888 /* */
3888 /* A straight call, as used in the following code, might cause a thread to */
3890 /* wake up when it should not (spurious) or become permanently blocked, as */
3891 /* should one of the worker threads here. */
3892
3893 status = pthread_cond_wait (&cv, &cv_mutex); (7)
3894 check (status, "cv condition wait bad status");
3895
3896 /* While blocking in the condition wait, the routine lets go of the mutex, but */
3897 /* it retrieves it upon return. */
3898
3899 status = pthread_mutex_unlock (&cv_mutex);
3900 check (status, "cv_mutex unlock bad status");
3901
3902 return (int)arg;
3903 }
Key to Example 16-1:
The debugger enables you to control the relative execution of threads to diagnose problems of the kind shown in Example 16-1. In this case, you can suspend the execution of the initial thread and let the worker threads complete their computations so that they will be waiting on the condition variable at the time of broadcast. The following procedure explains how:
Example 16-2 demonstrates a number of common errors that you may encounter when debugging tasking programs. The calls to procedure BREAK in the example mark points of interest where breakpoints could be set and the state of each task observed. If you ran the example under debugger control, you could enter the following commands to set breakpoints at each call to the procedure BREAK and display the current state of each task:
DBG> SET BREAK %LINE 46 DO (SHOW TASK/ALL) DBG> SET BREAK %LINE 71 DO (SHOW TASK/ALL) DBG> SET BREAK %LINE 76 DO (SHOW TASK/ALL) DBG> SET BREAK %LINE 92 DO (SHOW TASK/ALL) DBG> SET BREAK %LINE 100 DO (SHOW TASK/ALL) DBG> SET BREAK %LINE 104 DO (SHOW TASK/ALL) DBG> SET BREAK %LINE 120 DO (SHOW TASK/ALL)
4538P026.HTM OSSG Documentation 22-NOV-1996 13:02:10.67
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.