C H A P T E R 2 |
Using the Prism Environment |
This chapter describes, at an introductory level, various aspects of using the Prism environment. Succeeding chapters provide more detailed instruction on performing specific operations within the Prism environment.
The best way to learn how to use the Prism environment is to try it out for yourself as you read this chapter. The chapter is organized into the following sections:
This section describes the programming conditions under which you can make use of the Prism environment's features.
You can work on Sun Fortran (77, 90), C, and C++ programs within the Prism environment. However, support for debugging Fortran 90 and C++ programs is limited. These limitations are described in Appendix B.
The Prism environment supports the following compilers from Forte Developer 6 update 2 and the Sun ONE Studio 7, Compiler Collection:
To use the Prism environment's debugging features, compile and link each program module with the -g compiler option to produce the necessary debugging information.
If you compile programs with both the debugging option -g and an optimization option, such as -xO[1,2,3,4,5], the combined options change the behavior of several Prism commands. This topic is covered in Combining Debug and Optimization Options.
To enter the Prism environment, you must be logged in to a terminal or workstation that is running OpenWindows or the Common Desktop Environment (CDE).
Make certain that your DISPLAY environment variable is set for the terminal or workstation from which you are running OpenWindows or CDE. For example, if your workstation is named valhalla, you can issue this command (C shell example):
You can launch the Prism programming environment in four different ways:
When you start the Prism environment in MP program mode, you are essentially starting it along with a parallel processing environment. That parallel processing environment uses the number of processes, resource manager, and any other characteristics specified by the mprun(1) command. The syntax is:
mprun mprun-options prism prism-options
% mprun -np 4 -x lsf prism |
This example starts a multiprocessing environment with four processes under the control of the LSF resource manager, a host prism process, and four node prism processes, one for each of the four processes reserved by mprun(1). Valid prism-options for starting in MP program mode are:
prism-options --> [ -C | -CX ]
[ Xoption ]
[ < infile | > outfile ]
[ - install | -threads | -nothreads ]
[ program ]
If you include the name of a program on the prism command line, the Prism environment automatically loads the program when it completes the start process.
If you don't specify a program on the command line, the Prism environment starts without loading an MPI program. You can, however, load a program for debugging from within the Prism environment. See Loading a Multiprocess Program From Within the Prism Environment for more information.
You can specify other arguments with the program name to control various aspects of how the Prism environment deals with the program once it is loaded. Examples of this are provided in the following subsections.
Note - These descriptions all apply to launching and using the Prism environment in MP mode with its graphical user interface (GUI) enabled. See Appendix A for instructions on launching and using Prism's commands-only mode. See Appendix C for instructions on launching and using Prism's scalar mode. |
The number of processes you specify with the mprun-options have special meaning to the Prism environment. The following subsections illustrate the effect, including the special cases of -np 0 and -np 1:
When you want the Prism environment to debug a message-passing program with multiple processes distributed across multiple CPUs and nodes, simply use the mprun command's -np option to specify the number of processes that you want to run. When the program starts, the resource manager determines how the processes should be mapped to the available resources.
For example, the following command starts the Prism environment, loads the program a.out and, when the program is executed, causes eight instances of the program to be run under the control of the LSF resource manager.
% mprun -np 8 -x lsf prism |
The Prism environment creates a separate debug process for each MP process and uses these Prism processes to collect information about the MP processes and, if threads are present, about the threads.
It also creates a single administrative process that communicates with the Prism debug processes and provides the interface to the user. This main Prism process is referred to as Host Prism or the host process.
Each Prism debug process runs on the same node as the MP process to which it is attached.
If a program spawns additional MP processes during execution, the Prism environment creates a new debug session to support the newly spawned MP processes. This secondary debug session creates a set of secondary debug processes, one per spawned MP process. An MPI program can dynamically spawn MP processes via calls to the library functions MPI_Comm_spawn() or MPI_Comm_spawn_multiple(). See Enabling Support for Spawned MPI Processes for information about debugging spawned MP processes.
If you want to have one MP process running on each available CPU in a cluster, specify 0 for numprocs in the arguments to mprun.
% mprun -np 0 -x lsf prism a.out |
Note - You can also specify a single process to be run per node, regardless of how many CPUs the nodes contain. To do this, however, you need to pass additional runtime environment values to the program, which is done either through the arguments to mprun or the arguments to the resource manager under which the program runs. This topic is discussed, with examples, in Specifying Runtime Environment Options. |
To debug multiple threads, the Prism environment must be in MP mode with its multithread support features enabled.
The Prism environment automatically adopts a multithreaded view of a loaded program if that program has been linked to the libmpi_mt library or the libthread library.
However, when loading a threaded program that has not been linked to the libmpi_mt library, use the -threads argument to direct the Prism environment to view the program as threaded. Use of this option is illustrated below.
% mprun mprun-options [ rm-spec ] prism -threads program
In the following example, assume that a.out contains threads but was compiled without a link to libmpi_mt.
% mprun -np 4 -x lsf prism -threads a.out
The program a.out is executed as four processes and the Prism environment creates a separate debug process to handle each MP process. For each MPI process that is multithreaded, the corresponding debug process gathers debug information about each thread as well.
Note - If you specify the -threads option for a program that does not include threads, the Prism environment ignores the option. |
If you load a program that has been linked to the libmpi_mt library, but want to view only the main thread, specify the -nothreads option. This disables the Prism environment's support for multiple threads so that it views only the main stream of execution in that program.
% mprun mprun-options [ rm-spec ] prism -nothreads program
In the following example, assume that a.out was compiled with a link to libmpi_mt.
% mprun -np 4 -x lsf prism -nothreads a.out
This starts the Prism environment in MP mode with multithread support disabled. The program a.out will be executed as four processes, but the Prism debug processes will be aware only of the primary thread in each MPI process.
The MP mode is required for debugging multiple threads, even in a serial (single-process) program. This means you must specify the -np option of the mprun command to enable the MP mode, but with a numprocs value of 1.
% mprun -np 1 [ rm-spec ] prism -threads program
In the following example, the Prism environment starts in MP mode with support for debugging multiple threads enabled. The program a.out is executed as a single process.
% mprun -np 1 -x lsf -threads a.out
If you attempt to run the message-passing Prism environment in the background without specifying the -n flag to mprun, the Prism process hangs.
Once hung, you can either kill the Prism process manually from another terminal window using the mpkill command or put the Prism process in the foreground in your shell with the fg command, thereby releasing it from the freeze.
To run an MP Prism process in the background, add the -n flag to the mprun command line.
% mprun -n -np 4 prism &
You can attach the Prism environment to an MP program that is already running. One instance of the Prism environment is created for each process in the program, plus one for the host. All you need to provide is the job name or job names to which you want the Prism environment attached. The syntax for attaching Prism to a running parallel program is:
% prism [ program | -jid | -jid-list ] prism-options
Valid prism-options for attaching to a running MP program are:
prism-options --> [ program-name | - jid |- jid-list ]
[ -C | -CX ]
[ Xoption ]
[ < infile | > outfile ]
[ - install | -threads | -nothreads ]
The Prism environment loads the jobs you specify into the Prism environment. The processes are interrupted, and you can then work with the program in the Prism environment as you normally would. For more information, see Attaching to a Running Message-Passing Process.
You can start the Prism environment for use with serial (scalar) programs, by using this syntax:
% prism program-name prism-options
Valid prism-options for starting in serial program mode are:
prism-options --> [ -C | -CX ]
[ Xoption ]
[ < infile | > outfile ]
[ - install | -threads | -nothreads ]
You can attach the Prism environment to a running serial program by using this syntax:
% prism [ program | - pid ] prism-options
Valid prism-options for starting in serial program mode are:
prism-options --> [ -C | -CX ]
[ Xoption | core-file ]
[ < infile | > outfile ]
[ - install | -threads | -nothreads ]
When attaching to a running serial program in this manner, the Prism environment must be started on the same node on which the process is running.
There are several things you should know after starting the Prism environment:
After the Prism environment is started, you can load programs in either of the following ways:
Once a program is successfully loaded, the following conditions are in effect:
You can now issue commands to execute and debug the program.
Note - If the program's source file can't be found--either when trying to load at Prism startup or when trying to load from within the Prism environment--the Prism command window displays a warning message. You can instruct the Prism environment to search for the file in other directories with the Use selection on the File menu. See Creating a Directory List for Source Files for details. |
In the MP mode of the Prism environment, the Prism prompt includes the current pset, such as (prism all).
If the program to be debugged includes calls to either MPI_Comm_spawn() or MPI_Comm_spawn_multiple(), you need to set the follow_spawn Prism environment variable to on before the program reaches the first spawn function call. Otherwise, the Prism environment cannot create a new debug session to handle the spawned processes. You can set this environment variable by entering the following in the Prism command window.
(prism all) set follow_spawn = on
When follow_spawn is set to on and a spawn function call occurs, the Prism environment creates one or more secondary debug sessions, depending on the following circumstances:
Like the primary Prism processes, each secondary Prism process is located on the same node as the spawned MPI process to which it is attached.
Some Prism commands that are issued in a primary Prism debug session affects secondary Prism sessions. Others do not. For information about which commands cross primary/secondary Prism session boundaries, see Prism Commands With Special Functions in Spawned Sessions.
Also, secondary Prism sessions may not acquire every Prism option that is specified in the primary Prism session that spawned them. For a list of Prism options and their acquisition by secondary sessions, see Passing Command-Line Options to Secondary Sessions.
To disable Prism support for debugging dynamically spawned processes, set the follow_spawn environment variable to off.
Since the Prism environment creates a separate debugging session for each executable spawned by a call to MPI_Comm_spawn_multiple(), aggressive use of this function could lead to hundreds of Prism debug windows being opened. This could seriously complicate the task of tracking all the processes being debugged.
You can avoid this problem by limiting the creation of secondary debug sessions to a subset of the spawned executables. To do this, set the debug_spawn_aout variable, listing the names of the spawned executables to be debugged. The syntax for setting the debug_spawn_aout variable is
(prism all) set debug_spawn_aout = "aout_list"
For example, if a call to MPI_Comm_spawn_multiple() in the program alpha spawns the executables alpha, beta, and gamma, you can limit the creation of secondary debug sessions to beta and gamma by entering the following in the Prism command line:
(prism all) set debug_spawn_aout = "beta gamma"
The primary Prism session continues to debug alpha processes and secondary Prism sessions debug beta and gamma. The executable alpha is still spawned, but the Prism primary debug session does not create a secondary debug session for it.
If you expect to use the same aout_list in multiple successive debug sessions, you can store and reuse it automatically by storing it in the optional Prism initialization file .prisminit. When this file exists, the Prism environment automatically executes the commands contained in the file when it starts up.
For example, if you add the following lines to the .prisminit file:
set follow_spawn=onset debug_spawn_aout="beta gamma" |
the next time the Prism environment starts up, it will have spawn debugging enabled, but restricted to the spawned executables beta and gamma.
When debugging multiple sets of executables that have been created by calls to MPI_Comm_spawn_multiple(), the Prism process numbers might not coincide with the MPI ranks of the processes. In FIGURE 2-1 alpha first spawns beta. Then beta spawns further instances of beta and gamma. The rank of each instance of alpha, beta, and gamma in their respective MPI_COMM_WORLD is zero. The processes in each instance number from 0 (zero) to n-1. However, in the Prism session debugging beta, there are three instances of beta. Their processes, in the Prism session, number from 0 (zero) to 3n-1.
For information about using the Prism environment to debug multiple sessions, see Debugging Spawned Sun MPI Processes.
You can attach to a message-passing job or process that is currently running. If attaching to a process, the Prism environment must run on the same system on which the process is running. If attaching to a job, the Prism environment must be running on the same cluster as the job.
See Attaching to a Running Message-Passing Process for more information about attaching to and detaching from a running serial process or a message-passing job.
You can associate a core file with a single-process program or a particular process of a multiprocess program.
To Associate a Program or Process With a Core File at Startup |
% mprun mprun-options prism program corefile
or (if you have launched the Prism environment and loaded a single-process program),
See Associating a Core File With a Loaded Program for more information about core files.
You can include most standard X toolkit command-line options when you issue the prism command; for example, you can use the -geometry option to change the size of the main Prism window. See your X documentation for information on these options. Also, note these limitations:
X toolkit options are ignored if you use -C to run the Prism environment with the commands-only interface.
% mprun mprun-options prism < input-file
This specifies a file from which the Prism environment is to read and execute commands upon startup.
Note - When the TERM environment variable is not set before starting the Prism environment, the Prism environment does not echo input when commands are read from a file. |
% mprun mprun-options prism > log-file
This specifies a file to which the Prism environment commands and their output are to be logged.
If you have created a .prisminit initialization file, the Prism environment automatically executes the commands in the file when it starts up. See Initializing the Prism Environment for information on .prisminit.
You can specify runtime environment options either with the mprun command options or with the command options of the resource manager. See the Sun HPC ClusterTools User Guide for more information.
When debugging programs that make calls to MPI_Comm_spawn() or MPI_Comm_spawn_multiple(), the Prism environment creates special node Prism processes to debug the processes created by the spawn calls. These special node Prism processes are sometimes called secondary Prism sessions.
Secondary Prism sessions acquire some, but not all, options that you have set when you launch the primary Prism session. The acquisition status of Prism command-line options is described in TABLE 2-1.
The following three methods can be used for performing most Prism environment actions:
You can point and click with a mouse in the Prism environment to choose menu items and to perform actions within windows and dialog boxes.
In any window where you see this mouse icon:
you can left-click on the icon to obtain information about using the mouse in the window.
Note - The Prism environment assumes that you have a standard three-button mouse. |
You can use a keyboard to perform many of the same functions you can perform with a mouse. This section lists the supported keyboard alternatives.
In general, to use a keyboard alternative, the focus must be in the screen region where you want the action to take place. The focus is generally indicated by the location cursor, which is a heavy line around the region.
General keyboard alternatives to mouse control are listed in TABLE 2-2.
The keys and key combinations described in TABLE 2-3 work on the command line and in text-entry boxes -- that is, fields in a dialog box or window where you can enter or edit text.
In addition, you can use keyboard accelerators to perform actions from the menu bar; see Keyboard Accelerators for Main Menu Selections.
You can issue commands in the Prism environment from the command line in the command window. Most commands duplicate functions you can perform from the menu bar. Some functions, however, are only available via commands. See the Prism Reference Manual for complete information about Prism commands. See Using the Command Window for instructions on entering commands in the command window.
Many commands have the same syntax and perform the same action in both the Prism environment and the Solaris debugger dbx. There are differences, however; you should check the reference description of a command before using it.
The menu bar is the line of titles across the top of the main window of the Prism environment.
Each title is associated with a pull-down menu from which you can perform actions within the Prism environment.
A keyboard accelerator is a shortcut that lets you choose a frequently used menu item without displaying its pull-down menu. Keyboard accelerators consist of the Control key plus a function key; you press both at the same time to perform the action. The keyboard accelerator for a keyboard menu selection is displayed next to the name of the selection. If nothing is displayed, there is no accelerator for that selection.
The keyboard accelerators (on a Sun keyboard) are listed in TABLE 2-4.
The source window displays the source code for the executable program loaded into the Prism environment. (Chapter 3 describes how to load a program into the Prism environment and how to display the different source files that make up the program.) When you execute the program and execution then stops for any reason, the source window updates to show the code being executed at the stopping place. The Source File field at the top of the source window lists the name of the file displayed in the window.
You can resize the source window by dragging the small resize box at the lower right of the window. If you change the window's size, the new size is saved when you leave the Prism environment.
You cannot edit the source code displayed in the source window. This must be done within an editor, which can be called up from within the Prism environment. See Chapter 6 for instructions on editing programs.
You can move through a source file displayed in the source window by using the scroll bar on the right side of the window. You can also use the up and down arrow keys to scroll a line at a time, or press the Control key along with the arrow key to move half a page at a time.
To return to the current execution point, type Control-X in the source window.
The /regexp command searches forward in the file for the string (or regular expression) that you specify and repositions the file at the first occurrence it finds. The ?regexp command searches for the string (or regular expression) in the reverse direction.
You can select text in the source window by dragging over it with the mouse; the text is then highlighted. Or double-click with the mouse pointer on a word to select that word. Left-click anywhere in the source window to deselect text.
Right-click in the source window to display a menu that includes actions to perform on the selected text, as shown in FIGURE 2-2. For example, select Print to display a visualizer containing the value(s) of the selected variable or expression at the current point of execution. See Chapter 5 for a discussion of visualizers and printing. To close the pop-up menu, right-click anywhere else in the main window.
You can display the definition of a function by pressing the Shift key while selecting the name of the function in the source window. This is equivalent to choosing the Func selection from the File menu and selecting the name of the function from the list. When selecting the function name, highlight only the name, not arguments to the function.
You can split the source window to simultaneously display the source code and assembly code of the loaded program.
1. Load the program of interest.
2. Right-click in the source window to display the pop-up menu.
3. Click on the Show source pane selection in the pop-up menu.
4. Choose the Show .s source selection from the menu.
This causes the assembly code for your program to be displayed in the bottom pane of the window, as shown in FIGURE 2-3.
1. Right-click in the pane you want to close.
2. Choose Hide this source pane from the pop-up menu.
The line-number region shows the line numbers associated with the source code displayed in the source window. FIGURE 2-4 shows a portion of a line-number region, with a breakpoint set.
You will see the following symbols in the line-number region:
Note - If a breakpoint and tracepoint are both set at a given line, the breakpoint is indicated, but not the tracepoint. |
The command window is the area at the bottom of the main window in which you type commands and receive Prism output.
The command window consists of two boxes: the command line at the bottom and the history region above it. FIGURE 2-5 shows a command window.
You can resize the command window and scroll through it independently of the main window. If you do not intend to issue commands in the command window, you might want to make this window smaller so that you can display more code in the source window. If you use the command window frequently, you might want to make it bigger. If you change the size of the window, the new size is saved when you leave the Prism environment.
You can type in the command-line box whenever it is highlighted and an I-shaped cursor, called an I-beam, appears in it. See TABLE 2-3 for a list of keystrokes you can use in editing the command line. Press Return to issue the command. Type Control-C to interrupt execution of a command (or choose the Interrupt selection from the Execute menu).
You can issue multiple commands on the Prism command line, separating them with semicolons (;). There is one exception to this--you cannot follow a file name argument with a semicolon because the Prism environment parses it as part of the file name.
The Prism environment keeps the commands that you issue in a buffer. Type Control-P to display the previous command in this buffer. Type Control-N to display the next command in the buffer. You can then edit the command and issue it in the usual way.
During long-running commands (for example, when you have issued the run command to start a program executing), you may still be able to execute other commands. If you issue a command that requires that the current command complete execution, you receive a warning message and the Prism environment waits for the command to complete.
Commands that you issue on the command line are echoed in the history region, above the command line. The Prism environment's response appears beneath the echoed command. The Prism environment also displays other messages in this area, as well as command output that you specify to go to the command window. Use the scroll bar at the right of this box to move through the display.
To Specify the Maximum Number of Lines in the History Region |
(prism all) set $history = value
This limits the maximum number of lines in the history buffer to 2000. The default is 10,000.
The Prism environment uses memory in maintaining a large history region. A smaller history region, therefore, may improve performance and reduce the chances of the Prism environment running out of memory.
1. Select text using one of these methods:
2. Click the middle mouse button to paste the selected text into other text areas.
1. Triple-click on a line in the history region to select it.
2. Click the middle mouse button with the mouse pointer still in the history region.
3. Click the middle mouse button with the mouse pointer on the command line.
The selected text appears on the command line but is not executed. This gives you an opportunity to edit the text before executing it.
(prism all) where @ where.output
This puts the output of the where command (a stack trace) into the file where.output in your current working directory within the Prism environment. This method works for most commands.
This directs the output of the where command to the Prism environment window specified by the window argument. The argument window must be one of:
This displays the output of the list command in a dedicated window. Some commands that have equivalent menu selections display their output in the standard window for the menu selection.
Note - The output of edit, make, and sh cannot be redirected. The output of run can, however, be redirected by > and other shell redirection conventions. |
You can use the log command along with the source command to replay a session in the Prism environment. When replaying a Prism session, however, you must edit the log file to remove Prism output.
Use the log file for logging commands and output from within the Prism environment.
The log file filename will be located in the current directory. This can be helpful in saving a record of a Prism session. For example,
logs output to the file prism.log.
where filename is the name of the log file.
While working in the Prism environment, there are circumstances in which you may want to write expressions that the Prism environment will evaluate. For example, you may want to print or display expressions or specify an expression as a condition under which an action is to take place. You can write these expressions in the language of the program you are working on. This section discusses additional aspects of writing expressions.
Multiple variables and procedures can have the same name in a program. This can be a problem when you specify a variable or procedure in an expression. To determine which variable or procedure you mean, the Prism environment tries to resolve its name by using these rules:
1. Prism first tries to resolve the name using the scope of the current function. For example, if you use the name x and there is a variable named x in the current function or the current file, the Prism environment uses that x. The current function is ordinarily the function at the program's current stopping point, but you can change this, as described in Choosing the Current File and Function.
2. If this fails to resolve the name, the Prism environment goes up the call stack looking for the variable x in the caller of the current function, and then its caller, and so on, following the scoping and visibility rules of the current language.
3. If no match is found in any routine active on the stack, the Prism environment searches the static and global name spaces. If no match is found there, the Prism environment prints an error.
4. If the name is not found in the call stack, the Prism environment arbitrarily chooses one of the variables or procedures with the name in the source code. When the Prism environment prints out the information, it adds a message of the form "[using qualified name]". Qualified names are discussed below.
You can override the way that the Prism environment resolves names by qualifying the name.
A fully qualified name starts with a back-quotation mark, or back-quote, (`). The symbol farthest to the left in the name is the load object, followed optionally by the file, followed optionally by the procedure, followed by the variable name. Each element is preceded by a backquote (`). Examples of the Prism environment's identifier syntax are shown in TABLE 2-5.
This command displays the fully qualified name, as described below.
Partially qualified names do not begin with `, but have a ` in them. For example,
In this case, the Prism environment looks up the function name on the left first and picks the innermost symbol with that name that is visible from your current location. This is useful primarily in referring to variables in routines on the call stack.
Use the whereis command to display a list of all the fully qualified names that match the identifier you specify.
The Prism environment assigns its own names to variables in local blocks of C code. This approach disambiguates variable names, in case you reuse a variable name in more than one of these local blocks.
When debugging Fortran, the Prism environment attempts to be case-insensitive in interpreting names, but uses case to resolve ambiguities.
The Prism environment supports the use of a subset of Fortran intrinsic functions in writing expressions; the intrinsics work for all languages that the Prism environment supports, except as noted below.
The intrinsics, along with the supported arguments, are:
The intrinsics can be either uppercase or lowercase.
The Prism environment handles arrays slightly differently from the way C handles them.
For example, in a C program, you might make the following declaration and use a in an expression:
The type of a converts from "array of ints" to "pointer to int". Following the rules of C, therefore, a Prism command like this one should print a hexadecimal pointer value:
Instead, it prints two more than each element of a (that is, a[0] + 2, a[1] + 2, etc.). This enables you to do array operations and use visualizers on C arrays in the Prism environment. The print command and visualizers are discussed in Chapter 5.
To get the C behavior, issue the command as follows:
You can use Fortran 90 array-section syntax when specifying C arrays. This syntax is useful, for example, if you want to print the values of only a subset of the elements of an array. The syntax is:
(lower-bound: upper-bound: stride)
You must enclose the values in parentheses (rather than brackets), as in Fortran. If your array is multidimensional, you must separate the dimension specifications with commas within the parentheses, again as in Fortran.
For example, if you have the following array:
you can issue the following command to print the values of elements 2-4 of the first dimension and 2-10 of the second dimension:
The Prism environment provides expressions that you can use to detect NaNs (values that are "not a number") and infinities in your data. These expressions derive from the way NaNs and infinities are defined in the IEEE standard for floating-point arithmetic.
For example, if x is an array, issue this command to print only the elements of x that are NaNs:
(prism all) where (x .ne. x) print x
The print command is discussed in Chapter 5.
Also, note that if there are NaNs in an array, the mean of the values in the array will be a NaN. The mean is available via the Statistics selection in the Options menu of a visualizer--see Chapter 5 for details.
(prism all) (x * 0.0 .ne. 0.0)
You can use Fortran 90 generic procedures in any Prism command or dialog box that asks for a procedure. If you do so, the Prism environment prompts you for the name(s) of the specific procedure(s) you want to use.
For example, you use the syntax stop in procedure to set a breakpoint in a procedure. If you use this syntax for a generic procedure in the Prism graphical interface, a dialog box like the one shown in FIGURE 2-6 is displayed.
The commands-only interface of the Prism environment prompts you in a similar fashion, as shown below:
If you choose 0 or press Return, the command is cancelled. If you choose another number, the Prism environment sets the breakpoint(s) in the specified procedure(s). For example, the following sets the breakpoint in the fadd procedure that uses real*4 data.
You can issue Solaris commands from within the Prism environment.
Perform one of the following operations:
Note - For instructions on starting the default editor from the Prism command window, see To Start the Default Editor on the Current Source File. |
Some Solaris commands have equivalents in the Prism environment, as described below.
Use the standard Solaris shell commands, such as pwd, cd, and ls, to manage your current working directory. By default, your current working directory within the Prism environment is the directory from which you started the Prism environment.
The Prism environment interprets all relative file names with respect to the current working directory. The Prism environment also uses the current working directory to determine which files to show in file-selection dialog boxes.
You can set, unset, and display the settings of environment variables from within the Prism environment, just as you do in the Solaris environment.
To Kill a Process or Job Running Within the Prism Environment |
Issuing a kill command in the primary Prism session also kills all of the secondary Prism sessions.
1. Perform one of the following:
If you have created subprocesses, such as Solaris shells, while in the Prism environment, the Prism environment displays a message before exiting. For example, see FIGURE 2-7:
2. Take one of the following actions:
Issuing the quit command without any options quits only the session in which it is invoked.
To quit all Prism sessions--in primary and secondary sessions--use quit -all in the primary Prism session.
Note - The -all option is valid only in the primary session. |
If you brought the job into the Prism environment using the attach command, quit -all leaves the job's processes running and closes both the primary and secondary Prism sessions.
The Quit selection on the Prism File menu has the same effect as the quit command without the -all argument.
Copyright © 2002, Sun Microsystems, Inc. All rights reserved.