Part II
A Guide to Using the Ladebug Debugger

To add or change an environment variable, use a set_environment_variable_command. If the environment_variable_value is not specified, the environment variable value is set to "".

set_environment_variable_command
        : export environment_variable_name  = environment_variable_value 
        | setenv environment_variable_name  environment_variable_value 

environment_variable_value
	: string

(ladebug) printenv TOOLDIRECTORY 
Error: Environment variable 'TOOLDIRECTORY' was not found in the environment.
(ladebug) setenv TOOLDIRECTORY /usr/examples/tools 
(ladebug) printenv TOOLDIRECTORY 
TOOLDIRECTORY=/usr/examples/tools

To remove an environment variable, use the unsetenv command:

unset_environment_variable_command
        : unsetenv environment_variable_name
        | unsetenv *

If an asterisk (*) is specified, all environment variables are removed.

NOTE: There is no command to simply return to the initial state of the environment variables after the debugger starts. You must use set_environment_variable commands and unset_environment_variable commands appropriately.

6.8 Multiprocess Debugging

• It created the process.
• It attached to the process.
• A process that it was controlling executed a fork, and $catchforks was set.

At any one time, you can control only one of the processes that the debugger controls. The rest are stalled. You must explicitly switch the debugger to the process you want to work with, stalling the one it was controlling:

multiprocess_command
        : show_process_command
        | switch_process_command

You can show the processes the debugger controls:

show_process_command
        : show process [ all ]
        | process
	
all
	: all
	| *
 

(ladebug) show process 
>localhost:18348 (/usr/examples/x_list) loaded.

You can explicitly command the debugger to control a different process:

switch_process_command
        : process pid
        | process filename

The following example creates two processes and switches from one to the other:

(ladebug) process 
There is no current process.
You may start one by using the `load' or `attach' commands.
(ladebug) load /usr/examples/x_list 
Reading symbolic information ...done
(ladebug) process 
>localhost:18331 (/usr/examples/x_list) loaded.
(ladebug) set $old_process = $curprocess
(ladebug) print $old_process
18331
(ladebug) load /usr/examples/x_segv 
Reading symbolic information ...done
(ladebug) process 
 localhost:18331 (/usr/examples/x_list) loaded.
>localhost:18327 (/usr/examples/x_segv) loaded.
(ladebug) process $old_process 
(ladebug) process 
>localhost:18331 (/usr/examples/x_list) loaded.
 localhost:18327 (/usr/examples/x_segv) loaded.

Both the run command and the attach command switch the debugger to the process on which they operate.

6.9 Processes That Use fork()

• $catchforks—When set to a non-zero value, this variable instructs the debugger to stop the child process on exit out of the fork() or vfork() calls. The parent process continues to run. The default is 0 (zero).
• $stopparentonfork—When set to a non-zero value, this variable instructs the debugger to stop the parent process on exiting out of the fork() or vfork() calls after it forks a child process. The child process continues to run if $catchforks is 0; otherwise, it does not. The default is 0 (zero).
• $catchforkinfork—When set to a non-zero value, this variable instructs the debugger to stay in the fork routine after the fork and notifies you as soon as the forked process is created; otherwise, you are notified when the call finishes. The default is 0 (zero).

When a fork occurs, the debugger sets the debugger variables $childprocess and $parentprocess to the child and parent process IDs, respectively.

In the following example, the debugger notifies you that the child process has stopped. The parent process continues to run.

(ladebug) set $catchforks = 1
(ladebug) run
Process 29027 forked.  The child process is 29023.
Process 29023 stopped on fork.
stopped at [int main(void):6 0x120001178]	
      6  int pid = fork();
fork.c: I am the parent.
Process has exited with status 0
(ladebug) show process 
>localhost:29028 (/usr/examples/fork) loaded.
 localhost:29023 (/usr/examples/fork) paused.

• The debugger indicates that the child process has stopped, and shows the line number at which it is stopped.
• The last 2 lines show that the child process has stopped and that the parent process has completed execution.

Continuing the previous example, the following shows how to switch the debugger to the child process. Listing the source code shows the source for the child process.

(ladebug) process $childprocess 
(ladebug) show process 
 localhost:29028 (/usr/examples/fork) loaded.
>localhost:29023 (/usr/examples/fork) paused.
(ladebug) list 
      7 
      8   if (pid == 0)
      9    {
     10      printf("fork.c: I am the child.\n");
     11    }
     12   else
     13    {
     14      printf("fork.c: I am the parent.\n");
     15    }
     16 }

• The first line switches the current process context to the child process.
• The right angle bracket indicates the current process.
• The list command lists the source code for the current process.

6.10 Processes That Use exec()

In the following scenario, you set the predefined variables $catchforks and $catchexecs to 1. The debugger will notify you when an execution occurs. Because $catchforks is set, you will also be tracking the child process and, therefore, you will be notified of any exec in the child process.

The following example shows an exec occurring on the current context and the child process stopped on the runtime-loader entry point:

(ladebug) set $catchforks = 1
(ladebug) set $catchexecs = 1
(ladebug) run
Process 14839 forked.  The child process is 14835.
Process 14835 stopped on fork.
stopped at [int main(void):8 0x1200011f8]	
      8   if ((pid = fork()) == 0)
x_exec.c: I am the parent.
Process has exited with status 0
(ladebug) show process 
>localhost:14918 (x_exec) loaded.
 localhost:14835 (x_exec) paused.
(ladebug) process $childprocess 
(ladebug) list 6: 13
      6   int pid;
      7   
>     8   if ((pid = fork()) == 0)
      9       {
     10       printf("About to exec \n");
     11       fflush(stdout);  /* Make sure the output gets out! */
     12       execlp("announcer", "announcer", NULL);
     13       printf("After exec \n");
     14       }
     15   else
     16      {
     17       printf("x_exec.c: I am the parent.\n");
     18      }
(ladebug) cont 
About to exec 
The process 14835 has execed the image "./announcer".
Reading symbolic information ...done
stopped at [ 0x3ff8001bf48]	
      5     printf("announcer.c: I am here!! \n");

• Use process $childprocess to set the current process context to the child process.
• Listing the source code, you can see the process is almost ready to execute.
• The debugger notifies you when the exec occurs.
• The child process is stopped on the runtime-loader entry point. The source display shows the code in the main routine.

6.11 Core File Debugging

6.12 Kernel Debugging

• A process is hung
• Kernel parameters need to be examined or modified
• The operating system hangs, panics, or crashes

6.12.1 Security

6.12.2 Compiling a Kernel for Debugging

By default, compilation does not strip the symbol table information and optimization is only partial. If you do not change these defaults, you should not encounter a problem.

6.12.3 Patching a Disk File

(ladebug) patch @foo = 20

6.12.4 Setting the Thread Context

You can modify the current thread context by setting $tid to a valid thread identifier.

The debugger variable $tid is the same as $curthread except that $tid is used for kernel debugging.

6.12.5 Local Kernel Debugging

Invoke the debugger with the following command:

# ladebug -k /vmunix /dev/mem

Now you can use Ladebug commands to display the current process identification numbers (pids) and trace the execution of processes. The following example shows the use of the kps command to display the process IDs:

kernel_debugging_command
        : kps

(ladebug) kps
00000   kernel idle
00001   init
00003   kloadsrv
00020   update
02082   dtexec
02092   dtterm
02093   csh
...

If you want to examine the stack of the kloadsrv daemon, for example, you set the $pid symbol to its pid(3) and enter the where command, as in the following example:

(ladebug) set $pid = 3
(ladebug) where
>0  0xfffffc00002b3a10 in thread_block()  

6.12.6 Crash Dump Analysis

The operating system can crash in the following ways:

• Hardware trap—A hardware problem often results in the kernel trap() function being invoked.
• Software panic—A software panic, resulting from a software failure, calls the kernel panic() function.
• Hung system—When the system hangs, you can force the creation of dump files.

You can analyze the crash dump file to determine what caused the crash. For example, if a hardware trap occurred, you can examine variables, such as savedefp, the program counter ($pc), and the stack pointer ($sp), to help you determine why the crash occurred. If a software panic caused the crash, you can use the debugger to examine the crash dump and use the uerf utility to examine the error log. Using these tools, you can determine which function called the panic() routine.

Crash dump files, such as vmunix.n and vmcore.n, usually reside in the /var/adm/crash directory. The version number (n in vmunix.n and vmcore.n ) must match for the two files.

For example, you might use the following command to examine dump files:

# ladebug -k vmunix.1 vmcore.1 

6.12.6.1 Examining the Exception Frame

(ladebug) print savedefp/33X

ffffffff9618d940:   0000000000000000 fffffc000046f888 
ffffffff9618d950:   ffffffff86329ed0 0000000079cd612f 
.
.
.
ffffffff9618da30:   0000000000901402 0000000000001001 
ffffffff9618da40:   0000000000002000 

6.12.6.2 Extracting the Character Message Buffer

(ladebug) print *pmsgbuf
struct msgbuf {
msg_magic = 405601; 
msg_bufx = 1851; 
msg_bufr = 1343; 
msg_bufc = "Alpha boot: available memory from 0x6ca000 to 0x3f16000\nTru64 UNIX V.n  (Rev. 564); Fri Jul 11 11:25:29 EDT 1997 \nphysical m"; 
}

6.12.6.3 Using the crashdc Utility

See Compaq TRU64 UNIX Kernel Debugging and the crashdc(8) reference page for more information.

6.12.6.4 Managing Crash Dump File Creation

6.12.6.5 Saving Dumps to a File System

6.12.6.6 Selecting a Crash Dump Type

• By specifying the d flag to the boot_osflags console environment variable.
• By modifying the kernel's partial_dump variable to 0 using the debugger as follows:

  (ladebug) assign partial_dump = 0
  

  A partial_dump value of 1 indicates that partial dumps are to be generated.

6.12.6.7 Determining Crash Dump Partition Size

See Compaq TRU64 UNIX Kernel Debugging for more information.

6.12.6.8 Procedures for Creating Dumps of a Hung System

6.12.6.9 Guidelines for Examining Crash Dump Files

• Gather some facts about the system (for example, operating system type, version number, revision level, and hardware configuration).
• Look at the panic string, if one exists. This string is contained in the preserved message buffer, pmsgbuf, and in the panicstr global variable.
• Locate the thread executing at the time of the crash. (Use the where command.) Most likely, this thread will contain the events that led to the panic.
• Determine whether you can fix the problem. If the system crashed because of lack of resources (for example, swap space), you can probably eliminate the problem by adding more of that resource. If the problem is with the software, you may need to contact Compaq Customer Support.

• The crashdc utility
• Managing crash dump file creation
• Saving dumps to a file system
• Selecting full or partial crash dump files
• Determining crash dump partition size and file system space
• Procedures (according to hardware platform) for creating dumps of a hung system

NOTE: Crash dump analysis is possible only with local, not remote, kernel debugging.

Chapter 7 - Locating the Site of a Problem

To determine why a problem is happening, you usually want to execute your program up to or just before the point at which you observe the first evidence of the problem. Then you can examine the internal state of your program and try to identify something that explains the visible problem. Possibly you will see right away how the problem occurs, in which case you are finished debugging. You then correct your program, recompile, relink, and confirm that the correction works as intended.

Often, you will see something about the program state that is wrong but you will not see how it got that way. In that case, you need to make a guess at where the mistake might have occurred. Then, repeat this whole process, trying to stop at or just before the possible trouble point.

For simple problems, it may be easy to describe the conditions under which you want to stop the program; for example, "the first time traverse is called" or "when division_by_zero occurs". Other situations may require either more complex descriptions or repeated trial-and-error attempts to discover the critical information needed to solve your problem. Breakpoints provide the means by which you specify to the debugger an event or condition under which you want to intervene in the execution of your program and what actions you want the debugger to take when that event is detected.

You can define breakpoints based on:

• Reaching a certain place in your program (such as entering a certain function or reaching code for a particular source line number)
• Accessing the contents of a variable or other memory when it is either read or written
• Raising a specified signal

Breakpoint commands include the following:

breakpoint_command
        : breakpoint_definition_command
        | simple_stop_command
        | signal_command
        | obsolete_breakpoint_definition_command
        | breakpoint_table_command

• Breakpoint definitions
• Breakpoint tables

7.1 Breakpoint Definitions

The following is a particularly common breakpoint:

(ladebug) stop in main 
[#1: stop in int main(void) ]

The debugger responds to a breakpoint command by displaying how it recorded the request internally. The debugger assigns a number to the breakpoint (in this case, it is 1), which it uses later to refer to that breakpoint. The debugger does not just repeat the command as you entered it; it provides a more complete description of the function main to help you confirm that it has correctly identified the function you meant.

Later, after you cause the program to execute, if that event occurs, the debugger reports the event and then prompts you for what to do next. For example:

(ladebug) run
[1] stopped at [int main(void):182 0x1200023f8]	
    182     List<Node> nodeList;

Both the event part and the action part of a breakpoint definition command consist of several subparts:

breakpoint_definition_command
	: disposition
            [ quiet ]
              detector
            [ thread_filter ]
            [ logical_filter ]
            [ breakpoint_actions ]

NOTE: Additional obsolete forms of breakpoint definition are retained only for backward compatibility with earlier versions of the debugger. These forms are explained later. The obsolete forms may be eliminated in a future release.

There are three distinct points in time at which a breakpoint definition has an effect:

1. When the command is entered

   The command is parsed, names and expressions that occur in any of the event parts are evaluated, and the breakpoint actions are parsed and checked for correctness (but not evaluated).

2. When the debugger initiates program execution

   For each breakpoint that is not disabled, appropriate modifications are made to the program to enable detection of the specified event.

3. When a detector triggers during program execution

   The thread filter specification (if present) and logical filter (if present) are evaluated to determine whether the breakpoint as a whole has triggered. If not, then execution is resumed (silently). If so, the breakpoint actions are performed, after which execution stops or resumes according to the specified disposition.

7.1.1 Disposition

disposition
        : stop
        | when

The when command specifies that when the event specified by the breakpoint occurs and all processing for that breakpoint has been completed, the debugger may resume execution of the program. See the section When Multiple Breakpoints Trigger at Once for an explanation of how the debugger determines when to resume execution.

7.1.2 The quiet keyword

By default, when an event is detected and the debugger determines that the breakpoint actions should be performed, the debugger prints a line that identifies the breakpoint, for example:

(ladebug) when in main { stop } 
[#1: when in int main(void) { stop } ]
(ladebug) run
[1] when [int main(void):182 0x1200023f8] 
[1] stopped at [int main(void):182 0x1200023f8]	
    182     List<Node> nodeList;

7.1.3 Detectors

The debugger uses several kinds of detectors, each corresponding to a particular kind of event:

detector
        : place_detector
        | watch_detector
	| signal_detector
	| unaligned_detector

A place detector specifies a place or location in your program. It can refer to the beginning of a function, a particular line in one of your source files, a specific value of the PC (program counter), or certain sets of these.

A watch detector specifies a variable or other memory locations that should be monitored to detect certain kinds of access (read, write, and so on).

A signal detector specifies a set of UNIX signals to be monitored.

An unaligned access detector specifies any kind of memory access using an unaligned access.

This section describes each type of detector.

7.1.3.1 Place Detectors

place_detector
        : in function_name
        | in all function_name
	| pc address_expression
        | at line_specifier
	| every proc entry
	| every procedure entry
	| every instruction
        | expression

The in function_name detector specifies the event where execution reaches the entry of the named function. For example:

If the function name is ambiguous (there can be more than one function that matches the name in some languages, including C++), the debugger prompts you with a list of alternatives from which to choose.

(ladebug) stop in foo 
Select from
----------------------------------------------------
     1 int C::foo(double*)
     2 void C::foo(float)
     3 void C::foo(int)
     4 void C::foo(void)
     5 None of the above
----------------------------------------------------
2
[#4: stop in void C::foo(float) ]

The in all function_name detector is the same as in function_name except that it specifies all of the functions that match the given name, whether one or more.

(ladebug) stop in all foo 
[#3: stop in all foo ]

The pc address_expression detector specifies the event where execution reaches the given machine address:

(ladebug) stop pc 0x120002498 
[#7: stop PC == 0x120002498 ]

(ladebug) stop at 190 
[#8: stop at "x_list.cxx":190 ]

The every procedure entry detector specifies that a breakpoint should be established for every function entry point in the program.

(ladebug) stop every procedure entry 
[#9: stop every procedure entry ]

NOTE: This command can be very time-consuming because it searches your entire program — including all shared libraries that it references — and establishes breakpoints for every entry point in every executable image. This can also considerably slow execution of your program as it runs.

A disadvantage of this command is that it establishes breakpoint for hundreds or even thousands of entry points about which you have little or no information. For example, if you use stop every proc entry immediately after loading a program and then run it, the debugger will stop or trace over 100 entry points before reaching your main entry point. About the only thing that you can do if execution stops at most such unknown places is continue until some function relevant to your debugging is reached.

The every instruction detector specifies a breakpoint for every instruction in your entire program:

(ladebug) stop every instruction 
[#10: stop every instruction ]

When used with the when disposition, subsequent next and step commands allow you to trace all of the instructions that are executed as a result of those stepping commands. Beware that even when next is used to step over a called routine, the trace output includes all of the instructions that are executed within the called routine (and any routines that it calls).

NOTE: This command will slow execution of your program considerably.

The detector expression (that is, an expression not preceded by one of the keywords in, at, or pc) specifies either a function name or line number depending on how the expression is parsed and evaluated. An expression that evaluates to the name of a function is handled just like the equivalent command that uses in in the detector; otherwise, it is handled like the equivalent command that uses at in the detector.

7.1.3.2 Watch Detectors

watch_detector
        : basic_watch_detector watch_detector_modifiers

basic_watch_detector
        : variable variable_name
	| memory start_address_expression
        | memory start_address_expression , end_address_expression
        | memory start_address_expression : byte_count_expression

watch_detector_modifiers
        : [ access_modifier ] [ within_modifier ]

access_modifier
        : write
        | read
        | changed
	| any

within_modifier
        : within function_name

You can specify a variable whose memory is to be watched, or specify the memory directly. The accesses that are considered can be limited to those that write (the default), read, write and actually change the value, or can include all accesses.

If a variable is specified, the memory to be watched includes all of the memory for that variable, as determined by the variable's type. For example:

(ladebug) whatis _nextNode
class Node* Node::_nextNode
(ladebug) stop variable _nextNode write 
[#3: stop variable _nextNode 0x140001800, 0x140001807 write ]

If memory is specified directly in terms of its address, the memory to be watched is defined as follows:

• By default (no last address or size given), then 8 bytes beginning at the given start address:

  (ladebug) when memory 0x140001800 any 
  [#4: when memory 0x140001800, 0x140001807 any ]
  

• If an end address is given, then all bytes of memory from the start address to and including the end address:

  (ladebug) stop memory 0x140001800, 0x140001803 read 
  [#5: stop memory 0x140001800, 0x140001803 read ]
  

  This watches the 4 bytes specified on the command line.

• If a byte count is specified, then the given number of bytes starting at the given start address:

  (ladebug) stop memory 0x140001800:2 changed 
  [#6: stop memory 0x140001800, 0x140001801 changed ]
  

  This watches the 2 bytes specified on the command line for a change in contents.

If a within_modifier is specified, then only those accesses that occur within the given function (but not any function it calls) are watched. For example:

(ladebug) whatis t
int t
(ladebug) stop variable t write within foo 
[#2: stop variable t 0x140000248, 0x14000024b write within void C::foo(void) ]
(ladebug) cont 
[2] Address 0x140000248 was accessed at: 
void C::foo(void): x_overload.cxx
 [line 22, 0x12000195c]	stl	r31, 0(r2)
	0x140000248: Old value = 0x0000000f
	0x140000248: New value = 0x00000000
[2] stopped at [void C::foo(void):22 0x120001960]	
     22 void C::foo()         { t = 0; state++; return; }

7.1.3.3 Signal Detectors

signal_detector
        : signal signal_id ,...

signal_id
        : integer
        | signal_name

(ladebug) stop signal SEGV, 3, SIGINT 
[#2: stop signal 11, 3, 2 ]

7.1.3.4 Unaligned Access Detectors (Tru64 UNIX Only)

unaligned_detector
        : unaligned

Unaligned accesses are automatically handled by the Tru64 UNIX operating system. By default, an unaligned access results in an information message and then is corrected so that your program can continue. (You or your system administrator can choose a different default. See the uac(1) reference page for details.) This message looks like this:

Unaligned access pid=30231  va=0x11ffff791 pc=0x120001af4 ra=0x120001b84 inst=0xa0220000

You can request the debugger to detect unaligned accesses:

(ladebug) stop unaligned access 
[#1: stop unaligned access ]
(ladebug) run
Thread encountered Unaligned Access
[1] stopped at [int unalignedAccess(void):27 0x120001af8]	
     27     return y;

7.1.3.5 Unaligned Access Detector (Linux Only)

7.1.4 Thread Filter

thread_filter
        : thread thread_id ,...

A detected event is retained for further consideration only if the thread in which the event occurs matches one of the given threads. If not, the detection is quietly ignored.

Note that if the thread_filter does not indicate a match, then any related logical filter is not evaluated.

7.1.5 Logical Filter

logical_filter
        : if expression

The expression is checked syntactically in the context of the place where the breakpoint command is given: it must be syntactically valid according to the language rules that apply there. However, the expression is not evaluated and names that occur in the expression need not be visible. After the syntax check, the expression is remembered in an internal form and is not rechecked later when it is evaluated.

If an error occurs when the expression is evaluated, for example, because a name in the expression is not defined, then the error is reported and the value of the expression is assumed to be true.

Note that an error in the expression does not change the disposition. If continuation was specified, then that is still what occurs. For example:

(ladebug) when in List<Node>::append if x 
[#5: when in void List<Node>::append(class Node* const) if x ]
(ladebug) cont 
Symbol "x" is not defined.
[Error while evaluating breakpoint condition - taken as true]
[5] when [void List<Node>::append(class Node* const):148 0x120001d9c] 
Symbol "x" is not defined.
[Error while evaluating breakpoint condition - taken as true]
[5] when [void List<Node>::append(class Node* const):148 0x120001d9c] 
[4] stopped at [int main(void):194 0x1200025cc]	
    194     IntNode* newNode2 = new IntNode(4);

It is valid for a logical filter expression to contain a call to another routine in your program. Such a call is evaluated in the same way as if it occurred in a call or print command. However, execution of the called routine might result in triggering a breakpoint; this is called a recursive breakpoint.

7.1.6 Breakpoint Actions

breakpoint_actions
        : { action_list }

action_list
        : command 
        | command ;
        | command ;...

7.1.6.1 Special Commands

• Simple stop

  A simple_stop_command is a stop without any detector or other parameters:

  simple_stop_command
          : stop
  

  If used within a breakpoint action list, it specifies that the disposition for the breakpoint should be to stop after completion of action list processing, even if the breakpoint was specified with the when disposition. If used outside an action list, it has no effect.

  Note that a simple stop command does not terminate action list processing; it only affects the disposition that applies later. For example:

  (ladebug) when in List<Node>::print { stop ; print "*** stopped ***"} 
  [#6: when in void List<Node>::print(void) { stop ; print "*** stopped ***"} ]
  (ladebug) cont 
  [6] when [void List<Node>::print(void):162 0x120001e70] 
  *** stopped ***
  [6] stopped at [void List<Node>::print(void):162 0x120001e70]	
      162     Node* currentNode = _firstNode;
  

• History

  The history command does not display commands that are performed as part of the action list of a breakpoint.

7.1.6.2 Commands to Use with Caution

• call
• continue
• goto
• next
• return
• step
• Any command that contains an expression whose evaluation involves calling a function in your program

It is easy in such cases to lose track of just what state breakpoint processing is really in or where you really are in your program. Such confusion may mislead or misdirect your debugging effort. For further discussion, see the section on Recursive breakpoints.

7.1.6.3 Commands to Avoid

• attach and detach
• run and rerun
• process with an argument

The debugger does not explicitly prohibit these commands, but their behavior within action lists is implementation-defined and subject to change from release to release. In very specialized cases, you may be able to obtain useful results by using them in action lists, but do not expect the same behavior over the long term.

7.1.7 When Multiple Breakpoints Trigger at Once

When more than one breakpoint detector triggers, the thread filters and logical filters of all the breakpoints involved are processed before the action part of any breakpoint is performed.

After the set of breakpoints that trigger is determined, the action parts of each of them are performed in an undefined order.

After all action parts are performed, execution of the program is resumed only if all of the breakpoints so specify in their disposition. If any one of them specifies a break, the debugger prompts you for further commands.

7.1.8 Recursive Breakpoints

• call
• continue
• goto
• next
• return
• step
• Any command that contains an expression whose evaluation involves calling a function in your program

In all of these cases, the debugger temporarily suspends processing of the current breakpoint to start your program executing again and then waits for that execution to complete. As long as no new breakpoint is triggered during that execution, all will be fine. However, if a new breakpoint triggers, in particular one with the stop disposition, then you may be prompted for new command input for the recursive breakpoint even before the initial breakpoint has completed. Further, continuing execution may ultimately allow the original breakpoint to complete, at which time its disposition will come into play.

It is easy in such cases to lose track of just what state breakpoint processing is really in or where you really are in your program. Such confusion may mislead or misdirect your debugging effort. See the call command example which locates suspended execution in nested function calls.

7.1.9 Breakpoints and C++

7.1.9.1 Member Functions

(ladebug) list 3: 25
      3 class C {
      4 public:
      5     void foo();
      6     void foo(int);
      7     void foo(float);
      8     int  foo(double *);
      9 };
     10 
     11 C  o;
     12 C* p = new C;
     13 int t     = 0;
     14 int state = 1;
     15 
     16 main(){
     17     t++;
     18     o.foo();
     19     
     20 }
     21 
     22 void C::foo()         { t = 0; state++; return; }
     23 void C::foo(int i)    { state++; return;  }
     24 void C::foo(float f)  { state++; return;  }
     25 int  C::foo(double *) { return state;}

Member functions must be named in a way that makes them visible at the current position, according to the normal C++ visibility rules. For example:

(ladebug) stop in main 
[#1: stop in int main(void) ]
(ladebug) run
[1] stopped at [int main(void):17 0x120001924]	
     17     t++;
(ladebug) stop in foo 
Symbol "foo" is not defined.
foo has no valid breakpoint address
Warning: Breakpoint not set

If not positioned within a member function of a class, it is generally necessary to name the desired member function using type qualification, an object of the class type, or a pointer to an object of the class type. For example:

(ladebug) stop in C::foo 
Select from
----------------------------------------------------
     1 int C::foo(double*)
     2 void C::foo(float)
     3 void C::foo(int)
     4 void C::foo(void)
     5 None of the above
----------------------------------------------------
3
[#5: stop in void C::foo(int) ]
(ladebug) stop in o.foo 
Select from
----------------------------------------------------
     1 int C::foo(double*)
     2 void C::foo(float)
     3 void C::foo(int)
     4 void C::foo(void)
     5 None of the above
----------------------------------------------------
1
[#6: stop in int C::foo(double*) ]
(ladebug) stop in p->foo 
Select from
----------------------------------------------------
     1 int C::foo(double*)
     2 void C::foo(float)
     3 void C::foo(int)
     4 void C::foo(void)
     5 None of the above
----------------------------------------------------
4
[#7: stop in void C::foo(void) ]

You can avoid the ambiguity associated with an overloaded function by specifying a complete signature for the function name. For example:

(ladebug) stop in C::foo(void) 
[#8: stop in void C::foo(void) ]
(ladebug) stop in C::foo(int) 
[#9: stop in void C::foo(int) ]

7.1.9.2 Templates and Instantiations

Debugging of template instantiations is illustrated using the following source text:

(ladebug) list 144: 13
    144 template <class NODETYPE>
    145 void List<NODETYPE>::append(NODETYPE* const node)
    146 {
    147     
    148     if (!_firstNode) 
    149         _firstNode = node;	
    150     else {
    151         Node* currentNode = _firstNode;
    152         while (currentNode->getNextNode())
    153             currentNode = currentNode->getNextNode();
    154 	currentNode->setNextNode(node);	    
    155     }
    156 }

Normal debugging commands then apply to the instantiation (not the template as such):

(ladebug) whatis List<Node>::append
void List<Node>::append(class Node*)
(ladebug) stop in List<Node>::append 
[#1: stop in void List<Node>::append(class Node* const) ]
(ladebug) run
[1] stopped at [void List<Node>::append(class Node* const):148 0x120001d9c]	
    148     if (!_firstNode) 
(ladebug) where 2 
>0  0x120001d9c in ((List<Node>*)0x11ffff268)->List<Node>::append(node=0x140001800) "x_list.cxx":148
#1  0x1200024a4 in main() "x_list.cxx":187

7.1.9.3 Exception Handlers

terminate	Gains control when any unhandled exception occurs, which will result in program termination.
unexpected	Gains control when a function containing an exception specification tries to throw an exception that is not included in that specification.

These special library functions are illustrated using the following source:

(ladebug) list 30: 29
     30 // Throw an exception.  The "throw(int)" syntax tells the compiler that
     31 // only integer exceptions can escape this method.  This will result in 
     32 // an unexpected exception from C++.
     33 //
     34 void throwAnException() throw(int) 
     35 {
     36     throw "Bug";
     37 }
     38 
     39 // Provide some depth to the stack, for demonstration purposes
     40 //
     41 void someOperation()             
     42 {
     43     int z = unalignedAccess();  // Some tests ignore this exception
     44     throwAnException(); 
     45 }
     46 
     47 main() 
     48 {
     49     try {
     50         someOperation();
     51     }
     52     catch(char* str) {
     53         cout << "Caught exception [" << str << "]" << endl;
     54     }
     55     catch(...) {
     56         cout << "Caught something" << endl;
     57     }
     58 }

You can trace the flow of execution, as in the following:

(ladebug) stop at 52 
[#1: stop at "x_signals.cxx":52 ]
(ladebug) stop in all terminate 
[#2: stop in all terminate ]

Information:  An <opaque> type was presented during execution of the previous command.  For complete type information on this symbol, recompilation of the program will be necessary.  Consult the compiler man pages for details on producing full symbol table information using the -g (and -gall for cxx) flags.

(ladebug) stop in all unexpected 
[#3: stop in all unexpected ]
(ladebug) run ... 
[3] stopped at [<opaque> unexpected(void) 0x3ff81f2effc]	
(ladebug) where 
>0  0x3ff81f2effc in unexpected(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) in /usr/lib/cmplrs/cxx/libcxx.so
#1  0x120001b38 in throwAnException() "x_signals.cxx":36
#2  0x120001b88 in someOperation() "x_signals.cxx":44
#3  0x120001bc4 in main() "x_signals.cxx":50
#4  0x1200019c8 in __start(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) in /usr/examples/x_signals
(ladebug) cont 
[3] stopped at [<opaque> unexpected(...) 0x3ff81f160b4]	
(ladebug) where 
>0  0x3ff81f160b4 in unexpected(0x3ffc1700078, 0x3ff81f14c10, 0x0, 0x0, 0x0, 0x0) in /usr/lib/cmplrs/cxx/libcxx.so
#1  0x3ff81f2effc in unexpected(0x3ffc1700078, 0x3ff81f14c10, 0x0, 0x0, 0x0, 0x0) in /usr/lib/cmplrs/cxx/libcxx.so
#2  0x120001b38 in throwAnException() "x_signals.cxx":36
#3  0x120001b88 in someOperation() "x_signals.cxx":44
#4  0x120001bc4 in main() "x_signals.cxx":50
#5  0x1200019c8 in __start(0x3ffc1700078, 0x3ff81f14c10, 0x0, 0x0, 0x0, 0x0) in /usr/examples/x_signals
(ladebug) cont 
[2] stopped at [<opaque> terminate(...) 0x3ff81f15f7c]	
(ladebug) where 
>0  0x3ff81f15f7c in terminate(0x3ffc1700090, 0x3ff81f14c10, 0x11fffeb98, 0x0, 0xa0, 0x0) in /usr/lib/cmplrs/cxx/libcxx.so
#1  0x3ff81f16100 in unexpected(0x3ffc1700090, 0x3ff81f14c10, 0x11fffeb98, 0x0, 0xa0, 0x0) in /usr/lib/cmplrs/cxx/libcxx.so
#2  0x3ff81f2effc in unexpected(0x3ffc1700090, 0x3ff81f14c10, 0x11fffeb98, 0x0, 0xa0, 0x0) in /usr/lib/cmplrs/cxx/libcxx.so
#3  0x120001b38 in throwAnException() "x_signals.cxx":36
#4  0x120001b88 in someOperation() "x_signals.cxx":44
#5  0x120001bc4 in main() "x_signals.cxx":50
#6  0x1200019c8 in __start(0x3ffc1700090, 0x3ff81f14c10, 0x11fffeb98, 0x0, 0xa0, 0x0) in /usr/examples/x_signals
(ladebug) cont 
Thread received signal ABRT
stopped at [<opaque> __kill(...) 0x3ff800ea6c8]	

7.1.10 Special Signal Breakpoints

7.1.10.1 The catch and ignore Commands

signal_command
        : catch_command
        | ignore_command

catch_command
        : catch [ signal_id ]

ignore_command
        : ignore [ signal_id ]

A catch command with an operand specifies that the debugger should catch and handle the given UNIX signal. The signal can be specified by integer number or by standard signal name, with or without the leading "SIG". The catch command is equivalent to the breakpoint command:

(ladebug) catch BUS 

(ladebug) stop signal 10 
[#1: stop signal 10 ]

• No entry is made in the breakpoint table for a catch command.

• A catch for a signal that is already being caught does not create an additional breakpoint for that signal.

An ignore command with an operand specifies that the given UNIX signal should not be caught or handled by the debugger; rather such a signal is passed to your program. The ignore command is equivalent to deleting the breakpoint created by a catch command for that signal.:

(ladebug) ignore BUS 

A catch command without an operand lists all signals that are currently being handled. Similarly, an ignore command without an operand lists the signals that are currently being ignored. Together, the two lists show all signals known to the debugger.

You can issue these commands immediately after the debugger starts to show which signals are caught and which are ignored by default:

(ladebug) catch
INT, QUIT, ILL, TRAP, ABRT, EMT, FPE, BUS, SEGV, SYS, PIPE, TERM, URG, STOP, TTIN, TTOU, XCPU, XFSZ, PROF, USR1, USR2, VTALRM, RTMIN, RTMIN1, RTMIN2, RTMIN3, RTMIN4, RTMIN5, RTMIN6, RTMIN7, RTMAX, RTMAX7, RTMAX6, RTMAX5, RTMAX4, RTMAX3, RTMAX2, RTMAX1
(ladebug) ignore
HUP, KILL, ALRM, TSTP, CONT, CHLD, WINCH, IO

7.1.10.2 Unaligned Accesses (Tru64 UNIX Only)

(ladebug) catch unaligned

Although this looks like a normal catch command, it differs in several respects:

• unaligned is not the name of a UNIX signal.
• There is no corresponding signal number.
• unaligned is never listed by either the catch or ignore commands without an argument.

• No entry is made in the breakpoint table for a catch command.
• Repeating the command does not create an additional breakpoint.

NOTE: You cannot specify unaligned in a signal detector of a normal breakpoint definition.

You can request the debugger to ignore unaligned accesses when catch unaligned is in effect (the default) by using the following command:

(ladebug) ignore unaligned

7.1.10.3 Unaligned Accesses (Linux Only)

7.1.10.4 Ctrl/C

If you give the command ignore SIGINT, then it is no longer possible to regain control of your program using Ctrl/C. In that case, signal SIGINT is delivered directly to your program. Unless your program has explicitly arranged otherwise, SIGINT will result in program termination.

7.1.11 Breakpoint Interactions with exec(), fork(), dlopen() and dlclose() System Calls

The debugger keeps track of the exec() calls that occur so that it can keep track of various properties associated with each executable file. In particular, the breakpoint table is one of those properties. Thus, if you run or rerun your program, the same breakpoints can be re-established, even though a new process is initiated. Similarly, if you work with more than one process, each process has a distinct breakpoint table associated with it.

When a dlopen() system call occurs, the debugger reprocesses the current breakpoint table and automatically sets up the means to detect any events that apply to the newly loaded image.

When a dlclose() system call occurs, the debugger also reprocesses the breakpoint and de-activates any events that apply to the unloaded image.

7.1.12 Obsolete Breakpoint Commands

obsolete_breakpoint_definition_command
        : obsolete_watch_breakpoint_definition_command
        | obsolete_trace_breakpoint_definition_command
	| obsolete_stopi_breakpoint_definition_command
	| obsolete_wheni_breakpoint_definition_command
	| obsolete_tracei_breakpoint_definition_command

7.1.12.1 Obsolete Watchpoint Definition

obsolete_watch_breakpoint_definition_command
        : watch obsolete_watch_detector
            [ obsolete_watch_modifiers ]
            [ breakpoint_actions ]

obsolete_watch_detector
        : variable variable_name
	| [ memory ] start_address_expression
        | [ memory ] start_address_expression , end_address_expression
        | [ memory ] start_address_expression : byte_count_expression

obsolete_watch_modifiers
        : [ access_modifier ]
          [ thread_filter ]
          [ within_modifier ]
          [ logical_filter ]

• The obsolete watchpoint command begins with watch instead of stop.

• The keyword memory is optional; if omitted, it is assumed.

• The order of filters and modifiers is different.

(ladebug) watch variable _firstNode write 
[#3: watch variable _firstNode 0x11ffff0c8, 0x11ffff0cf write ]
(ladebug) cont 
[3] Address 0x11ffff0c9 was accessed at: 
void List<Node>::append(class Node* const): x_list.cxx
 [line 149, 0x120001db0]	stq	r2, 0(r3)
	0x11ffff0c8: Old value = 0x0000000000000000
	0x11ffff0c8: New value = 0x0000000140002c00
[3] stopped at [void List<Node>::append(class Node* const):149 0x120001db4]	
    149         _firstNode = node;	

7.1.12.2 Obsolete Tracepoint Definition

obsolete_trace_breakpoint_definition_command
        : trace [ variable_name ]
            [ thread_filter ]
            [ where_modifier ]
            [ logical_filter ]
            [ breakpoint_actions ]
        | trace function_name [ logical_filter ] [ breakpoint_actions ]
        | trace line_number [ logical_filter ] [ breakpoint_actions ]

where_modifier
        : in function_name
        | at line_number

• The obsolete tracepoint command begins with trace instead of when.

• If a variable name is specified, a trace identification line is displayed only when the value of the variable changes (and the logical filter evaluates to true).

  Note that the debugger implementation for detecting variable changes tends to be slow—at each place where control might be stopped, as specified by the where modifier and filters, the value of the variable is compared to the value remembered at the time execution began.

• The order of filters and modifiers is different.

(ladebug) trace in List<Node>::print 
[#7: trace in void List<Node>::print(void) ]
(ladebug) trace i in List<Node>::print 
[#8: trace i in void List<Node>::print(void) ]
(ladebug) trace List<Node>::print if i { print "Test 1"} 
[#9: trace in void List<Node>::print(void) if i { print "Test 1"} ]

If the trace command is given with no arguments, the debugger prints a trace identification line when each function in your program is entered. For example:

(ladebug) trace 
[#10: trace ]
(ladebug) status 
#10 at procedure entry { trace-proc }

7.1.12.3 Instruction-related breakpoint commands

obsolete_stopi_breakpoint_definition_command
        : stopi [ expression ]
            [ thread_filter ] [ match_address ] [ logical_filter ]

obsolete_tracei_breakpoint_definition_command
        : tracei [ expression ]
            [ thread_filter ] [ match_address ] [ logical_filter ]

obsolete_wheni_breakpoint_definition_command
        : wheni [ expression ]
            [ thread_filter ] [ match_address ] [ logical_filter ]
            breakpoint_actions

match_address
        : at address_expression

The stopi, tracei, and wheni forms of breakpoint definition are similar to the corresponding stop, trace, and when forms, with the following differences:

• They have a different initial keyword.

• If a variable name is specified, then breakpoint triggers only when the value of the variable changes (and the logical and thread filters are true).

  Note that the Ladebug implementation for detecting variable changes tends to be slow: at each place where control might be stopped, as specified by the where modifier and filters, the value of the variable is compared to the value remembered at the time execution began.

  Most important, the variable change and filter tests are performed after every instruction is executed, making these definitions especially demanding on program performance.

• The order of filters and modifiers is different.

• The at keyword is followed by an address in these commands, instead of a line number.

7.2 Breakpoint Tables

breakpoint_table_command
        : show_all_breakpoints_command
        | delete_breakpoint_command
        | enable_breakpoint_command
        | disable_breakpoint_command

• A unique breakpoint number that is used to identify and refer to that breakpoint.
• An event description that characterizes the circumstances under which the breakpoint triggers.
• Actions (a possibly empty list of Ladebug commands) to be performed when the breakpoint triggers.
• A final disposition: either continue or break (stop).
• Enabled and disabled states.

In addition to the main effects of a breakpoint definition, as discussed in Breakpoint Definitions, a breakpoint definition also sets the debugger variable $lasteventmade to the breakpoint number of the breakpoint just defined. This value can be recalled for later use if desired. For example:

(ladebug) stop in List<Node>::append 
[#2: stop in void List<Node>::append(class Node* const) ]
(ladebug) cont 
[2] stopped at [void List<Node>::append(class Node* const):148 0x120001d9c]	
    148     if (!_firstNode) 
(ladebug) print $lasteventmade
2
(ladebug) set $my_break = $lasteventmade
(ladebug) print $my_break
2

If an error occurs in a breakpoint command, the variable $lasteventmade is not changed.

7.2.1 Showing Breakpoint Status

show_all_breakpoints_command
        : status

(ladebug) status 
#1 PC==0x1200023f8 in int main(void) "x_list.cxx":182 { stop }
#2 PC==0x120001d9c in void List<Node>::append(class Node* const) "x_list.cxx":148 { break }
#3 Access memory (write) 0x11ffff0c8 to 0x11ffff0cf { stop }

When large or complex values are passed by value to the routine in the status line, the output can be voluminous. You can set the control variable $statusargs to 0 to suppress the output of argument type information in the status line.

7.2.2 Enabling, Disabling, and Deleting Breakpoints

disable_breakpoint_command
        : disable all
        | disable breakpoint_number_expression ,...

enable_breakpoint_command
	: enable all
        | enable breakpoint_number_expression ,...

delete_breakpoint_command
        : delete all
	| delete breakpoint_number_expression ,...

(ladebug) disable 1
(ladebug) status 
#1 PC==0x1200023f8 in int main(void) "x_list.cxx":182 { stop } Disabled
#2 PC==0x120001d9c in void List<Node>::append(class Node* const) "x_list.cxx":148 { break }
#3 Access memory (write) 0x11ffff0c8 to 0x11ffff0cf { stop }
(ladebug) disable 10 - 8,1 + 1 + 1
(ladebug) status 
#1 PC==0x1200023f8 in int main(void) "x_list.cxx":182 { stop } Disabled
#2 PC==0x120001d9c in void List<Node>::append(class Node* const) "x_list.cxx":148 { break } Disabled
#3 Access memory (write) 0x11ffff0c8 to 0x11ffff0cf { stop } Disabled
(ladebug) delete 1
(ladebug) status 
#2 PC==0x120001d9c in void List<Node>::append(class Node* const) "x_list.cxx":148 { break } Disabled
#3 Access memory (write) 0x11ffff0c8 to 0x11ffff0cf { stop } Disabled
(ladebug) enable all 
(ladebug) status 
#2 PC==0x120001d9c in void List<Node>::append(class Node* const) "x_list.cxx":148 { break }
#3 Access memory (write) 0x11ffff0c8 to 0x11ffff0cf { stop }

Chapter 8 - Looking Around at the Code, the Data, and Other Process Information

• The source files
• The threads, their mutexes, and their condition variables
• The call stack of one or more threads
• The data
• The generated code
• The shared libraries that are loaded

8.1 Looking at the Source Files

• Determine the location of the source files
• Select a particular file as the current file
• List portions of the current file
• Search through the current file for target strings

browse_source_command
        : source_directory_mapping_command
        | source_searchlist_command
	| select_source_file_command
        | list_source_file_command
        | search_source_file_command

Source files are compiled and linked into executable files. During debugging, the debugger tries to find these source files to display them for you. If the source files have moved, or if the paths to them are relative, the debugger may not be able to locate them. All the information the debugger needs comes from the executable files or shared libraries, not the source files.

8.1.1 How the Debugger Finds Source Files

The debugger searches for a source file (dir_name/base_name) using the following algorithm:

1. If dir_name is mapped to another source directory (mapped_dir_name), look for mapped_dir_name/base_name. Otherwise, look for the original file dir_name/base_name.
2. If Step 1 fails to find a readable file, for each entry use_dir in use_list, look for use_dir/dir_name/base_name. Note that the use_list entries are tried in the order they appear in the use_list.
3. If Step 2 fails, for each entry use_dir in use_list, look for use_dir/base_name. Just as in Step 2, the use_list entries are tried in the order they appear in the use_list.
4. If Step 3 fails, the debugger cannot find any source file.

The debugger has source directory mapping commands that:

• Inform you in which directories the debugger is looking for the source files.
• Allow you to designate directories in which the debugger will look for the source files.

	% pwd
        /usr/users/ladebug/sandbox/test/src/common/Examples
	% ls -R
        bin/ src/

	./bin:
        x_solarSystem*                 
   
	./src:
	solarSystemSrc/

        ./src/solarSystemSrc:
        base_class_includes/    main/                   star.cxx
        derived_class_includes/ orbit.cxx                        
        heavenlyBody.cxx        planet.cxx
        
        ./src/solarSystemSrc/base_class_includes:
        heavenlyBody.h  orbit.h

        ./src/solarSystemSrc/derived_class_includes:
        planet.h  star.h

        ./src/solarSystemSrc/main:
        solarSystem.cxx
        % cd src
	% cc -g -o ../bin/x_solarSystem \
          -IsolarSystemSrc/base_class_includes \
          -IsolarSystemSrc/derived_class_includes \
          main/solarSystem.cxx heavenlyBody.cxx orbit.cxx planet.cxx star.cxx

	% mv solarSystemSrc movedSolarSystemSrc

(ladebug) list $curline - 10: 20
Source file not found or not readable, tried...
    solarSystemSrc/main/solarSystem.cxx
    ./solarSystemSrc/main/solarSystem.cxx
    ../src/solarSystemSrc/main/solarSystem.cxx
    /usr/users303/brett/project_ladebug/sb/build-latest/test/src/common/Examples/bin-alpha-osf1/solarSystemSrc/main/solarSystem.cxx
    ./solarSystem.cxx
    ../src/solarSystem.cxx
    /usr/users303/brett/project_ladebug/sb/build-latest/test/src/common/Examples/bin-alpha-osf1/solarSystem.cxx

The following command displays a summary of the source directories in a.out. The ellipsis (...) here means that solarSystemSrc contains one or more source directories.

(ladebug) show source directory 
.
solarSystemSrc
 ...
/usr/include/cxx

Information: You can further expand ellipsis points (...) using the command

    show source directory <directory>
or
    show all source directory <directory>

where <directory> is the directory on the line above the '...'.
The first command displays only the children of <directory>, whereas
the second command displays all the descendants of <directory>.

(ladebug) map source directory solarSystemSrc ../src/movedSolarSystemSrc
(ladebug) list $curline - 10: 20
    104 
    105     // Insert the new entry appropriately
    106     //
    107     if (iAmBiggerThan < biggestCount) {
    108         biggestMoons[iAmBiggerThan] = moon;
    109     }
    110 }
    111 
    112 void main()
    113 {
>   114     unsigned int j = 1;    // for scoping examples
    115     for (unsigned int i = 0; i < biggestCount; i++)
    116         biggestMoons[i] = NULL;
    117 
    118     Star *sun = new Star("Sol", G, 2); 
    119     buildOurSolarSystem(sun);
    120     sun->printBodyAndItsSatellites(j);
    121     printBiggestMoons();
    122 }

(ladebug) show all source directory 
.
solarSystemSrc  *=>  ../src/movedSolarSystemSrc
 solarSystemSrc/base_class_includes  =>  ../src/movedSolarSystemSrc/base_class_includes
 solarSystemSrc/derived_class_includes  =>  ../src/movedSolarSystemSrc/derived_class_includes
 solarSystemSrc/main  =>  ../src/movedSolarSystemSrc/main
/usr/include/cxx

To summarize, the debugger provides the following four commands for checking and setting source directory mappings:

source_directory_mapping_command
        : show source directory [ directory_name ]
	| show all source directory [ directory_name ]
	| map source directory from_directory_name to_directory_name
	| unmap source directory  from_directory_name

The show all source directory command is identical to the show source directory command except that the mapping information of all the descendants of directory_name is displayed:

(ladebug) show source directory 
.
solarSystemSrc  *=>  ../src/movedSolarSystemSrc
 ...
/usr/include/cxx
(ladebug) show all source directory 
.
solarSystemSrc  *=>  ../src/movedSolarSystemSrc
 solarSystemSrc/base_class_includes  =>  ../src/movedSolarSystemSrc/base_class_includes
 solarSystemSrc/derived_class_includes  =>  ../src/movedSolarSystemSrc/derived_class_includes
 solarSystemSrc/main  =>  ../src/movedSolarSystemSrc/main
/usr/include/cxx

When you further expand ellipsis points (...) where directory is the directory on the line above the ellipsis points:

• The show source directory command displays only the children of directory_name.
• The show all source directory command displays all the descendants of directory_name.

The unmap source directory command maps from_directory_name back to itself; in other words, if from_directory_name has been mapped to some other directory, this command will restore its default mapping. For example:

(ladebug) show source directory 
.
solarSystemSrc  *=>  ../src/movedSolarSystemSrc
 ...
/usr/include/cxx
(ladebug) show source directory solarSystemSrc
solarSystemSrc  *=>  ../src/movedSolarSystemSrc
 solarSystemSrc/base_class_includes  =>  ../src/movedSolarSystemSrc/base_class_includes
 solarSystemSrc/derived_class_includes  =>  ../src/movedSolarSystemSrc/derived_class_includes
 solarSystemSrc/main  =>  ../src/movedSolarSystemSrc/main

(ladebug) unmap source directory solarSystemSrc
(ladebug) show source directory solarSystemSrc
solarSystemSrc
 solarSystemSrc/base_class_includes
 solarSystemSrc/derived_class_includes
 solarSystemSrc/main

By default, the use_list is: (1) the current directory and (2) the directory containing the executable file. Each process has its own use_list. You can also use the ladebug command -I option to specify search directories.

The following commands let you view and modify the use_list.

source_searchlist_command
        : use_command
        | unuse_command

You can customize your debugger environment source code search paths by adding commands to your .dbxinit file that use the use command:

use_command
	: use [directory_name ...]

If the directory_name is specified, it is either appended to or replaces the use_list, depending on whether the value of the $dbxuse debugger variable is zero (append) or non-zero (replace).

The unuse command removes entries from the use_list:

unuse_command
        : unuse [directory_name ...]
        | unuse *

Enter the unuse command without the directory_name to set the search list to the default (the home directory, the current directory, and the directory containing the executable file). Include the directory names to remove them from the search list. The asterisk (*) argument removes all directories from the search list.

8.1.2 How the Debugger Chooses Which Source File to List

You can see and modify the current source file selection:

select_source_file_command
        : file [ filename ]
	: fileexpr [ expression ]

Use the file command without a file name to display the name of the current file scope. Include the file name to change the file scope. Change the file scope to set a breakpoint in a function not in the file currently being executed.

To see source code for or set a breakpoint in a function not in the file currently being executed, use the file command to set the file scope.

If the file name is not a literal, use the fileexpr command. For example, if you have a script that calculates a file name in a debugger variable or in a routine that returns a file name as a string, you can use fileexpr to set the file.

The following example uses the file command to set the debugger file scope to a file different from the main program, and then stops at line number 26 in that file. This example also shows the fileexpr command setting the current scope back to the original file which is solarSystem.cxx.

(ladebug) run
[1] stopped at [void main(void):114 0x120004040]	
    114     unsigned int j = 1;    // for scoping examples
(ladebug) file 
solarSystemSrc/main/solarSystem.cxx
(ladebug) set $originalFile = "solarSystem.cxx"
(ladebug) list 24: 10
     24     Moon   *phobos    = new Moon("Phobos",       9,   11, mars);
     25     Moon   *deimos    = new Moon("Deimos",      23,    6, mars);
     26     
     27     Planet *jupiter   = new Planet("Jupiter",     778330, sun);
     28     Moon   *io        = new Moon("Io",         422, 1815, jupiter);
     29     Moon   *europa    = new Moon("Europa",     671, 1569, jupiter);
     30     Moon   *ganymede  = new Moon("Ganymede",  1070, 2631, jupiter);
     31     Moon   *callisto  = new Moon("Callisto",  1883, 2400, jupiter);
     32     Moon   *amalthea  = new Moon("Amalthea",   181,   98, jupiter); 
     33     
(ladebug) file star.cxx 
(ladebug) list 24: 10
     24 // Stars are simple objects
     25 //
     26 Star::Star(
     27     char*           name, 
     28     StellarClass    classification, 
     29     StellarSubclass subclassification)
     30         : HeavenlyBody(name),
     31           _classification(classification),
     32           _subclassification(subclassification)
     33 {
(ladebug) stop at 26 
[#2: stop at "solarSystemSrc/star.cxx":26 ]
(ladebug) cont 
[2] stopped at [Star::Star(char*, enum StellarClass, StellarSubclass):26 0x120004b4c]	
     26 Star::Star(
(ladebug) file 
solarSystemSrc/star.cxx
(ladebug) fileexpr $originalFile 
(ladebug) file 
solarSystemSrc/main/solarSystem.cxx
(ladebug) list 24: 10
     24     Moon   *phobos    = new Moon("Phobos",       9,   11, mars);
     25     Moon   *deimos    = new Moon("Deimos",      23,    6, mars);
     26     
     27     Planet *jupiter   = new Planet("Jupiter",     778330, sun);
     28     Moon   *io        = new Moon("Io",         422, 1815, jupiter);
     29     Moon   *europa    = new Moon("Europa",     671, 1569, jupiter);
     30     Moon   *ganymede  = new Moon("Ganymede",  1070, 2631, jupiter);
     31     Moon   *callisto  = new Moon("Callisto",  1883, 2400, jupiter);
     32     Moon   *amalthea  = new Moon("Amalthea",   181,   98, jupiter); 
     33     

8.1.3 Listing Source Files

However, some primitive inspection capabilities are built into the debugger. The list command displays source lines, beginning with the source code line corresponding to one of the following:

• The position of the program counter
• The last line listed, if multiple list commands are entered
• The line number specified as the first argument to the list command

list_source_file_command
        : list [ line_expression ]
        | list line_expression , line_expression
        | list line_expression : line_expression

line_expression
	: expression

If specified, the first expression must evaluate to either an integer (the line number of the first line to display within the current source file) or a function (the first line of the function).

Specify the exact range of source lines as either a comma followed by the expression for the last line, or a colon followed by the expression for the the number of lines. This second expression must evaluate to an integer value.

If a second expression is not given, the debugger shows 20 lines, fewer if the end of source file is reached.

For example, to list lines 16 through 20:

(ladebug) list 16, 20
     16 
     17 class Node {
     18 public:
     19     Node ();
     20     

(ladebug) list 16: 6
     16 
     17 class Node {
     18 public:
     19     Node ();
     20     
     21     virtual void printNodeData() const = 0; 

8.1.4 Searching the Content of Source Files

search_source_file_command
        : / [ string ]
        | ? [ string ]

NOTE: The string is actually just the rest of the line, not a string literal. The rest of the line is still having alias expansion done on it.

Use a slash (/) to search forward from the most recently listed line; use a question mark (?) to search backward. Like most searches, it will stop at the end (or beginning) of the file being searched, and will wrap if the command is repeated at that point.

When the string is omitted, the previous search continues from where it found the string. When the string is present, the search starts from either the start (/) or the end (?) of the current line.

When a match is found, the debugger lists the line number and the line, but that line does not become the current line. For example:

1. To locate _firstNode:

(ladebug) /_firstNode 
     69     NODETYPE* _firstNode;

2. Then to locate append before line 69:

(ladebug) ?append 
     65     void      append  (NODETYPE* const node);

3. Then to locate append after line 65:

(ladebug) /append 
    145 void List<NODETYPE>::append(NODETYPE* const node)

8.2 Looking at the Threads (Tru64 UNIX Only)

8.2.1 Thread Levels

To specify the thread level, set the $threadlevel debugger variable to one of the following strings:

• decthreads—for POSIX thread library debugging
• native—for kernel thread debugging.

For example:

(ladebug) set $threadlevel = "decthreads"

For core file debugging, the $threadlevel is always set to "native".

8.2.2 Thread Manipulation Commands

You can use a variety of commands to manipulate the threads:

thread_command
        : show_thread_command
        | switch_thread_command
        | show_condition_variable_command
        | show_mutex_variable_command
        | pthread_command

8.2.3 Thread Display Commands

show_thread_command
	: show thread [ thread_id_list ] [ thread-state-filter ]
 
thread_id_list
	: thread_id ,...
        | *
	
thread_state_filter
	: with state eq thread_state

eq
	: ==               (for Ada, C, and C++)
	| .eq.             (for Fortran)  
	| =                (for Cobol)
	| equal [ to ]     (for Cobol)

thread_state
	: ready
	| running
	| terminated
	| blocked 

Use the show thread command without parameters to list all the threads known to the debugger.

If you specify one or more thread identifiers, the debugger displays information about the threads you specify, if the thread matches what you specified in the list. If you omit a thread specification, the debugger displays information for all threads.

Use the show thread commands to list threads that have specific characteristics, such as threads that are currently blocked. For example:

(ladebug) print $threadlevel
"decthreads"
(ladebug) show thread 
  Thread Name                      State           Substate    Policy       Pri
  ------ ------------------------- --------------- ----------- ------------ ---
       1 default thread            running                     SCHED_OTHER  19
      -1 manager thread            blk SCS                     SCHED_RR     19
      -2 null thread for VP 0      ready           new         null thread   0
      -3 null thread for VP 1      ready                       null thread   0
      -4 null thread for VP 0      ready           new         null thread   0
      -5 null thread for VP 0      ready           new         null thread   0
>*     2 <anonymous>               running                     SCHED_OTHER  19
(ladebug) set $threadlevel = "native"
(ladebug) print $threadlevel
"native"
(ladebug) show thread 
   Id                  State         
>* 0x9                 stopped       
>* 0x9                 unstarted     
   0x3                 unstarted     
   0x7                 unstarted     

You can switch to a different thread as the current thread. The debugger variable $curthread contains the thread identifier of the current thread.

switch_thread_command
  	  : thread [ thread_id ]

Use the thread command without a thread identifier to identify the current thread. Supply a thread identifier to make another thread the current thread:

8.2.4 Mutex Queries

• All threads see a clean and consistent view of the data, without allowing one thread to change something while another thread is reading it
• Two threads do not change different parts of the data at the same time, possibly in inconsistent ways.

show_mutex_variable_command
        : show mutex  [ mutex_id_list ] [ mutex_state_filter ]

mutex_id_list
	: mutex_id  ,...
        | (mutex_id ,...)

mutex_state_filter
	: with state eq mutex_state
	
mutex_state
	: locked

Use the show mutex with state == locked command to display information exclusively for locked mutexes.

If $verbose is set to 1, the sequence numbers of the threads locking the mutexes are displayed.

The following example shows the output from a simple show mutex command:

(ladebug) show mutex 

Mutex  Name                      State Owner  Pri Type     Waiters (+Count)
------ ------------------------- ----- ------ --- -------- --------------------
     1 malloc                                     Normal
     2 brk                                        Normal
     3 exc cr                                     Recurs
     4 exc read rwl                               Normal
     5 known mutex queue                          Normal
     6 known cond queue                           Normal
     7 VM 0 lookaside                             Normal
     8 VM 1 lookaside                             Normal
     9 VM 2 lookaside                             Normal
    10 VM 0 cache                                 Normal
    11 VM 1 cache                                 Normal
    12 VM 2 cache                                 Normal
    13 thread 1 mutex                             Normal
    14 thread 1 wait                              Normal
    15 thread -1 mutex                            Normal
    16 thread -1 wait                             Normal
    17 thread -2 mutex                            Normal
    18 thread -2 wait                             Normal
    19 thread -3 mutex                            Normal
    20 thread -3 wait                             Normal
    21 thread -4 mutex                            Normal
    22 thread -4 wait                             Normal
    23 thread -5 mutex                            Normal
    24 thread -5 wait                             Normal
    25 debugger client registry                   Normal
    26 Global lock                                Recurs
    27 <anonymous>                                Normal
    28 <anonymous>                                Normal
    29 <anonymous>                                Normal
    30 thread 2 mutex                             Normal
    31 thread 2 wait                              Normal
    32 thread 0 mutex                             Normal
    33 thread 0 wait                              Normal

If the application being debugged has no pthreads, or if the $threadlevel is set to native, an appropriate message is issued.

8.2.5 Condition Variable Queries

show_condition_variable_command
        : show condition [ condition_id_list ] [ condition_state_filter ]

condition_id_list
        : condition_id ,...
	| (condition_id ,...)

condition_state_filter
	: with state eq condition_state	   
	
condition_state
	: wait  

Use the show condition command to list information about currently available condition variables. If you supply one or more condition identifiers, the debugger displays information about the condition variables you specify, provided that the list matches the identities of currently available condition variables. If you omit the condition variable specification, the debugger displays information about all the condition variables currently available.

Use the show condition with state == wait command to display information only for condition variables that have one or more threads waiting. If $verbose is set to 1, the sequence numbers of the threads waiting on the condition are displayed.

The following example shows output from a simple show condition command:

(ladebug) show condition 

Cond   Name                      Mutex  Type  Waiters (+Count)
------ ------------------------- ------ ----- ---------------------------------
    10 thread -3 wait
     3 thread 1 join
    11 thread -4 join
     6 thread -1 wait
    12 thread -4 wait
     2 <anonymous>
    13 thread -5 join
     7 thread -2 join
    14 thread -5 wait
     4 thread 1 wait
    15 <anonymous>
     8 thread -2 wait
    16 thread 2 join
     1 <anonymous>
    17 thread 2 wait
     9 thread -3 join
    18 thread 0 join
     5 thread -1 join
    19 thread 0 wait

If the application being debugged has no pthreads, or if the $threadlevel is set to native, an appropriate message is issued.

8.2.6 Other Thread Commmands

You can use the where command to display the stack trace of current threads. You can specify one or more threads or all threads.

The print command evaluates an optional expression in the context of the current thread and displays the result.

The call command evalutes an expression in the context of the current thread and makes the call in the context of the current thread.

The printregs command prints the registers for the current thread.

8.2.7 Undocumented pthread Support

You can pass an undocumented string directly into the undocumented pthread debugging support. This is an internal debugging aid, not intended for general use.

pthread_command
        : pthread string

8.3 Looking at the Call Stack

The machine code generated for these functions maintains this call stack. Some of this maintenance is done before the call, some at the start of the called function, some at the end of the called function, and some after the call.

Non-optimized machine code is usually very easy to correlate with the source code, but optimized machine code can be tricky. Details of this are given later in this section.

The debugger controls the call stacks of all the threads; you can use it to examine and manipulate call stacks, and use them as a basis for further queries:

call_stack_command
        : show_stack_command
        | change_stack_frame_command
        | pop_stack_frame_command

When your process is stopped by the debugger, you can show the call stack of the thread that caused the stoppage, or the call stack of any other thread.

The following commands show the most recent call frames on the call stack of the current or specified threads:

show_stack_command
	: where [ expression ] [ thread_specifier ]

thread_specifier
	: thread thread_id ,...	
        | thread all 

If specified, the expression must evaluate to a nonnegative integer. You can specify the number of call frames to show. If not specified, all the call frames for the thread are shown.

If specified, the thread_specifier specifies the threads whose call stacks are to be shown. If not specified, just the current thread is used.

When large and complex values are passed by value to a routine on the stack, the output of the where, up, down, and dump commands can be voluminous. You can set the control variable $stackargs to 0 to suppress the output of argument values in the where, up, down, and dump commands.

The stack trace provides the following information for each call level:

Call level	The number used to refer to a call level on the stack. The function entered most recently is at level 0.
Memory address	The address of the next instruction to be executed at this level.
Function name	The name of the function for the memory address.
File name	The source file for the memory address.
Line number	The number of the next source line of the memory address.

8.3.1 Navigating the Call Stack

change_stack_frame_command
        : up   [ expression ]
        | down [ expression ]
        | func [ loc ]

Use the up command or the down command without the expression to change to the call frame located one level up or down the stack. Specify an expression that evaluates to an integer to change the call frame up or down the specified number of levels. If the number of levels exceeds the number of active calls on the stack, the debugger issues a warning message and the call frame does not change.

When the current call frame changes, the debugger displays the source line corresponding to the last instruction executed in the function executing the selected call frame.

When large and complex values are passed by value to a routine on the stack, the output of the where, up, down, and dump commands can be voluminous. You can set the control variable $stackargs to 0 to suppress the output of argument values in the where, up, down, and dump commands.

Use the func command without the loc to display the current function. To change the function scope to a function that has a call frame in the call stack, specify the loc either as the name of the function or as an integer expression evaluating to the call level. If you specify the name, the most-recently entered call frame for that function becomes the current call frame.

If no frames are available to select from, the debugger context is set to the static context of the named function. The current scope and current language are set based on that function. Types and static variables local to that function are now visible and can be evaluated.

If you enter an integer expression, the debugger moves to the frame at level n, just as if you had entered up n.

In the following example, the current call frame is changed to one for method Planet::print so that a variable in that instance of print() can be displayed:

(ladebug) where 4 
#0  0x1200047dc in ((Planet*)0x140002860)->Planet::print(i=2) "solarSystemSrc/planet.cxx":19
#1  0x12000422c in ((HeavenlyBody*)0x140002860)->HeavenlyBody::printBodyAndItsSatellites(i=2) "solarSystemSrc/heavenlyBody.cxx":62
>2  0x120004254 in ((HeavenlyBody*)0x140002000)->HeavenlyBody::printBodyAndItsSatellites(i=1) "solarSystemSrc/heavenlyBody.cxx":68
#3  0x120004110 in main() "solarSystemSrc/main/solarSystem.cxx":120
(ladebug) list $curline - 5: 10
     62     print(i);
     63 
     64     // Recursively deal with the satellites.  Redeclare i for scoping examples.
     65     //
     66     unsigned int j = 1;
     67     for (HeavenlyBody* i = _firstSatellite; i; i = i->_outerNeighbor) {
>    68     	i->printBodyAndItsSatellites(j++);
     69     }
     70 }
(ladebug) whatis i
class HeavenlyBody* i
(ladebug) print i
0x140002860
(ladebug) func Planet::print
virtual void Planet::print(unsigned int) in solarSystemSrc/planet.cxx line No. 19:
     19     cout << "(" << i 
(ladebug) where 4 
>0  0x1200047dc in ((Planet*)0x140002860)->Planet::print(i=2) "solarSystemSrc/planet.cxx":19
#1  0x12000422c in ((HeavenlyBody*)0x140002860)->HeavenlyBody::printBodyAndItsSatellites(i=2) "solarSystemSrc/heavenlyBody.cxx":62
#2  0x120004254 in ((HeavenlyBody*)0x140002000)->HeavenlyBody::printBodyAndItsSatellites(i=1) "solarSystemSrc/heavenlyBody.cxx":68
#3  0x120004110 in main() "solarSystemSrc/main/solarSystem.cxx":120
(ladebug) list $curline - 5: 10
     14 {
     15 }
     16 
     17 void Planet::print(unsigned int i) const
     18 {
>    19     cout << "(" << i 
     20          << ") Planet [" << HeavenlyBody::name() << "]; "; 
     21     printOrbitalParameters();
     22     cout << endl;
     23 }
(ladebug) whatis i
unsigned int i
(ladebug) print i
2

8.3.2 The pop command

pop_stack_frame_command
        : pop [ expression ]

NOTE: Because it is extremely unlikely this will fix all the effects of a half-executed call, this command is not recommended for general use. Furthermore, the pop command does not provide a way to specify a return value when the frame being discarded corresponds to a function that should return a value. You may need to use the assign command to restore the values of global variables.

Instead of the pop command, you may want to use the return command, which finishes the call corresponding to the selected frame.

8.3.3 Call Frames and Optimized Code

• Inlining is when the compiler completely eliminates the call by instead generating the instructions for the called function at the call site, usually followed by merging those instructions with the other instructions surrounding the call site.

• Outlining is when the compiler creates a function where one did not exist explicitly in the source. For example, the compiler turns a loop body into a function, so that it can generate code that uses threads to execute the different iterations in parallel, or the compiler creates a single shared function to replace several sections of the source that are similar.

Depending on the information the compiler makes available to the debugger, inlined calls may or may not show up in the call stack display. Outlined calls will show up, and will be correlated to the code they came from. The compiler will probably have supplied the debugger with some invented name for the function.

8.3.4 Call Frames and Machine Code Correlation

• The machine code before the call performs the following operations:
  • Sets some context registers.
  • Puts the parameters either in registers or memory.
  • Loads the address of the function into a register.
  • Loads the address to return to into a register.
  • Branches to the function.

• The machine code at the start of the called function performs the following operations:
  • Sets some context registers.
  • Allocates stack space.
  • Saves some registers in the stack space.
  • Performs some setup of the local variables.

• The machine code at the end of the called function performs the following operations:
  • Restores the saved registers from the stack space.
  • Deallocates the stack space.
  • Branches to the address to return to.

• The machine code at the return address of the call frame sets some context registers.

8.3.5 Special C++ Issues

(ladebug) stop in List<Node>::print 
[#3: stop in void List<Node>::print(void) ]
(ladebug) cont 
[3] stopped at [void List<Node>::print(void):162 0x120001e70]	
    162     Node* currentNode = _firstNode;
(ladebug) where 2 
>0  0x120001e70 in ((List<Node>*)0x11ffff288)->List<Node>::print() "x_list.cxx":162
#1  0x1200026fc in main() "x_list.cxx":200

8.4 Looking at the Data

look_around_command
        : various_print_command
        | c++_look_around_command
	| call_command
        | whatis_command
        | whereis_command
        | which_command

various_print_command
        : print_command
        | printf_command
        | print_registers_command
        | dump_command

8.4.1 The print Command

print_command
	: print [ expression ,...  ]
        | print rescoped_expression
	| print printable_type
	 
rescoped_expression
	: filename ` qual_symbol
	| ` qual_symbol
	    
qual_symbol
	: expression
	| qual_symbol ` expression    

Use the $hexints, $decints, or $octints variables to select a radix for the output of the print command. Correspondingly, if you do not want to change the radix permanently, use the printx, printd, or printo commands to change the display radix temporarily.

Consider the following declarations in a C++ program:

(ladebug) list 59: 2
     59 const unsigned int biggestCount = 10;
     60 static Moon *biggestMoons[biggestCount];

(ladebug) print biggestMoons
[0] = 0x140002bc0,[1] = 0x140002f20,[2] = 0x140002c20,[3] = 0x140002b00,[4] = 0x140002920,[5] = 0x140002b60,[6] = 0x1400032e0,[7] = 0x1400031c0,[8] = 0x140002ec0,[9] = 0x140003220

(ladebug) print biggestMoons[3]
0x140002b00
(ladebug) print *biggestMoons[3]
class Moon { 
  _radius = 1815; 
  _name = 0x1200020b0="Io";       // class Planet::HeavenlyBody
  _innerNeighbor = 0x0;           // class Planet::HeavenlyBody
  _outerNeighbor = 0x140002b60;   // class Planet::HeavenlyBody
  _firstSatellite = 0x0;          // class Planet::HeavenlyBody
  _lastSatellite = 0x0;           // class Planet::HeavenlyBody
  _primary = 0x140002aa0;         // class Planet::Orbit
  _distance = 422;                // class Planet::Orbit
  _name = 0x140004280="Jupiter 1";               // class Planet::Orbit
}

8.4.1.1 Dereferencing Pointers

(ladebug) whatis newNode
class IntNode* newNode
(ladebug) print newNode
0x140001800
(ladebug) print *newNode
class IntNode {
  _data = 1; 
  _nextNode = 0x0;                // class Node
}

8.4.1.2 Printing C Strings

8.4.1.3 Restrictions on the print Command

8.4.2 The printf Command

printf_command	
	: printf [format_string [, expression  ,... ]]

(ladebug) printf "The PC is 0x%x", $pc
The PC is 0x120002700

8.4.3 The printregs Command

print_registers_command
	: printregs

(ladebug) printregs 
$r0  [$v0]  = 4396996887520             $r1  [$t0]  = 0
$r2  [$t1]  = 16384                     $r3  [$t2]  = 0
$r4  [$t3]  = 8192                      $r5  [$t4]  = 4395900160076
$r6  [$t5]  = 0                         $r7  [$t6]  = 0
$r8  [$t7]  = 0                         $r9  [$s0]  = 342189472
$r10 [$s1]  = 0                         $r11 [$s2]  = 4096
$r12 [$s3]  = 351003456                 $r13 [$s4]  = 4096
$r14 [$s5]  = 340581568                 $r15 [$s6]  = 1
$r16 [$a0]  = 4395931657104             $r17 [$a1]  = 4395931692608
$r18 [$a2]  = 43                        $r19 [$a3]  = 0
$r20 [$a4]  = 0                         $r21 [$a5]  = 3162
$r22 [$t8]  = 0                         $r23 [$t9]  = 4395899898312
$r24 [$t10] = 0                         $r25 [$t11] = 0
$r26 [$ra]  = 4831848192                $r27 [$t12] = 4395931628176
$r28 [$at]  = 0                         $r29 [$gp]  = 5368742704
$r30 [$sp]  = 4831834704                $r31 [$zero]= 0
$f0         = 10.1230001449585          $f1         = 0
$f2         = 0                         $f3         = 0
$f4         = 0                         $f5         = 0
$f6         = 0                         $f7         = 0
$f8         = 0                         $f9         = 0
$f10        = 0                         $f11        = 1.513228014981478e-315
$f12        = 0.1                       $f13        = 0
$f14        = 2.035550460865936e-320    $f15        = 3.00513504203182e-315
$f16        = 10.1230001449585          $f17        = 10.1230001449585
$f18        = 10.1230001449585          $f19        = 10.1230001449585
$f20        = 1.722711809292915e-315    $f21        = 1.513228014981478e-315
$f22        = 1.722711809292915e-315    $f23        = 1.667281912556707e-315
$f24        = 1.722711809292915e-315    $f25        = 1.513099478863056e-315
$f26        = 1.722714576060532e-315    $f27        = 1.513249931733528e-315
$f28        = 1.703843086550973e-315    $f29        = 0
$f30        = 1.722714576060532e-315    $f31        = 0
$pc         = 0x120002700               $ps         = 0x8
$fpcr       = 0x800000000000000         $vfp        = 0x11ffff2f0

8.4.4 The dump Command

Use the dump . command (include the dot) to list the parameters and local variables for all functions active on the stack.

dump_command	
	: dump qual_symbol
        | dump .

(ladebug) dump 
>0  0x120002700 in main() "x_list.cxx":200
nodeList=class List<Node>{ ... }
newNode=0x140001800
cNode=0x140002000
newNode2=0x140001840
cNode2=0x140002030

When large and complex values are passed by value to a routine on the stack, the output of the where, up, down, and dump commands can be voluminous. You can set the control variable $stackargs to 0 to suppress the output of argument values in the where, up, down, and dump commands.

8.4.5 The call Command

call_command
	: call call_expression

While the program counter is saved and restored, calling a function does not shield the program state from alteration if the function you call allocates memory or alters global variables. If the function affects global program variables, for instance, those variables will be permanently changed.

Functions compiled without the debugger option to include debugging information may lack important parameter information and are less likely to yield consistent results when called.

The call command executes the specified function with the parameters you supply and then returns control to you (at the Ladebug prompt) when the function returns. The call command discards the return value of the function. If you embed the function call in the expression argument of a print command, the debugger prints the return value after the function returns. The following example shows both methods of calling a function:

(ladebug) call earth->distance()
(ladebug) print earth->distance()
149600

(ladebug) print earth->distance() - 100000
49600
(ladebug) print mars->distance() - earth->distance()
78340
(ladebug) call io->print(3)
(3) Moon [Io], radius [1815] km; <Jupiter 1> orbits at 422 Megameters

When you call a function when execution is suspended in a called function, you are nesting function calls, as shown in the following example:

(ladebug) where 2 
>0  0x120003cf0 in buildOurSolarSystem(sun=0x140002000) "solarSystemSrc/main/solarSystem.cxx":55
#1  0x120004100 in main() "solarSystemSrc/main/solarSystem.cxx":119
(ladebug) status 
#1 PC==0x120003cf0 in void buildOurSolarSystem(class Star*) "solarSystemSrc/main/solarSystem.cxx":55 { break }
#2 PC==0x1200047dc in virtual void Planet::print(unsigned int) "solarSystemSrc/planet.cxx":19 { break }
#3 PC==0x1200044b4 in Megameters Orbit::distance(void) "solarSystemSrc/orbit.cxx":41 { break }
(ladebug) call mars->print(1)
[2] stopped at [virtual void Planet::print(unsigned int):19 0x1200047dc]	
     19     cout << "(" << i 
(ladebug) where 
>0  0x1200047dc in ((Planet*)0x140002980)->print(i=1) "solarSystemSrc/planet.cxx":19
(ladebug) next 
stopped at [virtual void Planet::print(unsigned int):21 0x120004874]	
     21     printOrbitalParameters();
(ladebug) print distance()
[3] stopped at [Megameters Orbit::distance(void):41 0x1200044b4]	
     41     return _distance; 
(ladebug) where 
>0  0x1200044b4 in ((Orbit*)0x1400029b0)->distance() "solarSystemSrc/orbit.cxx":41
(ladebug) disable 3
(ladebug) cont 
Called Procedure Returned
stopped at [virtual void Planet::print(unsigned int):21 0x120004874]	
     21     printOrbitalParameters();
(ladebug) where 
>0  0x120004874 in ((Planet*)0x140002980)->print(i=1) "solarSystemSrc/planet.cxx":21
(ladebug) cont 
(1) Planet [Mars]; <Sol 4> orbits at 227940 Megameters
Called Procedure Returned
stopped at [void buildOurSolarSystem(class Star*):55 0x120003cf0]	
     55     Planet *pluto     = new Planet("Pluto",      5913520, sun);

The debugger supports function calls and expression evaluations that call functions, with the following limitations:

• The debugger does not support passing and returning structures by value.
• The debugger does not implicitly construct temporary objects for call parameters.
• Optimization can prevent the debugger from knowing the type of a function return. Therefore, the debugger assumes returns are of the type int if the functions are optimized. If the returns are a different type, it may be necessary to cast the result when calling the optimized functions.

8.4.6 The whatis Command

whatis_command
	: whatis whatis_expression

(ladebug) whatis sun->_classification
const StellarClass _classification
(ladebug) whatis StellarClass
enum "solarSystemSrc/derived_class_includes/star.h"`StellarClass
 {O, B, A, F, G, K, M, R, N, S} StellarClass
(ladebug) print sun->_classification
G

8.4.7 The whereis Command

The scope information of a variable usually consists of the name of the source file that contains the function in which the variable is declared, the name of that function, and the name of the variable. The components of the scope information are separated by back-quotes (`).

whereis_command
	: whereis whereis_name
        
whereis_name
	: identifier_or_typedef_name
	| ( identifier_or_typedef_name )

(ladebug) whereis print 
"solarSystemSrc/base_class_includes/heavenlyBody.h"`HeavenlyBody::print
"solarSystemSrc/derived_class_includes/planet.h"`Moon::print
"solarSystemSrc/derived_class_includes/planet.h"`Planet::print
"solarSystemSrc/derived_class_includes/star.h"`Star::print
(ladebug) stop in "solarSystemSrc/derived_class_includes/planet.h"`Planet::print 
[#2: stop in virtual void Planet::print(unsigned int) ]
(ladebug) stop in "solarSystemSrc/derived_class_includes/star.h"`Star::print 
[#3: stop in virtual void Star::print(unsigned int) ]

8.4.8 The which Command

The scope information of a variable usually consists of the name of the source file that contains the function in which the variable is declared, the name of that function, and the name of the variable. The components of the scope information are separated by back-quotes (`).

which_command
	: which which_name
        
which_name
	: identifier_or_typedef_name
	| ( identifier_or_typedef_name )

(ladebug) where 4 
>0  0x1200047dc in ((Planet*)0x140002860)->Planet::print(i=2) "solarSystemSrc/planet.cxx":19
#1  0x12000422c in ((HeavenlyBody*)0x140002860)->HeavenlyBody::printBodyAndItsSatellites(i=2) "solarSystemSrc/heavenlyBody.cxx":62
#2  0x120004254 in ((HeavenlyBody*)0x140002000)->HeavenlyBody::printBodyAndItsSatellites(i=1) "solarSystemSrc/heavenlyBody.cxx":68
#3  0x120004110 in main() "solarSystemSrc/main/solarSystem.cxx":120
(ladebug) which i 
"solarSystemSrc/planet.cxx"`Planet::print(unsigned int)`i
(ladebug) assign i = 10
(ladebug) print i
10
(ladebug) whereis i
"solarSystemSrc/heavenlyBody.cxx"`HeavenlyBody::satelliteNumber(class HeavenlyBody*)`i
"solarSystemSrc/heavenlyBody.cxx"`HeavenlyBody::printBodyAndItsSatellites(unsigned int)`i
"solarSystemSrc/heavenlyBody.cxx"`HeavenlyBody::printBodyAndItsSatellites(unsigned int)`i
"solarSystemSrc/star.cxx"`Star::print(unsigned int)`i
"solarSystemSrc/planet.cxx"`Planet::print(unsigned int)`i
"solarSystemSrc/planet.cxx"`Moon::print(unsigned int)`i
"solarSystemSrc/derived_class_includes/planet.h"`Planet::print(unsigned int)`i
"solarSystemSrc/base_class_includes/heavenlyBody.h"`HeavenlyBody::print(unsigned int)`i
"solarSystemSrc/base_class_includes/heavenlyBody.h"`HeavenlyBody::printBodyAndItsSatellites(unsigned int)`i
"solarSystemSrc/main/solarSystem.cxx"`printBiggestMoons`i
"solarSystemSrc/main/solarSystem.cxx"`trackBiggestMoons(class Moon*)`i
"solarSystemSrc/main/solarSystem.cxx"`main`i
(ladebug) func HeavenlyBody::printBodyAndItsSatellites
void HeavenlyBody::printBodyAndItsSatellites(unsigned int) in solarSystemSrc/heavenlyBody.cxx line No. 62:
     62     print(i);
(ladebug) which i 
"solarSystemSrc/heavenlyBody.cxx"`HeavenlyBody::printBodyAndItsSatellites(unsigned int)`i
(ladebug) print i
2

8.4.9 Notes on C++ Debugging

8.4.9.1 Setting the Class Scope Using the class Command

The class command lets you set the scope to a class in the program you are debugging:

c++_look_around_command
        : class [ class_name ]

Setting the class scope nullifies the function scope and vice versa. To return to the default (current function) scope, use the command func 0.

Explicitly setting the debugger's current context to a class enables you to view a class to:

• Set a breakpoint in a member function
• Print static data members
• Examine any data member's type

After the class scope is set, you can set breakpoints in the class's member functions and examine data without explicitly mentioning the class name. If you do not want to affect the current context, you can use the scope resolution operator (::) to access a class whose members are not currently visible. Use the class command without an argument to display the current class scope. Specify an argument to change the class scope. After the class scope is set, refer to members of the class by omitting the classname:: prefix.

The following example shows the use of the class command to set the class scope to List in order to make member function append visible so a breakpoint can be set in append:

(ladebug) stop in append 
Symbol "append" is not defined.
append has no valid breakpoint address
Warning: Breakpoint not set
(ladebug) class List<Node>
class List<Node> {
  List(void);
  ~List(void);
  void append(class Node*);
  void print(void);
  class Node* _firstNode;
}
(ladebug) stop in append 
[#1: stop in void List<Node>::append(class Node* const) ]

8.4.9.2 Displaying Class Information

The whatis command displays the class type declaration, including the following:

• Data members
• Member functions
• Constructors
• Destructors
• Static data members
• Static member functions

For classes that are derived from other classes, the data members and member functions inherited from the base class are not displayed. Any member functions that are redefined from the base class are displayed.

The print command lets you display the value of data members and static members. Information regarding the public, private, or protected status of class members is not provided, because the debugger relaxes the related access rules to be more helpful to users.

The type signatures of member functions, constructors, and destructors are displayed in a form that is appropriate for later use in resolving references to overloaded functions.

The following example shows the whatis and print commands in conjunction with a class:

(ladebug) list 43: 12
     43 // Compound Node - contains integer and float data items
     44 //
     45 class CompoundNode : public IntNode {
     46 public:
     47     CompoundNode (float fdata, int idata);
     48     
     49     void printNodeData() const;    
     50 
     51 private:
     52     float _fdata;
     53 }; 
     54 
(ladebug) whatis CompoundNode
class CompoundNode : IntNode {
  CompoundNode(float, int);
  virtual void printNodeData(void);
  float _fdata;
}
(ladebug) whatis CompoundNode::CompoundNode
CompoundNode::CompoundNode(float, int)
(ladebug) stop in CompoundNode::printNodeData 
[#1: stop in virtual void CompoundNode::printNodeData(void) ]
(ladebug) run
The list is: 
Node 1 type is integer, value is 1
[1] stopped at [virtual void CompoundNode::printNodeData(void):109 0x12000236c]	
    109     cout << " type is compound, value is ";
(ladebug) print _fdata
12.345

8.4.9.3 Displaying Object Information

You can also display individual object members using the member access operators, period (.) and right arrow (->), in a print command.

You can use the scope resolution operator (::) to refer to global variables, to refer to hidden members in base classes, to explicitly refer to a member that is inherited, or otherwise to name a member hidden by the current context.

When you are in the context of a nested class, you must use the scope resolution operator to access members of the enclosing class.

The following example shows how to use the whatis and print commands to display object information:

(ladebug) whatis this
const class CompoundNode* const this
(ladebug) whatis *this
const class CompoundNode
(ladebug) print *this
class CompoundNode {
  _fdata = 12.345; 
  _data = 2;                      // class IntNode 
  _nextNode = 0x140001820;        // class IntNode::Node
}
(ladebug) print _fdata, _data
12.345 2
(ladebug) print this->_fdata, this->_data
12.345 2

8.4.9.4 Displaying Static and Dynamic Type Information

The static type of a class pointer or reference is its type as defined in the source code, and thus cannot change. The dynamic type is the type of the object being referenced, before any casts were made to that object, and thus may change during program execution.

The debugger provides a debugger variable, $usedynamictypes, which allows you to control which form of the type information is displayed. The default value for this variable is true (1), which indicates that the dynamic type information is displayed. Setting this variable to false (0) instructs the debugger to display static type information. The output of the print, trace, tracei, and whatis commands are affected.

The display of dynamic type information is supported for C++ class pointers and references. All other types display static type information. In addition, if the dynamic type of an object cannot be determined, the debugger defaults to the use of static type information.

This debugger functionality does not relax the C++ visibility rules regarding object member access through a pointer/reference (only members of the static type are accessible). For more information about the C++ visibility rules, see The Annotated C++ Reference Manual (by Margaret E. Ellis and Bjarne Stroustrup, 1990, Addison-Wesley Publishing Company).

In order for dynamic type information to be displayed, the object's static type must have at least one virtual function defined as part of its interface (either one it introduced or one it inherited from a base class). If no virtual functions are present for an object, only the static type information for that object is available for display.

The following example shows debugger output with $usedynamictypes set to 0 (false):

(ladebug) print $usedynamictypes
0
(ladebug) print *this
class HeavenlyBody { 
  _name = 0x120002088="Moon"; 
  _innerNeighbor = 0x0; 
  _outerNeighbor = 0x0; 
  _firstSatellite = 0x0; 
  _lastSatellite = 0x0; 
}

(ladebug) print $usedynamictypes
1
(ladebug) print *this
class Moon { 
  _radius = 1738; 
  _name = 0x120002088="Moon";     // class Planet::HeavenlyBody
  _innerNeighbor = 0x0;           // class Planet::HeavenlyBody
  _outerNeighbor = 0x0;           // class Planet::HeavenlyBody
  _firstSatellite = 0x0;          // class Planet::HeavenlyBody
  _lastSatellite = 0x0;           // class Planet::HeavenlyBody
  _primary = 0x1400028c0;         // class Planet::Orbit
  _distance = 384;                // class Planet::Orbit
  _name = 0x1400040f0="Earth 1";  // class Planet::Orbit
}

8.4.9.5 Displaying Virtual and Inherited Class Information

When you use the print command to display the format of C++ classes, the class name (or structure/union name) is displayed at the top of the output. Data members of a class that are inherited from another class are commented using a double slash (//). Only those data members that are inherited within the current class being printed are commented.

The following example shows how the debugger uses C++ style comments to identify inherited class members. In the example, class CompoundNode inherits from class IntNode, which inherits from class Node. When printing a class CompoundNode object, the data member _data is commented with "// class IntNode", signifying that it is inherited from class IntNode. The member _nextNode is commented with "// class IntNode::Node", showing that it is inherited from class IntNode, which inherits it from class Node. This commenting is also provided for C++ structs.

(ladebug) where 3 
>0  0x12000224c in ((Node*)0x140002000)->Node::Node() "x_list.cxx":77
#1  0x120002298 in ((IntNode*)0x140002000)->IntNode::IntNode(data=2) "x_list.cxx":88
#2  0x120002338 in ((CompoundNode*)0x140002000)->CompoundNode::CompoundNode(fdata=12.34500026702881, idata=2) "x_list.cxx":101
(ladebug) whatis *this
class Node {
  Node(void);
  virtual void printNodeData(void);
  class Node* getNextNode(void);
  void setNextNode(void);
  class Node* _nextNode;
}
(ladebug) print *this
class Node {
  _nextNode = 0x0;
}
(ladebug) up 1 
>1  0x120002298 in ((IntNode*)0x140002000)->IntNode::IntNode(data=2) "x_list.cxx":88
     88 IntNode::IntNode(int data) : _data(data)
(ladebug) whatis *this
class IntNode : Node {
  IntNode(int);
  virtual void printNodeData(void);
  int _data;
}
(ladebug) print *this
class IntNode {
  _data = 0; 
  _nextNode = 0x0;                // class Node
}
(ladebug) up 1 
>2  0x120002338 in ((CompoundNode*)0x140002000)->CompoundNode::CompoundNode(fdata=12.34500026702881, idata=2) "x_list.cxx":101
    101 CompoundNode::CompoundNode(float fdata, int idata) 
(ladebug) whatis *this
class CompoundNode : IntNode {
  CompoundNode(float, int);
  virtual void printNodeData(void);
  float _fdata;
}
(ladebug) print *this
class CompoundNode {
  _fdata = 0; 
  _data = 0;                      // class IntNode 
  _nextNode = 0x0;                // class IntNode::Node
}

	object.class::member

	object->class::member

The following example shows a case in which the expanded syntax can be used:

(ladebug) print *jupiter
class Planet { 
  _name = 0x1200020a8="Jupiter";  // class HeavenlyBody
  _innerNeighbor = 0x140002980;   // class HeavenlyBody
  _outerNeighbor = 0x140002ce0;   // class HeavenlyBody
  _firstSatellite = 0x140002b00;  // class HeavenlyBody
  _lastSatellite = 0x140002c80;   // class HeavenlyBody 
  _primary = 0x140002000;         // class Orbit
  _distance = 778330;             // class Orbit
  _name = 0x140004230="Sol 5";    // class Orbit
}
(ladebug) print jupiter->_name
Evaluating 'jupiter->_name' failed!
The value (class Planet { 
  _name = 0x1200020a8="Jupiter";  // class HeavenlyBody
  _innerNeighbor = 0x140002980;   // class HeavenlyBody
  _outerNeighbor = 0x140002ce0;   // class HeavenlyBody
  _firstSatellite = 0x140002b00;  // class HeavenlyBody
  _lastSatellite = 0x140002c80;   // class HeavenlyBody 
  _primary = 0x140002000;         // class Orbit
  _distance = 778330;             // class Orbit
  _name = 0x140004230="Sol 5";    // class Orbit
}) does not have a field named '_name'!
(ladebug) print jupiter->HeavenlyBody::_name
Evaluating 'jupiter->HeavenlyBody::_name' failed!
The value (class Planet { 
  _name = 0x1200020a8="Jupiter";  // class HeavenlyBody
  _innerNeighbor = 0x140002980;   // class HeavenlyBody
  _outerNeighbor = 0x140002ce0;   // class HeavenlyBody
  _firstSatellite = 0x140002b00;  // class HeavenlyBody
  _lastSatellite = 0x140002c80;   // class HeavenlyBody 
  _primary = 0x140002000;         // class Orbit
  _distance = 778330;             // class Orbit
  _name = 0x140004230="Sol 5";    // class Orbit
}) does not have a field named 'HeavenlyBody::_name'!
(ladebug) print jupiter->Orbit::_name
Evaluating 'jupiter->Orbit::_name' failed!
The value (class Planet { 
  _name = 0x1200020a8="Jupiter";  // class HeavenlyBody
  _innerNeighbor = 0x140002980;   // class HeavenlyBody
  _outerNeighbor = 0x140002ce0;   // class HeavenlyBody
  _firstSatellite = 0x140002b00;  // class HeavenlyBody
  _lastSatellite = 0x140002c80;   // class HeavenlyBody 
  _primary = 0x140002000;         // class Orbit
  _distance = 778330;             // class Orbit
  _name = 0x140004230="Sol 5";    // class Orbit
}) does not have a field named 'Orbit::_name'!

8.4.9.6 Member Functions on the Stack Trace

Sometimes the debugger does not see class type names with internal linkage. When this happens, the debugger issues the following error message:

	Name is overloaded. 

	Member function has been inlined. 

If a program is not compiled with the -g flag, a breakpoint set on an inlined member function may confuse the debugger.

8.4.9.7 Resolving Ambiguous References to Overloaded Functions

• Choose the correct reference from a selection menu.

  If the $overloadmenu variable is set to 1 (the default), whenever you specify a function name that is overloaded, a menu appears with all the possible functions; you must select from this menu. In this example, a breakpoint is set in foo, which is overloaded:

  (ladebug) set $overloadmenu = 1
  (ladebug) stop in C::foo 
  Select from
  ----------------------------------------------------
       1 int C::foo(double*)
       2 void C::foo(float)
       3 void C::foo(int)
       4 void C::foo(void)
       5 None of the above
  ----------------------------------------------------
  1
  [#10: stop in int C::foo(double*) ]
  

• Enter the function name with its full type signature.

  If you prefer this method, set the $overloadmenu variable to 0. To see the possible type signatures for the overloaded function, first display all the declarations of an overloaded function by using the whatis command.

  You cannot select a version of an overloaded function that has a type signature containing ellipsis points (...). Pointers to functions with type signatures that contain the list parameter or ellipsis points are not supported.

  Use the specific function type signature to refer to the desired version of the overloaded function. If a function has no parameter, include the void parameter as the function's type signature. In the following example, the function context is set to foo(double *), as foo is overloaded:

(ladebug) func foo
Error: foo is overloaded
(ladebug) func foo(double *)
int C::foo(double*) in x_overload.cxx line No. 25:
     25 int  C::foo(double *) { return state;}

8.4.9.8 Advanced Program Information —Verbose Mode

• Derived classes
• Virtual pointer tables for virtual functions
• Compiler-generated function members
• Compiler-generated temporary variables
• Implicit parameters in member functions

(ladebug) whatis CompoundNode::__vptr
(array [subrange 0 ... 0 of int] of union {
  void <member function>(void)* fptr;
  int ioffset;
})* CompoundNode::__vptr

The compiler generates additional parameters for nonstatic member functions. When the $verbose debugger variable is set to 1, these extra parameters are displayed as part of each member function's type signature. If you specify a version of an overloaded function by entering its type signature and the variable is set to 1, you must include these parameters. Do not include these parameters if the variable is set to 0.

When the $verbose variable is set to 1, the output of the dump command includes not only standard program variables but also compiler-generated temporary variables.

The following example prints class information using the whatis command under different settings of the $verbose variable:

(ladebug) set $verbose = 0
(ladebug) whatis CompoundNode
class CompoundNode : IntNode {
  CompoundNode(float, int);
  virtual void printNodeData(void);
  float _fdata;
}
(ladebug) set $verbose = 1
(ladebug) whatis CompoundNode
class CompoundNode : IntNode {
  (array [subrange 0 ... 0 of int] of union {
    void <member function>(void)* fptr;
    int ioffset;
  })* __vptr;
  CompoundNode(class CompoundNode*, float, int);
  virtual void printNodeData(const class CompoundNode*);
  float _fdata;
}

8.5 Looking at the Generated Code

8.5.1 Memory Display Command - (/)

machinecode_level_command
     : address_expression /[ count ] [ mode ]
     | address_expression , address_expression / [ mode ]

You can display stored values in the following formats by specifying mode:

mode
	: d       Print a short word in decimal
        | dd      Print a 32-bit (4-byte) decimal display
        | D       Print a long word in decimal
	| u       Print a short word in unsigned decimal
	| uu      Print a 32-bit (4-byte) unsigned decimal display
	| U       Print a long word in unsigned decimal
	| o       Print a short word in octal
	| oo      Print a 32-bit (4-byte) octal display
	| O       Print a long word in octal
	| x       Print a short word in hexadecimal
	| xx      Print a 32-bit (4-byte) hexadecimal display
	| X       Print a long word in hexadecimal
	| b	  Print a byte in hex
	| c	  Print a byte as a character
	| s	  Print a string of characters (a C-style string ending in null)
       	| C	  Print a wide character as a character
        | S	  Print a null terminated string of wide characters
        | f	  Print a single precision real number
        | g	  Print a double precision real number
        | L	  Print a long double precision real number
        | i	  Disassemble machine instructions

8.5.2 Machine-Level Debugging

Only those users familiar with machine-language programming and executable-file-code structure will find low-level debugging useful.

For more information on machine-level debugging, see Machine-Level Debugging in Ladebug Debugger Advanced Topics on the Ladebug website.

8.6 Looking at Shared Libraries

shared_library_command
        : listobj
        | readsharedobj filename
        | delsharedobj  filename

Use the readsharedobj command to read in the symbol table information for the specified shared object. This object must be a shared library or loadable kernel module. You can use the command only when you specify the debuggee; that is, either the debugger has been invoked with it, or the debuggee was loaded by the load command.

Conversely, use the delsharedobj command to remove the symbol table information for the shared object from the debugger.

Chapter 9 - Modifying the Process

modifying_command
        : assign target = expression
        | patch  target = expression
	
target
	: unary_expression  

9.1 The assign Command

The following example shows how to deposit the value 5 into the data member _data of a C++ object:

(ladebug) print node->_data
2
(ladebug) assign node->_data = 5
(ladebug) print node->_data
5

(ladebug) print *node
class CompoundNode { 
  _fdata = 12.345; 
  _data = 5;                      // class IntNode
  _nextNode = 0x0;                // class IntNode::Node
}
(ladebug) assign node->_data = -32
(ladebug) assign node->_fdata = 3.14159 * 4.2 * 4.2
(ladebug) assign node->_nextNode = _firstNode
(ladebug) print *node
class CompoundNode { 
  _fdata = 55.4176; 
  _data = -32;                    // class IntNode
  _nextNode = 0x140001800;        // class IntNode::Node
}

	assign [classname::]member = ["filename"] `expression 
	assign [object.]member = ["filename"] `expression 

You can use the assign command to alter the contents of memory specified by an address. See Machine-Level Debugging for more information.

(ladebug) print *(int *)(5368717328)
-32
(ladebug) assign *(int *)(5368717328) = 1024
(ladebug) print *(int *)(5368717328)
1024

9.2 The patch Command

Use this command exclusively when you need to change the on-disk binary. Use the assign command when you need only to modify debuggee memory. If the image is executing when you issue the patch command, the corresponding location in the debuggee address space is updated as well. (The debuggee is updated regardless of whether the patch to disk succeeded, as long as the source and destination expressions can be processed by the assign command.) If your program is loaded but not yet started, the patch to disk is performed without the corresponding assign to memory.

(ladebug) run
[1] stopped at [int main(void):24 0x120001324]
24     return 0;
(ladebug) patch i = 10
0x1400000d0 = 10
(ladebug) patch j = i + 12	
0x1400000d8 = 22
(ladebug)

Chapter 10 - Continuing Execution of the Process

continue_command
        : step_into_command
        | step_over_command
        | step_out_of_command
        | cont_command
        | cont_from_place_command

10.1 The step and stepi Commands

Use the step command to execute a line of source code. When the line being stepped contains a function call, the step command steps into the function and stops at the first executable statement.

Use the stepi command to step into the next machine instruction. When the instruction contains a function call, the stepi command steps into the function being called.

For multithreaded applications, use these commands to step the current thread while putting all other threads on hold.

If you supply the optional expression argument, the debugger evaluates the expression as a positive integer that specifies the number of times to execute the command. The expression can be any expression that is valid in the current context.

step_into_command
        : step  [ step_number ]
        | stepi [ step_number ]

step_number
        :  expression

(ladebug) step 
stopped at [void List<Node>::append(class Node* const):149 0x120001da8]	
    149         _firstNode = node;	
(ladebug) step 
stopped at [void List<Node>::append(class Node* const):156 0x120001e0c]	
    156 }

(ladebug) $curpc/4i 
void List<Node>::append(class Node* const): x_list.cxx
*[line 156, 0x120001e0c]	ldq	r26, 0(sp)
 [line 156, 0x120001e10]	ldq	r9, 8(sp)
 [line 156, 0x120001e14]	lda	sp, 32(sp)
 [line 156, 0x120001e18]	ret	r31, (r26), 1
(ladebug) stepi 
stopped at [void List<Node>::append(class Node* const):156 0x120001e10]	ldq	r9, 8(sp)
(ladebug) stepi 
stopped at [void List<Node>::append(class Node* const):156 0x120001e14]	lda	sp, 32(sp)
(ladebug) stepi 
stopped at [void List<Node>::append(class Node* const):156 0x120001e18]	ret	r31, (r26), 1
(ladebug) stepi 
stopped at [int main(void):187 0x1200024a8]	ldah	gp, 8192(r26)

10.2 The next and nexti Commands

step_over_command
        : next  [ step_number ]
        | nexti [ step_number ]

(ladebug) next 
stopped at [int main(void):189 0x1200024b0]	
    189     CompoundNode* cNode = new CompoundNode(12.345, 2);
(ladebug) next 
stopped at [int main(void):190 0x120002530]	
    190     nodeList.append(cNode); 

(ladebug) cont 
[2] stopped at [void List<Node>::append(class Node* const):152 0x120001dc4]	
    152         while (currentNode->getNextNode())
(ladebug) $curpc/4i 
void List<Node>::append(class Node* const): x_list.cxx
*[line 152, 0x120001dc4]	ldq	r27, -32584(gp)
 [line 152, 0x120001dc8]	jsr	r26, (r27), Node::getNextNode
 [line 152, 0x120001dcc]	ldah	gp, 8192(r26)
 [line 152, 0x120001dd0]	lda	gp, 25956(gp)
(ladebug) nexti 
stopped at [void List<Node>::append(class Node* const):152 0x120001dc8]	jsr	r26, (r27), Node::getNextNode
(ladebug) stepi 
stopped at [class Node* Node::getNextNode(void):81 0x120002264]	bis	r31, r16, r1
(ladebug) cont 
[2] stopped at [void List<Node>::append(class Node* const):152 0x120001dc4]	
    152         while (currentNode->getNextNode())
(ladebug) nexti 
stopped at [void List<Node>::append(class Node* const):152 0x120001dc8]	jsr	r26, (r27), Node::getNextNode
(ladebug) nexti 
stopped at [void List<Node>::append(class Node* const):152 0x120001dcc]	ldah	gp, 8192(r26)

10.3 The return Command

step_out_of_command
        : return
        | return qual_symbol

(ladebug) next 
stopped at [void List<Node>::append(class Node* const):153 0x120001dd8]	
    153             currentNode = currentNode->getNextNode();
(ladebug) return 
stopped at [int main(void):192 0x1200025b0]	
    192     nodeList.append(new IntNode(3)); 	

10.4 The cont Command

cont_command
        : cont [ in loc ]  
        | cont [ signal ] [ to_source_line ]
        | number_expression cont [ signal ]  
        | conti to address_expression

to_source_line
	: to [filename_string :] line_number  
        
number_expression
	: expression

In the following example, a cont command resumes process execution after it was suspended by a breakpoint.

(ladebug) list $curline - 5: 10
    187     nodeList.append(newNode);   
    188     
    189     CompoundNode* cNode = new CompoundNode(12.345, 2);
    190     nodeList.append(cNode); 
    191     		    
>   192     nodeList.append(new IntNode(3)); 	
    193     	    
    194     IntNode* newNode2 = new IntNode(4);
    195     nodeList.append(newNode2);
    196     
(ladebug) stop at 195 
[#3: stop at "x_list.cxx":195 ]
(ladebug) cont 
[3] stopped at [int main(void):195 0x120002644]	
    195     nodeList.append(newNode2);

Use the in argument to continue until the named function is reached. The function name must be valid. If the function name is overloaded and you do not resolve the scope of the function in the command line, the debugger prompts you with the list of overloaded functions bearing that name from which to choose.

Use the to parameter value to resume execution and then halt when the specified source line is reached. The form of the optional to parameter must be either:

• filename_string:line_number, which explicitly identifies both the source file and the line number where execution is to be halted.
• line_number, a positive numeric, which indicates the line number of the current source file where execution is to be halted.

You can set a one-time breakpoint on an instruction address before continuing by entering conti to address_expression.

NOTE: Modifying the PC before continuing using the goto command is extremely dangerous and can yield unpredictable results. Using this command is therefore not recommended.

cont_from_place_command	
        : goto line_expression

Chapter 11 - Using Snapshots as an Undo Mechanism

snapshot_command
        : save_snapshot_command
        | clone_snapshot_command
	| show_snapshot_command
        | delete_snapshot_command

11.1 The save snapshot Command

save_snapshot_command
        : save snapshot

(ladebug) save snapshot 
# 1 saved at 13:27:54 (PID: 29077).
    stopped at [int main(void):182 0x1200023f8]	
    182     List<Node> nodeList;

11.2 The clone snapshot Command

Use the clone snapshot command to revert the state of the debuggee process to that of a previously saved snapshot. By doing this, you can conveniently return to the state saved in the snapshot as opposed to rerunning the process and re-entering the debugger command sequence that brought you to that state.

Note that rerun and clone snapshot are different in that rerun always executes the process from the beginning, whereas clone snapshot does not execute the process at all; it simply duplicates the saved snapshot (using a mechanism similar to the fork system call) and behaves as though the process execution has stopped at the point when the snapshot was saved.

The clone snapshot command clones the snapshot specified by snapshot_id. If no snapshot_id is specified, the most-recently saved existing snapshot is cloned.

clone_snapshot_command
        : clone snapshot [ snapshot_id ]

Cloning a snapshot has two side effects:

• The snapshots created after the cloned snapshot are deleted. For example, suppose four snapshots are saved from a process. Cloning the second snapshot results in the deletion of the third and fourth snapshots.
• The current process is killed and replaced by the clone process. Thus, if you enter show process after cloning a snapshot, you will see that the process ID of the current process has changed to that of the cloned process. For example:

(ladebug) show process 
>localhost:29013 (/usr/examples/x_list) paused.
(ladebug) clone snapshot 
Process has exited
Process 29089 cloned from Snapshot 1.
# 1 saved at 13:27:54 (PID: 29077).
    stopped at [int main(void):182 0x1200023f8]	
    182     List<Node> nodeList;
(ladebug) show process 
>localhost:29089 (/usr/examples/x_list) paused.

11.3 The show snapshot Command

show_snapshot_command
        : show snapshot [ snapshot_id_list ]

snapshot_id_list
	: snapshot_id ,...
	| all
	| *

(ladebug) show snapshot all
# 1 saved at 13:27:54 (PID: 29077).
    stopped at [int main(void):182 0x1200023f8]	
    182     List<Node> nodeList;

11.4 The delete snapshot Command

delete_snapshot_command
        : delete snapshot [ snapshot_id_list ]

(ladebug) show snapshot all
# 1 saved at 13:27:54 (PID: 29077).
    stopped at [int main(void):182 0x1200023f8]	
    182     List<Node> nodeList;
(ladebug) delete snapshot 
(ladebug) show snapshot all
No snapshots have been saved.

11.5 Snapshot limitations

• Snapshots are implemented by causing the process to fork.  The state saved in a snapshot does not include I/O and forks. In other words, when you clone a snapshot, the I/O that has been done since the snapshot was saved is not undone; likewise, the child processes that have been spawned since the snapshot was saved are not killed.
• The save snapshot command saves the state of the current process only. If you are doing multiprocess debugging, you might want to save a snapshot for each process.
• Snapshots on a multithreaded process are not supported.
• Snapshots are not supported for remote, kernel, or core file debugging.

Chapter 12 - Debugging Optimized Code (Linux Features)

If you are debugging optimized code under the Alpha Linux operating system, the following information applies:

• The debugger for the Alpha Linux operating system provides several features that make it easier to debug a program that has been compiled with optimization. These features are described in this section.
• Support for these features is limited to programs compiled using compilers from Compaq Computer Corporation. These include Compaq Fortran 90, Compaq C and Compaq C++.
• Taking advantage of these features requires compiling your program as described in this chapter. The debugger automatically takes advantage of specialized information that is included in the resulting executable program.
• No Ladebug commands control the debugger behavior when debugging optimized code. Rather, existing commands sometimes behave somewhat differently than you would see in the absence of optimization.

The sections that follow provide some insight into how Compaq compilers and the debugger deal with the consequences of key optimizations and how that may influence debugging of your program.

12.1 Why Debug Optimized Code?

Why would you ever try to debug an optimized version? The most likely reason is that the program appears to work correctly when unoptimized but somehow fails when optimized. As a result, you may have little choice but to try to isolate the problem using the optimized program.

The most common reason that a program apparently works correctly when unoptimized but fails when optimized is this:

Your program performs some action whose behavior is undefined or implementation dependent, and the optimized version is different from the unoptimized version when performing this action.

For example, your program might read and depend on the value of a variable that was not assigned a value. When executed in unoptimized form, the value that happens to be in that variable might accidently result in the desired behavior. But when optimized, the variable might have some other value that leads to different behavior. As another example, sometimes your program may be subtly dependent on the exact order in which operations are performed—and optimization can result in a different order. There are many other examples that are beyond the scope of this discussion.

It is also possible that there is a bug in the compiler. While it does happen, experience with Compaq compilers indicates that this is rare.

In any case, to determine the cause or nature of the problem requires debugging using the optimized version. Then you can determine how best to resolve the problem. (Of course, you could also choose to reduce the level of optimization, possibly to none, to obtain the desired behavior, but that may not result in acceptable performance.)

12.2 Program Preparation

Note that the -g3 option differs from the -g option in that it does not affect the optimization level. That is, -g (equivalent to -g2) sets the optimization level to zero (that is, -O0), even overriding an explicit optimization setting; -g3 leaves the optimization level unchanged. See the reference pages for the respective compilers for further details.

12.3 Split Lifetime Variables

Split lifetime information in the debugging symbol table describes each of the child variables associated with the main variable, where it is allocated, and the exact range of addresses over which each child is valid.

Because assignments may not occur in the same order as in the source code, the split lifetime information also includes a list of all of the places where the current value may have been assigned. In general, this is a list of possibilities, because several execution paths may converge, bringing together multiple assignment possibilities; the debugger does not trace the exact execution path that reaches a stopping point, so it can only report the set of relevant alternatives.

When a variable does not have a value at the current location, the debugger cannot print a value for it and reports an error as follows:

(ladebug) print L
Info: symbol L is defined but not allocated (optimized away)
Error: no value for symbol L

The first error message line indicates that there is a symbol L, but that it does not currently have a value. The preceding informational line distinguishes between two cases:

• The symbol is not allocated at all (was optimized away). Such a symbol can never have a value.
• The symbol does not have a value at the current location. Such a symbol has split lifetimes and will have a value at other locations, just not here.

If a variable is not declared at all, then the error report looks like the following:

(ladebug) print L
Symbol "L" is not defined.

(ladebug) print j
2
Value assigned at line 5

(ladebug) print k
3
Value assigned at one of these lines: 6, 11

The following limitations apply:

• When a variable has more than one value at a location, the debugger displays only the first one discovered and ignores the rest.
• The list of lines at which a value was possibly assigned may not be complete. The lines that are listed are definitely known to be possible assignments; the absence of a line usually means it did not, but unfortunately this is not definitive.

12.4 Semantic Stepping

Semantic stepping causes the program to execute up to, but not including, an instruction that causes a semantic effect, as well as being in a different line. Instructions that cause semantic effects are instructions that:

• Assign a value to a user variable
• Make a control flow decision
• Make or return from a routine call

12.5 Discontiguous Scopes

Debugging optimized code information in the symbol table includes a detailed description of the possibly multiple disjoint instruction ranges that belong to or make up a scope. This helps assure that variable lookups find the right symbols at the current location.

You are not likely to directly perceive the effects and benefits of this support; just know that it is part of "getting the right answer" in the presence of optimization.

12.6 General Cautions

Use with Caution

down, dump, func, return, where, pop, up

These commands generally depend on there being a distinct call frame on the execution stack for each called function. However, inlining can merge a called routine into the caller, resulting in one frame instead of the two (or more) that might be expected. You can use these commands, but be careful to make sure that you end up in the frame you intend after each use and do not be misled.

next, nexti

For a call that is inlined, the next and nexti commands will appear to step into the called function instead of stepping over it.

Avoid Completely

assign

It is generally not possible to reliably assign to a variable before the value of the variable has been used.

goto

It is generally not possible to reliably determine where the first instruction of a line begins or to avoid repeating instructions from the destination line that may have already been executed.

The condition expression may not have a value at all in some places where the expression needs to be evaluated. Worse yet, the debugger sometimes attempts to cache the address of a variable, which does not correctly support split variables.

The debugger does not support watching a split variable. This command will most likely fail because the debugger cannot watch a variable (child or otherwise) that is allocated in a register; even if it does appear to succeed, the debugger will be watching the location of just one child, even when that location is not relevant.

It is generally not possible to reliably determine whether a variable has only one lifetime and thus a unique address.

Chapter 13 - Limitations

• Compaq C++
• Compaq Fortran
• Compaq Ada
• Compaq COBOL

13.1 Limitations on Support for Compaq C++

To make the debugger more useful, it relaxes some standard C++ name visibility rules. For example, you can reference public, protected, and private class members.

The following limitations apply to debugging a C++ program:

• If a program is not compiled with the -g flag, do not set a breakpoint on an inline member function; it may confuse the debugger.
• When you use the debugger to display virtual and inherited class information, the debugger does not support pointers to members of a class.
• The debugger does not support calling the C++ constructs new and delete. As alternatives, use the malloc() and free() routines from C.
• Sometimes the debugger does not see class type names with internal linkage, and it issues an error message stating that the name is overloaded.
• You cannot select a version of an overloaded function that has a type signature containing ellipsis points (...).
• Pointers to functions with type signatures that contain parameter list or ellipsis arguments are not supported.

Limitations for debugging templates include the following:

• You cannot specify a template by name in a debugger command. You must use the name of an instantiation of the template.
• Setting a breakpoint at a line number that is inside a template function will not necessarily stop at all instantiations of the function within the given file, but only at a randomly chosen few.

13.2 Limitations on Support for Compaq Fortran

Be aware of the following data-type limitations when you debug a Fortran program:

• The debugger does not allow setting a breakpoint on a program routine named MAIN.
• Substring notation is not supported.

The following limitations apply only to Compaq Fortran 90:

• Compaq Fortran 90 array constructors, structure constructors, adjustable arrays, and vector subscripts are not supported.
• Compaq Fortran 90 user-defined (derived) operators are not supported.
• The debugger does not handle variables of 16-bit character data types.

13.2.1 Limitations on Procedure Invocations

• The debugger does not support invocations of user-defined procedures unless they have been compiled with debug information.
• The debugger does not support complex or real*16 procedure return values.
• The debugger does not support real*16 or complex*32 procedure arguments.
• Of the Fortran intrinsic procedures, the debugger currently supports only:
  • the mathematical functions (for example, ACOS, ACOSD, SIN, SQRT, and so on)
  • the kind type functions (KIND, SELECTED_INT_KIND, SELECTED_REAL_KIND)
  as described in the Compaq Fortran Language Reference Manual section that discusses categories of intrinsic functions.

13.3 Limitations on Support for Compaq Ada

13.3.1 Limitations on Expressions

Ada Expression	Debugger Equivalent
Binary operations and unary operations	Only integer, floating, and Boolean expressions are easily expressed.
a+b,-,*	a+b,-,*
a/b	a/b
a = b /= < <= > >=	a = = b != < <= > >=
a and b	a&&b
a or b	a | | b
a rem b	a%b
not(a=b)	!(a==b)
-a	-a
Qualified expressions	None. There is no easy way of evaluating subtype bounds.
Type conversions	Only simple numeric conversions are supported, and the bounds checking cannot be done. Furthermore, float -> integer truncates rather than rounds. integer -> float (ladebug) print (float) (2147483647) 2147483648.0 (ladebug) print (double) (2147483647) 2147483647.0
Attributes	None, but if E is an enumeration type with default representations for the values, then: E'PRED(X) is the same as x-1. E'SUCC(X) is the same as x+1
p.all	*p (pointer reference)
p.m	p -> m (member of an "access record" type)

13.3.2 Limitations on Data Types

All Types The debugger, unlike the Ada language, allows out-of-bounds assignments to be performed.

Integer Types

If integer types of different sizes are mixed (for example, byte-integer and word-integer), the one with the smaller size is converted to the larger size.

Floating-Point Types If integer and floating-point types are mixed in an expression, the debugger converts the integer type to a floating-point type.

The debugger displays floating-point values that are exact integers in integer literal format.

Fixed-Point Types

The debugger displays fixed-point values as real-type literals or as structures. The structure contains values for the sign and the mantissa. To display the structure's value, multiply the sign and mantissa values. For example:

(ladebug) list 5
      5 procedure a_showFixedPointType is
      6 
      7     type FixedPoint is delta 0.1 range -3.0 .. 9.0;
      8     myVar : FixedPoint := 1.0;
      9 
     10 begin
>    11     myVar := myVar + 1.0;
     12 end;
(ladebug) print myVar
packed object {
  fixed_point, small = 0.625E-1 * mantissa = 16;
}
(ladebug) print 6.25E-02 * 16
1.0

Enumeration Types

The debugger displays enumeration values as the actual enumeral or its position.

You must manually convert enumeration values to 'pos values before you can use them as array indices.

Array Types

The debugger displays string array values in horizontal ASCII format, enclosed in quotation ("x") marks. A single component (character) is displayed within single quotation ('x') marks.

The debugger allows you to assign a component value to a single component; you cannot assign using an entire array or array aggregate.

Arrays whose components are neither a single bit nor a multiple of bytes are described to the debugger as structures; a print command displays only the first component of such arrays.

Records

The debugger cannot display record components whose offsets from the start of the record are not known at compile time.

For variant records, however, the debugger can display the entire record object that has been declared with the default variant value. The debugger allows you to print or assign a value to a component of a record variant that is not active.

Access Types

The debugger does not support allocators, so you cannot create new access objects with the debugger. When you specify the name of an access object, the debugger displays the memory location of the object it designates. You can examine the memory location value.

13.3.3 Limitations on Tasking Programs

13.4 Limitations on Support for Compaq Cobol

13.4.1 Limitations on Assignment

• 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:

  (ladebug) list 10: 3
       10 01 firstItem            PIC  9(9)v99.
       11 01 secondItem           PIC  9999v99.
       12 01 thirdItem            PIC 9(13)v9(5).
  

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

  (ladebug) print firstItem, secondItem
          2.46 1234.56
  (ladebug) assign firstItem = 1.23
  (ladebug) assign secondItem = 8765.22
  (ladebug) print firstItem, secondItem
          1.23 8765.22
  (ladebug) assign firstItem = secondItem
  (ladebug) print firstItem, secondItem
       8765.22 8765.22
  

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

  (ladebug) assign firstItem = 1.2
  This item may only be assigned values of equivalent scale (-2)
  (ladebug) assign thirdItem = firstItem
  This item may only be assigned values of equivalent scale (-5)
  

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

  (ladebug) assign secondItem = firstItem
  This item may only be assigned values with a maximum precision of (6)
  

• 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.

13.4.2 Other Limitations

• Qualification involving more than one intervening level produces a debugger error if the intervening level is an OCCURS item.

• Some debugger command usage is affected by COBOL language syntax when execution is stopped within a COBOL procedure. One effect is that expressions typed on the Ladebug command line must include spaces around arithmetic operators, such as plus (+) and minus (-).

  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) &coboldata/10i 
  Bad or unimplemented printout mode for examine command.
  Using X instead.
  0x120002a90: 23bd5c8027bb2000
  

  This debugger command says "from the given program location" (signified by the address of coboldata), 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) &coboldata/10 i 
   coboldata(void): c_coboldata.cob
   [line 2, 0x120002a90]	ldah	gp, 8192(r27)
   [line 2, 0x120002a94]	lda	gp, 23680(gp)
   [line 2, 0x120002a98]	lda	sp, -144(sp)
   [line 2, 0x120002a9c]	stq	r26, 48(sp)
   [line 2, 0x120002aa0]	stq	r9, 56(sp)
   [line 2, 0x120002aa4]	ldq	r9, -32720(gp)
   [line 2, 0x120002aa8]	ldah	r2, -1(gp)
   [line 2, 0x120002aac]	ldq	r27, -32488(gp)
   [line 2, 0x120002ab0]	ldq	r16, -32736(gp)
   [line 58, 0x120002ab4]	lda	r9, -21(r9)
  

  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.