Tru64 UNIX
Ladebug Debugger Manual
Previous Contents Index

1.6 Preparing for and Starting a Debugging Session

This section explains how to:

1.6.1 Compiling and Linking a Program

Direct the compiler (normally with the -g flag; use the appropriate flag for your compiler) to produce an executable file that includes full symbolic debugging information.

Some systems provide variants of the flag (-g1, -g2, and so on). These give different levels of symbol information and optimization.

Some compilers optimize the object code to reduce the size of the program or to make it run faster. For example, some optimization techniques eliminate certain variables. In addition to building symbolic information, the -g flag disables optimization of your program so that you can debug it more easily. For detailed information on compiling and linking, see the chapter on your language or your compiler documentation.

Ladebug can debug programs with less than complete symbolic information. (See Chapter 14 for details.)

The following example shows how to compile and link a C program named eightqueens before using the debugger. The compiler is invoked from the C shell (%). In the following example, the file eightqueens.c contains the program's source code. 


% cc -g eightqueens.c -o eightqueens

The cc command invokes both the compiler and the linker. (For more information about compiling that is specific to a particular language, see the documentation furnished with that language.)

The -g flag directs the compiler to write the symbolic information associated with eightqueens.c into the program file eightqueens (in addition to the code and data for the program). This symbol information allows you to use the names of variables and other symbols declared in eightqueens.c when using the debugger. If your program's source code is in several files, you must compile each file whose symbols you want to reference with the -g flag.

1.6.2 Starting the Debugger Within CDE

The debugger is integrated with the common UNIX desktop user environment, CDE (Common Desktop Environment). For more information about using CDE, see the CDE User's Guide. This section explains the most common ways to start the debugger GUI from within the CDE environment.

To start the debugger and bring your program under debugger control:

  1. From the CDE Front Panel, click on the Application Manager icon (Figure 1-1).

    Figure 1-1 CDE Application Manager Icon

  2. From the CDE Application Manager group window, double click on the Developer's Toolkit icon (Figure 1-2) to open the Developer's Toolkit group.
    You can move icons from the Developer's Toolkit group into another group or to the front of the Control Panel depending on your preference. See the CDE User's Guide for more information.

    Figure 1-2 CDE Developer's Toolkit Icon

  3. From the Developer's Toolkit group, double click on the Ladebug icon (Figure 1-3).

    Figure 1-3 CDE Ladebug Icon


    To access the Ladebug release notes, double click on the README.Ladebug icon.
  4. When you double click on the Ladebug icon, a dialog box appears in which you can enter the name of the executable file you want to debug. You can drag an executable file from the CDE File Manager into the dialog box space for file name.
    Alternatively, you can drag an executable file from the CDE File Manager onto the Ladebug icon in the Developer's Toolkit group to start the debugger using that executable.
    If you do not specify a file to debug, click on OK and the debugger starts up as shown in Figure 1-4. The Main Window remains empty until you bring a program under debugger control (see step 6). Upon startup, the debugger executes any user-defined initialization file.

    Figure 1-4 Debugger Window at Startup


  5. Bring a specified program under debugger control by using the following steps:
    1. Choose File:Run New Program... on the Main Window. The Run New Program dialog box appears, listing the files in your working directory. Figure 1-5 shows the Run New Program dialog box as it appears if the debugger is not invoked from within CDE. If you invoke the debugger from within CDE, this dialog box displays "Enter path or folder name" in place of "Filter", and an additional window section entitled "Folders".

      Figure 1-5 Running a Program by Specifying a Program File

    2. Click on Filter to display the programs available in the subdirectory. In Programs, click on the name of the program file to be debugged. The program field now shows the program file name.
    3. Enter any debugger options in Debugger Options: field. For more information, see the online help about Command Options or the ladebug (1) reference page.
    4. Enter any program arguments in the Program Arguments: field.
    5. Enter the name of the program core dump file in the Core File: field. If such a core file exists in the current directory, you can use the debugger to look at the state of the program when it failed.
    6. Toggle the Set Initial Breakpoint and Run button, if necessary.
      The default position for the Set Initial Breakpoint and Run toggle is on. If the toggle is on, the debugger:
      • Loads the program.
      • Sets the initial breakpoint on the program's main entry point.
      • Issues the run command to execute the program to that breakpoint.

      If the toggle is off:
      • The debugger loads the program. A breakpoint at the program's entry point is not set and execution of the program does not commence.
      • If you linked your program with the ald command or the amake command, both of which are specific to Ada programs, the command line will be initially case insensitive.
      • You must enter a run command or press the Continue button at the prompt to execute the program. This will cause the program to run to completion, if you have not set any breakpoints.

      The off toggle selection is useful for the following tasks:
      Type of Debugger User Task
      All debugger users Examine a core file.
      Expert debugger users Set initial breakpoints in program initialization code in the command interface or GUI.
      Ada debugger users Debug Ada package elaboration routines.
    7. Click on OK.

When the program is under debugger control and the Set Initial Breakpoint and Run toggle is on, the debugger:

Figure 1-6 Source Display at Startup

You can now debug your program.

1.6.3 Starting the Debugger Within Emacs

You can control your debugger process entirely through the Emacs GUD buffer (see Section 1.6.3.3), which is a variant of Shell mode. All the Ladebug commands are available, and you can use the Shell mode history commands to repeat them.

Ladebug Version 3.0 supports GNU Emacs Version 19.22 and above.

The information in the following sections assumes the user is familiar with Emacs and is using the Emacs notation for naming keys and key sequences.

1.6.3.1 Loading Ladebug-Specific Emacs Lisp Code

For each Emacs session, before you can invoke Ladebug, you must load the Ladebug-specific Emacs lisp code, as follows: 


M-x load-file /usr/lib/Emacs/lisp/ladebug.el

You can also place a load-file command in your Emacs initialization file (~/.Emacs). For example, 


load-file ".../ladebug.el"

1.6.3.2 Invoking Ladebug Within Emacs

To start Ladebug within Emacs and specify the name of the target program you want to debug, enter: 


M-x ladebug [target-program]

1.6.3.3 Emacs Debugging Buffers

When you start Ladebug, Emacs displays the GUD (Grand Unified Debugger) buffer in which the (ladebug) prompt is displayed. The GUD buffer saves all of the commands you enter and the program output for you to edit.

When you issue the Ladebug run command in the GUD buffer and hit a breakpoint, Emacs displays the source of your program in a second buffer (source buffer) and indicates the current execution line with =>.

By default, Emacs sets its current working directory to be the directory containing the target program. Ladebug does not do this when invoked directly, therefore you may need to change the source code search path when using Ladebug from within Emacs. To set an alternate source code search path, enter the use command with a directory argument, for example: 


(ladebug) use usr/prog/test

All Emacs editing functions and GUD key bindings are available. For example:

For more information on Emacs functionality and key bindings, refer to Emacs documentation.

1.6.4 Starting the Debugger from the Shell

There are several ways to start the debugger from the shell and bring a program under debugger control. For example, you can invoke the debugger from the shell and specify:

Once you have invoked the debugger, you can bring a process or program under debugger control from the the debugger prompt by attaching to a process or loading a program. For applications that fork and/or exec, you can also control whether to bring the child process under debugger control.

1.6.4.1 Invoking the Debugger from the Shell

To bring a program or process under debugger control from the shell, choose the appropriate syntax for invoking the debugger. The following examples show how you can use the dxladebug command to invoke the debugger GUI. To invoke the command interface, use the same options with the ladebug command . See Part 5 for more information.

1.6.4.2 Bringing a Program Under Debugger Control from the Ladebug Prompt

To bring a program or process under debugger control after invoking the debugger from the shell, do the following:

For information about attaching to a process, see Section 3.2.8. For information about loading image and core files, see Section 9.1.7.

1.6.5 When Your Program Completes Execution

When your program completes execution normally during a debugging session, the debugger issues the following message: 


Process has exited with status...

You then have the following options:

1.6.6 Rerunning the Same Program from the Current Debugging Session

You can rerun the program currently under debugger control at any time during a debugging session. If you modified the program (created a new binary) during the debugging session, choosing File:Rerun Same Program will bring the new binary under debugger control. The Rerun Same Program dialog box appears (Figure 1-7).

Figure 1-7 Rerunning the Same Program

Enter any arguments to be passed to the program in the Arguments: field. Choose whether to keep or not to keep the user-set breakpoints that you previously set, activated, or deactivated (see Section 3.3). Click on OK. An initial breakpoint will be set unless you previously turned the Set Initial Breakpoint and Run button off in the Run New Program dialog box.

When you rerun a program, it is in the same initial state as when you first brought it under debugger control. Any breakpoints that were set in the program remain set. The source display and current location pointer are updated accordingly.

After you revise the program and create a new version of the program file with a new name, choose File:Run New Program... in the main window to bring the new version under debugger control.

1.6.7 Running Another Program from the Current Debugging Session

You can bring another program under debugger control and close the current program being debugged at any time during a debugging session by following the instructions in Step #5 in Section 1.6.2.

Use the run command in the command interface at any time during the debugging session to bring another program under debugger control and close the current program being debugged.

1.6.8 Interrupting Program Execution and Aborting Debugger Operations

To interrupt program execution or to abort a debugger operation during a debugging session, click on the Interrupt button on the push-button panel (see Figure 2-1). This is useful if, for example, the program is in an infinite loop.

Clicking on Interrupt does not end the debugging session. Clicking on Interrupt has no effect when the program is not running nor does it have any affect when the debugger is not performing an operation. Click on Continue to resume program execution.

Enter Ctrl/C or quit in the command interface to end the debugging session.

1.6.9 Ending a Debugging Session

To end a debugging session and terminate the debugger, choose File:Exit Debugger on the main window or enter quit from the command prompt either in the Command Message View of the GUI or from the prompt in the command interface. This returns control to system level.

To run another program from the current debugging session, see Section 1.6.7.

1.7 Searching and Editing Your Program

To search the text of your program, select Find... from the Edit menu to invoke the Search Source File dialog box (<REFERENCE>(d_search_fig)).

The Search Source File dialog box contains toggles for selecting:

You can select where to start the search by using one of the following options from the Start From: menu:

You can select the type of search from the following Search Type: options:

To perform a search, use the following method:

  1. Enter a text string in the Find: text box.
  2. Set the search attributes (direction, wrap, search type, starting point).
  3. Click on the Find button.

If the debugger does not find the text string, it displays a "not found" message. If the expression is invalid, the debugger displays an "invalid expression" message. If the debugger finds the selection, the Start From: field updates to Last Found. You can search for the next occurrence of the string by reclicking the Find button. If you enter a new string into the Find: text box, Start From: reverts to its prior setting.

You can select files to search from the File:Source Browser... in the Main Window. For more information on displaying files in your application, see Section 2.1.1. Selecting Start From: Current Line reverts the view to the file containing the current program counter.

The debugger keeps a history of previous searches until you click the Clear History button. You can store the configuration of the dialog box, including the entries on the history list, in the Ladebug resource file by selecting Options:Save Options on the Main Window. For more information about the Ladebug resource file, see Chapter 4.

The debugger provides a simple text editor you can use to edit your source files while debugging your program (Figure 1-8).

Figure 1-8 Editor Window

To invoke the editor, choose Commands:Edit File on the Main Window. By default, the editor window displays an empty text buffer, called dbg_editor_main. However, if you are debugging a program when you invoke the editor, the editor window displays this program, names the filled text buffer with its file specification, and places dbg_editor_main on the buffer menu at the upper right corner as an alternative text buffer.

The editor allows you to create any number of text buffers by choosing File:New (for empty text buffers) or File:Open (for existing files). The name of each text buffer appears in the buffer menu. You can cut, copy, and paste text across buffers by choosing items from the Edit menu and selecting buffers from the buffer menu.

When you complete your edits, save these to your file by choosing the File:Save or File:Save As. Then recompile and relink your source file so the changes will take effect.

You can also edit your program with Emacs. For more information about using Emacs, see Section 1.6.

1.8 Using Online Help

The following types of online help about the debugger and debugging are available during a debugging session:

Previous Next Contents Index