WO1997014096A1 - System and method for debugging computer software - Google Patents

Abstract

A system (450) and method (200) of operation for determining operational characteristics of a computer software program. An executable program having a plurality of executable blocks is loaded into memory (456). A parent process is loaded into a same address space in memory (456). Each entry point is determined (204). Entry point instructions are replaced with branches so the parent process (206). Execution of the executable program commences (208). When each entry point is reached, diagnostic code is selectively written into memory (211, 212). Execution is then continued (214). When run, the diagnostic code reports an operational characteristic of the executable program. Diagnostic code is written only for executable blocks about to be executed and based upon dynamic user input. Another embodiment (600) maintains a virtual register set and investigates operation of the computer software program by emulating the effect of the program on the virtual register set and memory. Emulation code blocks may be generated just prior to their execution or generated at one time for the complete computer software program.

Description

SYSTEM AND METHOD FOR DEBUGGING COMPUTER SOFTWARE

BACKGROUND

1. Technical Field:

This invention relates generally to computer software and more particularly to a system and related method for determining operational characteristics of an executable computer software program. In one embodiment, the system and related method operate in a common

address space with the executable computer software program and rewrite the executable computer software program as executed, causing the executable computer software program to branch to validation routines that validate particular instructions within the executable computer software program. In another embodiment, the system and related method maintain a virtual

machine state for the executable computer software program while determining the operational characteristics in a primary address space by emulating the operation of the computer software program in the virtual machine state.

2. Description of Related Art: Over time, with the increasing complexity of computer systems, computer software

running on the computer systems has also become quite complex. Software developers dedicate many man years to the development of particular computer software programs that

provide great benefits to users of the programs. However, as the complexity of computer

software programs increase, the difficulty associated with developing the computer software

programs also increases. While the construction of the computer software programs has become difficult, the detection of programming errors in the computer software has also become exceedingly difficult.

A typical program error may relate to the mismanagement of memory, the mis-

management of bulk storage, or the mismanagement of registers within a computer system. A single error may cause significant errors in the operation of the computer system. Thus, substantial resources are dedicated within a programming environment to debugging computer

software prior to its release to the public. However, the difficulty in removing errors or bugs from computer software programming increases exponentially with the complexity and size of the computer software program. Thus, as complexity increases, the percentage of total resources dedicated to debugging programming errors also increases. Resultantly, a relatively

larger percentage of programmers are dedicated to debugging the computer software programs as complexity increases.

Nonetheless, effort expended to remove bugs prior to the release of the software is well

spent. Bugs that are located after the release of the computer software program are at least ten

times as expensive to fix as those that are caught prior to the program's release. When bugs are located after a product has shipped, significant additional costs must be expended in the

replacement of executable copies of the computer software obtained by the user. Further, consequential damages caused to the reputation of the software vendor and the reputation of the

software program itself will reduce future revenues from the sale of the software.

Thus, diagnostic programs have been developed that operate on computer software

programs to find problems within the programs. In a typical de-bugging environment, a parent

process performs de-bugging functions on a child process. A classical example of such a

parent-child process is the UNIX DBX utility which operates as a parent process looking for a recognized or identified bug within a child process, which is an executable program. However, the DBX utility is useful in finding only known problems within a child process. The DBX

utility does not search for unknown problems within the child process. Further, since the DBX

utility operates in one address space while the child program operates in a different address space, the interaction between the two spaces requires a full context switch to the operating system and the utility is slow in operation and also resource intensive.

Unfortunately, many problems that occur within an executable program are neither

easily detected nor easily correlated with and underlying programming error. In the case of memory errors, wherein the memory is improperly used by the instructions within the computer software program, manifestations of the error oftentimes do not become apparent until hours or days after execution of the error has occurred. Thus, in this situation, even though a programmer is cognizant of a particular problem that has resulted during execution of a program, he or she will be unable to correlate the particular problem with respective erroneous instructions within the computer software program.

Thus, other programs have been developed in an attempt to identify memory errors within computer programs. One technique used by various programs in an attempt to discover memory allocation and usage errors is to surround an applicable block of memory associated with the program with a "guard band. " Periodic examination of the guard band indicates whether a memory overwrite error has been executed by the program under examination. However, the use of the guard band does not indicate when improper reads, improper

allocations, or improper deallocations have been performed by the program under examination.

Thus, the use of the guard band around an allocated portion of memory does not fully indicate the possible ranges of errors that have been implemented by the program under examination.

Further, the use of a guard band does not indicate at what point in time or in what context the

guard band has been overwritten by the program under examination.

Another utility developed to de-bug computer programs is called PURIFY, manufactured by Pure Software, Inc. The PURIFY utility operates on an executable program by reading the executable program, locating all load and store instructions within the program under examination, inserting diagnostic instructions immediately before the load and store instructions to alter the program under examination and writing the altered program under examination to a disk for storage. After the modified program is written to permanent storage, it may then be loaded into memory and run to produce diagnostic output to aid in the de- bugging of the program. Unfortunately, because the PURIFY utility operates on each of the executable routines and subroutines in the program under examination, the modified program written to disk is excessively large and takes up great storage capacity. Further, because the

PURIFY utility receives user instructions only prior to its commencing the modification of the

program under examination, it will operate in accordance with the user instructions throughout its operation and cannot be altered by user input while running.

Another shortcoming of the PURIFY utility relates to the manner in which code is rewritten and executed. A default execution mode of the PURIFY utility is in the address space of the program under examination or "target" . Inserted instructions which validate instructions that affect memory, i.e. reads and writes (these instructions are referred to as " validation instructions") save the volatile state of the target to memory before performing the

validation. Thus, during execution, the utility performs a context switch to a validation state widiin which the validation instructions are be executed, execute the validation instructions, report errors if appropriate and restores the volatile state of the target. On an Intel Corporation

Pentium architecture machine, approximately 80% of the instructions in any given target

require validation. In a PowerPC architecture machine, manufactured by Motorola and IBM, approximately 40% of all instructions require validation in any given target. In a PowerPC architecture machine, saving and restoring the volatile state of the processor ("switching contexts") requires approximately 46 instructions. Thus, the number of instructions added by

the PURIFY utility is large and execution of the modified target often takes 100 times as much time compared to execution of the unmodified target.

Other utilities operate on source code in an interpretive matter to provide diagnosis on the source code itself. However, these source code diagnostics do not operate upon library

routines that may be called by the source code. Thus, problems related to calls to the library routines as well as problems with the library routines themselves, will not be discovered by the interpretive source code based utilities. Further, the utilities that operate upon source code tend to be slow in operation because of their interpretive nature and the significant overhead required in the operation on source code.

These and other objects of the invention will be apparent from examination of the drawings and remainder of the specification which follows. SUMMARY OF THE INVENTION

The present invention relates to a system and associated method of operation for

determining operational characteristics of a computer software program. The method includes

as a first step, loading an executable program into a memory of a computer. The executable program includes a plurality of blocks of executable code. A parent process already loaded will load the executable program into memory in the same address space of the computer. In

this fashion, the parent process may operate on the child process, which is the executable

program under investigation, in the same address space with minimal context switching.

Next, the method includes deteirnining an entry point for each block of executable code within the executable program. Once the entry points are determined, instructions are written to gain control at the entry points, and then the execution of the executable program is initiated. When each entry point is reached, diagnostic code is selectively written into memory wherein the diagnostic code reports an operational characteristic of the executable program. After the diagnostic code has been written, execution of the executable program continues which causes the diagnostic code to be executed in conjunction with the execution of the particular executable

block. In this fashion, the diagnostic instructions indicate errors or events of interest resulting from the execution of the executable block. Such errors or events are reported to a user.

Thus, the method of the present invention provides a run time diagnostic that only writes diagnostic instructions for those portions of the executable program that will be run just prior to the execution of the executable block. In this fashion, minimal processing time is required and diagnostic constraints may be tailored based upon a user's input.

Another embodiment of the present invention emulates operation of the executable program by emulating the state that would be created and maintained by the executable program during its execution. At startup, an emulator loads the executable program into memory and allows the executable program to initialize the machine state. The emulator takes

control from the executable program and commences its operation. In one embodiment, the

emulator repeatedly generates or retrieves emulation code blocks for respective segments of the executable program and executes the emulation code blocks to emulate operation of respective portions of the executable program. In another embodiment, the emulator generates emulation

code for the complete executable program at one time and writes the resultant code to disk for execution at a later time. In either case, the emulator emulates operation of the executable program in virtual register space to allow the emulator to operate without context switches. By avoiding context switches and operating on the executable program in the virtual register space,

execution times are substantially reduced.

Thus, the present invention avoids time intensive context switches from an execution state to a validation state. A first embodiment of the present invention performs minor state saves when performing validation functions: Another embodiment of the present invention

operates in a validation state as a default and emulates operation of the target on a virtual machine state and memory. By avoiding the context switches, the present invention allows for a substantial improvement in execution times over prior verification utilities.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a logic diagram illustrating a method for determining operational characteristics of a computer software program in accordance with the present invention;

FIG. 2 is a logic diagram illustrating an alternative method for deteπriining operational characteristics of a computer software program in accordance with the present invention;

FIG. 3a is a logic diagram illustrating in more detail step 202 of the method of FIG. 2;

FIG. 3b is a logic diagram illustrating in more detail step 204 of the method of FIG. 2;

FIG. 3c is a logic diagram illustrating in more detail step 206 of the method of FIG. 2;

FIG. 3d is a logic diagram illustrating in more detail step 212 of the method of FIG. 2; FIG. 4 is a logic diagram illustrating the execution of medium context switch instructions written in accordance with substep 250 of FIG. 3c and diagnostic instructions written in accordance with substep 262 of FIG. 3d;

FIG. 5 is a logic diagram illustrating the execution of a light weight context switch

instructions written in accordance with substep 250 of FIG. 3c and diagnostic instructions written in accordance with substep 262 of FIG. 3d;

FIG. 6 is a logic diagram illustrating particular diagnostic code written by the parent

process in accordance with the present invention;

FIG. 7 is a logic diagram illustrating another alternative method for deteιτnining operational characteristics of a computer software program in accordance with fhe present

invention;

FIG. 8 is a block diagram illustrating a data processing system in accordance with the

present invention; FIG. 9 is a block diagram illustrating a correlating system that correlates a reported

operational characteristic of the executable program with a corresponding portion of a

respective source code file in accordance with the present invention;

FIG. 10 is logic diagram illustrating an alternative embodiment of a validation method of the present invention wherein a virtual register set is established and maintained for the

executable software program while validating operation of the executable software by

emulating operation of the executable software program on the virtual register set and memory;

FIG. 11 is a logic diagram illustrating steps for initiating operation of a routine used to validate operation of the executable software program such that control is gained by a parent process that performs the validation;

FIG. 12 is a logic diagram illustrating steps for discovering a volatile state of the executable software program after control has been gained by the emulator that performs the validation;

FIG. 13 is a logic diagram illustrating steps for fetching and creating emulation code fragments, each emulation code fragment emulating operation of one or more instructions of the executable software program when executed;

FIG. 14 is a logic diagram illustrating steps for determining whether validation

instructions are required for any of the instructions contained within the executable software program and for generating the validation instructions if they are required; FIG. 15 is a logic diagram illustrating steps taken in executing of a block of emulation code, the block of emulation code containing a prologue, at least one emulation code fragment

and either an epilogue or a branch to additional emulation code fragments; FIG. 16 is still another embodiment of the present invention that verifies operation of an executable software program by rewriting the executable software program to maintain a virtual register set to disk and executing the rewritten executable software program; and

FIG. 17 is a block diagram illustrating a data processing system that operates upon an executable software program to verify the operation of the executable software program, the data processing system maintaining a virtual register set to allow the data processing system to operate in a default execution state wherein validation functions are executed.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates a method 100 for deteirnining operational characteristics of a computer software program. The method is implemented on a computer of a type that is

known in the art that includes a processor, memory, mass storage, input/output, buses for

communication amongst the components, input/output devices that allow input from a user, and

other components that are known in the art. The method of the present invention may run on any architecture type and the description herein provided is not limited to any particular architecture. While the teachings of the present invention may be implemented in various manners depending upon the particular system upon which the method would run, certain

descriptions are provided herein for explanation purposes only and do not limit the teachings of the present invention.

The method 100 commences at step 102 of loading an executable program into a

memory of a computer. The memory is of a type known in the art and the loading occurs in a

manner that is also known in the art. Those skilled in the art will readily appreciate that the loading of an executable program into memory may be performed in any number of manners to accomplish a common goal.

The method 100 next moves to step 104 of examining an instruction. Step 104 is performed by a parent process running in the same address space as the executable program, or child process, that has been previously loaded into memory in step 102. Thus, any interaction between the parent process and the child process may be implemented without any intervention

by the operating system. Without intervention of the operating system, the efficiency of the method 100 of the present invention operates in significantly streamlined manner as compared to prior art systems. Upon a first execution of step 104, the parent process examines a first instruction within the executable program. After the instruction has been examined at step 104, it is determined at decision step

106 whether the instruction is of interest. Typically, the decision is based upon user input that

indicates the types of characteristics the user wishes to investigate. For example, the user may

wish to look at memory allocation, de-allocation, write, and read operations that could erroneously affect the contents of the memory. In this situation, upon execution of the parent process, the user instructs the parent process to investigate these types of memory allocation

and usage characteristics. Based upon the user input, the parent process determine which types of instructions are of interest to the process.

If at step 106 the instruction is of interest, the method 100 proceeds to step 108 and replaces the instruction of interest with a branch instruction to a diagnostic location within memory. This diagnostic location within memory resides in close proximity to the portion of the executable program that is under investigation so that a branch relative instruction may be used to branch to the diagnostic location.

After step 108, the method proceeds to step 110 of writing diagnostic instructions and a

branch instruction at the diagnostic location. In conjunction with step 110, the method includes writing instructions for saving at least a portion of a state of the computer. The diagnostic

instructions also include instructions for examining at least a portion of the state of the computer, reporting an operational characteristic of the executable program based on the examining, restoring the portion of the state of the computer, executing the instruction of interest, and branching back to the executable program at a location immediately following the instruction of interest. By examining at least a portion of the state of the computer and having

knowledge of what type of instruction the instruction of interest is, it may be determined whether execution of the instruction of interest will cause an event of a type that the user desires to be informed of. From step 110, and from step 106 if the answer was no, the method proceeds to step

112 where it is determined whether the last instruction has been examined. If the last

instruction has not been examined, the method returns to step 104 where a subsequent instruction is examined. However, if the last instruction has been examined at step 112, the

method proceeds to step 114 wherein the executable program, including the additional

diagnostic instructions, is executed. Upon the execution of the program including the diagnostic instructions written in step 114, the method 100 determines whether or not the execution of the instructions of interest cause an actual problem in the operation of the program. Such information is reported to the user in a fashion that allows the user to determine

which instructions caused the error or event and to alter the instructions.

Thus, the method 100 of the present invention provides the important benefit of performing diagnostics on the executable program while operating fully within a single address

space. Further, the method 100 of the present invention provides the important benefit of only

writing diagnostic instructions as directed by the user. User input may be altered at any time during execution of the method so that the scope of diagnostic instructions written changes. Thus, the method 100 of the present invention performs a superior investigation of the operational characteristics of the computer software program with a significantly reduced overhead and run time.

FIG. 2 illustrates an alternative method 200 for determining operational characteristics of a computer software program. The method 200 commences at step 202 of loading an executable program into a memory of a computer. The executable program includes a plurality of blocks of executable code. As one skilled in the art will readily appreciate, the blocks of executable code could comprise a main portion of a computer program, subroutines, functions, procedures, or various blocks of executable code that are known in the art. The blocks of executable code could be contained within the executable program that is loaded into the

memory of the computer or could be contained within shared libraries which are referenced by

the executable program.

From step 202, the method proceeds to step 204 of determining an entry point for each block of executable code. These entry points correspond to particular memory locations to which a program calling the executable block of code transitions when it calls the block of executable code. As one skilled in the art will readily appreciate, upon a transition to a

particular executable block, a computer's program counter may be provided with a respective address for the particular executable block so that execution will proceed at the executable

block.

Next, at step 206, the method 200 includes replacing entry point instructions for each block of executable code with branches to a controlling process. This controlling process is the

parent process that is running in the same address space as the executable program which is referred to as the child process. Because the parent process and the child process operate in the same address space, control may be passed between the parent and the child without

intervention from the operating system, significantly reducing the overhead required to perform the investigation of the operation of the executable program.

Next, from block 206, the method proceeds to block 208 of commencing execution of

the executable program. Commencing the execution of executable program is known in the art and can comprise simply the step of inserting the entry point of the executable program into the program counter of the particular computer system on which the executable program is located.

Next, at step 210, it is determined whether or not an entry point has been reached. Such a determination may be easily made since at each entry point a branch instruction to the controlling process has been inserted. If an entry point has not been reached at step 210, the method proceeds to step 214 wherein execution is continued in the executable program or child

process. However, if at step 210 it is determined that an entry point has been reached the

method proceeds to step 211 where the method branches to the parent process.

At step 211, the method 200 includes allocating a region within memory for the insertion of diagnostic instructions. The allocation of memory locations is known in the art and

will not be further described herein except to expand on the principles of the present invention.

Next, the method proceeds to step 212 wherein diagnostic instructions are selectively written into the allocated region within memory. These diagnostic instructions will selectively report an operational characteristic of the executable program upon their execution. The

particular types of instructions written will be determined both by the user input that defines events of interest and the type of instructions contained in the executable block whose entry point has been reached. Thus, step 212 writes diagnostic instructions for the complete executable block associated with the entry point reached.

From step 212, the method proceeds to step 214 of continuing execution of the executable program. Upon the execution of step 214, the diagnostic instructions as well as instructions inherent within the executable program will be executed. During this step 214, the diagnostic instructions written into the diagnostic region in memory report whether events of interest have occurred in the execution of the executable program. The diagnostic instructions may also report such things as memory allocation errors, code coverage, memory access tracing, and code performance depending upon user input.

Additional instructions could be inserted between step 214 and step 216 that would delete the diagnostic instructions and deallocate the diagnostic region associated with the entry point. Such steps, if performed, would reduce the memory requirements of the method 200. These steps could be dependently performed based on the total memory consumed by the method or could be performed after each execution of instructions. As one skilled in the art will readily appreciate, the operation of the method 200 of the present invention may be tailored for particular user requirements.

Next, at step 216, it is determined whether or not the process is complete. If the process is not complete, the method returns to step 210. However, if the method is completed at step 216 the method ends.

Thus, the method 200 illustrated in FIG. 2 provides the important benefit of writing

diagnostic code only for those portions of the executable program that will be executed. Thus, the overhead associated with the method 200 of the present invention as compared to prior art devices is significantly reduced. Further, because the parent process implemented in accordance with the method 200 of the present invention dynamically manipulates the child process, it can respond dynamically to changes in user input while the process is executing. This additional benefit will allow a programmer to investigate only those portions of the

executable program of particular interest. FIG. 3a illustrates, in more detailed fashion, step 202 of FIG. 2. Step 202 begins at substep 220 wherein a particular module of the executable program is read into memory. The method then proceeds to substep 222 wherein a data structure is established for each particular module that is read into memory. This structure will include information describing the text data, table of contents (TOC), BSS, and other information associated with the executable module. The data structures in substep 222 are established by the parent process for the parent process' later use in manipulating the child process.

From substep 222 the method proceeds to substep 224 where it is determined whether

all modules required for the execution of the child process have been loaded. A module consists of either the executable program that is loaded from disk or a library module which is also loaded from disk. If all modules have not been loaded, the method proceeds from substep

224 back to substep 220 to read another module into memory. However, if at substep 224 it is

determined that all modules have been loaded, the method proceeds to substep 226.

At substep 226 a data area for each module is established. These data areas will include all necessary segments for the execution of the particular modules. For example, in one

particular application the data area would include a data area, a BSS area, a text area, and a table of contents (TOC) area. In substep 226, the data area values are established that will enable the respective module to run.

From substep 226 the method proceeds to substep 228 of adjusting all relative addresses

within the modules. Normally, the loader, upon loading an executable program into memory, determines addresses within the executable modules that were previously indexed relative to a particular starting point or entry point. However, because the method 200 of the present invention does not use a loader, it must perform substep 228 to adjust the relative addresses to

point to the locations in memory where the data areas for the particular modules are located. Next, at substep 230, the method includes establishing external symbol addresses. As is known in the art, executable modules refer to data items which exist in other executable modules. A mechanism for accomplishing such references is to name the data items with alpha-numeric identifiers. These alpha-numeric identifiers are then used to match import requests from particular load modules with exports from other load modules. Substep 230 insures that the symbols will properly be identified and indexed for access during execution.

Thus, the substeps of step 202 set up the executable modules within memory so that they may execute in conjunction with the method 200 of the present invention. The substeps of step 202 operate similarly to a loader. However, step 202 performs the substeps in a manner which allows the parent process to investigate the structure of the executable modules, track the structure, and later operate on the executable modules to determine their operational characteristics.

FIG. 3b illustrates substeps associated with step 204 of FIG. 2. As is recalled, step 204

of FIG. 2 includes determimng entry points for each block of executable code loaded into the memory of the computer. Substep 232 includes reading a first or next module data structure. The module data structure includes the symbol table, which contains information about all the symbols within the executable module, including C-sect information, entry point information,

and other optional information dependent upon the particular module and the particular compilation process used in accordance with method of the present invention. Indexing of the module data structures has previously been performed so that the parent process may read the data structures. In one embodiment of the present invention, the symbol table is part of a previously existing module data structure. However, in another embodiment of the present invention, a symbol table is created and/or an existing symbol table is modified as part of

substep 232 and then operated upon after its creation. From substep 232, the method step 204 proceeds to substep 234 wherein the a symbol,

first or next, is read from the module data structure. Each symbol contains information that allows the parent process to determine whether the location in the module corresponding to the symbol is an entry point. Thus, substep 234 reads the information associated with the symbol

that allows this determination to be made. Next, at substep 236, it is determined whether the symbol corresponds to an entry point for an executable block. If the symbol corresponds to an entry point, the method proceeds to substep 238 wherein the symbol and the corresponding location are added to the entry point

list. However, if at substep 236 it was determined that the symbol does not correspond to an entry point, the method proceeded to substep 240. From substep 238 the method proceeded to substep 240 where it is deteπnined whether the investigation of the particular module and the symbols within the module has been

completed. If the investigation has not been completed, the method proceeds from substep 234

wherein additional symbols are investigated. However, if at substep 240 it is deteπnined that

the module has been completely investigated, the method proceeds to decision substep 242. At decision substep 242 it is determined whether all modules have been investigated. If all modules have not been investigated at substep 242 the method returns to substep 232 where

another module data structure is read and operated upon. However, if at substep 242 it is determined that all modules have been investigated, the method proceeds from step 204 according to the method of FIG. 2.

Thus, the substeps of step 204 illustrated in FIG. 3b illustrate how the method 200 of

the present invention locates the entry points within each of the executable module of the

executable program. The entry points of the executable modules will be used in accordance with further steps of the method of the present invention as will be fully described hereinafter. FIG. 3c illustrates substeps associated with step 206 of FIG. 2. As is recalled, step 206

of FIG. 2 includes replacing entry point instructions with branches to the controlling process. As has been previously been described, the controlling process is also referred to as the parent process and occupies the same address space as the executable program or child process.

As a first substep in step 206, substep 244 includes saving the entry point instruction for

the particular entry point. Next, substep 246 includes allocating a memory location for context switch instructions. Next, the method proceeds to substep 248 where the particular entry point instruction is replaced with a branch instruction that directs the process to the respective context switch instruction location allocated in substep 246. Thus, upon an execution of the branch instruction at the location that had previously had the entry point instruction, the process

switches or branches to the respective context switch instruction location.

Next, substep 250 includes writing context switch instructions at the respective context switch instruction location. The context switch instructions include instructions for switching to the context of the parent process and allow the parent process to gain control at the particular execution point. These context switch instructions may include either light weight context

switch instructions or medium context switch instructions to be further described herein. However, the context switch instructions will not include full context switch instructions as would be required to move to a differing address space, such as the one occupied by the

operating system.

Thus, the substeps associated with step 206 place context switch instructions within the executable computer software program that, during execution, allow the process to switch from the child process to the parent process in the same address space in a streamlined manner.

FIG. 3d illustrates in more detail the substeps associated with step 212 of the method 200 of FIG. 2. As is recalled, step 212 involves writing diagnostic instructions at a diagnostic location within memory, the diagnostic instructions determining an operational characteristic of

the executable program.

As a first substep of step 212, substep 252 includes replacing the branch to the context switch instructions with the entry point instruction that was removed in step 206 and as was previously described with reference to substep 248 of FIG. 3c. Because control has already

been transferred to the controlling process via the execution of the branch instruction in step 208 of FIG. 2, the branch instruction may be replaced. Thus, substep 252 undoes the substitution of the branch instruction inserted in step 206. Thus, the next time that the entry

point for the executable block is reached, it will not automatically branch to the parent process but will perform the instructions written in accordance with step 212 of FIG. 2. Thus, in

accordance with the method 200 of FIG. 2, the diagnostic instructions written in step 212 of FIG. 2 are written only for those executable blocks to be executed.

Referring again to FIG. 3d the method proceeds to substep 254 of examining an

instruction, first or next, within the executable block. The method then proceeds to decision substep 256 where, based upon user input, it is determined whether the instruction is currently of interest. As has been previously discussed, based upon user input, certain instructions within the executable block may cause errors or events of interest when executed and are

determined to be instructions of interest on that basis. At substep 256 it is deteιτnined whether the particular instruction is of interest based upon the current user input. Because user input may be changed at will by the user, during the execution of the method 200 of the present invention, the criterion used in substep 256 may change. Thus, substep 256 provides for the

alteration of criterion by the user during the running of the method 200.

If at substep 256 the instruction is not currently of interest, the method proceeds to substep 264 where it is determined whether the current instruction is the last instruction in the executable block. However, if at substep 256 it is determined that the instruction is currently of interest, the method proceeds to substep 258.

At substep 258, a diagnostic location is allocated within memory for the particular instruction of interest. The location within memory that is allocated is in close proximity to the instruction of interest. The close proximity of the diagnostic location within memory allows a branch relative instruction to be executed to the diagnostic location without exceeding the outer limits of the branch relative instruction. However, as one skilled in the art will readily

appreciate, in different situations, the requirement of close proximity may neither be required

nor desirable. From substep 258 the method proceeds to substep 260 of replacing the instruction of

interest with a branch to the diagnostic location within memory. This branch instruction as

well as other branch instructions used in accordance with the present invention will be branch relative instructions. Next, at substep 262, diagnostic instructions are written in the diagnostic location within memory. These diagnostic instructions, as have been previously discussed, when executed will determine operational characteristics of the executable computer software

computer program located in memory. Diagnostics available include memory allocation diagnostics, memory read/write diagnostics, performance diagnostics, and code coverage diagnostics, memory access tracing diagnostics, such diagnostics useful in diagnosing the

operation of the executable computer program.

From substep 262, method step 212 proceeds to substep 264 where it is determined whether the currently investigated instruction is the last instruction in the executable block. If

the current instruction is not the last instruction in the executable block, the method proceeds to

substep 254 wherein the next instruction in the executable block is examined. Thus, the substeps incorporated into step 212 of the method 200 of the present invention provide the important benefits of selectively inserting diagnostic instructions based upon a user input only into those executable blocks about to be executed. Thus, the diagnostic instructions

selectively look at certain characteristics of the program. Because the diagnostic instructions are only written for a particular executable block of the executable program that is about to be executed, overhead and processing time are minimized. Further, since the user may selectively

alter the criterion at any point in time, the diagnostic instructions that must be written to

perform the paπicular goal of the user are also minimized.

FIG. 4 illustrates the execution 300 of medium weight context switch instructions written in accordance with substep 250 of FIG. 3c and diagnostic instructions written in accordance with substep 262 of FIG. 3d. In accordance with the execution 300, a medium

context switch is performed between the child process, or executable software program, and the parent process, or diagnostic program. The particular execution 300 will occur as a subset of

step 214 of FIG. 2. Thus, the execution 300 is shown to illustrate how context switches in

accordance with the run-time aspect of the method 200 of the present invention are performed.

The execution commences at substep 302 wherein the branch to the diagnostic location is executed. Next at substep 304 the stack is pushed to create a stack frame to save all or a part of a current state of the computer. As is known in the art, the use of a stack may be had to

temporarily allocate storage locations in a simplified manner. Next, at substep 306, the

complete volatile state of the computer is saved in the stack frame. The volatile state will include any information which may be altered while the parent process' diagnostic routines are functioning. Thus, the volatile state stored in the stack frame represents the state of the computer at the point when the child process branched to the diagnostic location associated with the instruction of interest.

Next, substep 308 calculates a target address of the instruction of interest that was replaced with the branch instruction. In a particular scenario, the target address corresponds to the memory location that will be operated upon by the instruction of interest.

Next, substep 310 branches to a diagnostic function within the parent process and passes the target address to the parent process. Then, substep 312 executes the diagnostic function within the parent. The diagnostic function uses the target address and determine

whether or not the execution of the instruction of interest with the target address will generate an event of which the user has expressed an interest in learning. The diagnostic function is one of many designed to operate in conjunction with differing types of instructions of interest. By operating in conjunction with differing instructions of interest, the diagnostic instructions generate differing event reports, reporting on differing events.

Next, substep 314 restores the volatile state of the computer from the stack frame.

Thus, the state in which the computer was in when it branched to the diagnostic location has been restored. Next, substep 316 pops the stack to its prior address. As one skilled in the art will readily appreciate, popping the stack simply points the stack pointer back one position.

Next, substep 318 executes the instruction of interest that was replaced with the branch instruction. Then, substep 320 branches to an instruction at a location within the executable block immediately following the instruction of interest so that execution within the executable software program is continued beyond the particular instruction of interest.

Depending upon the instruction of interest, parameters other than the target address will be determined and a different diagnostic function will be called than the one illustrated in

conjunction with FIG. 4. Thus, by passing different parameters between the child process and the parent process and by selectively calling different diagnostic functions within the parent

process, different operational characteristics of the child process may be determined. For example, for diagnosis of stack operations, parameters relating to the stack pointer are passed and a function is called that investigates stack operations. As one skilled in the art will readily

appreciate, differing operational characteristics of the executable program may be investigated by writing diagnostics relating to particular instructions or types of instructions and by selectively passing desired parameters back and forth between the parent process and the child

process.

Thus, the substeps of execution 300 perform a medium context switch wherein a portion of the state of the computer is saved before switching to the parent process. This medium context switch requires significantly less processing resources than a full context switch to the operating system, and allows the diagnosis process to operate in an efficient

manner. Because the parent, or diagnostic, process and the child process operate in the same process space, a partial context switch may be performed in accordance with the present invention without corrupting the operation of the computer. After a diagnostic function has been completed for a block of executable code, the

diagnostic instructions written for the block may be deleted and the memory deallocated. Such an operation would be possible after step 216 in FIG. 2, for example. Such an operation could also be performed, at least partially, after substep 318 of FIG. 4. In either case, computer resource usage would be decreased by deallocating those portions of memory that were

previously allocated but would not further be used.

FIG. 5 illustrates the execution 350 of light weight context switch instructions written in

accordance with substep 250 of FIG. 3c and diagnostic instructions written in accordance with

substep 262 of FIG. 3d. In accordance with the execution 350, a light weight context switch is

performed between the child process, or executable software program, and the parent process, or diagnostic program. The particular execution 350 will occur as a subset of step 214 of FIG. 2. Thus, the execution 350 is shown to illustrate how context switches in accordance with the run-time aspect of the method 200 of the present invention are performed.

First, at substep 352, the execution includes executing the branch instruction to the diagnostic location. This branch instruction had been inserted at substep 260 illustrated in FIG. 3d. Thus, the diagnostic location is in close proximity to the executable block currently being executed so that a branch relative instruction may be used.

Next, substep 354 pushes the to create a stack frame. At substep 356 a partial volatile state is stored in the stack frame created in substep 354. This partial volatile state saves just enough operational room to determine whether a medium weight context switch is warranted. Next, at substep 358, the program branches to local diagnostic instructions written within the child text segment. These particular local diagnostics instructions were written at substep 262 of method step 212 illustrated in FIG. 3d. Next, at substep 360, the local

diagnostics are run.

At decision substep 362 it is determined whether or not the local diagnostics have generated an error. If no error is generated, it is determined that no error in execution or event

of interest has occurred and the user need not be notified via a reporting and execution proceeds to substep 370.

However, if substep 362 generates an error, execution proceeds to substep 364 wherein the remaining volatile state is stored in the stack frame. Then, execution proceeds to substep

366 wherein a branch to the parent diagnostics is performed. The particular branch instruction executed at substep 366 will be determined based upon user input and the particular instruction

of interest from which execution has branched.

From substep 366 the execution proceeds to substep 368 wherein the remaining volatile state of the computer is restored. Such remaining volatile state had been previously stored in the stack frame in substep 356. Next, at substep 370, the partial volatile state is also restored such that in conjunction with substep 368 nearly the full volatile state of the computer has been restored to its condition prior to the branch instruction of substep 352.

Next, at substep 372, the stack is popped such that the stack pointer is decremented by

the stack frame size. As one skilled in the art will readily appreciate, the complete state of the computer cannot be restored until the stack pointer has been popped in substep 372. Such is

the case because the volatile state of the computer has been stored in the stack and the

decrement of the stack pointer would cause this volatile state to be lost. Thus, after substep 372, the complete state of the computer is restored to its condition when the branch instruction

was executed in substep 352.

Next, at substep 374, the instruction of interest that was replaced with a branch

instruction is executed. From substep 374, execution proceeds to substep 376 wherein the program branches to an instruction immediately following the replaced instruction location.

Thus, the execution steps 350 executed in accordance with the instructions written in substep 250 of FIG. 3c and substep 262 of FIG. 3d allow for a light weight context switch

when such is possible. However, when a light weight context switch is not possible, the substeps 350 cause a medium weight context switch to be performed. Thus, the execution substeps 350 provide for reduced processing in context switching when such is possible.

FIG. 6 illustrates a particular diagnostics instruction 400 within the parent process that

determines whether or not a memory location has been violated. As is known in the art, a memory map may be used in a manner such that two bits represent the state of any particular data location in memory. The data location may comprise any data width, but the data width of the present embodiment corresponds to the particular system. A first bit in the memory map represents whether or not the data block is available to be written and the second bit associated with the data block represents whether or not the data block is available to be read. Thus, the memory map will having two unique bits for each particular data block represents fully the state of those memory addresses stored in the memory map. At substep 402 it is determined whether or not the target address is stored in a memory map. If it is not, processing is bypassed and no reporting is performed. If the target address is in the memory map, the method proceeds to substep 404 that deteraiines whether the operation

on the target address will violate the memory map state. Substep 404 determines whether the current state of the bits within the target address of the memory map are in a state such that the execution of the instruction of interest on the address is valid. If the operation violates the

memory map state, the method proceeds to substep 406 wherein it notifies the user of the particular violation. Generally, in this scenario, the instruction of interest will be a load or store instruction that will either read from memory or write to memory, respectively. Thus, if

a particular memory block has not been allocated, as indicated by a first status bit, the block cannot be written to. If the second status bit indicates that the memory block has not previously been written to, then the memory block cannot be read. Thus, the determination in step 404 may be made based upon the memory map, the target address, and the type of

instruction of interest. If at substep 404 the operation does not violate the memory map state the method proceeds to substep 405 wherein the memory map is selectively updated based upon the particular instruction of interest that will be performed. For example, if the instruction of interest writes to a writable memory block, the memory map is updated.

Thus, the steps 400 of FIG. 6 illustrate a simplified method in which a diagnostic instruction executed by the parent application may determine whether or not an instruction of interest if executed will violate a particular memory constrained in the system. In this fashion,

memory errors that were previously unresolvable until they surfaced or became apparent in another fashion may be identified simply by executing the method 200 of the present invention. In this fashion, the de-bugging of particular computer software programs is more easily

accomplished and more efficiently accomplished than was possible with prior art devices.

FIG. 7 illustrates an alternative method 410 for determining operational characteristics of a computer software program in accordance with the present invention. The method commences at substep 412 where a diagnostic program is loaded into memory in a address

space. Next, at substep 414, an executable program is also loaded into memory into a same address space as the diagnostic program. Next, at substep 416, the method includes initiating the execution of the executable program. Such substep has previously been described with reference to the figures and will not be described further herein.

At substep 418, the method includes selectively gaining control of the executable program to determine its operational characteristics. In gaining control of the executable program, branch instructions will be inserted into the executable program that branched to the diagnostic program. At the diagnostic program, diagnostic routines are executed to determine

the operational characteristics.

Next, at step 420, the method includes selectively resuming execution of the executable program. The selective resumption of execution shall be done in accordance with the diagnosis

previously performed in substep 418. From substep 420 the method proceeds to substep 422 where it is determine whether the operation is completed. If the operation is not completed, the method returns to method substep 418. However, if the method is completed, the method

ends.

Thus, the method illustrated in FIG. 7 performs the important advantage of loading the diagnostic program and the executable program into a common address space in a computer. Because of the common address space constraint, the parent may examine the operation of the child with πώiimal overhead and context switching. Such context switching will be performed

only as required so as to minimize the overall processing requirements of the method. The various embodiments of the present invention may include steps to implement code coverage, memory access tracing, program performance, and memory leak detection in accordance with methods known in the art. For example, code coverage may be determined by

tracking which executable portions of the executable software program are executed. The parent process constructs a table to track such execution and updates the table as the portions of the executable program are executed. Such a feature could be implemented in conjunction with

step 212 of FIG. 2. Program performance could be determined by tracking the execution of particular segments of code and reporting such to the user. Instructions could be inserted in step 110 of FIG. 1 to perform such a function. Further memory leaks may be determined by a

"garbage collection" process that is known in the art and could easily be implemented in conjunction with the present invention.

Memory access tracing could be performed by setting respective memory map locations

to indicate that read or write operations are not permitted and creating a table that identifies

which memory locations have been so set. Upon the receipt of an error relating to the access of the respective memory, instead of recording an error for the access, a record of the access is reported to the user. Such a record indicates at what point and in what context the memory

access has occurred, thus providing a trace of the memory accesses to the user.

The present invention may also incoφorate block tracing. As is known in the art, block tracing investigates the execution path of a particular process. Typically, block tracing routines produce a tree-structure type report that indicates which executable blocks are performed during execution. Alternatively, block tracing produces a tree-structure type report that

indicates the executable block call structure of an executable program. The present invention includes block tracing capabilities as well as the ability to execute selective block tracing. With

selective block tracing, the present invention allows a user to select which blocks are to be reported or to select blocks not to be reported. The selected blocks may be altered during

execution such that the block tracing report is tailored to a user's particular needs.

FIG. 8 illustrates a data processing system 450 in accordance with the present

invention. The data processing system 450 comprises a processor 452, a processor bus 454,

memory 456, and an input/out interface 460. The data processing system 450 includes a local video interface 450 for interfacing a local video display to the processor bus 454. An

input/output port 460 connects to a hard disk storage or other bulk storage 464 via a peripheral bus 462 and couples the peripheral bus 462 to the processor bus 454. The components of the

data processing system 450 are known in the art and may be operated in conjunction with various architectures and software operating systems.

The memory 456 includes instructions for performing a number of substeps. The substeps include loading an executable program into a memory of a computer. The executable

program includes a plurality of blocks with executable codes that may be executed by the data processing system 450 of the present invention. The memory 456 also stores instructions for

determining an entry point for each block of executable code within the executable program.

The memory 456 also stores instructions for commencing the execution of the executable

program. Further, memory 456 stores instructions for selectively writing diagnostic code into the memory 456 that reports an operational characteristic of the executable program upon execution. Such diagnostic code is written for each entry point that is reached within the

executable program. Finally, the memory 456 stores instructions for executing the diagnostic code in conjunction with a respective block of the executable code.

In this fashion, the data processing system 450 of the present invention may operate upon executable programs stored within its memory 456 to alter the structure of the executable program within a same address space to diagnose the operation of the executable program. Unlike other processes which operate on executable code and writes it to the hard disk 464, or

other permanent storage devices, the data processing system 450 of the present invention performs self-modifying code that significantly streamlines the diagnostic process on the

executable program. Thus, the data processing system 450 of the present invention provides important advantages that were not previously realized in conjunction with diagnostic utilities. FIG. 9 illustrates a correlating system 500 included in the present invention. The

correlating system 500 correlates a reported operational characteristic of the executable program with a corresponding portion of a respective source code file. For example, the correlating system 500 may list in a first display certain operational characteristics as selected

by the user. As illustrated, the operational characteristics comprise a plurality of errors 502 detected by the present invention within the executable software program. These errors may include error 1 504 and error 2 506 through error N 508. Each of these errors corresponds to at least one erroneous instruction or instructions within the executable software program. The

errors displayed provide the user with sufficient detail to allow the user to determine what type of source code instruction or instructions caused the error.

The correlating system 500 also displays the corresponding portion of the respective source code file 503 in conjunction with the reported operational characteristic of the

executable program. For example, if error 1 504 is selected, the correlating system 500 displays a section of source code 510 that correlates to the particular error. The user may then enter the source code window 503 and edit the source code to correct the error.

In accordance with the correlating system of FIG. 9, the present invention provides a

complete solution for detecting operational characteristics of an executable program, reporting the characteristics to the user, correlating the characteristics to particular source code instructions of a corresponding source code file, and allowing a user to correct the source code

instructions all in a run-time environment.

FIG. 10 is logic diagram illustrating in general an alternative embodiment of a validation method 600 of the present invention wherein a virtual register set is maintained for

the executable software program ("target") while validating operation of the target. The method 600 is embodied in a computer software program executable on a digital computer an operating in accordance with the method steps herein described. As one will appreciate, the method 600 could be practiced on a digital computer specifically constructed to perform the

steps of the method or on a general purpose computer programmed to perform the methods of

the method 600. In either case, the digital computer would accomplish the steps herein disclosed and described.

An emulation program or process (hereinafter "emulator") operates as a parent process

gaining control of the executable target without allowing the target to execute. The emulator

then inteφrets the target, writes emulation code based upon the target to perform validation functions and either executes the emulation code or writes the emulation code to disk storage for later execution. In the method 600 of FIG. 10, the emulator writes emulation code blocks for instructions in the target to be executed and executes the emulation code immediately after

writing the emulation code blocks. However, in another embodiment that will be later described herein, the emulation code blocks are written to disk as created for the complete target and the emulation code blocks are executed at a later time.

The method 600 commences at step 620 wherein the target is loaded into main memory of the digital computer implementing the method 600 without initiating execution of the target. In the embodiment illustrated, an operating system loader is employed to load the target into memory. Upon loading, the target commences operation by initializing the computer system.

However, Immediately after the target initializes the computer system, the emulator gains control of the computer system. As will be further described herein, the emulator gains control

through the insertion of a branch instruction into the target prior to loading the target. When the target executes the branch instruction, it branches to the emulator.

At step 604, the method 600 then determines the virtual machine state via investigation of the computer system and the target and writes the virtual machine state to memory. Determining the initial target state includes determining the contents of all non-volatile registers

for the particular processor. Once the virtual register values are discovered, they are stored in dedicated memory for further use. These registers are referred to as a virtual register set

("VRS").

The method 600 next proceeds to step 606 wherein a block of emulation code is fetched

based upon the registers of the VRS. In particular, the instruction pointer of the VRS is employed to fetch a block of emulation code. As is recalled, the instruction pointer of the VRS was initially determined and stored at step 604. As an initial value, the instruction pointer of

the VRS points to a first non-initialization instruction of the target that would have been executed had the emulator not inserted the branch instruction. Thus, at step 606, the emulator retrieves the value of the instruction pointer and fetches a block of emulation code corresponding to the instruction pointer. The block of emulation code may emulate not only the instruction in the target referenced by the instruction pointer of the VRS but a sequence of instructions starting at the instruction pointer. The one or more instructions for which emulation code is fetched at step 606 are referred to as a "segment" of instructions. During normal execution of a target application, instructions are executed in order until a jump

instruction, a branch instruction or another instruction that causes the instruction pointer to be altered in a non-incremental fashion. Thus, a segment of instructions executed sequentially in

order may be emulated with a single block of emulation code. In the embodiment described, the emulator creates all blocks of emulation instructions

during its execution. Thus, at the first iteration of step 606, an emulation code block corresponding to the instruction pointer must be generated and returned. However, during

additional iterations of step 606 wherein the instruction pointer equals its value during a prior iteration, the emulation code block need only be fetched since it was created during a prior

iteration of step 606.

Next, step 608 includes executing the fetched block of emulation code. During

execution of the fetched block of emulation code, the emulator emulates execution by the target of the particular instructions for which emulation code was fetched in step 606. Thus, at each iteration of step 608 a particular segment of the target code is emulated, such emulation

emulating one or more instructions of the target. Execution of step 608 causes the VRS and the

memory operated upon by the target to updated just as the machine register set and memory would have been updated during execution of the equivalent instructions in the target. However, the emulator has inserted validation instructions into the emulation code block that

are also executed to determine whether memory accesses made in the equivalent target instructions are valid. Resultantly, by executing the emulation code, the added instructions detect memory errors and leaks. The emulation code also keeps track of requests made to the operating system to manage memory, i.e. allocations, frees, reallocations that affect later memory accesses .

From step 608, the method 600 determines whether a termination condition has been met at step 610. During normal operation, an instruction pointer value of zero indicates that a termination condition is met and the method 600 is done. Typically, a termination condition is

met after complete execution of the target. Other embodiments, however, could selectively execute portions of target by terminating at the initiation of user.

FIG. 11 is a logic diagram illustrating steps for accomplishing step 602 of FIG. 10. At step 620, the emulator, or parent process, inserts a begin emulation instruction into the target immediately after an initialization block in the target. The begin emulation instruction, when executed, gains control of the execution of the target transfers control of the target process to the emulator. In the embodiment illustrated, the begin emulation instruction is a branch

instruction to an entry point in the emulator. Next, at step 622, the emulator launches the target application. The emulator employs the operating system to begin execution of the

modified target executable in a standard load operation. Once execution of the target has

commenced, and the branch instruction is reached, execution branches to the emulation routine

at the designated entry point. At this point, control has been transferred from the target application to the emulator.

FIG. 12 is a logic diagram illustrating steps for discovering a volatile state of the

executable software program after control has been gained by the parent process that performs

the validation in accordance with step 604 of FIG. 10. As a first step 630, the emulator allocates a virtual register set in memory. In the illustrated embodiment executed on a Pentium processor manufactured by Intel Coφoration, the EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI, EIP and EFLGS registers comprise the VRS. Of these registers, ESP, EBP, ESI, EDI and EIP are non-volatile registers while the others are volatile registers. In the described embodiment, 40 bytes are allocated for the VRS.

Next, at step 632, the emulator queries the CPU and inteφrets the stack to discover the

machine state in order to determine the values of the VRS. As is recalled, the emulator established control immediately after the target initialized the state of the computer system on which it was loaded. Thus, at step 632, the emulator discovers the initialized state of the

machine corresponding to the target. Next, at step 634, the emulator records the non-volatile state of the machine into the VRS, i.e. copy information discovered at step 632 into the VRS. As previously described, the registers ESP, EBP, ESI, EDI and EIP are non-volatile registers and their contents are therefore copied into the VRS. Thus after completing the steps of 602,

the initialized non-volatile state of the target application is stored in the VRS. FIG. 13 is a logic diagram illustrating steps for fetching and creating emulation code

fragments in accordance with step 606 of FIG. 10, each emulation code fragment emulating

operation of one or more instructions of the executable software program (a segment of instructions) when executed. At step 640, the emulator hashes the virtual instruction pointer or

EIP of the VRS. The illustrated embodiment uses a standard hash lookup in an attempt to find

a corresponding entry in a hash table created for this puφose. The hashing function employed with the illustrated embodiment logically ANDs the value of the virtual instruction pointer with a value corresponding to the number of bits in the hash table. As is recalled, the virtual instruction pointer points to an instruction in the target application. Thus, even though the

emulator is using the actual instruction pointer in its own operation, the virtual instruction pointer points to the next instruction in the target to be emulated by the emulator.

If an entry is found for the virtual instruction pointer in the hash table, operation proceeds from step 642 to step 662. However, if at step 642, no entry is found in the hash

table for the virtual instruction pointer, the emulator proceeds to step 644 wherein memory is allocated for a new emulation block to be created, the new emulation code block corresponding to the value of the virtual instruction pointer. The amount of memory allocated depends upon the instruction in the target to which the virtual instruction pointer points (instruction of interest

or "IOI". In the embodiment illustrated, an initial amount of memory is first allocated. However, the allocation is then incrementally increased as additional storage is required for adding additional emulation code to the fragment.

Next, at step 646, the emulator writes prologue code to the emulation code block. Prologue code instructions, when executed, update the stack of the emulator and write a pointer to the VRS onto the stack for use by the emulator in creating the emulation code block. Next, at step 648, the emulator reads the IOI from the target application. In the described embodiment operable on a Pentium class machine, the IOI comprise one of a number of

lengths. Step 648 reads the instruction so as to retrieve the complete IOI but not neighboring

instructions. At this step, the emulator may allocate additional memory for the emulation code

block based upon the type of IOI retrieved and its projected emulation block fragment size. Then at step 650, the emulator creates an emulation code fragment for the target IOI.

The emulation code fragment is a group of instructions that (1) prepare arguments for calling a memory access validation function if necessary, and (2) emulate the effects of the original

instruction on the VRS and memory. Depending upon the IOI of the target, the emulation code fragment could comprise as few as three instructions or up to fifty instructions. Of course, if

the IOI affects memory, a greater number of instructions are required that not only emulate the effect of the IOI on the VRS but determine whether the IOI performs a valid memory access and reports when an invalid memory access has been performed.

Next, at step 652, the emulator adds the generated emulation code fragment to the emulation code block. At this point, the emulator may also expand the emulation code block as

necessary to contain the new information. Then, at step 654, the emulator determines whether the instruction at the current virtual instruction pointer is the last target instruction for the emulation block. Blocks are terminated upon reaching a branch or jump instruction. Blocks may also be terminated upon a return or call instruction. As previously described, emulation

code blocks emulate single instructions in the target or segments of instructions in the target that will be executed in succession each time the target executes the first instruction in the segment of instructions. If at step 654 it is determined that the current IOI is not the last instruction in the target for the emulation block, the emulator updates the virtual instruction pointer at step 656 and returns to step 648 to continue constructing the emulation block. At step 658, the emulator writes epilogue code to the emulation code block. The epilogue includes whatever code is necessary to clean up the machine state during the execution

of the emulation code block. Typically, the epilogue varies for each emulation code block. Instructions that may be included in any epilogue include instructions for popping the stack and updating the virtual instruction pointer. Next, at step 660, the method includes adding the emulation code block to the hash table in a manner known in the art so that the next time the

value of the virtual instruction pointer is hashed, the hash table indexes the emulation code block created. Thus, the next time a block fetch is made at this virtual instruction pointer, it will succeed without having to create a new emulation code block. Finally, at step 662, the

emulator returns the emulation code block for execution.

FIG. 14 is a logic diagram illustrating steps taken by the emulator to determine whether validation instructions are required for any of the instructions contained within the executable software program and for writing the validation instructions if they are required, such steps an

expansion of the step 650 of FIG. 13. At step 692, the emulator determines whether the IOI of the target to which the virtual instruction pointer points reads or modifies memory. If the IOI does read or modify memory, the emulator proceeds to step 694. However, if the step does not read or modify memory, the emulator proceeds to step 698. At step 694, the emulator writes instructions that prepare validation arguments that will be used by the validation instructions. These arguments are specific for the particular IOI referenced by the virtual instruction pointer. Next, at step 696, the emulator writes validation instructions that, when executed, perform memory validation using the arguments prepared in step 694. Then, at step 698, the emulator

writes instructions that, when executed, simulate the effect of the IOI on the virtual register set and memory. Following are two examples of emulation code blocks that emulate the operation of the instructions within the target that are executable on a Pentium class machine. Each of the

examples includes a prologue for the particular emulation code fragment. In the embodiment

illustrated, each emulation code fragment may include additional prologue instructions that prepare the computer on which the emulator operates for execution of the emulation code fragment.

EXAMPLE 1

Instruction of Interest: move EAX, [EBX + 0x20]

Emulation Code Fragment: push EBP (beginning of prologue) mov EBP, ESP mov EAX, [EBP + 4] (end of prologue) mov ECX, [EAX + OxC] (beginning of fragment; [EAX + 0x10] points to the location of the EBX virtual register within the within the

VRS) mov EDX, [ECX + 0x20] mov [EAX + 0x0], EDX ([EAX + 0x0] points to the location of EAX virtual register within the VRS)

EXAMPLE 2

Instruction of Interest: push EAX Emulation Code Fragment:

push EBP (beginning of prologue) mov EBP, ESP mov EAX, [EBP + 4] (end of prologue)

sub [EAX + 0x10], 0x4 ([EAX + 0x10] points to the ESP within the VRS)

mov ECX, [EAX + 0x0] ([EAX + 0x0] points to EAX within the VRS mov EDX, [EAX + 0x10] (copy new value of ESP into EDX) mov [EDX], ECX (store the contents of ECX (the value of VRS- > EAX) at

EDX (VRS- > ESP))

Each of these examples includes instructions for emulating operation of on IOI of the target upon the VRS. Thus, operation of the target may be emulated within the emulator address space. Other target application instructions, as opposed to those of Example 1 and

Example 2 require the validation of memory reads or modifications. As described with reference to step 694, the emulator writes validation instructions that perform memory validation. A group of validation instructions which perform the memory validation is typically referred to as a "validation function". Validation functions are known in the art and are typically specific to the instructions being operated upon as well as the machine upon which the instructions execute. In a described embodiment of the present invention, the emulator operates upon the x86 instruction set by Intel. However, in other embodiments, the emulator

may operate upon the PowerPC by Motorola and International Business Machines, MIPs, SPARC by Sun Computer Systems, Inc.. ALPHA by Digital Equipment Coφoration, Hewlett- Packard chip sets, and other instruction sets that may be developed. For each IOI, the emulator uses a common set of library routines to create a fragment which emulates the effect of the instruction on the VRS and memory, such fragment often times

including a validation function. In the present embodiment for the x86 instruction set, the

library set consists of approximately 200 to 800 library routines. Each library routine contains code that receives a pointer to the IOI (in most cases the virtual instruction pointer) and the routine operates based upon the IOI itself and the data passed to it, including op codes, pointers, flags, addresses, offsets and other parameters. Some IOIs share common library

routines, i.e. some ADD and SUB instructions that operate on common registers and have common arguments. However, the form of the parameters to a particular instruction may require information be passed to the library function to enable it to properly create the fragment. Based upon these variables, the emulator creates both validation functions and

instructions that emulate operation of the target upon the VRS. The emulator creates validation functions that operate in conjunction with a memory bit map to determine whether IOIs properly operated upon memory or erroneously operated upon memory. Memory bit maps that provide bookkeeping functions for memory are known in the art as is the interaction between

verification functions and the memory bit maps.

FIG. 15 is a logic diagram illustrating execution of a block of emulation code, the block of emulation code containing a prologue, at least one emulation code fragment and either an epilogue or a branch to additional emulation code fragments. At block 670, the emulator executes a prologue in the emulation block. By executing the prologue, the emulator prepares for execution of the emulation code fragments that emulate operation of the target within the

virtual register space. Execution of the prologue typically pushes the stack and secures a

pointer to the VRS. Steps 672 through 678 execute individual emulation code fragments within the emulation code block. These fragments validate the operations performed on memory by the original IOIs and simulate the effects of the IOIs on the VRS and memory. Finally, at

block 680, the emulator executes the epilogue in the emulation block. Execution of the epilogue typically pops the stack pointer, pops the stack and returns control to the emulator.

Execution of the epilogue may also update the instruction pointer so that execution branches directly to me prologue of an emulation block that corresponds to the newly updated instruction pointer. With reference to FIG. 10, instead of returning to the emulator lookup stage of step 606, execution may branch to an emulation code block that already exists for the

newly updated instruction pointer value. Thus, step 606 of FIG. 10 may be bypassed simply by updating the instruction pointer accordingly. FIG. 16 is a logic diagram illustrating another embodiment of the present invention that

verifies operation of an executable software program by rewriting the executable software

program to maintain a virtual register set. The method 700, as opposed to the previous embodiment, writes emulation code to disk instead of immediately executing the emulation code as written. Execution commences in the method 700 with the emulator reading an

executable target into memory at step 702. The details of step 702 are accomplished substantially in accordance with those steps detailed in FIG. 11. Next, the emulator reads the next instruction from the target at step 704. The emulator accomplishes this steps by simply indexing to the next instruction in the target application. If the emulator determines that the memory would be affected by execution of the instruction at step 706, the emulator proceeds to step 708. However, if the emulator determines that memory would not affected by execution of the indexed instruction, the emulator proceeds to step 712.

At step 708, the emulator writes instructions to create arguments necessary to validate

the effects on memory by the indexed instruction. Once these arguments are created, the emulator writes the instructions to call a validation function at step 710. The validation function is then written with the arguments so that when it is performed, it validates the effect

of the instruction on memory. Next, the emulator writes instructions that emulate the effect of the instruction on the VRS at step 712. Steps 708, 710 and 712 are performed substantially in

the same manner as those steps discussed with respect to FIGs. 13 and 14 as previously

described. These emulation instructions are written to memory and stored in memory in the embodiment described. However, in other embodiments, the instructions may be written directly to hard disk storage.

At step 714, the emulator determines whether the currently indexed instruction is the

last instruction in the target. If it is not, the emulator returns to step 704 wherein the next instruction is read from the target. Thus, not until all instructions of the target have been investigated will the emulator cease writing emulation code fragments. When the emulator determines that the current instruction is the last instruction in the target, it proceeds to step

716 where the emulator writes instructions that manage the memory map and the virtual registers. Next, at step 718, the emulator adjusts all altered indexes, jumps offsets and references. Because the emulator rewrote the target with additional instructions, indexes, offsets and references in the rewritten code are erroneous. Thus, the emulator reindexes each and every one of these indexes, offsets and references to indicate the location of the corresponding code. Thus, when the emulation code operates, it will function substantially as the target functioned, except that it operates upon the virtual reference set and self performs validation functions. Finally, at step 720, the emulator writes the resulting executable to disk

720.

Thus, when a user executes the resulting executable, the executable performs validation

of the target application. As opposed to the embodiment of FIGs. 10 through 15, the

embodiment of FIG. 16 performs a complete construction of the emulation code prior to execution. The embodiment of FIGs. 10 through 15 generated emulation code as needed and didn't necessarily create emulation code for the complete target.

As was previously described, prior art validation programs, such as the PURE utility performed full context switches at each validation function. Emulation of the instructions of the target were significantly faster than a context switch, so much so that, even though every instruction of the target must be emulated in accordance with the embodiment of the present

invention, the emulation and validation combination is significantly more efficient than the context switch and validation combination.

FIG. 17 is a block diagram illustrating a data processing system 800 that operates upon an executable software program to verify the operation of the executable software program

The data processing system 800 maintains a virtual register set to allow the data processing system to operate in a default execution state wherein validation functions are executed. The data processing system 800 comprises a processor 802, memory 804, disk storage 806, a user

interface 808 and a processor bus 810. The processor 802 comprises a Pentium class processor in the described embodiment and includes a plurality of registers 822 within the processor 802. At initialization of the target, the emulator retrieves the non-volatile of these registers 822 to create the VRS. Memory comprises a stack 812, emulator memory 814, virtual register set memory 816, the executable target 818 and executable target memory 820.

During execution of the steps of the methods of FIGs. 10 through 16, the processor 802 loads the executable target into executable target memory 818, alters the executable target and

then launches the executable target. The executable target initializes the state of the data processing system 800 and the emulator then regains control. The emulator, using emulator memory 814 discovers the state of the data processing system 800 and stores the state in the VRS memory 816 and emulator memory 814. The emulator then constructs and executes the emulation code within its own process space, operating upon the VRS and executable target memory 820 while operating in the execution space of the emulator.

As is evident from the description that is provided above, the implementation of the

present invention can vary greatly depending upon the desired goal of the user. However, the scope of the present invention is intended to cover all variations and substitutions which are and which may become apparent from the illustrative embodiment of the present invention that is provided above, and the scope of the invention should be extended to the claimed invention

and its equivalents. It is to be understood that many variations and modifications may be effected without departing from the scope ofthe present disclosure.

Claims

Claims:

1. A method for determining operational characteristics of a computer software program,

the method comprising the steps of:

(a) loading an executable program into a memory of a computer;

(b) selectively identifying at least one instruction of interest within the executable program;

(c) for each instruction of interest, selectively replacing the instruction of interest with a branch instruction that causes a branch to a diagnostic location within memory, the diagnostic location containing diagnostic instructions for:

(i) saving at least a portion of a state of the computer;

(ii) examining at least a portion of the state of the computer;

(iii) based on the examining, selectively reporting an operational characteristic of the executable program;

(iv) restoring the portion of the state of the computer;

(v) executing the instruction of interest; and

(vi) branching back to the executable program at a location immediately following the instruction of interest; and

(d) commencing execution of the executable program.

2. The method of claim 1 , wherein the steps of selectively identifying at least one instruction of interest and selectively replacing the instruction of interest are selectively

executed based upon user input.

3. The method of claim 1, further comprising the step of: (e) allocating memory for the diagnostic location.

4. The method of claim 1, further comprising the step of:

(e) determining a portion of the executable program about to be executed,

wherein the steps of selectively identifying at least one instruction of interest and selectively replacing the instruction of interest are performed only for the portion of the executable program about to be executed.

5. The method of claim 1 , further comprising the step of: (e) replacing the branch instruction with the instruction of interest.

6. The method of claim 5, further comprising the step of:

(f) deleting the diagnostic instructions.

7. The method of claim 1, wherein an operational characteristic is selected from the group

consisting of code coverage, memory access tracing, and program performance.

8. The method of claim 1, wherein an operational characteristic is used to identify and report errors in the operation of the executable program, wherein errors in the operation

of the executable program are selected from the group consisting of memory allocation errors, memory deallocation errors, memory write errors, memory read errors, and

memory leak errors.

9. The method of claim 1, wherein loading an executable program into a memory of a computer includes loading a plurality of executable blocks into memory.

10. The method of claim 9, further comprising the step of:

(e) determining an entry point of each of the executable blocks.

11. The method of claim 9, wherein the steps of selectively identifying at least one instruction of interest and selectively replacing the instruction of interest are performed only for executable blocks about to be executed.

12. The method of claim 9, further comprising the step of:

(e) allocating a diagnostic location in memory for each of the executable blocks.

13. The method of claim 12, further comprising the step of: (f) deallocating at least one diagnostic location in memory.

14. The method of claim 9, wherein the operational characteristic comprises block tracing and wherein the method includes the step of:

(e) generating a block tracing report, wherein the block tracing report traces an execution of the executable blocks.

15. The method of claim 14, wherein the block tracing report includes only selected executable blocks.

16. The method of claim 14, wherein the block tracing report includes only non-selected executable blocks.

17. The method of claim 1, further comprising the step of:

(e) determining at least one instruction of interest type based on an operational characteristic selected by a user, wherein the selectively identifying is based on the instruction of interest type.

18. The method of claim 1 , further comprising the step of: (e) correlating a reported operational characteristic of the executable program with a corresponding portion of a respective source code file.

19. The method of claim 18, further comprising the step of:

(f) displaying the corresponding portion of the respective source code file in conjunction with the reported operational characteristic of the executable

program.

20. A method for determining operational characteristics of a computer software program, the method comprising the steps of:

(a) loading an executable program into a memory of a computer, the executable program including a plurality of blocks of executable code; (b) determining an entry point for each block of executable code;

(c) for each entry point, replacing an entry point instruction within a respective

block of executable code with a branch to a controlling process;

(d) commencing execution of the executable program;

(e) for each entry point reached, selectively writing diagnostic code in memory for a respective block of executable code that reports an operational characteristic of the executable program upon execution; and

(f) executing the diagnostic code in conjunction with the respective block of

executable code.

21. The method of claim 20, wherein the step of writing diagnostic code in memory comprises the substeps of:

(i) selectively identifying at least one instruction of interest within the respective block of executable code;

(ii) for each instruction of interest, selectively replacing the instruction of interest with a branch instruction that causes a branch to a diagnostic location within memory, the diagnostic location containing diagnostic instructions for: saving at least a portion of a state of the computer; examining at least a portion of the state of the computer; based on the examining, selectively reporting an operational characteristic of the executable program; restoring the portion of the state of the computer;

executing the instruction of interest; and

branching back to the respective block of executable code at a location immediately following the instruction of interest.

22. The method of claim 21, wherein the steps of selectively identifying at least one instruction of interest and selectively replacing the instruction of interest are selectively executed based upon user input.

23. The method of claim 21, further comprising the step of:

(e) replacing the branch instruction with the instruction of interest.

24. The method of claim 21 , further comprising the step of:

(f) deleting the diagnostic instructions.

25. The method of claim 21 , further comprising the step of: (g) allocating memory for the diagnostic location.

26. The method of claim 24, further comprising the step of:

(h) deallocating at least one diagnostic location in memory.

27. The method of claim 21 , further comprising the step of: (g) determining at least one instruction of interest type based on an operational characteristic selected by a user, wherein the selectively identifying is based on the instruction of interest type.

28. The method of claim 21 , further comprising the step of:

(g) correlating a reported operational characteristic of the executable program with a corresponding portion of a respective source code file.

29. The method of claim 28, further comprising the step of: (h) displaying the corresponding portion of the respective source code file in conjunction with the reported operational characteristic of the executable

program.

30. The method of claim 20, wherein an operational characteristic is selected from the group consisting of code coverage, memory access tracing, and program performance.

31. The method of claim 20, wherein an operational characteristic is used to identify and report errors in the operation of the executable program, wherein errors in the operation of the executable program are selected from the group consisting of memory allocation

errors, memory deallocation errors, memory write errors, memory read errors, and memory leak errors.

32. The method of claim 20, wherein the operational characteristic comprises block tracing

and wherein the method includes the step of: (g) generating a block tracing report, wherein the block tracing report traces an execution of the executable blocks.

33. The method of claim 32, wherein the block tracing report includes only selected executable blocks.

34. The method of claim 32, wherein the block tracing report includes only non-selected executable blocks.

35. A method for determining operational characteristics of a computer software program, the method comprising the steps of:

(a) loading a diagnostic program into a memory of a computer in a address space;

(b) loading an executable program into the memory in the address space; and

(c) executing the diagnostic program, wherein the diagnostic program performs the substeps of:

(i) initiating execution of the executable program;

(ii) selectively gaining control from the executable program to determine

operational characteristics of the executable program; and (iii) selectively resuming execution of the executable program.

36. The method of claim 35, wherein the step of selectively gaining control from the executable program to determine operational characteristics of the executable program

comprises the substeps of:

selectively identifying at least one instruction of interest within the executable program; for each instruction of interest, selectively replacing the instruction of interest with a branch instruction that causes a branch to a diagnostic location within memory, the diagnostic location containing diagnostic instructions for:

saving at least a portion of a state of the computer;

examining at least a portion of the state of the computer; based on the examining, selectively reporting an operational characteristic of the executable program;

restoring the portion of the state of the computer;

executing the instruction of interest; and branching back to the executable program at a location immediately following the instruction of interest.

37. The method of claim 36, wherein the steps of selectively identifying at least one instruction of interest and selectively replacing the instruction of interest are selectively executed based upon user input.

38. The method of claim 36, further comprising the step of: (d) allocating memory for the diagnostic location.

39. The method of claim 36, further comprising the step of:

(d) deteirnining a portion of the executable program about to be executed, wherein the steps of selectively identifying at least one instruction of interest and selectively replacing the instruction of interest are performed only for the poπion of the executable program about to be executed.

40. The method of claim 36, further comprising the step of:

(d) replacing the branch instruction with the instruction of interest.

41. The method of claim 36, further comprising the step of:

(e) deleting the diagnostic instructions.

42. The method of claim 36, further comprising the step of:

(d) allocating a diagnostic location in memory for each of the executable blocks.

43. The method of claim 36, further comprising the step of:

(e) deallocating at least one diagnostic location in memory.

44. The method of claim 35, wherein an operational characteristic is selected from the group consisting of code coverage, memory access tracing, and program performance.

45. The method of claim 35, wherein an operational characteristic is used to identify and

report errors in the operation of the executable program, wherein errors in the operation of the executable program are selected from the group consisting of memory allocation

errors, memory deallocation errors, memory write errors, memory read errors, and

memory leak errors.

46. The method of claim 35, wherein loading an executable program into a memory of a computer includes loading a plurality of executable blocks into memory.

47. The method of claim 46, further comprising the step of:

(d) determining an entry point of each of the executable blocks.

48. The method of claim 46, wherein the steps of selectively identifying at least one instruction of interest and selectively replacing the instruction of interest are performed only for executable blocks about to be executed.

49. The method of claim 46, wherein the operational characteristic comprises block tracing and wherein the method includes the step of:

(d) generating a block tracing report, wherein the block tracing report traces an

execution of the executable blocks.

50. The method of claim 49, wherein the block tracing report includes only selected executable blocks.

51. The method of claim 49, wherein the block tracing report includes only non-selected executable blocks.

52. The method of claim 36, further comprising the step of:

(d) determining at least one instruction of interest type based on an operational

characteristic selected by a user, wherein the selectively identifying is based on the instruction of interest type.

53. The method of claim 35, further comprising the step of:

(d) correlating a reported operational characteristic of the executable program with a corresponding portion of a respective source code file.

54. The method of claim 53, further comprising the step of:

(e) displaying the corresponding portion of the respective source code file in

conjunction with the reported operational characteristic of the executable program.

55. A data processing system comprising: processor, wherein the processor executes instructions; processor bus operably coupled to the processor; input/output interface operably coupled to the processor bus, wherein the input/output interface allows a user to interface with the processor; and memory operably coupled to the processor bus, wherein the memory stores instructions

for:

loading an executable program into the memory;

selectively identifying at least one instruction of interest within the executable

program; for each instruction of interest, selectively replacing the instruction of interest

with a branch instruction that causes a branch to a diagnostic location within memory, the diagnostic location containing diagnostic instructions for: saving at least a portion of a state of the processor; examining at least a portion of the state of the processor; based on the examining, selectively reporting an operational

characteristic of the executable program; restoring the portion of the state of the processor; executing the instruction of interest; and

branching back to the executable program at a location immediately following the instruction of interest; and commencing execution of the executable program.

56. A data processing system comprising: processor, wherein the processor executes instructions; processor bus operably coupled to the processor; input/output interface operably coupled to the processor bus, wherein the input/output

interface allows a user to interface with the processor; and memory operably coupled to the processor bus, wherein the memory stores instructions for: loading an executable program into the memory, the executable program including a plurality of blocks of executable code; determining an entry point for each block of executable code; for each entry point, replacing an entry point instruction within a respective

block of executable code with a branch to a controlling process; commencing execution of the executable program; for each entry point reached, selectively writing diagnostic code in memory for a respective block of executable code that reports an operational characteristic of the executable program upon execution; and executing the diagnostic code in conjunction with the respective block of executable code.

57. A data processing system comprising: processor, wherein the processor executes instructions;

processor bus operably coupled to the processor;

input/output interface operably coupled to the processor bus, wherein the input/output interface allows a user to interface with the processor; and memory operably coupled to the processor bus, wherein the memory stores instructions for: loading a diagnostic program into the memory in a address space; loading an executable program into the memory in the address space; executing the diagnostic program, wherein the diagnostic program performs the

steps of: initiating execution of the executable program; selectively gaining control from the executable program to determine

operational characteristics of the executable program; and

selectively resuming execution of the executable program.

58. A computer readable medium, wherein the computer readable medium includes

instructions for:

(a) loading an executable program into a memory of a computer;

(b) selectively identifying at least one instruction of interest within the executable program; (c) for each instruction of interest, selectively replacing the instruction of interest with a branch instruction that causes a branch to a diagnostic location within

memory, the diagnostic location containing diagnostic instructions for:

(i) saving at least a portion of a state of the computer; (ii) examining at least a portion of the state of the computer;

(iii) based on the examining, selectively reporting an operational characteristic of the executable program;

(iv) restoring the portion of the state of the computer; (v) executing the instruction of interest; and (vi) branching back to the executable program at a location immediately following the instruction of interest; and

(d) commencing execution of the executable program.

59. A computer readable medium, wherein the computer readable medium includes

instructions for:

(a) loading an executable program into a memory of a computer, the executable program including a plurality of blocks of executable code;

(b) determining an entry point for each block of executable code;

(c) for each entry point, replacing an entry point instruction within a respective block of executable code with a branch to a controlling process;

(d) commencing execution of the executable program; (e) for each entry point reached, selectively writing diagnostic code in memory for

a respective block of executable code that reports an operational characteristic of the executable program upon execution; and

(f) executing the diagnostic code in conjunction with the respective block of

executable code.

60. A computer readable medium, wherein the computer readable medium includes instructions for:

(a) loading a diagnostic program into a memory of a computer in a address space; (b) loading an executable program into the memory in the address space; and

(c) executing the diagnostic program, wherein the diagnostic program performs the

substeps of:

(i) initiating execution of the executable program;

(ii) selectively gaining control from the executable program to determine operational characteristics of the executable program; and

(iii) selectively resuming execution of the executable program.

61. A method for determining operational characteristics of a computer software program,

the method comprising the steps of:

(a) loading an executable program into a memory of a computer; (b) determining an initial state of the computer created by loading the executable program; (c) storing the initial state in a virtual register set; and (d) for a segment of instructions of the executable program, creating emulation instructions that, when executed, emulate operation of the executable program on the virtual

register set to verify memory usage.

62. The method of claim 61 , further comprising the step of:

(e) executing the emulation instructions to emulate operation of the executable

program on the virtual register set to verify memory usage.

63. The method of claim 62, further comprising the step of:

(f) repeating steps (d) and (e) for a plurality of segments of instructions of the

executable program.

64. The method of claim 61, wherein emulation instructions are created for only a portion of the instructions of the executable program.

65. A method for determining operational characteristics of a computer software program, the method comprising the steps of:

(a) loading an executable program into a memory of a computer;

(b) determining an initial state of the computer created by loading the executable program;

(c) storing the initial state in a virtual register set; and

(d) for each instruction of interest of the executable program, creating emulation instructions that, when executed, emulate operation of the executable program on the virtual register set to verify memory usage.

66. The method of claim 65, further comprising the step of:

(e) executing the emulation instructions to emulate operation of the executable program on the virtual register set to verify memory usage.

67. The method of claim 65, wherein emulation instructions are created for only a portion of the instructions of the executable program.

68. A computer readable medium, wherein the computer readable medium includes instructions for:

(a) loading an executable program into a memory of a computer;

(b) determming an initial state of the computer created by loading the executable program;

(c) storing the initial state in a virtual register set; and

(d) for a segment of instructions of the executable program, creating emulation instructions that, when executed, emulate operation of the executable program on the virtual

register set to verify memory usage.

69. A computer readable medium, wherein the computer readable medium includes

instructions for:

(a) loading an executable program into a memory of a computer; (b) determining an initial state of the computer created by loading the executable

program;

(c) storing the initial state in a virtual register set; and (d) for each instruction of interest of the executable program, creating emulation

instructions that, when executed, emulate operation of the executable program on the virtual

register set to verify memory usage.

70. A data processing system comprising:

processor, wherein the processor executes instructions;

processor bus operably coupled to the processor; input/output interface operably coupled to the processor bus, wherein the input/output interface allows a user to interface with the processor; and memory operably coupled to the processor bus, wherein the memory comprises:

a stack; executable target portion into which an executable target is loaded; executable target memory portion; virtual register set portion to store a virtual register set; and

emulator instruction portion that stores an emulator that generates blocks of emulator code that, when executed, emulate the operation of the executable target on the virtual register set and the executable target memory portion.