KR100303188B1 - Method and apparatus for measuring code coverage of embedded software on a traget hardware platform - Google Patents

Abstract

PURPOSE: A method and device for analyzing a computer program is provided to interpret a computer program including a plurality of modules. CONSTITUTION: A programmer selects a portion of a computer program as an instrument(300). The code selected by the programmer is instrumented(310). The programmer instruments one module in a computer program for creating one instrumented module. The other modules out of a plurality of modules are not instrumented. The programmer combines the codes which are not selected for the instrument with the instrumented code(320). A code not including the total program is collected, and an object code is manufactured, and the code is linked for forming an available computer program(330). An available computer program is returned by combining code portions(340).

Description

METHOD AND APPARATUS FOR MEASURING CODE COVERAGE OF EMBEDDED SOFTWARE ON A TRAGET HARDWARE PLATFORM

TECHNICAL FIELD The present invention relates to the field of software development, and more particularly, to a method and apparatus for interpreting execution of a computer program. Moreover, the present invention relates to a method and apparatus for generating data that is responsible for branch coverage testing a selected portion of a computer program.

As computer programs become larger and more complex, the importance of software development programs increases. Software development programs enhance programmers' ability to develop computer programs efficiently and quickly.

An important and time consuming step in computer program development is the testing phase. In order to fully test a computer program, a programmer must ensure that each of the modules that make up the entire program are tested.

It is difficult to test each module of a computer program because some modules run under exceptional circumstances. For example, a spreadsheet program may have five modules that run continuously under normal operating conditions, and five other modules that execute only when certain conditions exist within the computer. If the program was tested under normal operating conditions, five modules would run completely, but five other modules would probably not be tested at all.

To correct this situation, programmers create multiple test programs to test and recreate an exceptional environment that runs five modules that normally do not run. However, creating these conditions can be difficult. For example, it is difficult for a computer program under test to simulate certain conditions when run in an embedded microcontroller— embedded microcontrollers are processing units that do not have some special form of general purpose microprocessors. In order to know if the test programs are efficient, the program needs to have feedback from the computer program under test to indicate that the modules are running.

The above situation becomes more difficult if the computer program being developed is intended to run on a processor that is structurally different from the processor running the software development programs. For example, a series of software development programs designed to run on an Intel type processor may include computer program development that will be compatible with a Zilog type processor. In this situation, the computer program being developed cannot be run on the same processor as the software development program. This indicates that a software development program is almost useless in determining the performance of a computer program scheduled to be run by a Zilog processor.

Another part of computer program development is known as program maintenance. In some cases, program maintenance refers to the ongoing segmentation and expansion of a computer program after the initial version is distributed to users. It is important to know the specific environment in which a computer program is running in order to know how to best segment and extend the computer program after it is distributed. For example, a computer program may be running in a way that the programmer could not have predicted. Therefore, it is useful to receive data from a computer program a few hours after distribution to determine under what circumstances the computer program was running. By interpreting this data, the programmer knows where to spend time optimizing a computer program. As a result, most important modules are efficiently optimized, while less important modules are not fully optimized.

Conventional software development programs exist for development programs to be run on the same type of processor as the processor executing the software development program. However, as noted above, these software development programs are of little use in a development program designed to run on a processor that is structurally different from the processor running the software development programs. In addition, these conventional software development programs do not work well in a multi-tasking environment due to the complexity of collecting execution data when several tasks are running simultaneously.

Currently available software development programs also exist for generating and collecting data from a program that is scheduled to run on a processor that is structurally different from the processor on which the software development program runs. However, these software development programs allow the programmer to specify which parts of the computer must generate data and which parts do not. These software development programs must specify that too much data must be generated, which causes problems in data collection and interpretation.

If a computer program is too instrumented, it can adversely affect the performance of the entire computer program. When a processor executing a computer program reaches a portion of a computer program containing instrumented code, the processor needs time to execute the instrumented code (code inserted by the software development program and generating executable data). . This is the time normally spent executing application code (not instrumented code). Most processors have sufficient processing power to execute both the instrumented and application code without significantly impacting the performance of the computer program. However, if there is too much instrumented code, the processor will spend too much time executing this instrumented instrumentation code and generating corresponding data, resulting in unacceptable performance of the entire computer program. Thus, by being able to select specific portions of the instrumented computer program, the effect of the instrumented metrology code can be kept to a minimum.

Thus, it is advantageous to have a software development program for generating and collecting performance and debugging data from certain portions of a computer program. In particular, it is advantageous to have a software development program capable of collecting and generating data from a program running on a processor that is structurally different from the processor running the software development program. This software development program can function efficiently in a multitasking environment. Moreover, it is also advantageous for software development programs that collect data over a period to indicate how a computer program is actually running. It is also useful to allow programmers to examine this data to determine the effectiveness of test programs that execute various modules of every program.

The present invention provides a method and apparatus for interpreting a computer program comprising a plurality of modules. First, the module to be included in the computer program includes additional lines of code added to it so that it is an instrumented module. Additional lines of code will generate data to help programmers develop computer programs more efficiently. Instrumented modules are combined with others, ie uninstrumented modules, to form computer programs that may be running in a data processing system. The computer program then runs. Instrumented modules generate data when executed by a processor in a data processing system. This data is passed to a data processing system capable of interpreting the data, and as a result of this interpretation, the programmer can examine the performance and execution characteristics of the computer program to develop the computer program more efficiently.

1 is a perspective view of a data processing system to which the present invention can be applied;

2 is a block diagram of the data processing system shown in FIG. 1 showing various components of the data processing system according to the present invention;

3 is a flow chart for making an executable computer program according to the present invention;

4A is a flowchart for executing an executable computer program and collecting information from the executable computer program according to the present invention;

4B is a perspective view of a table used to store data generated by the instrumented code;

5 is a perspective view of a computing system that can implement the present invention;

6 is a configuration diagram of a computer program running in a target data processing unit;

7 is a structural diagram of a single threaded process that enables the present invention to generate data in a multitasking environment.

* Explanation of symbols on the main parts of the drawing

502, 504, 506: data processing system 508: target data processing unit

602, 604, 614, 616: instrumented modules

606, 616, 622: uninstrumented modules

610, 618: buffer

These and additional objects, forms, and advantages of the present invention will become apparent from the following detailed description.

Referring to the accompanying drawings, in particular FIG. 1, there is shown a data processing system 10 in which the present invention is implemented. As shown in the figure, the data processing system 10 includes many components that are connected to each other. In particular, the system unit 12 may be connected to and drive any arbitrary monitor 14 (such as a conventional video display). In addition, the system unit 12 may be selectively connected with an input device such as a PC keyboard 16 or a mouse 18. Any output device such as printer 20 may also be connected to system unit 12. Finally, system unit 12 will include one or more mass storage devices, such as diskette drive 22.

As described below, the system unit 12 responds to an input device such as a PC keyboard 16 or a mouse 18 or a local networking interface. Moreover, input / output (I / O) devices such as floppy diskette drive 22, display 14, printer 20 and local network communication system are connected to system unit 12 in a known manner. Of course, those skilled in the art will appreciate that conventional components may be coupled with the system unit 12 for interconnection. In accordance with the present invention, data processing system 10 includes a system processor interconnected with RAM, ROM, and a plurality of I / O devices.

In normal use, data processing system 10 may be designed to give independent computing power to a small group user as a server or a single user, and to be set inexpensively for the purchase of an individual or a small business. In operation, the system processor performs functions under an operating system such as Microsoft's Windows 95, IBM's OS / 2 operating system or Apple Computer's Mac OS or DOS. OS / 2 is a registered trademark of IBM Corporation, and "Mac OS" is a registered trademark of Apple Computer Corporation.

The data processing system 10 is connected with the target data processing unit 13. The data processing system 10 may send data through the input / output port and receive data from the target data processing unit 13. The target data processing unit 13 may be composed of any one of many written elements. For example, the target data processing unit 13 may be another data processing system that is fully developed or may be part of a large data processing system such as a controller card connected to the system bus of the large data processing system. Typically, the target data processing unit 13 is a new device under test. In this case, the data processing system 10 may send a stimulus to the target data processing unit 13 and receive performance and debugging data from the target data processing unit 13.

Before describing the structure in connection with the present invention, it will be helpful to consider a brief overview of the operation of the data processing system 10. 2, a block diagram illustrating various components of a data processing system 10 in accordance with the present invention is shown. 2 also illustrates the connections of the motherboard 11 with components of the motherboard 11, I / O slots 46a-46d, and other hardware of the data processing system 10. System central processing unit (CPU) 26 having a microprocessor connected to memory control unit 50 connected to volatile RAM 58 via high speed CPU local bus 24 via bus control timing unit 38. Is connected to the motherboard (11).

Referring to Figure 2, CPU local bus 24 (including data, address and control components) is connected to CPU 26, optional math processor 27, cache controller 28 and cache memory 30. To provide. The buffer 32 is also connected to the CPU local bus 24. The buffer 32 itself is connected to the low speed (relative to the CPU local bus) system bus 34 and contains addresses, data and control elements. System bus 34 extends between buffer 32 and other buffers 36. Moreover, system bus 34 is coupled with bus control and timing unit 38 and direct memory access (DMA) unit 40. The DMA unit 40 includes a central arbitration unit 48 and a DMA controller 41. The buffer 36 provides an interface between the system bus 34 and any selector such as a Peripheral Component Interconnect (PCI) bus 44. Other bus architectures such as the ISA bus or NuBus may be used instead of the PCI bus 44. This memory module represents the system memory of the data processing system 10.

Another buffer 66 is connected between the system bus 34 and the motherboard I / O bus 68. Motherboard I / O bus 68 includes addresses, data, and control elements, respectively. Display adapter 70 (used to drive arbitrary display 14), clock 72, nonvolatile RAM 74 (hereinafter referred to as NVRAM), RS232 adapter 76, parallel adapter 78, Multiple peripherals such as timer 80, diskette adapter 82 PC keyboard / mouse controller 84, and ROM 86 and various I / O adapters are coupled along motherboard bus 68. ROM 86 includes a BIOS that provides user transparent communications between many I / O devices.

Ports A and B are connected to the keyboard / mouse controller 84. These ports are used to connect a keyboard and mouse to a PC system (as opposed to an ASCII terminal). The RS 232 controller is connected to the RS232 adapter unit 76. Another optional ASCII terminal can be connected to the system via this contactor.

In particular, only a few data processing systems 10 may be implemented using any suitable computer, such as an IBM personal computer, Apple Macintosh computer, or Sun WeekStation.

A data flow diagram showing the construction of an executable computer program according to the present invention is shown in FIG. First, in Fig. 3, the programmer selects an "instrument" of any part of the computer program (block 300). The term “instrument” refers to adding additional lines of code to a given portion of a computer program, where performance and debugging data is generated when the added code is executed. The data generated by the instrumented code is stored and analyzed to determine any performance characteristics of the computer program being tested. In the present invention, a programmer can select any characteristic portion of a computer program to be instrumented. In an embodiment of the invention, the selected source code module is instrumented. In conventional software development programs, the programmer has not been given the option of instrumenting selected portions of the computer program. The programmer had to either instrument the entire program or not the computer program at all. By allowing instrumentation in selected portions of the computer program during testing, the computer program will not be included in unnecessarily instrumented code portions. This is important because the presence of too much instrumented code in a computer program can lead to unacceptable execution of the computer program being tested.

The code selected by the programmer is then instrumented (block 310). As above, instrumenting the code involves the addition of additional code (instrumentation code) that generates performance and debugging data at runtime. The location of this instrumentation code in the computer program being tested is inserted onto the branch statement in the program being tested. In addition, instrumentation code is often found at the beginning of each module selected to be instrumented. By placing instrumentation code at these locations, data is generated that allows branch coverage analysis of the computer program being tested. Instrumentation code exists alongside code that already exists in the selected module (application code) and is performed in the same way as application code. For a more detailed description of where to place instrumented code in the computer program under test and what kind of data is generated when such instrumented code is executed, see United States, Texas 75234, Dallas, Suit 900, Freeway, 3010 LBJ. See "Logiscope Handbook, Release 1.4, April 25, 1994," by Logiscope Inc. of the material.

Code that the programmer did not select for the instrument (block 320) is combined with the code instrumented at block 310 (block 330). Code that does not include the entire program is collected and linked to form a computer program executable to produce the object code (block 330). The exact way in which code fragments are combined and returned to executable computer programs varies widely from system to system. However, it is well known to those skilled in the art. The aggregate results of blocks 300-330 are shown as a computer program capable of performing (block 340).

4A illustrates how a viable computer program is executed and data is collected from the computer program. First, the executable computer program shown in block 340 may be transferred to the target data processing unit to be executed (step 400). This step is optional. In some examples, the executable computer program may be designed to run in the same data processing system that is collected and linked in block 330. For example, if a programmer is developing a computer program to run on an Intel microprocessor running on Microsoft's Windows operating system, the program is best developed on a data processing system using an Intel microprocessor running on a Windows operating system. will be good. If so, the computer program could be tested on the same machine that was originally developed. However, if a data processing system running on a Windows operating system using an Intel microprocessor is developing a computer program designed to run on an embedded microcontroller by Motorola, the computer program under development will not be able to run on an Intel machine. In this case, before the computer program is executed, the executable computer program must be transferred to the embedded microcontroller. There are many ways to transfer a computer program executable from one computing unit to another. Examples of this are serial ports, parallel ports and LANs.

Subsequently, an executable computer program is executed on the target data processing unit (step 410). The exact method of initiating the performance of the computer program being tested varies considerably from system to system. In some instances, executable programs will run under the control of an operating system. In another example, in particular, the computer program tested in the embedded microcontroller will include a full set of programs to be run on the embedded microcontroller. (I.e. operating system and multiple applications). While running on the target data processing unit, the computer program being tested will receive a series of test stimuli designed to execute various parts of the computer program that do not normally run on a regular base. Also, programmers generally want to generate data in addition to computer program execution in normal mode operation in order to optimize computer programs.

Test data generated by the instrumented code is passed and stored for later analysis (step 420). As above, the instrumented code segment generates data when executed. This data is then forwarded and stored for analysis. For example, instrumented code can output data to a serial port or store it on a hard disk. In addition, data can be stored in a database structure that facilitates analysis over long periods of time. The data generated by the instrumented code is stored in the form shown in FIG. 4B.

Referring now to FIG. 4B, a table 450 is shown. The table 450 is composed of a series of frames. Frame 452, another typical frame in table 450, includes several fields. Pointer field 454 is a pointer that contains the location of another field within frame 452. The coefficient field 456 then contains the coefficient value used to store a given portion of the instrumentation code that has been executed many times. Data field 458 is used to field data items generated by some portion of the instrumentation code. Finally, the length field 460 represents the data length in the data field 458.

As above, coefficient field 456 stores the number of times a given portion of instrumentation has been performed. If a given portion of the instrumentation code has been executed more than once, no other frame needs to be added to the table 450. Instead, a frame previously generated by a given portion of the instrumentation code may have its coefficient field incremented. In this way the memory space can be preserved.

An effective way to determine if duplicate traces are generated by a given piece of instrumentation code is to generate a hash value such as

Here, data [i] represents each data byte of the data field. Using this hash value, one can quickly point the table 450 to determine if the frame to be recorded is a duplicate of a previously existing frame. If the previously existing frame is equivalent to the frame to be recorded, the frame to be recorded will be deleted and the coefficient field of the previously existing frame will be increased. Only by increasing the value of the coefficient field will the time and space necessary for duplication frame recording be preserved.

Referring again to FIG. 4A, data generated by the instrumented code is sent to a data processing system capable of analyzing the data (step 430). As in step 400, step 430 is selected if a computer program is already running in a data processing system capable of analyzing data generated by the instrumented code. However, if the instrumented code is running on an embedded microcontroller, the data generated by the instrumented code needs to be sent to a general purpose data processing system for analysis.

Finally, the data generated when the instrumented code is executed is analyzed (step 440). This analysis can determine the branch coverage of a set of test programs, or show that portions of a computer program are mostly running under given conditions. For example, see the Logiscope Handbook for possible analysis types in the data generated by the instrumented code.

Referring now to FIG. 5, a perspective view of a typical computer system for implementing the present invention. Included in data processing system 502 are the program under development and the software development program according to the present invention. In the data processing system 502, which may be a UNIX-based workstation, a user may select source code modules within the instrumenting program. The instrumenter tool, which is then part of the software development program, inserts a line of source code within the selected module. Additional lines of source code inserted by the instrumenter tool will generate execution data when executed by the target data processing unit 508. Source modules instrumented along with other source code modules and other routines that need to be included in the final computer program are compiled and linked in the data processing system 502. The result is a program that can be executed by the target data processing unit 508.

After generating a program that can be executed in the target data processing unit 508, the data processing system 502 sends the executable program to the target data processing unit 508.

As shown in Figure 5, the target data processing unit 508 is a controller for an array of disk drives. However, target data processing unit 508 may take the form of one of a number of target data processing units used in remote calls or other computing technologies.

Once the executable computer program has been transferred to the target data processing unit 508, the program is executed. During execution, the data processing system 506 sends a series of test stimuli to the target data processing unit 508. These test stimuli may be designed to execute portions of code that do not operate normally, or the test stimuli may test the performance of specific portions of code in the program being executed.

When an instrumented module in a program executed on the target data processing unit 508 is executed, the module generates execution data that reflects the performance and coverage of the program. For example, the instrumentation code in a module will report the value of some variable, or indicate that a particular branch code has been executed.

In an embodiment, the instrumentation code will store an initial set of data if it is to be initially executed. After the initial run, the instrumentation code will generate a small amount of data in the next run. The operation of this method allows the instrumentation code to prevent the occurrence of duplicate data of previously generated data. This helps to store memory resources of the target data processing apparatus. You can also increment the counter when certain instrumentation code is executed. The value of the counter indicates the number of times a particular branch of the program tested was executed.

When the instrumentation code generates data, the data is stored in a buffer located in the memory of the target data processing apparatus 508. Storing data generated by instrumentation in the memory of the target data processing apparatus 508 consumes memory resources of the target data processing apparatus 508. However, storing data in this manner requires little execution time and does not significantly affect program execution in the target data processing apparatus 508. In other embodiments, data may be sent directly to the data processing system 504 upon data generation, or the data may be stored in a nonvolatile storage device coupled to the target data processing device 508.

After the program executed in the target data processing apparatus 508 is finished, the execution data stored in the memory buffer of the target data processing apparatus 508 is transferred to the data processing system 504. When the execution data is located in the data processing system 504, the software development program may evaluate the data to determine the end of the test program using the instruction point and the decision path application method. By studying these analyzes, programmers can optimize and develop programs more efficiently.

6 shows a diagram of the configuration of a computer program executed in a target data processing apparatus. In a particular example, the executing computer program and the target data processing device may execute several tasks at the same time. A task is defined as a structure in an execution computer that includes a logical grouping of one or more modules. Tasks in the program are organized so that they can process data at the same time.

Three tasks 608, 620, 624 are shown in FIG. 6. Task 608 includes three modules 602, 604, and 606. Task 620 includes modules 616 and 614 and task 624 includes module 622, which is a single module.

According to the present invention, the programmer selects the modules included in the instrumented multitask computer program 612. Modules 602, 604, and 614 include instrumentation code and generate execution data at run time.

Buffers 610 and 618 are provided to store data generated when a module containing instrumentation code is executed. Buffers 610 and 618 include a large single buffer or a series of small buffers connected to each other. In accordance with the present invention, a separate buffer is provided for each task of the module that contains the instrumented code. If only a single buffer is provided in a system with modules containing instrumented code, the instrumentation code within each task continues to overwrite and interfere with the execution data of other tasks located in the same buffer. By having a separate buffer for each task that contains instrumentation code, there will be no risk of data generated by one module of one task interfering with data generated by another module of another task.

Execution data generated by such instrumented modules 602, 604 is stored in buffer 610, while instrumented module 614 stores its execution data in buffer 618. As a result, there is no buffer associated with task 624 because no module has been instrumented with task 624.

7 is a single connection process that may occur in a multiple task environment in accordance with the present invention. The processing shown in Figure 7 is a representative example of a possible flow that could be modified in accordance with the present invention. Processing begins with task 700. Task 700 appears as the start of task 700 and shows two slices of instrumentation code and other standard application code.

Initially task 700 will be executed. The next instrumentation code 702 will be executed. At this point the flow of processing will switch to the routine 706. As soon as it is directly entered into the routine 706, the code is executed such that the target data processor cannot act as an interrupt. This code is called Int-Lock. By avoiding the interrupt role, the target data processing device is guaranteed to be able to complete the logging of data as specified by the instrumentation code without leaving the routine 706. Execution data stored in a buffer associated with task 700 is guaranteed to be properly ordered.

After the routine 706 disables or interrupts the performance of the role, the data will be logged in the buffer associated with the task 700 as specified by the instrumentation code. In Figure 7, this buffer is referred to as buffer 700. After all data has been logged to the buffer 700, the routine 706 will be able to act as an interrupt. The code that makes the role perform or enables interrupts is called Int-Unlock. At this point routine 706 transitions to task 700.

After executing the instrumentation code 702, the task 700 will execute the actual instrumentation code 704. In the same manner as the execution of the instrumentation code 702, the execution of the instrumentation code 704 will transfer control from task 700 to the routine 706. Again, as in the case of instrumentation code 702, routine 706 disables the role of interrupts, and logs data as specified by instrumentation 704 in the buffer associated with task 700. Then it becomes possible to act as an interrupt. At this point, the routine 706 transfers control to the task 700.

In practice, task 700 will be terminated. At this point, task 710 is initialized. Task 710 will be executed in a similar manner as task 700. Instrumentation code 712, 714 requests routine 716 to log data to a buffer associated with task 710. In the example shown in FIG. 7, task 700 will execute again after task 710 completes execution. Task 700 will execute as described above and will switch execution to task 720 at some point. Task 720 will be executed in a manner very similar to tasks 700 and 710. Instrumentation code 722, 724 will call routine 726 to register data in a buffer associated with task 720.

While the invention has been described in the context of a full functional set of data processing systems, those skilled in the art will appreciate that the apparatus of the invention may be dispensed in a variety of forms in the form of instruction computer readable media, the invention of which is intended to facilitate It will be appreciated that the same applies to the particular type of signal relation medium used to implement the same. Examples of computer readable media include recordable media such as floppy disks and CD-ROMs and transmission media such as digital and analog communication links.

While the invention has been particularly shown and described with reference to preferred embodiments, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention.

In a method and apparatus for interpreting a computer program comprising a plurality of modules provided according to the present invention as described above, the module to be included in the computer program includes additional lines of code added thereto, By doing so, programmers can develop computer programs more efficiently.

Claims (16)

A method for analyzing a computer program comprising a plurality of modules for determining performance and execution characteristics of the computer program, the method comprising: Instrumenting one module in a computer program to create one instrumented module, wherein another module of the plurality of modules is an uninstrumented module; Combining the uninstrumented module with the instrumented module to form a computer program; Executing the computer program on a data processing system; Generating execution data when the instrumented module is executed; And Analyzing the execution data to determine performance and execution characteristics of the computer program Computer program analysis method comprising a. The method of claim 1, After the combining step, further comprising communicating the computer program to a target data processing unit; The instrument step and the combining step are performed on a source data processing system, and the executing and generating steps are performed on a target data processing unit. Computer program analysis method. The method of claim 2, The target data processing unit is a built-in microcontroller Computer program analysis method. The method of claim 1, The instrumented module includes instrumentation code that has not changed in response to the executing step. Computer program analysis method. A data processing system for analyzing execution data for effectively developing a computer program, Data processing systems; A computer program having a plurality of modules, including one instrumented module containing instrumented code and one module containing uninstrumented code, wherein when the data processing system executes the computer program, the instrument Module generates run data; Means for collecting and storing the execution data; And Means for analyzing the execution data to determine performance and execution characteristics of the computer program such that the computer program is effectively developed Data processing system comprising a. The method of claim 5, Further comprising a target data processing unit, The data processing system combines the uninstrumented module with the instrumented module to form a computer program, and thereafter communicates the computer program to a target data processing unit where the computer program is executed and execution data is generated. doing Data processing system. The method of claim 5, The target data processing unit is a built-in microcontroller Data processing system. A data processing system for analyzing a computer program having at least two modules, A first source computer, a second source computer and a target data processing unit; The first source computer, A first mode of operation for instrumenting one module in the computer program to create one instrumented module while keeping one module in the computer program uninstrumented; A second mode of operation for combining the instrumented and uninstrumented modules to produce the computer program; And A third operation mode for communicating the computer program to a target data processing unit Can operate in a number of operation modes, including, The target data processing unit, A first operation mode for executing the computer program and generating execution data when a target data processing unit executes an instrumented module in the computer program; And A second mode of operation for communicating the execution data to the second source computer Can operate in a number of operation modes, including, The second source computer may operate in a first mode of operation for analyzing the execution data to enhance development of the computer program. Data processing system. The method of claim 8, The first source computer is the second source computer Data processing system. A method for analyzing a computer program designed to run on an embedded target data processing unit, the method comprising: On a source computer system, instrumenting a source code module of the computer program to create an instrumented module; Compiling, on the source computer system, an uninstrumented module that is different from the instrumented module; Combining, on the source computer system, the instrumented module and the uninstrumented module to form a computer program that can be executed in an embedded target data processing unit; Communicating the computer program from the source computer system to an embedded target data processing unit; Executing the computer program on the embedded target data processing unit; Generating execution data on the embedded target data processing unit when the instrumented module is executed; Communicating the execution data from the embedded target data processing unit to the source computer system; And Analyzing, on the source computer system, the execution data to determine performance and performance characteristics of the computer program. Computer program analysis method comprising a. A method for generating execution data from a multi-tasking computer program comprising a plurality of tasks having a plurality of modules for determining performance and execution characteristics of the multi-tasking computer program, the method comprising: Instrumenting a first module in a first task to form a first instrumented module and instrumenting a second module in a second task to form a second instrumented module, wherein another module of the plurality of modules Is an instrumented module-; Combining the first and second instrumented modules with the uninstrumented modules to form a multi-tasking computer program; Associating the first task with a first memory buffer and associating the second task with a second memory buffer; Executing the multi-tasking computer program on a data processing system, including the first and second instrumented modules, wherein the first and second instrumented modules generate execution data when executed; And Storing execution data generated by the first instrumented module in the first memory buffer and storing execution data generated by the second instrumented module in the second memory buffer, wherein the first Execution data in the memory buffer and the second memory buffer reflect the performance and execution characteristics of the multi-tasking computer program. Execution data generation method comprising a. The method of claim 11, After the multi-tasking computer program completes execution, storing the contents of the first memory buffer and the second memory buffer in a nonvolatile memory device. Execution data generation method further comprising. The method of claim 11, In response to subsequent execution of the first instrumented module, Incrementing a counter associated with the first instrumented module; And Storing additional execution data without information that overlaps with the stored execution data prior to subsequent execution of the first instrumented module Execution data generation method further comprising. A data processing system for generating execution data from a multi-tasking computer program comprising a plurality of tasks having a plurality of modules, the method comprising: Data processing systems; A multi-tasking computer program comprising a first instrumented module in a first task and a second instrumented module in a second task, wherein another one of the plurality of modules is an uninstrumented module, When executing a multi-tasking computer program comprising first and second instrumented modules, the first and second instrumented modules generate execution data; Means for associating a first task with a first memory buffer and associating a second task with a second memory buffer; And Means for storing execution data generated by the first instrumented module in the first memory buffer and storing execution data generated by the second instrumented module in a second memory buffer, wherein the first Execution data in the memory buffer and the second memory buffer reflect the performance and execution characteristics of the multi-tasking computer program. Data processing system comprising a. The method of claim 14, Means for storing contents of the first memory buffer and the second memory buffer in a nonvolatile memory after the multi-tasking computer program has finished executing Data processing system further comprising. The method of claim 14, In response to subsequent execution of the first instrumented module, Means for incrementing a counter associated with the first instrumented module; And Means for storing additional execution data without information that overlaps with the stored execution data prior to subsequent execution of the first instrumented module Data processing system further comprising.

Images