Byte code instrumentation

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C714S035000, C714S038110, C714S045000, C714S048000

Reexamination Certificate

active

06186677

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
This application relates to the field of computer software and more particularly to the field of computer software for instrumentation of code in order to facilitate debugging.
2. Description of Related Art
Code instrumentation is performed by adding statements to software in order to monitor performance and operation of the software during run time. Code instrumentation is sometimes used to facilitate debugging of run time errors relating to memory accesses. Specifically, since many run time errors are the result of improperly accessing or using memory (e.g., writing beyond an array's boundaries, not freeing dynamically allocated memory, etc.), then instrumentation may be used to supplement memory accessing portions of the software with additional software that monitors memory accesses and provides an indication when it appears that an improper access has occurred.
Instrumentation may be performed manually by having the programmer insert source code statements that intermittently output or record values related to memory variables, such as array indices and amounts of free space left in the allocation heap. However, such manual instrumentation is often inefficient for a number of reasons. Manual instrumentation requires the programmer to recognize possible sources of error in order to be able to insert the appropriate source code to perform the instrumentation. However, once the programmer has identified possible sources of error, it may be more straight-forward to simply examine the potentially errant code and fix the error rather than perform the additional steps associated with adding source code instrumentation statements. In addition, manually adding source code instrumentation statements requires repeated recompiling of the source code before execution, which adds time and effort to the debugging process. Also, the programmer must remember which statements are instrumentation statements in order to remove those statements once the added debugging statements are no longer needed.
Various systems exists for automating the debugging process. U.S. Pat. No. 5,581,696 to Kolawa et. al (the '696 patent) is directed to a method of using a computer for automatically instrumenting a computer program for dynamic debugging. In the system disclosed in the '696 patent, the instrumentation software examines and supplements a parse tree intermediate stage produced by the compiler. The parse tree is a tree having nodes corresponding to tokens that represent individual source code statements. The system described in the '696 patent traverses the parse tree to locate tokens of interest (e.g., tokens corresponding to memory accesses) and supplements those tokens with additional tokens corresponding to code that monitors the memory accesses. However, since the contents of the parse tree depend upon the particular source programming language used, the system disclosed in the '696 patent is also source dependent.
U.S. Pat. Nos. 5,193,180, 5,335,344, and 5,535,329 all to Hastings (the Hastings patents), disclose a system for instrumenting computer object code to detect memory access errors. The instrumentation includes providing additional code that maintains the status of each and every program memory location along with supplementing object code instructions that access the program memory with additional code that facilitates maintaining status of the memory locations. To the extent that the object code is independent of the particular source code that is used, the system disclosed in the Hastings patents is also independent of the source code language used.
However, since the system disclosed in the Hastings patents involves modifying object code, then the system is target dependent in that it may only be configured to work with object code that executes a particular target processor's native language. Although it may be desirable to adapt the Hastings system to work with object code for a variety of target processors, such an adaptation would require significant modifications to the system since object code instructions that access memory may vary significantly between different target processor languages. In addition, monitoring program memory accesses by maintaining the status of program memory locations allows some improper operations to be performed by the software without being detected. For example, reading a memory location beyond an array's boundaries may not be detected if the memory location that is read has been allocated and initialized in connection with another memory variable.
Other systems for facilitating debugging exist. For example, U.S. Pat. No. 4,667,290 to Goss et al. is directed to compilers that create intermediate representation (IR) code that is both source and target independent. Column 5, lines 57-60 disclose using the IR code to facilitate debugging by retaining portions of the IR code that would otherwise be eliminated in the course of optimization if debugging is not being performed. Similarly, U.S. Pat. No. 5,175,856 to Van Dyke et al. discloses a compiler that produces an IR code where debugging is facilitated by passing information through the intermediate code file.
U.S. Pat. Nos. 5,276,881, 5,280,613, and 5,339,419, all to Chan et al., disclose a compiler system that produces an IR code. U.S. Pat. No. 5,276,881 is illustrative of the three patents and discloses symbolic debugging support provided in connection with the compiler system described in the patent. Column 59, lines 15-19 indicate that if the symbolic debug option is specified, “ . . . then the Low-level Code Generator 1322 writes additional information to the Low Level CIR 1338.”. (CIR is an acronym for Compiler Intermediate Representation.) Column 57, lines 59-63 indicate that the Low-Level CIR 1338 is analogous to the compiler intermediate representation 212, but the low level CIR 1338 is not architecturally neutral (i.e., is target dependent). Column 57, lines 63-65 state specifically that the Low-Level CIR 1338 is dependent upon the particular architecture of the target computer platform.
Thus, none of the references that disclose use of IR code in connection with compilers appear to directly address the difficulties presented by the '696 patent and the Hasting patents, discussed above.
SUMMARY OF THE INVENTION
According to the present invention, instrumenting a computer program includes examining an initial intermediate representation of the program, selecting portions of the initial intermediate representation for instrumentation, instrumenting the portions, and converting the instrumented portions into byte code. Selecting the portions may include choosing portions of the initial intermediate representation corresponding to pointer arithmetic operations, operations that reads memory locations, operations that change memory locations, and/or operations that causes program variables to become defined or undefined within the program. Instrumenting the portions may include adding run time code that provides a user with an indication when a run time error occurs. Converting the instrumented portions may include transforming the insumented IR code into byte code
Instrumenting a computer program may also include creating an IR tree of nodes corresponding to IR operations and operands of the initial intermediate representation where the nodes being interconnected according to a logical relationship between the operators and the operands and where instrumenting the portions includes modifying the IR tree. Instrumenting may also include transforming the IR tree into an instrumented intermediate representation that is structurally equivalent to the initial intermediate representation. The IR tree may include nodes that are interconnected so that children nodes of an operator are the operands of the operator. The IR tree may be created by placing the children nodes on a local stack and then popping the children nodes off the local stack to connect the children nodes to parent nodes.
Instrumenting a comput

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Byte code instrumentation does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Byte code instrumentation, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Byte code instrumentation will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2588115

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.