|
|
The Debug menu in the default debugger configuration allows you to create and grab processes, view core images and release processes. Clicking MENU on the Debug button brings up a menu with different options, depending on which panes are present in the window. The following options appear in the Debug menu of one or more windows in the default configuration (remember that you can configure the Debug menu to have different options, or can move these options to different menus):
The Create popup window lets you create one or more processes. You may specify the file to create by dragging an object file from a folder in the desktop and dropping it onto the Create window, or by typing the pathname of the object file in the ``Command Line'' field. The shell-style command line may include input and/or output redirection and may include a shell pipe. All resulting processes are stopped at the ``Location'' specified in the ``Starting Location'' field. If you specify a function other than main, and the function cannot be found in a process' address space, the process will be stopped at the function main. If main cannot be found, the process will be stopped at the address specified in the object file's header. When a multi-threaded process is created, it will have an initial ``main'' thread. The main thread is stopped at the specified location.
Since the processes or threads are halted after creation, you must then use one of the commands in the ``Control menu'' to start them running.
If the Capture I/O option is selected, the input and output of the process is captured and displayed in the Transcript area of the ``Command pane'' and input to the process must be entered with the ``Input'' popup window. If the Capture I/O option is not selected, the output of the process will go to the debugger's parent xterm window, and input is entered by typing in that window. This behavior is most useful when you are debugging a curses-based program, or one that is highly interactive. Capture I/O should always be selected if the debugger was invoked from its icon rather than from an xterm window.
The Follow Child Processes option controls the debugger's behavior if any of the created processes or threads fork. If Follow Child Processes is not selected, the debugger will not control the child process. If it is selected, the debugger will control the child process and any of its threads (the process may be released from debugger control using the ``Release'' command). All threads created by a subject process will be followed by the debugger (but may also be released using the ``Release'' button). The ``Output Action'' popup window lets you control the debugger's behavior with respect to newly created threads.
If the Kill Processes From Previous Create option is selected, all processes resulting from the previous create command are killed. This lets you restart processes without having to specifically find and kill all the remaining processes.
If the New Window Set option is not selected, the created processes are all added to the Create window's window set. If New Window Set is selected, a new window set is created, and all the created processes will be controlled by the new window set. In both cases, the first program in the pipeline becomes the current process in the controlling window set.
If you create processes with a ``Script'' or through the ``Command pane'', the ``Command Line'' field in the Create window will be updated to reflect the most recent create command.
In the debugger's default configuration, the Create option is available in the ``Debug menu'' of the Process and Source windows.
The Grab Core popup window lets you open a core file and its corresponding object file for examination. Enter the names of the core and object on the corresponding lines in the window.
If the New Window Set option is selected, a new window set will be created to display the grabbed core image, otherwise the core image will be displayed in the popup window's parent window set. In both cases, the grabbed core image will become the current process in its window set, and the thread that encountered the fault will become the current thread, if possible.
Grabbed core images may be examined using all of the commands available for examining live processes, but may not be altered or run.
In the debugger's default configuration the Grab Core option is always available in the ``Debug menu'' of the Process and Source windows.
The Grab Process popup window lets you take control of a live process. The window contains a scrolling list of processes you may grab (the processes other than the debugger itself with the same user ID). You may select more than one process from the list. The list of processes is searchable. See ``Searching in lists''.
By default, debug loads symbolic information for the process from the object file from which the process was created. You may enter on the ``Object File'' line the name of an alternate object file from which to load symbolic information. This is useful when debugging long running applications that have no symbol information. If you enter a file name on the ``Object File'' line you must select only one process from the list.
If the New Window Set option is not selected, the grabbed processes are all added to the Grab Process window's window set. If it is selected, a new window set is created, and all the grabbed processes will be controlled by the new window set. In both cases, the selected item that appears first in the list will become the current process in its window set. If that process uses the threads interfaces, the debugger will randomly select a thread from that process to become the current thread.
The Follow Child Processes option controls the debugger's behavior if any of the grabbed processes fork. If Follow Child Processes is not selected, the debugger will not control the child process. If it is selected, the debugger will control the child process (the process may be released from debugger control using the ``Release'' button). All threads created by a subject process will be followed by the debugger (but may also be released using the ``Release'' button). The ``Output Action'' popup window lets you control the debugger's behavior with respect to newly created threads.
In the debugger's default configuration the Grab Process option is always available in the ``Debug menu'' of the Process and Source windows.
The Release menu option lets you release one or more processes or threads from the debugger's control. Clicking SELECT on Release brings up a popup menu with two options, Release Running and Release Suspended. If you choose Release Running, the processes or threads are released and allowed to run. If threads are selected, the Release Suspended option will not be available, since individual threads cannot be released in a stopped state. For processes, if you choose Release Suspended, the processes are released in a stopped state, and can be grabbed again later. To release a threaded process in a stopped state, you can either select all threads of the process, and then select Release Suspended, or select one of the child threads, set ``Granularity'' Property's ``Other commands apply to'' option to Parent Process, and then select Release Suspended. If the latter is used, be warned that unless the Granularity Property is reset, all subsequent commands will apply to the parent process.
If any processes or threads in the ``Process pane'' are selected, those processes or threads are released, otherwise the current process or thread is released.
Both grabbed and created processes (see ``Grab process'' and ``Create'') may be released.
In the debugger's default configuration the Release option is found in the ``Debug menu'' of the Process and Source windows. The Release option is not available if there are no processes or threads in the window set.