1. The program ID COBOL_EXAMPLE is implicitly external and is emitted as cobol_example.
2. The use of external causes B-2 to be emitted as B_2 and C_3 to be emitted as C_3.
3. This is the first occurrence of overloaded-name. Because it is a local symbol, it is emitted as OVERLOADED-NAME.
4. Both C_3 and C-3 refer to the same object, which is C_3 in .
5. Both D-4 and D_4 refer to the local symbol emitted as D-4.
6. This is the second occurrence of overloaded-name. Since it is a program ID, it is implicitly external and is emitted as overloaded_name.
7. This is the second occurrence of b_2. Because it is a local symbol, it is emitted as B-2.
8. This is the third occurrence of b-2. Since it is a program ID, it is implicitly external and is emitted as b_2.

The sample debugging session in Example 8-2 demonstrates how Ladebug handles the symbols from the sample COBOL program in Example 8-1.

Example 8-2 Sample COBOL Debugging Session

Welcome to the Ladebug Debugger Version 4.0 ------------------ object file name: example Reading symbolic information ...done (ladebug) stop at 51 [#1: stop at "example.cob":51 ] (ladebug) run *** Ladebug COBOL Example *** A_1 = 1 B-2 = 2 C_3 = 3 C-3 = 3 D-4 = 4 D_4 = 4 [1] stopped at [cobol_example:51 0x12000cd14] 51 CALL "Overloaded-Name". (ladebug) whatis d-4 (1) array [subrange 1 ... 1 of int] of char d-4 (ladebug) whatis D_4 (1) array [subrange 1 ... 1 of int] of char D_4 (ladebug) print d_4 (1) "4" (ladebug) whereis d-4 (1) "example.cob"`cobol_example`D-4 (ladebug) whereis b-2 (2) "B_2" B_2 "example.cob"`cobol_example`B_2 "example.cob"`overloaded_name`B-2 "example.cob"`b_2 (ladebug) which b-2 (3) "example.cob"`cobol_example`B_2 (ladebug) print b-2 (4) 2 (ladebug) step stopped at [overloaded_name:61 0x12000ce04] 61 program-id. OverLoaded-NAME. (ladebug) stop at 78 [2] stopped at [cobol_example:78 0x12000cf20] (ladebug) next stopped at [overloaded_name:69 0x12000ce30] 69 display "*** Overloaded-Name ***". (ladebug) which b-2 (5) "example.cob"`overloaded_name`B-2 (ladebug) whatis b-2 pic 99 usage display b-2 (ladebug) print b-2 12 (ladebug) return *** Overloaded-Name *** b_2 = 12 *** end of Overloaded-Name *** stopped at [cobol_example:51 0x12000cd58] 51 CALL "Overloaded-Name". (ladebug) n stopped at [cobol_example:52 0x12000cd68] 52 CALL "B-2". (ladebug) s stopped at [b_2:78 0x12000cef4] 78 program-id. b-2. (ladebug) which b-2 "c_example6-2.cob"`b_2 (ladebug) whatis c_example6-2.cob`b_2 void b_2(void) (ladebug) cont *** b_2 *** *** end of b_2 *** ***END Ladebug COBOL Example*** Thread has finished executing (ladebug) q

1. Since there is only one object named D-4, all four spellings are resolved to the same address. The whereis command displays only one instance of d-4, namely "example.cob"`cobol_example`D-4.
2. There are three different instances of b-2 in this example. The whereis command lists all three.

   "example.cob"`cobol_example`B_2 -- PIC X external "example.cob"`overloaded_name`B-2 -- PIX 99 "example.cob"`b_2 -- program id

3. Based on the current context, the B_2 PIC X external instance of b-2 is the one visibile in the current scope.
4. Based on callout (3), b-2 refers to "example.cob"`cobol_example`B_2, which has a value of 2.
5. Since the current context is in the procedure Overloaded-name, the which command refers to the B-2 local to Overloaded-name
   ("example.cob"`overloaded_name`B-2`) .

For another example of debugging a COBOL program with Ladebug, see the appendix on tools in the <REFERENCE>(DEC_COB_UM).

8.4 Debugging Mixed-Language Programs

The Ladebug debugger lets you debug mixed-language programs. The flow of control across programs written in different languages in your executable image is transparent.

The debugger automatically identifies the language of the current program or code segment on the basis of information embedded in the executable file. For example, if program execution is suspended in a code segment in COBOL, the current language is COBOL. If the program executes a C function, the current language becomes C. The current language determines for the debugger the valid expression syntax and the semantics used to evaluate an expression.

The debugger sets the $lang variable to the language of the current program or code segment. By manually setting the $lang debugger variable, you can force the debugger to interpret expressions used in commands by the rules and semantics of a particular language. For example, you can check the current setting of $lang and change it as follows:

(ladebug) print $lang "C++" (ladebug) set $lang = "Cobol"

When the debugger reaches the end of your program, the $lang variable is not set to the language of the _exit routine, which is written in machine code.

8.5 Limitations on Assignment

The following limitations apply to assignment in COBOL debugging:

• You cannot assign new values to character string items (PIC X or PIC A).
• The scales of the items in an assignment must match. Consider the following declarations:

  01 itema pic 9(9)v99. 01 itemb pic 9999v99. 01 bigitem pic 9(13)v9(5).

  The debugger allows assignment of the values 1.23 or 8765.22 to itema, but does not allow assignment of the value 1.2 to itema. The following debugger commands are supported because the quantities on both sides of the assignment operator (=) have the same scale:

  (ladebug) assign itema = 1.23 (ladebug) assign itema = 8765.22 (ladebug) assign itema = itemb

  
  The following debugger commands are not supported because the quantities involved are of different scales:

  (ladebug) assign itema = 1.2 (ladebug) assign bigitem = itema

• You cannot assign a value of greater precision to an item. Given the declarations, the following debugger command is not supported, because itema has greater precision than itemb:

  (ladebug) assign itemb = itema

• With numeric edited items, the precisions of the quantities on both sides of the assignment must be the same.
• A numeric edited item cannot be assigned to other numeric items.

Other limitations when you debug COBOL programs include:

• Subordinate items must be fully qualified for the debugger to find them, and also must be specified in uppercase. Consider the following example:

  01 A. 03 B. 05 C pic 9.

  For this group, the debugger cannot find C unless you fully qualify it, as follows:

  C of B of a

• Qualification involving more than one intervening level produces a debugger error if the intervening level is an OCCURS item. For example, C of B of a for the group is supported, but not if B is an OCCURS item.
  For the transformation rules, see Section 8.3.
• Some Ladebug command usage is affected by COBOL language syntax when execution is stopped within a COBOL procedure. One effect is that expressions typed on the debugger command line must include spaces around arithmetic operators like "+" and "-".
• Another effect of COBOL language syntax is in the debugger memory-examine command. For example, to look at the next 10 program instructions, you would normally use:

  (ladebug) ./10i

  This debugger command says "from the current program location" (signified by the dot), examine the next 10 program locations (10 being the count) in instruction mode (signified by the "i").
  When debugging COBOL programs, you need to enter this command as follows:

  (ladebug) ./10 i

  Add a space between the count (10) and the mode indicator (i) .

• Reference modification is not supported.
• The OF qualifier keyword is supported, but the IN keyword is not supported.
• Tables (OCCURS items) with variable upper bounds are not supported.
• Breakpoints on labels are not supported.
• Subscripting is supported, but only for tables of one dimension.
• Stopping program execution at a program label (paragraph or section name) is not supported.
• The debugger does not correctly evaluate all COBOL condition expressions.
• The debugger supports only simple arithmetic operations in COBOL. It does not support full expression evaluation, including exponentiation, reference modification, and arithmetic operations with operands of different scales.

This part describes the following advanced debugging topics:

• Debugging multiprocess applications
• Debugging multithreaded applications
• Debugging core files
• Using debugger scripts
• Debugging shared libraries
• Working with limited debugging information
• Machine-level debugging
• Remote debugging
• Kernel debugging
• Debugging client/server applications

With the debugger, you can debug more than one program or process. This chapter explains how to:

• Display and select from a list of available processes
• Attach and detach a process
• Load images and core files
• Remove process information from the debugger
• Debug programs that fork a child process and/or exec a program

This chapter contains two sample multiprocess debugging sessions, one from the graphical user interface, (see Section 9.1.3), and one from the command interface (see Section 9.1.4).

9.1 Debugging Multiprocess Applications

This section describes how to bring a process under debugger control and attach and detach a process, and contains a sample session.

9.1.1 Bringing a Process Under Debugger Control

The Source View Context Panel contains menu buttons that list the processes under debugger control. It allows you to change the process by selecting any process on the menu and making it the current process.

To select a process, pull down the Process menu button and select the process you want. The contents of the Source View and the Call Stack and any displayed optional views are updated to reflect the current context.

9.1.2 Attaching and Detaching Processes

To attach to a process not currently under debugger control, choose Command:Attach to Process in the Main Window. This displays a Process Selection dialog box that shows you the list of active processes to which you have access (Figure 9-1).

Figure 9-1 Process Selection Dialog Box

Select the process you want to attach to. The Source View reflects the new process. If you have optional views displayed, they will be updated to reflect the new process.

If no breakpoint is set in the process to which you are attaching, the process will run to completion. However, you can set the $stoponattach toggle in the dialog box to stop the process right after the debugger attaches to it by default.

The Source View will not reflect the new process if the debugger cannot find the path to the actual source file.

You can attach to a process using the attach or load command at the command prompt. The views are not updated until the run command is executed. If a break is not set, the process will run to completion. Use the stop in or stop at command to set a break. For more information, see Section 3.2.8.

After Ladebug attaches to a process, control is returned to the debugger when the process stops (for example, after having received a signal). You can also manually return control to the debugger by pressing Ctrl/C.

To detach a process, choose Commands:Detach Process in the Main Window. This displays a dialog box showing all the current processes under debugger control.

Click on the desired process to remove it from debugger control. If the process is current (displayed in the Source View and Optional Views), the process will run to completion and the views are reinitialized (blanked out). If the process you detach is not current, it will run to completion and the current process will continue to display in the Source View.

The views do not close automatically. To close the views, use the Views menu or exit the debugger.

You can also detach a process by using the detach command at the command prompt. Ladebug only detaches the specified process and removes all the user-specified breakpoints from that process.

The following restrictions apply when you debug an attached process:

• In the context of an attached process, the run and rerun commands are disabled.
• The quit command will terminate any process Ladebug created when invoking the debugger with an image file or when using the load image_file command. If it is attached to any process, Ladebug will detach itself from the process.

This section describes how to use the debugger graphical user interface to debug a multiprocess application. It presents an example application that forks a child process and execs a program.

Ladebug provides predefined debugger variables that you can set in order to debug multiprocess applications that fork and/or exec.

Setting $catchforks to 1 instructs Ladebug to notify the user when a program forks a child process. Setting $catchexecs to 1 instructs Ladebug to notify the user when a program execs. Setting $stopparentonfork to 1 stops the parent process when a program forks a child process.

For more information on debugger variables, see Section 9.1.9.1. For different scenarios in which these variables are used, see Section 9.1.9.2 and Section 9.1.9.3.

The general steps for debugging a multiprocess application are as follows:

1. Start the application.
2. Pull down the Process menu. The Process menu displays the current process on top. The image name for each process displays next to each process.
3. Select a different process by clicking on the process you want to debug. (The Source View and the Call Stack are updated.)

Figure 9-2 Multiprocess Application

1. In Figure 9-2, a parent process (200) forks a child process (201).
2. When the parent process forks, the Source View shows that the parent process has stopped.
3. The child process is selected from the process menu pulldown (process 201).
4. Entering the cont command continues running the child process which execs the program factorial.

You can continue debugging the child process or return to the parent process by selecting it in the process menu pulldown. When the process has finished executing, a message displays that process has exited and the Source View reinitializes (blanks out).

You can also bring a process into debugger control in the following ways:

• From the GUI, using the Attach to Process dialog box.
• From the command line, using various Ladebug command line options and arguments (for example, specifying a core file for core file debugging or the -k flag for local kernel debugging).
• From the Ladebug prompt, you can load a program using the load command or attach to a running process using the attach command.
• When the Ladebug variable $catchforks is set to 1, Ladebug keeps track of newly forked processes.

Example 9-1 demonstrates the use of Ladebug commands to debug a multiprocess application using the command interface.

In the first part of the program, the process command shows the current process. The load lets you load an image or core file. Specifying show process all displays a list of processes, running or stopped.

Example 9-1 Debugging a Multiprocess Application - Loading an Image File and Showing Processes

$ ladebug Welcome to the Ladebug Debugger Version 4.0-9 (ladebug) process There is no current process. You may start one by using the `load' or `attach' commands. (ladebug) load a.out Reading symbolic information ...done (ladebug) process(1) Current Process: localhost:18340 (a.out). (ladebug) show process all(2) >localhost:18340 (a.out) Unstarted. (ladebug) load file-func Reading symbolic information ...done (ladebug) process Current Process: localhost:18551 (file-func).(3) (ladebug) show process all(4) localhost:18340 (a.out) Unstarted. >localhost:18551 (file-func) Unstarted. (ladebug) process 18340(5) (ladebug) process Current Process: localhost:18340 (a.out). (ladebug) list 1(6) 1 2 int main(int argc, char* argv[]) 3 { 4 int a = sizeof(**argv); 5 int b = sizeof(+(**argv)); 6 int c = sizeof(-(**argv)); 7 return a+b+c; 8 }

1. Ladebug sets the current process.
2. Ladebug shows information for all processes. In this case, there is only one process.
3. After loading file-func, Ladebug displays a new current process (process 18551).
4. Ladebug now shows two processes. The arrow (>) indicates the current process.
5. When you specify the process ID, Ladebug switches to that process. In this case, it switches to process 18340.
6. Process 18340 is now the current process. Ladebug lists the process' source code.

Switching between processes sets the current process context, as shown in Example 9-2.

Example 9-2 Debugging a Multiprocess Application - Switching Between Processes

(ladebug) process 18551(1) (ladebug) process Current Process: localhost:18551 (file-func). (ladebug) list 1(2) 1 2 3 #include <stdio.h> 4 5 int gfi = 100; 6 7 int g1 = 10; 8 9 int funcA(i) { 10 11 int a, x; 12 x = 1; 13 a = i + g1 + x; 14 return a; 15 } 16 17 int funcB(i) { 18 19 int a; 20 a = i; 21 return a;