1. Field of the Invention
The present invention generally relates to debugger systems for computer software.
2. Description of the Prior Art
During the coding of computer programs, the inadvertent production of errors, or bugs, is typically unavoidable. Debugging systems help identify, and thus eliminate, these bugs from a computer program.
One tool used with debuggers are breakpoints. Breakpoints are stopping locations in a computer program under test. The computer program will run until it reaches a predetermined breakpoint address; control is then returned to the debugger. At this point, the debugger can examine the memory locations used by the computer program under test. By examining these memory locations, the user can locate and eliminate bugs in the computer program under test.
There are difficulties with breakpoints, however. For example, some computer systems are parts of systems in which the computer system under test provides and receives data from another part of the system within a certain time restriction. The breakpoints can thus cause timing problems. Sometimes it is not feasible for the computer user to be around during the testing of the computer system. For example, if a breakpoint is set at a location where it is unlikely for the program to hit, it would not make sense for the computer user to sit at the computer screen waiting for such an unlikely event. Additionally, some testing of the computer system can occur late at night when the software engineers are not available.
One way to avoid these problems is through the use of tracepoints. Tracepoints are similar to breakpoints, but unlike breakpoints, they do not stop the program indefinitely. Once the program reaches a tracepoint, data in predetermined memory locations are stored. Control is then returned to the computer program under test. After the computer program has run, a xe2x80x9chex dumpxe2x80x9d of all the data obtained by the tracepoints is provided to the user. The user sifts through the hexadecimal representation of the data in order to determine the bugs in the computer system. It is desired to have an improved tracepointing system for examining a computer program under test.
One embodiment of the present invention relates to the use of programming abstractions to represent the tracepoint output as well as the data to collect at each tracepoint event. This makes it easier for the user of the debugging system to collect and evaluate the tracepoint event data. The user does not have to sift through the hexadecimal representations in order to determine the locations of and contents of memory. For example, if a variable, X, is used in the source code of the computer program under test, the debugger system can interpret the user""s command xe2x80x9ccollect Xxe2x80x9d at a given tracepoint to collect the data stored in the memory location associated with the variable, X. Later, an instruction to xe2x80x9cprint Xxe2x80x9d will cause the debugging software to display the value of X. The user need not look up the address of variable X, then look at the contents of that address; the debugger system does this automatically for the user.
In a preferred embodiment, the system can collect data from the stack and then produce an output indicating what subroutine called which, and with what arguments, at the time of the tracepoint event.
In a preferred embodiment, the debugger system uses a programming abstraction, such as a variable used in the source code of the program under test, and checks the address and symbol table created during the compiling of the computer program under test to determine some indication of the addresses of the required data. This indication is sent to a debugger agent (a subprogram running on the target system that provides services for the debugger on the host computer) along with the computer program under test. The debugger agent in the target system collects the desired data and stores the data into a buffer when a tracepoint is executed. After the computer program under test has run, the debugger system can send a request to the debugger agent on the target to obtain the data in the buffer. The debugger can then represent the data using programming abstractions. In a preferred embodiment, both the collection and display representations of the data uses the symbol and address table created by the compiler for the compiled program under test.
In another embodiment of the present invention, the system includes bytecode expressions that are run as part of the tracepoint collecting of data at the target system. The target system can evaluate expressions in order to determine the data to collect. For example, consider an array Q[n] which has 100 elements. If the user wants to collect the data in the location Q[X+Y], where X and Y are both program variables, the present invention can evaluate X+Y in order to determine the address location of the array value Q[X+Y] in order to obtain this value and store it in the buffer. In this way, less data need be stored. For example, if only the element Q[X+Y] is required, the system need not store all 100 elements of the array each time the tracepoint is hit. This is an important consideration because the data storage capacity of the buffer at the target system is an important limiting factor. A given tracepoint could be hit a large number of times. By using bytecode expressions, the buffer is not filled with unwanted data. and thus filled prematurely.
Having the arithmetic expression evaluated at the target system rather than at the debugger is important. In breakpoint systems, typically the evaluation of expressions is done at the debugger. This is undesirable when using tracepoints that operate in real time because the arithmetic calculations of the expressions at the target system can occur much faster than the data transfer between the target system and the host system. For the same reason, the debugger agent stores the data into a buffer, rather than sending the data directly to the host system at the time of a tracepoint event.