7 BREAKPOINTS AND ASSERTIONS

This chapter contains the following sections:

Introduction to Breakpoints
Code Breakpoints
Data Breakpoints
Listing Breakpoints
Setting Breakpoints
Data Breakpoints over a Range of Addresses
Temporary Breakpoints
Breakpoint Names
Setting the Count
Sequence Breakpoints
Deleting Breakpoints
Enabling/Disabling Breakpoints
Breakpoint Commands
Attaching Conditionals to a Breakpoint
Attaching Macros to a Breakpoint
Attaching Strings to a Breakpoint
Suppressing Breakpoint Messages
Up-level Breakpoints
Patches
Patching Code out of a Program
Patching Code into a Program
Replacing Code in a Program
Diagnostic Output and Statistical Information
Assertions
Assertion Mode
Defining an Assertion
Editing an Assertion
Activating and Suspending Assertions
Deleting Assertions
Using Assertions
Gathering Statistics with Assertions

You can use breakpoints to stop program execution at specified locations and return control to the user. An assertion is a number of statements executed by the debugger each time the target executes a program line. Use assertions to track down bugs, the cause of which is very hard to find.

7.1 Introduction to Breakpoints

Breakpoints halt program execution and return control to you. There are several types of breakpoints: code, data, instruction count, cycle count, timer and sequence. A code breakpoint halts the program on a particular statement or instruction; a data breakpoint stops the program when a particular memory address (or range of addresses) is accessed; an instruction count breakpoint halts the program after a specified number of instructions have been executed; a cycle count breakpoint stops the program after a number of CPU cycles; a timer breakpoint stops the program after a number of micro seconds or ticks and sequence breakpoints stop the program when a number of breakpoints are hit in a specified sequence.

Data breakpoints, instruction count breakpoints, cycle count breakpoints and timer breakpoints are not available for all execution environments, please check the Addendum.

7.1.1 Code Breakpoints

A code breakpoint is set on a line in the code and makes the program halt exactly before that line executes. When you define a code breakpoint, you can include four elements:

In the Source Window, a green colored toggle shows that no breakpoint is set. A red colored toggle shows that a breakpoint is installed. An orange colored toggle indicates an installed but disabled breakpoint. If coverage is enabled, coverage markers are present to the right of the breakpoint toggles. An executed line is marked and not executed lines are not marked.

Figure 7-1: Code Breakpoint

Permanent/Temporary Code Breakpoints

Code breakpoints can be: permanent or temporary. A permanent breakpoint exists until explicitly deleted. A temporary breakpoint only exists until it stops the program once.

Probe Point Code Breakpoints

A breakpoint can be treated as a probe point. When a probe point breakpoint is hit, the associated commands are executed and program execution is continued. Probe points are used with File I/O simulation and sequence breakpoints.

How CrossView Pro Sets Code Breakpoints

CrossView Pro depends on the symbol table for information about how machine instructions map to lines of source. In general, the C compiler issues line symbols at the start of each statement or line, whichever comes first. This can lead to some surprising results. If you look carefully, you can tell on which line CrossView Pro set the breakpoint, since CrossView Pro tells you on which line the program stopped, a line that may be different from the one you expected. To find out what happens if you install a code breakpoint, use single stepping and watch the order in which the source lines print out.

Multiple Statements on a Single Source Line

If you frequently include multiple statements on a single line in your source code, you may have difficulties setting code breakpoints at certain locations. For instance, suppose you have a source line containing:

Suppose you want to halt execution after the assignment to a and before the one to b. A normal code breakpoint does not work here, because execution stops at the first instruction of the source line. CrossView Pro provides you with the capability of disassembling the code and inserting breakpoints at the machine level. You can use the Assembly Source Window or the Intermixed Source Window to spot the right location.

For more information on machine level breakpoints, see below.

Setting Breakpoints for Multi-line Statements

Code breakpoints have a special behavior for multiple-line statements, such as a multiple-line if. In an if clause, a line symbol is generated at the beginning of the list of conditions, and the other lines of the conditions are generally associated with the first line of the clause. In an if-then-else construct, the } character before the else is associated with the branch-around to the end of the statement.

Consider the following example:

If you try to set a code breakpoint at line 23, CrossView Pro sets the breakpoint on the preceding statement. If you try to set a breakpoint on line 22, CrossView Pro highlights line 23. If you set a breakpoint on line 25, it hits after the assignment to x, but before the jump to line 27. Notice that it is not hit unless the if clause is true. In other words, a breakpoint on line 25 is really a break on the }, not on the else {. The same behavior applies when the else { statement is on the next source line.

Breakpoints and For Loops and While Loops

The code generated for a C 'for' statement has three parts: the initialization; the body of the loop; and the increment, test, and branch. The initialization part and the increment, test, and branch are different parts of code, but are both associated with the 'for' statement itself. For example consider:

A breakpoint placed on line 99 will only be hit once, because it is hit at the initialization code. The code for the increment, test, and branch is associated with line 101, not 99, as you might expect.

The same applies to 'while' loops.

Breakpoints and Emulator Mode

Upon entering emulator mode, the debugger removes any breakpoints it established in the target code. Removing breakpoints ensures that you can access unmodified target code. When emulator mode ends, CrossView Pro reestablishes breakpoints as necessary.

As long as you avoid the debugger's own breakpoint trap, you may establish arbitrary breakpoint conditions while in emulator mode. These will not be removed by CrossView Pro and thus remain active, however, after you exit emulator mode. If one of these breakpoints is hit during normal debugging, CrossView Pro will issue a message such as:

System Startup Code

It is possible (for example, by using the si command) to debug system level startup code that initializes the target environment. You should not use any global variables in CrossView Pro expressions until the data area has been initialized. CrossView Pro assertions and other CrossView Pro commands that examine C variables may deliver erroneous information or cause memory access errors if used before the C environment is established.

7.1.2 Data Breakpoints

A data breakpoint instructs the execution environment to watch a particular data address or address range and halt execution if the program reads from or writes to that address. Data breakpoints are a powerful feature for tracking the use, and possible misuse, of pointers, global variables and memory mapped I/O ports.

Data breakpoints are not available for all execution environments, please check the Addendum.

When setting a data breakpoint, you can specify whether the breakpoint stops the program when data is read from, written to, or both.

Data breakpoints are implemented in hardware. As a consequence, the number of allowable data breakpoints is limited by your execution environment. A simulator does not have these restrictions. Refer to the environment-specific Addendum for more information.

You may set a data breakpoint on a local variable, but only if the local variable is active. CrossView Pro notifies you when program execution passes beyond a local variable's scope, and a breakpoint set on such a variable is deleted automatically. Data breakpoints for static variables do not have this restriction.

Note that any local variables placed in registers cannot be tracked with data breakpoints. In this case, you must use an assertion. Refer to the Assertions section later in this chapter for more information.

7.1.3 Listing Breakpoints

To see a listing of all of the currently defined breakpoints:

Select the Breakpoints | Breakpoints... menu item from the menu bar to view the Breakpoints dialog box.

In the Command Window, enter the l b or B commands. The list appears in the Command Window.

For example entering the B command can result in:

The breakpoint's number (used when deleting breakpoints) is listed first, then if it is enabled or disabled, then its type: such as CODE for code breakpoints and DATA for data breakpoints. Next, CrossView Pro lists the function and/or address, its count and reset count, and finally any attached commands enclosed by { and }.

FUNCTION: View all breakpoints in the Command window.

COMMAND: B

CrossView Pro decrements the count each time the breakpoint is hit. When the breakpoint's count reaches 0, CrossView Pro halts the program.

7.2 Setting Breakpoints

You may set a code or data breakpoint by:

When you set a new breakpoint using the mouse, without using the Breakpoint dialog box, the type is always permanent, the count 1 and the location corresponds to the current viewing position, if the Source Window is open. These variables are described in more detail below.

Setting Breakpoints from the Menu

To set a breakpoint from the menu, select the Breakpoints | Breakpoints... menu item to view the Breakpoints dialog box. From this dialog box, you can define several types of breakpoints.

To set a code break point at line number # of the C source, click the Add > button and select Code Breakpoint.... Click the Break At... button, choose a C module (for example demo.c) and click the OK button. Now you can enter a line number to set the breakpoint at.

Figure 7-2: Breakpoints dialog box

The last entry of the list is always empty. Select it to start defining a new breakpoint.

Setting Breakpoints from the Source Window

You can set or remove a code breakpoint directly from the Source Window by clicking on:

To set data breakpoints use the menu as described above.

Setting Breakpoints from the Stack Window

See the section Up-level Breakpoints later in this chapter.

Setting Breakpoints from the Command Window

You can set a code breakpoint from the Command Window using the break code command or the b command, and set a data breakpoint using the break data command. Several options are available after these commands.

See the break command in the Command Reference for detailed information.

For example, the following command sets a code breakpoint at the address specified by function main:

To set a code breakpoint at a specific source line, you can enter a breakpoint address in the form: filename#line after the break command, or you can specify a line number, followed by the b command and any commands you want to attach to the breakpoint. For example, to set a code breakpoint at line 51 in your source, enter:

or

If you do not specify a line number, a breakpoint will be set at the current viewing position.

FUNCTION: Set a code breakpoint.

COMMAND: break [code] address [, option]...

FUNCTION: Set a code breakpoint.

COMMAND: [line_number] b [commands]

To set a data breakpoint, you must specify the break data command, followed by an address, followed by any commands you want to attach to the breakpoint. There are three types of data breakpoints:

For example, to set a data breakpoint to watch the lowest byte in memory of the global variable initval, enter:

This command instructs CrossView Pro to set a data breakpoint that will halt execution if the program writes to the lowest byte in memory of the variable initval. Note that you have to specify the variable's address, otherwise the variable's value is used.

FUNCTION: Set a data breakpoint.

COMMAND: break data address [,option]...

7.2.1 Data Breakpoints over a Range of Addresses

You can also use data breakpoints to watch a contiguous range of memory. As with standard data breakpoints, data breakpoints over a range of addresses can be set to watch for reading, writing or both. To set a data breakpoint of this type:

Using mouse and menu:

From the Command Window:

For example, to ensure that the program stops if any of recordvar's fields are either written to or read from:

FUNCTION: Set a data breakpoint over a range of addresses.

COMMAND: break data address, end_addr=end_address [,option]...

7.2.2 Temporary Breakpoints

Breakpoints can be: permanent or temporary. A breakpoint exists until it is manually deleted. A temporary breakpoint is automatically removed by CrossView Pro after it halts the program once.

To set a temporary breakpoint:

Follow these steps:

From the Command Window:

For example,

sets a temporary breakpoint at line 51 and resumes execution at the current execution position.

FUNCTION: Set a temporary code breakpoint.

COMMAND: break code address, temporary=true [,option]...

7.2.3 Breakpoint Names

You can associate a symbolic name with a breakpoint. You can then use this name with the following commands: break set and break delete. Breakpoint names must be unique and cannot be a number or the word "all". Allowed characters are a-z, A-Z, 0-9 and '_'.

To assign a name to a breakpoint:

Follow these steps:

Use the name=name option of the break command in the Command Window.

For example,

sets a code breakpoint at address 0x1234 with the name brk_1.

7.2.4 Setting the Count

CrossView Pro allows you to set a breakpoint's count. The count defines how many times you encounter the breakpoint before it halts the program. For example, a breakpoint with a count of 3 means the program stops on the third hit. Each time the breakpoint is hit, CrossView Pro decrements the count. When the count reaches 0, CrossView Pro halts the program, and resets the count to the value of the reset count. The default reset count is 1.

To set a breakpoint's count,

Follow these steps:

From the Command Window,

For example, suppose you have a breakpoint set at address 0x59 of your source code. The first time the program halts at address 0x59, enter:

This command sets the breakpoint's count to 3 and the reset count to 4. You can observe a breakpoint's current count and reset count when you list the breakpoints in the Command Window with the l b command.

FUNCTION: Set the count and reset count for a breakpoint.

COMMAND: break type address, count=count

FUNCTION: Set the count and reset count for a breakpoint separately.

COMMAND: break type address, count=count, reset_count=reset_count

7.2.5 Sequence Breakpoints

A sequence breakpoint is a special kind of breakpoint. Only if other breakpoints are hit in a specified order, the sequence breakpoint itself will hit.

To hit a breakpoint without halting the program, the breakpoint in the sequence must be specified as a Probe point. When a probe point is hit, the associated commands are executed and program execution is continued.

When all specified probe points are passed in the logical sequence you specified, the program stops at the last breakpoint in the sequence.

To set a sequence breakpoint:

Follow these steps:

From the Command Window:

For example,

In this example, the sequence breakpoint hits when probe point 0 is hit first, then 1 and 3 are hit in any order, and finally probe point 2 is hit.

FUNCTION: Set a sequence breakpoint.

COMMAND: break sequence sequence [, option]...

7.3 Deleting Breakpoints

You can delete a breakpoint directly from the source code, using the menu items, or through the Command Window. To see a list of active breakpoints, click on the Breakpoints | Breakpoints... menu item or use the l b command in the Command Window.

To delete a code breakpoint:

Click on the corresponding red breakpoint toggle next to the source line in the Source Window. This deletes the code breakpoint and the breakpoint toggle turns green.

You can also follow these steps:

Use the break delete breakpoint_number | name command in the Command Window. You need to know the breakpoint's number or name for this command.

For example, to delete the breakpoint numbered 1, enter:

FUNCTION: Delete a breakpoint.

COMMAND: break delete breakpoint_number
break delete breakpoint_name

To clear all the breakpoints in the program, type:

FUNCTION: Delete all breakpoints.

COMMAND: break delete all

7.4 Enabling/Disabling Breakpoints

You can enable or disable a breakpoint directly from the source code, using the menu items, or through the Command Window. To see a list of active breakpoints, click on the Breakpoints | Breakpoints... menu item or use the l b command in the Command Window.

To enable or disable a code breakpoint:

Follow these steps:

On Windows:

On UNIX:

Use the break enable or break disable command in the Command Window to enable or disable a breakpoint. You need to know the breakpoint's number or name for these commands.

For example, to disable the breakpoint numbered 1, enter:

FUNCTION: Disable a breakpoint.

COMMAND: break disable breakpoint_number
break disable
breakpoint_name

To enable the breakpoint numbered 1, enter:

FUNCTION: Enable a breakpoint.

COMMAND: break enable breakpoint_number
break enable
breakpoint_name

7.5 Breakpoint Commands

CrossView Pro allows you to attach commands to code and data breakpoints. When execution halts at a breakpoint, CrossView Pro executes the commands. Valid commands are almost any C statements and CrossView Pro commands, giving you a very powerful tool for manipulating a debugging session. To do this:

Follow these steps:

You do not need to enclose a group of commands in brackets. However, each individual command must be delimited by a semicolon.

Figure 7-3: Breakpoint Commands

Type the commands, enclosed in brackets and delimited by semicolons, after commands= argument of the break command in the Command Window.

For instance, suppose you want a program to stop at a breakpoint, display a variable's value, and resume execution all in one stroke. To perform this function, you need to attach the appropriate commands to a breakpoint. Enter:

This places a breakpoint at address main. When execution stops at the breakpoint, CrossView Pro displays the value of initval and immediately resumes execution.

If you enable the Probe point check box, you can omit the C command. This is done automatically.

You can attach almost any valid CrossView Pro commands or C statement to breakpoints. This latitude allows you to use breakpoints in powerful ways. Later on you find out how breakpoints can create patches in your program.

CrossView Pro does not check the syntax of attached commands until the breakpoint is hit.

Data breakpoints accept command lists the same way as code breakpoints. For instance, to set a data breakpoint that monitors the lowest byte in memory of the value of initval, enter:

Every time the program writes to the lowest byte in memory of the variable initval, this breakpoint halts the program, prints the value of initval and continues execution.

For more information on the use of attached commands, see the Patches and Diagnostic Output and Statistical Information sections later in this chapter.

7.5.1 Attaching Conditionals to a Breakpoint

You can pass standard C conditionals to a breakpoint.

For example:

stops the program at line 63, checks to make sure the variable initval is 17, and resumes execution if it is. If initval's value does not equal 17, CrossView Pro prints the value, and the program remains halted.

7.5.2 Attaching Macros to a Breakpoint

You can attach any currently defined macro to a breakpoint in a command list. For example, suppose you define a macro named rg that checks the value of the variable initval. The command to define this macro is:

If the value does not equal 17, the macro prints the value and halts the program. Otherwise, execution continues.

You can include this macro at any point by attaching it to a breakpoint. Entering:

this is a very efficient way to insert the macro with breakpoints at lines 51 and 63.

For more information on macros, refer to Defining and Using Macros chapter.

7.5.3 Attaching Strings to a Breakpoint

You can attach strings to a breakpoint's command list. This feature is useful for placing comments and reminders within your breakpoints. Attaching a string to a breakpoint also eliminates the need for diagnostic printf( ) statements in your compiled code.

For example, you could place a breakpoint on line 49 such as:

Whenever the breakpoint on line 49 is hit, CrossView Pro prints the string and continues execution.

7.6 Suppressing Breakpoint Messages

Whenever a breakpoint is hit, CrossView Pro displays in the Command Window, the name of the function, line number and file in which the breakpoint appears. You can suppress this information by setting breakpoint "silent" mode. In the silent mode, the current location is not printed out.

To set silent mode you can use the Q (for quiet) command as part of the command attached to a breakpoint definition.

Pass the Q command to a breakpoint first. For example:

stops the program on line 51, but does not print a message stating where the break occurred.

7.7 Up-level Breakpoints

Up-level breakpoints are breakpoints set at the entrance and/or exit of functions. Basically, up-level breakpoints are code breakpoints that are directly connected to the current HLL stack handling.

To see the current HLL stack, open the Stack Window or enter the t command in the Command Window.

You can set up-level breakpoints via the Stack Window or in the Command Window. You cannot set up-level breakpoints in the Source Window:

Double-click on the function in the Stack Window to install a stack breakpoint after the function call.

You can also follow these steps:

You have the option of setting the breakpoint before (function entry) or after (up-level) a selected function.

All breakpoints set through the Stack Window are temporary by default. To make a breakpoint permanent, select the Breakpoints | Breakpoints... menu item to open the Breakpoints dialog. Select the breakpoint you want to edit and click on the Edit... button. Click on the Advanced>> button and disable the Remove when hit check box.

In the Command Window, use the following commands:

Command Function Type
bU Sets breakpoint after call to function temporary
bu Sets breakpoint after call to function permanent
bB Sets breakpoint at beginning of function temporary
bb Sets breakpoint at beginning of function permanent

For example, suppose you have accidentally single-stepped into a function called factorial( ). If you do not want to single step through the function, an up-level breakpoint can help you. Enter:

The bU command sets a temporary breakpoint after return of the function. Now, instead of having to single step all the way through the function, you can start continuous execution, which stops when it hits the new breakpoint at the function's return. Note that it makes no difference whether the function has several possible points of return; the up-level breakpoint works at all points of return. Note that when the function that contains the breakpoint is called from one of the functions that are located below it on the stack, the execution may be stopped before returning at the desired stack level, for example with recursive functions.

When setting up-level breakpoints from the Command Window, you can specify how deep in the stack the function's address is located. For example, if you are two functions down from the main( ) program, enter:

This command breaks when you return to the top level of the call graph.

FUNCTION: Set a temporary breakpoint after call to function.

COMMAND: [stack] bU [commands]

FUNCTION: Set a permanent breakpoint after call to function.

COMMAND: [stack] bu [commands]

FUNCTION: Set a temporary breakpoint at function entry.

COMMAND: [stack] bB [commands]

FUNCTION: Set a permanent breakpoint at function entry.

COMMAND: [stack] bb [commands]

7.8 Patches

A patch is a means of using CrossView Pro to change the execution of your program without recompiling. Patches involve manipulating breakpoints to skip code, include code, or replace existing code with new code.

Basically, a patch is a breakpoint with certain associated commands that enable you to alter program execution. This capability is a useful debugging tool.

You can associate the commands used to patch code with a breakpoint through either the Command Window or through the Commands edit box in the Breakpoint dialog box. The examples below set breakpoints using CrossView Pro commands typed in the Command Window. Breakpoints can also be set using the Breakpoints | Breakpoints... menu item. In this case the commands between the brackets are entered into the Command edit area.

7.8.1 Patching Code out of a Program

To patch code out of a program, you can set a breakpoint that changes the execution position. For instance, suppose you want to patch an infinite loop out of your source.

On line 78, place a breakpoint that jumps to line 83, effectively bypassing the loop. In the Command Window, enter:

This creates a breakpoint on line 78 that does nothing more than move the execution position beyond the loop and issue a C command. Remember that the breakpoint on line 78 is hit before the C statement on that line executes.

7.8.2 Patching Code into a Program

You can also patch code into a program by just including the code in the breakpoint command. For example, suppose you want to add an equation with the variable loopvar.

In the Command Window, enter:

This command halts execution at line 78, adds the statement loopvar=0 to the program, and continues execution.

7.8.3 Replacing Code in a Program

Finally, you can combine the two techniques described above to replace code in a program. For instance, suppose you want to replace an infinite loop with new code.

In the Command Window, enter:

This command sets a breakpoint that halts execution (quietly) at line 78 and inserts an if statement into the program. If sum is less than 100, sum increments and line 78 executes again. If sum equals 100, CrossView Pro moves the execution position to line 83 (beyond the infinite loop) and resumes execution.

7.9 Diagnostic Output and Statistical Information

Breakpoints with attached commands allow you to report on various variables while the program executes. In the past, one inefficient method of tracking variables was to litter code with printf() statements. Using breakpoints makes that process unnecessary.

For instance, suppose you want to keep track of the variable loopvar at line 59 of a program. Install a breakpoint with the following command:

The breakpoint halts the program, prints the value of loopvar, and resumes execution. The Q command suppresses the listing of where the break occurred. This breakpoint does not affect the source code and no recompilation is necessary.

Using special variables, you can also keep statistics about your program, such as how many times a line of code executes or how many times a variable is accessed.

For example, suppose you want to know how many times line 60 executes. You must define a special variable to keep track of your statistical data, and set a breakpoint to accumulate the data for you.

First, define the special variable. In the Command Window, enter:

This command defines the special variable $test and sets it to zero. For convenience, you can also set a breakpoint at the beginning of the program that initializes $test.

Secondly, set a breakpoint at line 60 that increments $test and continues execution every time the program hits line 60:

7.10 Assertions

An assertion is a collection of debugger commands executed by the debugger after each program line. When you execute a program using assertions, the debugger is in assertion mode. Running the debugger in assertion mode is a way of executing continuous control of certain data.

Using assertions, you can have continuous control of certain data and stop program execution if any of the set conditions are fulfilled. In this respect, assertions are similar to data breakpoints. Assertions, however, are more versatile than data breakpoints. For instance, a data breakpoint can only detect when a variable is accessed. An assertion, on the other hand, can check that the variable's value falls within a certain range. Also, an assertion can monitor variables whose values are kept in registers.

The default limit for the number of assertions you can define is 16. It is possible to increase the number of assertions by selecting the Initialization tab in the File | Options... dialog box. Each individual assertion can be activated or deactivated. In addition, you can also choose to suppress all assertions by turning off the global assertion mode.

Opening the Assertions Dialog Box

Select Breakpoints | Assertions... menu item.

The Assertions dialog box contains scrollable lists of all defined assertions, and provides functions for defining, activating, suspending, editing and deleting assertions.

7.10.1 Assertion Mode

The debugger is running in assertion mode when there is at least one active assertion. A program executing in assertion mode is actually being single-stepped very quickly, to ignore breakpoints. Because the program is single-stepping, however, it runs significantly slower than at normal speed.

An Assertion Mode Active checkbox is available that activates all marked (*) assertions. Clear this option if you want to suspend all assertions temporarily. To activate marked assertions:

Open the Assertions dialog box and activate all marked assertions by enabling the Assertion Mode Active check box.

In the Command Window, enter the A command:

The Global Active state activates all assertions. Globally activating the assertion mode, however, does not change how each assertion is marked.

FUNCTION: Activate assertion mechanism.

COMMAND: A a

FUNCTION: Suspend assertion mechanism.

COMMAND: A s

FUNCTION: Toggle assertion mechanism.

COMMAND: A

7.10.2 Defining an Assertion

To define or edit an assertion:

Follow these steps:

Figure 7-4: Defining Assertions

Use the a command followed by a list of commands.

FUNCTION: Create an assertion.

COMMAND: a commands

Assertions accept standard C statements and certain CrossView Pro commands as arguments.

An assertion usually contains a conditional. For example, suppose you want to create an assertion that watches the value of the global variable initval to see that it's value does not exceed a certain limit. In this case, you enter in the Assertion dialog box (or into the Command Window after the a command):

This command creates an assertion with the condition that if initval exceeds 17, CrossView Pro halts the program. The {x} is a special assertion command that tells CrossView Pro to halt the program and return control to you.

7.10.3 Editing an Assertion

To edit the contents of an assertion:

Follow these steps:

You must delete the specific assertion (section 7.10.5 ) and define a new assertion (previous section) with the desired command.

7.10.4 Activating and Suspending Assertions

A particular assertion is either active or suspended. A suspended assertion does not execute before every line, but it retains its definition.

You may find it helpful to use activate and suspend assertion commands in conjunction with code breakpoints, since assertions tend to slow the target program. By attaching commands to a breakpoint to activate and suspend assertions, you can turn assertions on only for certain sections of code where a particular value needs checking. This method can dramatically speed up the program.

Open up the Assertions dialog box from the Breakppoints menu and double-click on the assertion's number.

To activate or suspend an assertion from the Command Window, you must know the assertion's number. To see a list of assertions and their assigned numbers:

To activate an assertion:

To suspend an assertion:

FUNCTION: Activate an assertion.

COMMAND: assertion_number a a

FUNCTION: Suspend an assertion.

COMMAND: assertion_number a s

7.10.5 Deleting Assertions

Deleting an assertion removes its definition. It is important to note the difference between suspending an assertion and deleting an assertion: deleting an assertion removes its definition for good, while suspending it retains the definition but prevents its execution.

Follow these steps:

Follow these steps:

FUNCTION: Delete an assertion.

COMMAND: assertion_number a d

7.10.6 Using Assertions

You can use assertions for almost any type of debugging task. For example, if you want to check the value of a global variable, global_val, during the execution of a certain function, f(). A data breakpoint or a straightforward CrossView Pro assertion does not suffice for this task since there is no way to make either method limited to that function's code range. The solution lies in creating an assertion that is active only over a specific range of lines. In this case, you could solve your problem with the following steps:

Using the mouse and menu:

1. Open the Assertions dialog box from Breakpoints | Assertions... menu.

2. Click on the New... button.

3. Set up the assertion to check the value of global_val. Enter:

This assertion halts program execution if the value of global_val equals 17.

4. Open the Breakpoints dialog box by selecting the Breakpoints | Breakpoints... menu item. Click the Add > button and select Code Breakpoint....

5. We want to establish a breakpoint at line 112, the first line of the function f( ) and attach commands to the breakpoint to activate assertion mode and continue execution. Change the Line number to 112. Click in the Command edit area and enter:

6. Create an assertion whose only function is to check that the current line number is still valid for assertion mode. To do this, use the reserved special variable $LINE, which contains the line number of the current execution position. In the Assertions dialog box, click on New... and enter:

If the line number exceeds 120, the program is about to leave the function f( ) and CrossView Pro deactivates assertion mode. Normally, the x command would make the program stop, but the non-zero value tells CrossView Pro to execute the rest of the commands in the list, in this case, C for continue.

You must enter all commands in the Command Window.

1. First set up the assertion you want:

2. Now set a breakpoint on the first line of the function factorial() that will activate assertion mode, and continue execution:

3. Now create an assertion that does nothing but make sure that the current line number is still valid for assertion mode. If the line number exceeds 120, you know you have left the function f() and assertion mode should be suspended.

$LINE is a reserved special variable that CrossView Pro maintains containing the number of the line currently executing. If it becomes equal to 120, assertion mode is turned off. Normally, the x would make the program stop, but the non-zero value 1 tells CrossView Pro to execute the rest of the commands in the list, in this case, C for continue.

In this manner you have created an assertion that is only active over a limited range of source lines.

7.10.7 Gathering Statistics with Assertions

You can also use assertions to gather statistics about your code. For instance, you can find out how many lines of C code execute in a particular session:

$numlines is a user-defined special variable that increments on each line of C code. When the program stops, type:

and CrossView Pro gives the result. To start again, you may want to re-initialize $numlines to zero:

Or just set a breakpoint on the first line of code to do the same.


Copyright © 2002 Altium BV