Invoking the debugger

From the UNIX desktop, the debugger may be invoked in one of four ways:

1. By dragging an object file from a folder and dropping it onto the debugger's icon in the Desktop_Tools folder of the Application Manager. This will start the debugger with the dropped object file as a created process. This has the advantage of making the debugger's current directory the same as the folder in which the object file appears. The disadvantages are that you cannot give the debugger or created object any options, or redirect the debugged object's I/O, and you cannot drag and drop a core file onto the debugger's icon. However, you can drag an entry from the /proc folder and drop it on the debugger's icon to grab a running object.

2. By double clicking on the debugger's icon in the Desktop_Tools folder of the Application Manager. This will start up the debugger with an empty Source window. From there, you may create or grab processes with the options in the ``Debug menu''. This will let you pass options to the debugged processes, but not to the debugger itself. This method also has the disadvantage that the debugger's current working directory may have no connection with the directory of the file you want to debug. You can set the current working directory with the ``Change Directory'' option which is in the ``File menu'' of the Source, Process, and Command windows in the debugger's default configuration.

3. By clicking the right mouse button on the icon in the File Manager that represents the executable you want to debug. A popup menu will display a Debug option. You can select this option to start the debugger with the icon's object file as the created process. This has the advantage of making the debugger's current directory the same as the folder in which the object file appears. The disadvantages are that you cannot give the debugger or created object any options, or redirect the debugged object's I/O.

4. By typing debug options in an xterm window. Even though you type a command to start the debugger, this will still invoke the graphical interface. You may, however, use the command line interface by typing debug -ic (ic for interface, command). Although this is more work than clicking on an icon, this method is the most flexible, allowing you to create processes with options, grab running processes, or grab core files from the command line. See debug(1) for the options available.

   The -X option lets you pass options specific to the graphical user interface. For example,

   $ debug -X-iconic
   

   will bring up the initial debugger windows as their respective minimized icons. You can also use the -X option to specify such things as fonts and colors. For example,

   $ debug -X"-background green"
   

   will make green the background color for all the debugger's windows, and

   $ debug -X '-xrm "debug*Source*background: green"'
   

   will set the background color in the Source window only. Note that the -X option takes only one argument, so any option that you want to pass through with whitespace in it must be quoted.

   In this method, the debugger's current working directory will be the same as the xterm window's.

Several of the properties that can be set from the options in the ``Properties menu'' can also be set as customizable resources (see ``Resource settings'') or may be set from the command line. The command line options are:

• -command_level level - level may be one of PROGRAM, PROCESS or THREAD (case is insignificant). This specifies whether debugger commands apply by default to the current thread, all threads in the current process or all threads in the current program. See ``Granularity''.

• -config dirname - dirname is the full or relative pathname of the directory containing the configuration files for the debugger. The default configuration directory is /usr/ccs/lib/debug_config. See ``Configuration'' under ``Customization'').

• -dis_mode mode - mode may be one of SOURCE or NOSOURCE (case is insignificant). This specifies whether the disassembly pane displays source interspersed with the machine instructions. See ``Disassembly Mode''.

• -event_action action - action may be one of BEEP, MESSAGE, RAISE, or NONE (case is insignificant). This specifies the behavior of the debugger when an event triggers in a subject process. See ``Output Action''.

• -event_level level - level may be one of PROGRAM, PROCESS or THREAD (case is insignificant). This specifies whether debugger events apply by default to the current thread, all threads in the current process or all threads in the current program. See ``Granularity''.

• -iconic - if present instructs debug to come up in iconified mode.

• -output_action action - action may be one of BEEP, MESSAGE, RAISE or NONE (case is insignificant). This specifies the behavior of the debugger when a subject process generates output. See ``Output Action''.

• -source_no_wrap - if present, source displayed in the source pane will not wrap to the following line if too long to fit on a single line. A horizontal scroll bar will allow viewing of the long lines. See ``Source pane''.

• -symbols type[,type..] - type may be any of LOCAL, FILE, GLOBAL, DEBUGGER or USER (separated by commas, case is insignificant). This specifies the types of symbols to be displayed in the ``Symbol pane''. See ``Symbols''.

• -thread_action action[,action] - action may be either NONE, STOP, BEEP or both STOP and BEEP (list both, separated by a comma, case is insignificant). This specifies the behavior of the debugger when a thread changes state. See ``Output Action''.

Using all three methods of invocation, you may create or grab additional processes using the ``Create'', ``Grab process'', and ``Grab core'' popup windows. Note that threads can only be created under programmatic control, and also cannot be individually grabbed.