Prism 7.0 Software User's Guide
|    
|
| Prism 7.0 Software User's Guide
|
|
| C H A P T E R 3 |
|
Loading and Executing a Program |
This chapter describes how to load and run programs within the Prism environment. It covers the following topics:
To use this chapter most effectively, you should already have an executable program that you want to run within the Prism environment. You can also develop a new program by calling up an editor within the Prism environment; see Chapter 6.
Before you can execute or debug a program in the Prism environment, you must first load the program into the Prism environment. You can load only one program at a time.
As described in Chapter 2, you can load a program into the Prism environment by specifying its name as an argument to the prism command. If you don't use this method, you can load a program once you are in the Prism environment by using one of the methods discussed next.
1. Choose Open from the File menu or the tear-off region.
A dialog box like the one shown in FIGURE 3-1 appears:
2. Double-click on the program name in the Programs scrollable list (if the name is listed).
Or, you can put its path name into the Selection box, then click on Open. To put the file's path name into the Selection box, you can either type it directly in the box or click on its name in the Programs list. The Programs list contains the executable programs in your current working directory.
Use the Open-Program Filter dialog box to control the display of file names in the Programs list; the box uses standard Solaris filters. For example, you can click on a directory in the Directories list if you want to change to that directory. But the Programs list does not update automatically to show the programs in the new directory. Instead, the filter changes to directory-name/*, indicating that all files in directory-name are to be displayed. Click on Filter to display the file names of the programs. Or simply double-click on the directory name in the Directories list to display the programs in the directory.
If you want to use a different filter, you can edit the Open-Program Filter box directly. For example, change it to directory-name/prog* to display only programs beginning with prog.
3. Click on Cancel or press the Esc key if you decide not to load a program.
Use the name of the executable program as its argument. For example, to load the program myprogram, enter
Once a program has been successfully loaded, the following occurs:
You can now issue commands to execute and debug this program.
If the Prism environment cannot find the source file, it displays a warning message in the command window. Select Use from the File menu to specify other directories in which the Prism environment is to search; see Creating a Directory List for Source Files for details.
To load a new program, perform one of the following:
You can have the Prism environment associate a core file with a program by specifying its file name after the name of the program on the prism command line.
Where corefile is the name of the corresponding core file.
The Prism environment's core command is not available when using the Prism environment with message-passing programs. Instead, you must specify the name of the process core file from the Prism command line.
In either case, when a program failure results in a core dump, the Prism environment reports the error that caused the core dump and loads the program with a stopped status at the location where the error occurred. You can then work with the program within the Prism environment. You can, for example, examine the stack and print the values of variables. You cannot, however, continue execution from the current location.
You can examine a core file created by a message-passing program from within the Prism environment. However, because only one file will be examined, the Prism environment will be started in scalar mode. The procedure for examining a core file for a local process is as follows:
This lets you inspect the state of your process at the time the core dump was taken.
Note the following restrictions to this procedure:
You can attach the Prism environment to a MP process that has already started.
1. Obtain the job ID of the processes.
The following is an example of bjobs output (LSF environment):
host4-0 54 =>bjobs JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME 15232 jay RUN hpc host4-0 host4-0 chess Sep 24 13:35 host4-1 |
% prism -options [program | - ] job_ID
Note that job_ID is the ID of all the processes (not an individual process ID).
3. Use the -n (or -np, -c, -p) option when you request that the Prism environment attach to a job.
Without one of these options, the Prism environment assumes that the ID number is a process ID rather than a job ID.
For example, the following starts the Prism environment and attaches to the running processes in job 15232:
See the LSF Batch User's Guide for further information about bjobs. See the Sun HPC ClusterTools User's Guide for further information about mpps.
You attach to a single process of a message-passing program by specifying its process ID. If you do this, however, you won't be able to view or debug what is happening in the other processes.
When you launch the Prism environment, you can specify a list of jobs to attach. Note that if the list of job IDs belongs to the same executable, the Prism environment starts only one session.
A job is automatically detached from the Prism environment if you quit it or run another program. You can detach from the job without leaving the Prism environment by issuing the detach command.
The Prism environment lets you detach only when all the processes in the job are stopped. The detach operation itself sets them all running again, outside control of the debugger.
You start execution of a program in the Prism environment by issuing the run command or choosing the Run or Run (args) selection from the Execute menu. You can attach to a program that is already running by using the attach command. This is described in Attaching to a Running Message-Passing Process.
When the program starts executing, the status region displays the message running.
You can continue to interact with the Prism environment while a program is running, but many features will be unavailable. Unavailable selections are grayed out in menus. If you issue a command that cannot be executed while the program is running, it is queued until the program stops.
By default, the Prism environment creates a new window for a program's I/O. This window persists across multiple executions and program loads, giving you a complete history of your program's input and output. If you prefer, you can display I/O in the X terminal from which you invoked the Prism environment. See Resource Descriptions for details.
The Prism environment displays status messages before, during, and after the execution of a program. FIGURE 3-1 lists the various status messages that might be displayed.
When using the Prism environment to debug a multiprocess and/or multithreaded program, menu actions such as Step and Next apply to the processes (or threads) belonging to the current set of processes (or threads).
When debugging multiprocess programs, it can be useful at times to be able to identify when a specific process or set of processes has stopped execution. It can also be useful to be able to interrupt execution of individual processes. The Prism environment meets these needs with the commands wait and interrupt.
|
|
A process is considered to have stopped if it has entered the done, break, interrupted, or error state.
There are two versions of the wait command:
There are corresponding Wait Any and Wait Every selections in the Prism environment's Execute menu. They apply to the processes of the current set.
If you prefer to have the step and next commands wait for processes to finish executing before letting you issue other commands, you can issue them along with the wait command. For example,
executes the next line, then waits for all processes in the current pset to finish execution.
If you use this command sequence frequently, you can provide an alias for it through the alias command. The Prism environment provides the default alias contw for the following command sequence:
When using the Prism environment to debug a scalar program, the > symbol in the line-number region points to the next line to be executed. In a multiprocess or multithreaded program, there can be multiple execution points within the program. The Prism environment marks all the execution points for the processes in the current set with a > in the line-number region or a * character when the current source position is the same as the current execution point.
|
|
Shift-click on the execution pointer symbol.
This shows the process(es) for which the symbol is the execution pointer.
(prism all) pstatus pset_qualifier
This finds out the execution status of the pset specified by the pset_qualifier argument.
This finds out the execution status of processes in the current pset.
|
|
When issued in the primary Prism session, this command cleans up current secondary Prism sessions (shutting down both the secondary Prism sessions and the debuggee processes) before rerunning the currently loaded program.
The rerun command is not valid when issued in the secondary Prism sessions.
For more information about debugging multiple sessions within the Prism environment, see Enabling Support for Spawned MPI Processes.
This starts a program using the commands-only interface. The program starts up in the background.
This brings the running program into the foreground. Note that you cannot execute Prism commands while the program is executing in the foreground.
This key sequence sends the running program to the background and regains the (prism) prompt.
This command terminates the debugging session. Before quitting, the Prism environment kills the debugging process if it was started with run, or the Prism environment will detach from it if the program was previously attached.
The Prism environment enables you to view your program at the level of an individual process or individual thread.
|
Note - To view a program at the process level means to view the program at the level of the main thread. |
You can use the Prism environment to view all of the processes (and threads), or subsets of the processes (and threads) that make up the program. For example, at times it may be useful to look at the status of process 0 (or thread 0.1). At other times, you might want to look at all processes or threads that have encountered an error, or at all processes or threads in which the value of a particular variable exceeds a certain number.
Such groups of processes or threads (psets) are often of interest because they have some useful characteristic in common. The Prism environment treats a pset as a unit: For example, you can use the name of a pset as a qualifier for many commands. The command is then executed for each process in the set.
You can view psets in the Psets window, as described in Using the Psets Window and Viewing Pset Contents From the Psets Window.
The Prism environment provides predefined psets for certain groups of processes (and threads). For example, the set of all processes (and threads) in an error state is a predefined pset. You can also define your own psets, as described in Defining Psets; for example, you can define a pset to be those processes (and threads) in which variable x is greater than 0. To Delete Psets From the Psets Window describes how to delete psets.
Some Prism commands can be directed to apply to specific psets by including pset qualifiers as arguments to those commands. If you don't specify a pset as a qualifier to one of these commands, the command is executed on the current pset. The concept of the current pset is described in The Current Pset. The Current Process describes the current process, which is a distinguished process (or thread) within a pset.
|
Note - In threaded programs, the Prism environment extends the notion of current process to refer to the current thread of a pset. |
You can navigate to any defined pset using the pull-down menu and arrow keys on the main MP Prism window. The pset navigator controls are shown at the bottom of FIGURE 3-1.
You can use the Psets window to view the current status of the processes in your program and to perform many of the actions associated with psets.
Perform one of the following operations:
FIGURE 3-4 shows the Psets window for a nonthreaded 16-process message-passing program, including several user-defined psets.
FIGURE 3-5 shows the Psets window for a multithreaded program, including the predefined psets.
The various components of the window are described in detail in later sections. Here is a brief overview:
The Prism environment provides the following predefined psets:
These sets are dynamic; that is, as a program executes, the Prism environment automatically adjusts the contents of each set to reflect the program's current state.
In addition, there are two set names that have special meaning: current and cycle. These are discussed in The Current Pset and The cycle Pset, respectively.
You can create psets in the Prism environment. This section describes the syntax of pset creation. This syntax provides a convenient shorthand method for entering complicated pset specifications.
Psets can be constructed using one or more of the following syntactical building blocks:
Note that you can use predefined psets to define new psets. Except for pset all, when you use a predefined pset to define a new pset, the Prism environment uses the instantaneous value of the predefined pset. Thus, even if the predefined pset changes, the user-defined pset remains unchanged until the user forces
reevaluation with a Prism command, such as eval pset.
(prism all) command pset pset_specifier
Put the pset_specifier clause at the end of the command line (but before an on window clause, if any).
(prism all) print x pset error
prints the values of the variable x in the predefined pset error. (See Visualizing Multiple Processes for a discussion of printing variables in the Prism environment.)
You can assign a name to a pset. This is convenient if you plan to use the set frequently in your Prism session.
Use the syntax described above in Defining Psets to specify the pset. You can use any name except the names that the Prism environment predefines; see Predefined Psets. The name must begin with a letter; it can contain any alphanumeric character, plus the dollar sign ($) and underscore (_).
To create a pset called odd, which contains the odd-numbered processes between 1 and 31, type:
(prism all) define pset odd 1:31:2
To create a pset from the first thread in process one, type:
(prism all) define pset gui_thread 1.1
To create a pset from the second thread in process one, type:
(prism all) define pset io_thread 1.2
To create a pset from an expression that takes the intersection of all processes and threads and subtracts the two psets defined in the two previous examples, type:
(prism all) define pset workers (all.all - gui_thread - io_thread)
To create a pset that consists of all processes in which x is not equal to 0, enter
(prism all) define pset xon {x .NE. 0}
Note that x must be active in all processes for this syntax to work. As described above, you can use the intrinsic isactive to ensure that x is active in the processes that are evaluated. The following example creates a variable pset whose contents will change based on the value of x:
(prism all) define pset xon {isactive(x) && (x .NE. 0)}
Variable psets are discussed in a later section.
Finally, note that all processes must be stopped for this syntax to work. To ensure that the definition applies only to stopped processes, use the following syntax:
(prism all) define pset xon stopped && {isactive(x) && (x .NE. 0)}
Dynamic, user-defined psets are deleted when you reload a program. To get a list of these psets before reloading, issue the command show psets. You can then use this list to help reissue the define pset commands. See Viewing Pset Contents From the Psets Window for more information about show psets.
The Prism environment evaluates the membership of a variable pset when it is defined. If no processes meet the condition, the Prism environment prints appropriate error messages, but the set is defined.
(prism all) eval pset psetname
The following example evaluates the membership of the pset xon:
This causes the display for the pset to be updated in the Psets window.
Note that this evaluation fails if one of the following is true:
For example, type the following command:
(prism all) define pset foo {x > 0}
You must be certain that all processes are stopped and that x is active on all processes when you type the command:
For greater assurance that the evaluation will succeed, use the following syntax:
(prism all) define pset foo stopped && {isactive(x) && (x > 0)}
The extra information provided ensures that the evaluation takes place only in processes that are stopped and in which x is active.
If an evaluation fails, the membership of the pset remains what it was before you issued the eval pset command.
You can use the eval pset command in event actions; see Events Taking Pset Qualifiers.
You can use combinations of named psets and pset expressions to isolate processes and threads of interest, as shown in TABLE 3-2:
|
All threads in which the variable var is on the stack for a process (or is a global) and has value 1 |
Each of the following lines specify the same pset:
|
pset {var_i == 3} . { var_j == 4} |
The easiest way to view the contents of psets is to use the Psets window.
By default, the window displays the current pset (which starts out being the predefined pset all) and the psets break, running, and error. When you create a new pset via the define pset command, that set is also displayed automatically.
The processes within a pset are numbered starting at the upper left, increasing from left to right and then jumping to the next row. You can display information about them as follows:
1. Choose the Show selection from the Options menu in the Psets window.
This displays a list of psets; the predefined psets are at the top, followed by any user-defined set names.
2. Click on a set name, and that set is displayed in the window.
1. Choose the Hide selection from the Options menu.
This displays the list of predefined and user-defined psets.
2. Click on a set name to remove that set from the display.
Note that hiding a pset doesn't otherwise affect its status; it still exists and can be used in commands.
Note also that the Show and Hide submenus include the choices All Sets and all. The All Sets choice refers to all psets; the all choice refers to the predefined pset all.
1. Use the navigator rectangle (between the Cycle and the Zoom arrows) to pan through the psets.
The gray box in the rectangle shows the position of the display area relative to all the psets that are to be displayed:
2. Either drag the box or click at a spot in the rectangle.
The box moves to that spot, and the display window shows the psets in this area of the total display.
To display more psets at the same time, click on the Zoom up arrow to the right of the navigator rectangle. This raises the zoom factor, increasing the size of the boxes that represent the psets. Clicking on the Zoom down arrow decreases the size of these boxes.
(prism all) show pset [psetname]
For example, this command might produce this subsequent response:
(prism all) show pset stopped The set contains the following processes: 0:3. |
The show pset command is discussed further in To Find Out the Current Pset.
The show psets command displays the contents and status of all psets, as shown by the following sample output:
You can delete named psets that you have defined. You cannot delete any predefined pset except cycle; see The cycle Pset.
See Events Taking Pset Qualifiers for a discussion of the effects of deleting a pset on events that have been defined to affect the members of that set.
The command syntax described in Defining Psets lets you apply a command to a specific pset. If you don't use this syntax, the command is applied to the current pset; current is a predefined pset name in the Prism environment. In addition, many graphical actions in the Prism environment apply only to the members of the current set.
Note that you cannot change the current pset to one that has no members. If you try to do so, nothing will happen in the Psets window and you will get a message like the following in the history region of the command window:
Cannot set current pset to running -- it is empty.
When a program is first loaded, the current pset is the default pset, all.
The Psets window also displays the processes in the current pset. In this example, issuing the show pset command at the Prism commandline causes the Prism Environment to list the processes in the current pset:
(prism foo)show pset pset 'current' is defined as 'foo'. The set contains the following processes: 1,2. |
Predefined Psets describes predefined psets-- sets like running, stopped, and interrupted whose contents the Prism environment automatically updates during execution of the program.
If you specify a predefined pset as the current pset, it becomes a static pset that consists of the processes that are members of the predefined set at the time it is made the current set. To make this clear, the (prism) prompt changes to list the processes that are members of this static set. In this example, if processes 0, 1, and 13 are the only processes that are stopped, the pset command changes the Prism commandline prompt to list the processes 0, 1, and 13:
Output of the show pset command is explicit under these circumstances.
Issuing the pset command with no arguments displays the same information.
Note that the (prism) prompt can become quite long if there are many processes in a current pset derived from a dynamic pset. By default, the prompt length is limited to 25 characters. You can change this default by issuing the set command with the $prompt_length variable, specifying the maximum number of characters to appear in the pset part of the prompt. In this example, the command shortens the prompt long_pset_name to long_pset:
(prism long_pset_name)set $prompt_length=9 (prism long_pset) |
Defining Psets describes how to create variable psets -- user-defined psets whose membership can change in the course of program execution.
If you make a variable pset your current set, its membership is determined by the most recent eval pset command you have executed for the set.
Each pset has a current process, which serves as the scoping point for Prism commands. By default, the process with the lowest rank is the current process. If that process is threaded, its lowest numbered thread is the current process.
The Prism environment uses the current process and current thread in several ways:
(prism all) process 2 The current process is now 2. |
The syntax of the process command includes both process number and thread ID, as shown below:
(prism all) process process_number.thread_ID
process_number is the rank of the process that you want to make the current process. thread_ID is the identifying number of the thread in that process that you want to be the current thread.
If you do not specify the thread_ID value, it defaults to the lowest numbered thread on the specified process. This is illustrated in the following example:
(prism all) pset 1:4:2.2:3 (prism 1:4:2.2:3)process 3 (prism 1:4:2.2:3) |
This example replaces the pset all with a pset consisting of the processes and threads: 1.2, 1.3, 3.2, and 3.3. In other words, the pset command specifies that the new pset will consist of a subset of processes in the range of 1 through 4. Within this range, the subset is restricted to threads 2 and 3 on those processes that are selected by a process stride of 2.
When the pset command completes execution, the default current process is 1.2. This is the process with the lowest rank and the lowest numbered thread on that process.
The process command on the second line changes the current process to 3.2.
When using the Prism environment to debug a message-passing program, the scope of the current process determines the scope for resolving the names of variables.
If a command applies to a pset other than the current set, the Prism environment uses the scope of that set's current process.
It is possible that other members of the pset will have different scopes from that of the current process, or that its scope level will not even exist in these processes. In these cases, you receive an error message when you try to issue a command (for example, print or display) that requires a consistent scope. To solve the problem, you can do one of the following:
Commands such as pset and process that affect scope print the current function when you issue them.
In debugging a message-passing program, you may often want to look, in turn, at each process within a pset . The cycle pset provides you with a convenient way of doing this.
(prism all)define pset cycle psetname
If psetname is dynamic, the cycle pset is statically fixed when you create it. You can then cycle through each process in this pset to examine it in turn.
By default, the cycle pset is equivalent to the current pset. For more information about the define pset command, see Defining Psets.
For example,the following copies foo into the cycle pset:
(prism all)define pset cycle foo
Note that changing the cycle pset erases any previous cycling information. For example, if you do the following:
1. Make foo the current set and cycle partway through it.
3. Once again make foo the current set.
Then you start at the beginning again when you cycle through the members of foo.
Use the Cycle arrows at the top left of the window to cycle through the members of the cycle set.
Click on the right arrow to cycle up through the members of the set; click on the left arrow to cycle down through the members.
This has the same effect as clicking on the right cycle arrow in the Psets window.
In a nonthreaded program, the cycle command sets the current process to the next one in the current pset. In a threaded program, it sets the current process to be the next valid thread on the current process. If the cycle command is entered when the current thread is the last thread in the process, it steps to the next process in the pset.
In the following example, this Prism session defines a pset, makes it the current set, and then cycles through its members:
(prism all) define pset foo 0:3 (prism all) pset foo (prism foo) cycle (prism 1) cycle (prism 2) cycle (prism 3) cycle (prism 0) |
Choose Cycle from the Source-Window pop-up menu. This advances to the next member of the cycle pset.
The Prism environment includes a Cycle window type for visualizing data. When you print a variable's value to the Cycle window, the value changes to that of the variable in the new process whenever you cycle through the members of the cycle pset. For more information, see Visualizing Multiple Processes.
The pset command takes two thread-specific options, -hide and -unhide. These options control membership in a set of hidden threads.
Hidden threads never appear in any pset, and debugging commands are never sent to them regardless of the definition of the current set. Once hidden, those threads are represented by empty stripes in the Psets window and Where graph. By default, the set of hidden threads consists of threads 2, 3, and 4 in all ranks. These are auxiliary threads created by any program that is linked with libthread.so and are rarely interesting to a programmer.
The following procedures are valid only when debugging a multithreaded program.
(prism all)pset -hide pset_expression
The Prism environment evaluates pset_expression and adds the result to the set of hidden threads.
(prism all)pset -unhide pset_expression
The Prism environment evaluates pset_expression and subtracts the result from the set of hidden threads.
As mentioned at the beginning of this chapter, you can specify pset qualifiers with several Prism commands. The following commands can take a pset as a qualifier:
(prism) command options pset_qualifier [on window]
A command with a pset qualifier applies only to the processes in the set. If you omit the qualifier, the command applies to the processes in the current set.
For example, the following sets a breakpoint at line 12 for the processes in pset error:
(prism all) stop at 12 pset error
The following displays the Where graph for processes 0 through 10:
(prism all) where pset 0:10 on dedicated
See Displaying the Where Graph for a description of the Where graph.
The following creates a trace event for the members of the current pset:
(prism all) trace at 12 if x > 10
Note that this last command applies only to the members of the current pset. To apply it to all processes, use the syntax:
(prism all) trace at 12 if x > 10 pset all
Many commands cannot logically take a pset qualifier. You get an error message if you try to issue one of these commands with a pset qualifier.
When running threaded programs in the Prism environment, you can encounter unbounded psets. An unbounded pset is one that contains the value of all in the thread-part of a pset specifier. The membership of such psets varies unpredictably. The term unbounded distinguishes such psets from those whose membership varies deterministically, which are referred to as variable psets (see Naming Psets).
pset 3.all
The size of such an unbounded pset is not constant, since it contains all threads created during the life of the program. The size of this set will change as threads are created and destroyed.
Pset expressions that omit specifying the thread-part imply all threads, so that pset 2 means pset 2.all, and pset all means pset all.all, both of which are unbounded sets.
If a pset expression includes one or more unbounded psets, it is also unbounded.
The Prism environment places several restrictions on the use of unbounded psets. You cannot use an unbounded pset as the context for an event specification or a wait every command. For an overview of information about event specifications, see Overview of Events.
In the following example, both of these uses of the wait every command are illegal:
(prism all) wait every pset all ... (prism all) pset all (prism all) wait every |
Similarly, you may not use unbounded sets as the context for the stop or trace commands when these commands contain actions. Examples:
(prism all) stop in foo {print x} pset all ; illegal (prism all) stop in foo pset all ; legal, does not contain an action |
The Prism environment handles the psets that apply to the wait every, stop, and trace commands in a similar manner. When using a constant (bounded) pset, the Prism environment records the membership of the pset when the command is issued. When using an unbounded pset, the Prism environment reevaluates the pset each time the command executes. In the following example, foo is an unbounded pset.
(prism all) stop at 10 pset foo
Each time a thread executes line 10, the Prism environment reevaluates pset foo, and stops the thread if it is a member of foo.
The Prism environment enables you to control the contents of psets derived from unbounded sets of threads. You can specify a constant membership of such a pset by capturing snapshots of the unbounded sets. You capture snapshots of unbounded sets by including the snapshot (pset_expression) argument with any command that takes a pset qualifier.
Here is an example of how the contents of unbounded psets can vary:
After running the program for a while, the membership of all and all1 both change, as shown in the following example:
(prism all) command (pset_name) pset snapshot (expression)
In the following example, a snapshot pset, called snap1, is created. snap1 contains a subset of the threads in pset all, as defined by the snapshot expression.
Then, after running the program for a while, the membership of (all - 1.1) and snap1 differ, as shown in this example:
However, you can force the update of the membership of pset snap1 by issuing the eval pset command. For example,
(prism all)eval pset snap1 (prism all)show pset snap1 Pset 'snap1' is defined as 'snapshot ( all - 1.1 )'. The set contains the following threads: (0,2).(1,5,6), 1.(5,6) |
The following example shows a situation in which using an unbounded pset, all, generates an error. Note that, in a threaded program, all is equivalent to the unbounded set of all.all, which is the union of all processes and all threads. The use of the snapshot argument, however, avoids that error.
You cannot establish a current pset that contains non-existent threads. The pset command in the following example is wrong because it specifies a thread (5) that has not been created yet.
(prism all)show pset all The set contains the following threads: (0:3).1 (prism all)pset all.5 |
However, in certain contexts, such as setting breakpoints, you may use a pset qualifier containing nonexistent threads, as shown in the following example:
(prism all)stop in foo pset all.5 (prism all) |
You can use a Prism session to debug more than one Sun MPI job at a time. To debug a child or client program, it is necessary to launch an additional Prism session. If the child program is spawned using calls to MPI_Comm_spawn() or MPI_Comm_spawn_multiple(), Prism can (if enabled) debug the child program as well.
However, if an MPI job connects to another job, the current Prism session has control only of the parent or server MPI job. It cannot debug the children or clients of that job. This might occur, for example, when an MPI job sets up a client/server connection to another MPI job with MPI_Comm_accept or MPI_Comm_connect.
With the exception of programs using calls to MPI_Comm_spawn() or MPI_Comm_spawn_multiple(), to use the Prism environment to debug a Sun MPI program, the program must be written in the SPMD (single program, multiple data) style--that is, all processes that make up a Sun MPI program must be running the same executable.
The Prism environment uses the concepts of current file and current function.
The current file is the source file currently displayed in the source window. The current function is the function or procedure displayed in the source window. You might change the current file or function if, for example, you want to set a breakpoint in a file that is not currently displayed in the source window, and you don't know the line number at which to set the breakpoint.
In addition, changing the current file and current function changes the scope used by the Prism environment for commands that refer to line numbers without specifying a file, as well as the scope used by the Prism environment in identifying variables; see How the Prism Environment Chooses the Correct Variable or Procedure for a discussion of how the Prism environment identifies variables. The scope pointer (-) in the line-number region moves to the current file or current function to indicate the beginning of the new scope.
|
Note - The File window displays only files compiled with the -g switch. |
Note that if the function you choose is in a different source file from the current file, changing to this function also has the effect of changing the current file.
If the Prism environment cannot find a file--because you moved it or for some other reason--you can explicitly add its directory to the Prism environment's search path.
|
Note - No matter what the contents of your directory list are, the Prism environment searches for the source file first in the directory in which the program was compiled. |
| Prism 7.0 Software User's Guide
| 817-0088-10 |
|
Copyright © 2002, Sun Microsystems, Inc. All rights reserved.
