Glossary of DIA SDK Terms

 

This glossary defines terms that appear in the Debug Interface Access (DIA) SDK.

compiland

The basic unit of compilation or translation. A project usually consists of several compilands (for example, .c and .cpp files) that are compiled to produce a corresponding object file. See also function.

executable file

The top-most level of the executable image. See module.

function

Several functions may make up a compiland. Functions that are members of a class are referred to as methods. Functions may in turn consist of several lexical blocks.

injected source

Code that has been placed into the symbol store by attribute providers or other components of the compilation process. May also refer to code that is generated automatically by the compiler and/or linker.

image

See module.

lexical scope

The region of source code in which a symbol (or identifier) is considered valid; that is, a namespace, file, function, block of code, or function prototype.

module

An independent unit of execution that forms part of one or more larger applications. Both .exe and .dll files are considered modules. See also compiland.

namespace

A set of unique symbols or identifiers; a collection of symbols related by function or vendor.

performance-oriented grammar optimizer (POGO)

A tool for controlled language checking and generation.

procedure

See function.

program database (.pdb) file

A file used to store symbolic information about the compiled application.

prologue (prolog)

A sequence of code instructions at the start of a function that preserves registers, sets the CPU state, and establishes the stack. Different calling conventions use different prologues.

relative virtual address (RVA)

An offset from the address of a module loaded in memory. See also virtual address.

slot

The location offset of an imported function within the import address table of an executable; the location offset of a memory address in a Microsoft Intermediate Language (MSIL) P-code assembly.

symbol

For the compiler, any name used to identify coding constructs (such as a variable, function, structure, enumeration, constant, class, method, property, and so on) and memory locations within an application.

thunk

Code that performs a translation or conversion during a call or indirection. For example, a thunk may be used to change the size or type of function parameters when passing data between 16-bit and 32-bit code.

user-defined types (UDT)

Base data types explicitly defined with a new name through the pre-compiler's typedef directive. They are equivalent to the base types from which they were defined.

virtual address (VA)

For systems with virtual memory, a VA is a memory location that intervening hardware and/or software maps to physical memory. As an application runs, the same virtual address may be mapped to many different physical addresses as data and programs are paged out and paged in to new memory locations. See also relative virtual address.