This chapter defines many terms common to CrossView Pro and source-level embedded systems debugging. Italicized items in definitions are also entries.
A
absolute file. The IEEE-695 file (.abs) that contains symbolic debug information and the executable code of the target system.
active window. A user-selected CrossView Pro window that commands operate on as a default. An active window's title appears in red (on color monitors) or inverse video (on monochrome).
Assembly window. An CrossView Pro window showing a part of the disassembled program space. It also indicates such information as the current execution position, viewing position and installed breakpoints.
assertion. A command or set of commands to be executed before every line of source code. Assertions are especially useful in tracking down hard to find bugs when other methods fail. Individual assertions may either be active or suspended. See also assertion mode.
assertion mode. A mode of CrossView Pro operation under which assertions will be executed. Before CrossView Pro executes a source line of code, it tests for an arbitrary condition specified by the user. Since CrossView Pro is single stepping breakpoints will not be effective. As long as there is at least one assertion active, CrossView Pro operates in assertion mode. A program running in assertion mode will stop when an asserted command executes an X (exit assertion mode) command.
B
background mode. A feature in CrossView Pro that lets the execution environment run while you can still enter CrossView Pro commands.
bias. The offset value from zero at which a target program is actually loaded into memory. The bias can be set with the -n startup option.
breakpoint. A mechanism for stopping target program execution at a particular line of code (see code breakpoint), when a memory address is accessed (see data breakpoint), or at a return from a function (see uplevel breakpoint). There are two general kinds of breakpoints, hardware which the emulator sets in its circuitry, and software, which are special instructions placed in user code. Since the number of simultaneous hardware breakpoints is limited in number, CrossView Pro uses software breakpoints. Using transparency mode, however, you may set your own hardware breakpoints.
Breakpoint window. An CrossView Pro pop-up window displaying code and data breakpoints, and any attached commands.
C
C-trace window. An CrossView Pro window keeping a record of the most recently executed C or machine statements.
cache. Some microprocessors keep in on-chip memory a copy of the most recently executed instructions to speed processing. Sometimes execution will not halt until the this private storage (the cache) is exhausted. See also skidding.
code breakpoint. A breakpoint that halts program execution when a particular line of code is reached. A code breakpoint can have a command list. A breakpoint can be set on a line of source code or at the address of a machine instruction. See also count .
Command window. The Command window contains all user input. Output may be directed to the Command window.
command list. A series of CrossView Pro and/or C commands attached to a code or data breakpoint, executed when the breakpoint is hit.
Composite window. An CrossView Pro window that is a combination of three separate windows: the Data, Register, and Stack windows.
count. The number of times a breakpoint must be hit before execution halts. Breakpoints are created with a count of 1. The C command may be used to change the count of a breakpoint.
current function. The function that execution is currently in. The current function is always at level 0 on the stack.
D
data breakpoint. A breakpoint that halts program execution when a particular memory address (or an address within a particular range) is written to, read from, or both. A data breakpoint may have a command list and a count.
data monitoring. CrossView Pro allows you to monitor expressions and variables in the Data window. CrossView Pro updates their values whenever execution stops.
Data window. An CrossView Pro window displaying the values of monitored expressions.
diagnostic output. Program output designed for debugging purposes. With CrossView Pro, breakpoints and data monitoring can be used for diagnostic output, eliminating the need for intrusive and annoying printf calls compiled into code.
dot operand. The period character "." used in an expression to represent the last value CrossView Pro calculated. The dot operand is useful as shorthand.
E
embedded system. An application program built for a microprocessor running in real-time. An embedded system usually is part of a larger, non-computer system, hence the term "embedded." The TASKING product line is designed for embedded systems programming.
emulator. A device used to monitor various aspects of a microprocessor's operation. An emulator usually is built around two chips, the target microprocessor and a controlling chip. The controller chip can start and stop the target chip's program execution, and can examine and change registers and memory. An emulator can be connected via a probe to a hardware prototype to emulate fully the behavior of the target chip. Hence it is an ideal debugging device. See ROM monitor.
__end_. A run-time library routine used to implement command line function calls. It must be linked into the object code.
execution position. The source line corresponding to the value of the program counter. See viewing position.
F
format. The manner in which CrossView Pro displays data; for instance, hexadecimal, character and octal are different formats. You may include special format codes when specifying variables.
H
hardware breakpoint. See breakpoint.
Help window. One of two levels of windows summarizing the syntax and function of CrossView Pro commands.
history mechanism. The process by which CrossView Pro retains the last twenty CrossView Pro commands issued.
host system. The computer system on which CrossView Pro is run. The host system is connected to the target system, usually with an RS-232 cable.
I
image part. This is the downloadable part of the absolute file (.abs) that contains the executable code of the target program. See also absolute file.
interrupt key. The key that interrupts ongoing processes. On many systems this is ctrl-C.
L
Librarian. The utility which manages libraries of program modules at the prelink or postlink phase of development.
line mode. An CrossView Pro operating mode in which all screen output appears after the prompt. No windows are present. See also window mode.
Linker. The utility which combines separate object modules into a single module, resolving references.
local variable. A variable that can only be referenced from within its defining function.
Locator. The utility which assigns absolute target-memory locations to relocatable sections and resolves address references.
low-level breakpoint. A code breakpoint placed on an individual machine instruction. Low-level breakpoints can be set with the bi command.
M
macro. A user-created shorthand for an CrossView Pro command sequence. Macros can accept parameters and can be saved to a file.
Macro window. An CrossView Pro window that lists all currently defined macros. It automatically appears whenever you define a new macro in window mode.
main(). The function where a C program's execution begins. See also system startup code.
MAU. Abbreviation for minimum addressable unit.
memory map. The configuration of an emulator's memory that specifies which addresses are read-only, and which are read/write. With many emulators, you must first set up a memory map before using CrossView Pro.
minimum addressable unit. For a given processor, the amount of memory located between an address and the next address. It is not necessarily equivalent to a word or a byte. Abbreviated MAU.
O
object language. A representation for target machine instructions, with the ability to represent either relocatable or absolute address locations.
On-line Help. A complete summary of all CrossView Pro commands and individual descriptions available while CrossView Pro is running.
On-line Tutorial. A playback file supplied with CrossView Pro that demonstrates CrossView Pro's capabilities.
optimizer. A phase of the compiler which identifies sections of source code that can be made more efficient by the code emitter and directs the code emitter to implement those improvements.
output buffer. The location in memory where CrossView Pro directs simulated output. See also simulated I/O.
overlay. A module that may be loaded into memory at an address other than the address specified at locate time. CrossView Pro allows you to debug relocatable code by specifying an offset when invoking the debugger. CrossView Pro uses the information to correlate executable code with the symbol table.
P
patch. A technique to alter program flow (without recompiling the source code) with CrossView Pro commands and/or C expressions. With CrossView Pro, it is possible to use breakpoints to alter program flow by patching in new code or moving the execution position around existing code.
pop-up window. A window that appears in certain situations that overlaps the current display. Pop-up windows usually contain information (like a command definition) that need not be continuously displayed. The Breakpoint, Macro and Help windows are pop-up windows.
probe. A part of an emulator that can be inserted in place of the target chip in the actual embedded systems hardware.
pseudo-assembly. An optional output from the compiler that lists an assembly code representation of the compiled output. Since the compiler compiles directly to object code, there is no actual assembly output.
Q
quiet command. A Q instruction in the command list of a breakpoint suppressing the default display of function: line number: source file.
R
record & playback. The ability to save CrossView Pro commands (and, if desired, Command window output) to a file. CrossView Pro can play back simple text files consisting solely of CrossView Pro commands.
Register window. An CrossView Pro window showing the contents of the target microprocessor's registers.
reserved special variables. Special variables ($LINE, $PROCEDURE, $FILE) whose values CrossView Pro maintains to reflect the current status of the debugging session. See also special variables.
ROM monitor. A program which supervises or controls, at an elementary level, the overall operation of an embedded system. There are ROM monitors, designed to TASKING's specifications that communicate with CrossView Pro. Because of the limited hardware features of most boards containing ROM monitors, some CrossView Pro features may not be supported. See also emulator.
RS-232 cable. A cable that transmits serial data between the host and target systems.
S
scope. The extent to which a variable can be referred to. Global variables are always in scope; local variables are only in scope when their defining function is the current function.
select. To make a window active.
simulated I/O. A technique to trap input and output calls for debugging purposes. Simulated I/O is often used for testing a program before the actual input and output hardware devices are present. See also stream.
Simulated I/O window. An CrossView Pro window containing all the input and output streams directed to the screen. CrossView Pro can display from one to four separate windows at a time.
single stepping. Executing a source statement or a machine instruction then halting. Single stepping lets you observe a program executing in stop-motion, to observe registers, variables and program flow.
skidding. When a microprocessor executes a few instructions after a data breakpoint halts execution. On some microprocessors, execution may not stop until all instructions in its cache have been executed. It is important to realize therefore that a target program may not halt at the precise instruction where the data breakpoint occurred.
software breakpoint. See breakpoint.
source level debugger. A debugger capable of correlating source code and variable names with object code. CrossView Pro is a source level debugger.
Source window. An CrossView Pro window containing the listing of the target program. It also indicates such information as the current execution position, viewing position and installed breakpoints.
special variable. A variable independent of the target program that CrossView Pro maintains for the user's benefit. Special variables start with a $ and are defined when first mentioned. CrossView Pro also maintains reserved special variables that contain information about the state of the debugging session.
split screen mode. See window mode.
stack depth. The level that a particular return address from a function resides on the stack. The current function is always at stack depth zero.
stack traceback. An operation in which CrossView Pro reads the return addresses and passed parameters off the stack to reconstruct program flow.
Stack window. An CrossView Pro window showing the function calls on the stack, with the values of the parameters passed to them.
startup options. Special command line switches passed to CrossView Pro when the debugger is first loaded. These options control items such as the number of assertions allowed, or can perform various actions such as to start recording screen output to a file.
stream. A particular input or output data path for simulated I/O. Each stream has a unique number for identifying purposes.
switches. See startup options.
symbolic debugger. A type of debugger generally limited to dealing with global, non-dynamic variables. Symbolic debuggers know nothing of the data types; they translate global names and global subroutines into addresses. See also source level debugger.
symbol information. The necessary information for CrossView Pro to correlate object code with source code. The symbol information is part of the absolute file (.abs file). See also absolute file.
system startup code. A run-time library routine written in assembly language source that initializes the target environment before calling main(). See also main().
T
target communication. The low-level communication between the host and the target system. For the most part, CrossView Pro handles target communications, allowing the programmer to concentrate on the high-level information.
target microprocessor. The chip on which the target program runs.
target system. The emulator or ROM monitor where the target microprocessor resides, and on which the target program runs.
trace buffer. A target-resident buffer that contains the most recent commands executed by the target microprocessor. CrossView Pro uses this buffer to perform a C-trace.
transparency mode. The mode in which CrossView Pro passes user input directly to the emulator. Transparency mode is often used when setting up memory maps.
U
uplevel breakpoint. A code breakpoint set at the return from a function at a specified stack depth.
V
viewing position. The line of source code currently being viewed. This line contains the cursor. Some commands operate as a default on the viewing position. The viewing position and the execution position are initially the same, but you may adjust each individually.
W
window mode. An CrossView Pro operating mode in which the screen is divided into several windows (which you may control) where various information is grouped by category. See also line mode.
Z
zoom. To expand the Data, Register or Stack window to the full width of the screen.