15 GLOSSARY

15.1 What this Chapter Covers

This chapter defines terms common to CrossView Pro and source-level embedded systems debugging. Italicized items in definitions are also glossary entries.

15.2 Glossary Terms

A

absolute file. The IEEE-695 file (.abs) or the ELF/DWARF v1.1 or v2.0 file (.elf) that contains symbolic debug information and the final executable code of the target system.

active window. The window last selected by the user in CrossView Pro that commands operate on as a default. An active window's title appears in a different color (on color monitors) or inverse video (on monochrome).

assertion. A command or set of commands to be executed before every line of source code, assessing the application state on validity. 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 assesses all assertions active. 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 be stopped when an asserted command executes the x (exit assertion mode) command.

B

background mode. A target dependent feature in CrossView Pro that lets the execution environment run and at the same time allows you to enter a reduced set of CrossView Pro commands, for example to monitor memory contents.

bias. A value added to program code addresses to tell CrossView Pro where the application has actually been loaded into memory. The bias can be set in the Load Application dialog or with the -n startup option.

breakpoint. A mechanism for stopping target program execution, for example 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 up-level breakpoint). There are two general kinds of breakpoints. Hardware, which the emulator or on-chip debug support 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 both kinds by default. Other types of breakpoints are for example instruction count breakpoint, cycle count breakpoint, timer breakpoint and sequence breakpoint. See also probe point.

breakpoint window. A CrossView Pro dialog displaying all breakpoints, and any attached commands.

C

C-trace window. A CrossView Pro window keeping a record of the most recently executed C or machine statements.

cache. Some microprocessors keep a copy of the most recently executed instructions in on-chip memory to speed-up execution.

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 .

code coverage. See coverage.

command window. A CrossView Pro window that gives access to CrossView Pro via a command line interface with history.

command list. A series of CrossView Pro commands and/or C (assignment) statements attached to a code or data breakpoint, executed when the breakpoint is hit.

count. The number of times a breakpoint must be hit to finally stop execution. Breakpoints are created with a count of 1. The C command may be used to change the count of a breakpoint.

coverage. With code coverage the source line is marked for each source code line that is executed. Through code coverage you can find executed and non-executed areas of the application program. Data coverage allows you to verify which memory locations, i.e. which variables, are accessed during program execution. Additionally, you can see stack and heap usage. The availability of this feature depends on the execution environment.

cycle count breakpoint. A breakpoint that halts program execution after a specified number of CPU cycles. A cycle count breakpoint can have a command list.

current function. The function that is currently being executed. The current function is always at level 0 on the stack. Also stored in the CrossView Pro special variable $PROCEDURE.

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 coverage. See coverage.

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. A CrossView Pro window displaying the values of monitored expressions.

diagnostic output. Program output designed for debugging purposes. With CrossView Pro, probe points and data monitoring can be used for diagnostic output, eliminating the need for intrusive and annoying printf calls compiled into code.

disassembly window. A CrossView Pro window showing a part of the disassembled program space. It also displays other information such as the current execution position, viewing position and installed breakpoints.

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. Computer(s) executing an application program built to run in (semi) 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 and control 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 fully emulate the behavior of the target chip. See ROM monitor.

execution position. The source line to be executed next. See viewing position.

F

File System Simulation (FSS). A facility to redirect all C library file I/O operations on the target, to the host system via CrossView Pro. File system simulation is often used to provide input to an application for which no hardware I/O is available yet and to log test results.

format. The manner in which CrossView Pro displays addresses and 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. A window explaining the use of CrossView Pro windows and dialogs and summarizing the syntax and function of CrossView Pro commands.

history mechanism. A facility for modifying and executing previous CrossView Pro commands.

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 that contains the executable code of the target program. See also absolute file.

instruction count breakpoint. A breakpoint that halts program execution when a number of instructions have been executed. An instruction count breakpoint can have a command list.

interrupt key. The key that interrupts ongoing processes. On many systems this is ctrl-C.

I/O Simulation. A technique to intercept input and output for debugging purposes. I/O Simulation is often used for testing a program before the actual input and output hardware devices are present. See also stream.

L

local variable. A variable that can only be referenced from within its defining function.

low-level breakpoint. A code breakpoint placed on an individual machine instruction. Low-level breakpoints can be set with the break code address command.

M

macro. A user-created shorthand for a CrossView Pro command sequence. Macros can accept parameters and can be saved to a file.

main(). The function where a C program's execution begins. See also system startup code.

MAU. See minimem addressable unit.

memory map. The configuration of an emulator's memory that specifies which addresses are read-only, and which addresses are read/write. With many emulators, you must first set up a memory map before using CrossView Pro, for example via transparency commands.

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.

monitoring. See data monitoring.

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.

output buffer. The location in memory where CrossView Pro directs I/O simulation output. See also I/O Simulation.

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.

probe. A part of an emulator that can be inserted in place of the target chip in the actual embedded systems hardware.

probe point. A special kind of breakpoint. When a probe point breakpoint is hit, the associated commands are executed and program execution is continued.

profiling. For each source code line that is executed, the timing information is given.

Q

quiet command. A Q instruction at the start of 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. A 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. 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 exchanges asynchronous 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.

sequence breakpoint. A breakpoint that halts program execution when breakpoints are hit in a specified sequence. A sequence breakpoint can have a command list.

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 pipeline 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. A CrossView Pro window displaying the high-level language program code. It also displays 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.

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. A 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 I/O simulation. Per method, File System Simulation, File I/O or Debug Instrument I/O, a unique stream numbering scheme is used.

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. 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 targeted microprocessor where the embedded application runs.

terminal window. A CrossView Pro window containing all the input and output streams directed to the screen. CrossView Pro can display several windows at a time.

timer breakpoint. A breakpoint that halts program execution after a specified number of seconds or timer ticks. A timer breakpoint can have a command list.

trace buffer. A target-resident buffer that contains the most recent instructions executed by the target microprocessor. CrossView Pro uses this buffer to deduce 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

up-level 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 dashed line cursor. Some commands operate by default on the viewing position. The viewing position and the execution position are initially the same, but you may adjust each individually.


Copyright © 2002 Altium BV