JPH1165885A - Device and method for debugging software - Google Patents

Abstract

PROBLEM TO BE SOLVED: To correctly generate function call stack information even in the case of an object code, to which the optimizing processing of a compiler is performed, and to enable execution trace using a high-level language. SOLUTION: This device has a break point setting managing part 18 for setting software break to the start and end addresses of an arbitrary function and a function execution history data storage part 19 for recording the argument information or return value information of the executed function. By performing the analysis of stack data when these software break conditions occur, the function call stack information can be correctly generated even in the case of the object code, to which the optimizing processing of the compiler is performed, and the execution trace is enabled using the high-level language.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software debugging apparatus and method used in a debugging process of software development, and more particularly, to an object code to be debugged which has been subjected to a compiler optimization process. The present invention relates to a software debug apparatus and method for correctly generating function call stack information even when stack data cannot be correctly analyzed and realizing a program execution trace at a high-level language level.

[0002]

2. Description of the Related Art A function call stack function sequentially lists functions that have not been returned to a caller among functions already called at a specific point in time, and places a currently executing function at the top of the list. Display function displays the argument name and value passed for each call, return value, etc.

[0003] In addition, conventional source debuggers often support only program execution trace at the assembler level, so that developers cannot perform debugging at the level of the programming language used by themselves.

FIG. 2 is a block diagram of a conventional software debug device. In FIG. 2, a software debugging apparatus includes a computer 10 including a source debugger 11 which is an application program for debugging, and an emulator 12 for emulating a program under test under the control of the source debugger 11.
And The compiler 25 and the linker 26 generate an object file 27 from the C language source file 24, and the object file 27 is a program to be tested. The object file 27 is executed by the emulation unit 15 in the emulator 12, and the execution result is stored in the form of trace data in the trace data storage unit 16.
Is accumulated in

A method for realizing the function call stack function will be described. Execute the program under test to an arbitrary address and stop the execution of the program. At this time, the source debugger 11 transfers the data of the stack memory in the emulation unit 15 to the stack information analysis unit 2 via the communication interface unit 14 and the communication interface unit 13.
Read into 3. Further, the source debugger 11 reads the debug information included in the object file 27, analyzes the symbol information in the symbol information analysis unit 17, and sends the result to the stack information analysis unit 23. The stack information analysis unit 23 analyzes information of functions loaded on the stack memory from the symbol information output from the symbol information analysis unit 17 and the data of the stack memory output from the emulation unit 15.

FIG. 3 shows how data is stored in a stack memory when a general function is called. The currently called function has the stack information as shown in FIG. 3 loaded on the stack memory. By analyzing these, it is possible to know the order of function calls. The function information created by the stack information analysis unit 23 is displayed on the function call stack display unit 20 as function call stack information.

Next, a method of realizing the program execution trace function will be described. When the program under test is executed by the emulation unit 15, data indicating an instruction execution result and a memory access result is written to the trace data storage unit 16. Source debugger 1
1 reads out the trace data stored in the trace data storage unit 16 via the communication interface unit 14 and the communication interface unit 13, shapes the data, and displays the data on the execution trace display unit 22. In this case, the trace data stored in the trace data storage unit 16 is
Since the data is at the assembler level, the data displayed on the display unit 22 in the execution trace is the data at the assembler level unless special processing is performed by the source debugger 11.

As a conventional example, Japanese Patent Laid-Open Publication No. Hei 6-242943 discloses a "source code level debugging device". This is to enable source code debugging even when the source program and the disassembled code can no longer be matched, for example, when the file is changed, and is different from the purpose and application of the present invention.

[0009]

Hereinafter, a method of stacking the stack data will be described with reference to FIG. When calling a function, before calling the target function, the caller function first saves the value of the register used for the work purpose on the stack memory. This is the work register save area 50. Next, the function and the return address of the function are loaded on the stack memory and the function is called. The called function saves the current frame pointer value 57 and the register value to be allocated for the register variable, and secures an area for the automatic variable. These are respectively the argument area 5
1. Stored in a return address area 52, an OLDFP area 53, a register variable save area 54, and an automatic variable area 55. The argument area 51 includes a noauto function, no
In the case of a function that passes an argument to a register, such as a rec function, the function is a data saving area of the register storing the argument. As a special case, the OLD FP area 53 does not exist when the use of the frame pointer is not specified by the optimization option of the compiler or when the noauto function or the norec function is called. The stack frame size 56 is output information of the compiler, and determines the position of the return address area 52 using the stack pointer (SP) and this value. OLD FP area 5
The value stored in 3 indicates the end 57 of the stack data of the caller function that called the currently executing function.

FIG. 4 shows an example of a C language source program using noauto and norec function declarations. There are three functions declared in the program.
n is a normal function, funcA is a function declared noauto, and funcB is a function declared norec. The program is executed from the main function on the 25th line in FIG.
FIG. 5 shows the state of the stack memory when a break occurs when the funcB function on the 0th line is called.

In FIG. 5, reference numerals 60, 61, and 62 denote stack data on which the main function is loaded when the funcA function is called, and reference numerals 63, 64, and 65 denote stack data on which the funcA function is loaded when the funcB function is called. By reading the current value of the program counter (PC) from the emulator unit and comparing it with the symbol information, it is possible to specify that the function currently being executed is the funcB function.

Also, the value stored in the return address area 65 is read from the current SP value, and the value of the return address accumulated by the funcA function can be obtained. Since this address is within the range of the funcA function, it can be concluded that the funcB function was called from the funcA function. Further, in order to specify the caller function of the funcA function, the address value stored in the return address area 62 must be read.

However, since the size information of the work register save area 63 is not included in the output of the compiler, the position of the return address area 62 cannot be specified, and the stack data cannot be correctly analyzed any more. Therefore, except when the OLD FP area 53 of FIG. 3 is stacked on the stack memory, that is, when the optimization option of the compiler is specified, the noauto function, the no
When the rec function is used, there is a problem that the calling relation of the nested functions cannot be checked by analyzing the stack data.

As described above, the function stack trace function is realized by sequentially analyzing the stack data loaded on the stack memory at the time of calling the function, depending on the current SP position. . The data stacked on the stack memory includes not only the return address of the function but also information on arguments and data saved in registers, and it is required to analyze these correctly.

[0015] To increase code efficiency, the programmer
The compiler may specify optimization options to optimize the stack frame at compile time, or use compiler-specific extensions. For example, in the case of a function that does not use an automatic variable, the stack frame can be optimized by declaring the function as a noauto function. By optimizing the stack frame,
It is possible to simplify the pre- and post-processing of the function call, to shorten the object code and improve the execution speed. Also,
For functions that do not call other functions from the function itself,
By declaring a function as a norec function, no
The same effect as the auto function can be obtained.

In order to provide execution trace information at the high-level language level in the configuration of the conventional debug device, the trace data stored in the trace data storage unit 16 of FIG. It is conceivable to create high-level language-level execution trace information based on the symbol information read from the object file 27. However, in this case, the data stored in the trace data storage unit 16 includes many data other than the data necessary for creating the execution trace information, and there is little actually valid data. Therefore, it is considered that a sufficient amount of execution trace information cannot be created.

Increasing the capacity of the trace memory for storing the trace data is cost effective and cannot be said to be an effective means. Therefore, it is considered that it is practically impossible to realize a practical high-level language-level execution trace with the configuration of the conventional debug device.

[Object of the Invention] An object of the present invention is to enable function call stack information to be correctly generated even for object code that has been subjected to compiler optimization processing.

Another object of the present invention is to realize an execution trace at a high-level language level.

[0020]

According to the present invention, as a means for solving the above-mentioned problems, a source program to be inspected is converted into an object code by a compiling process, and a process according to the object code is sequentially executed. A software debug device that verifies the source program by executing a function in a breakpoint setting management unit for setting a software break condition at a start address and an end address of an arbitrary function in the source program; A function execution history data storage unit for storing information; and a means for generating the function execution history data by analyzing a stack memory every time the software break condition is satisfied. Provide debugging device It is intended.

[0021] Further, there is provided a means for generating function call stack information from information registered in the function execution history data storage.

The present invention is characterized in that there is provided a means for generating high-level language-level execution trace information from the information registered in the function execution history data storage.

Further, according to the present invention, as a means for solving the above-mentioned problem, a source program to be inspected is converted into an object code by a compiling process.
In a software debugging method for verifying the source program by sequentially executing processes according to the object code, a software break condition is set at a start address and an end address of an arbitrary function in the source program, and A software debugging method characterized by generating function execution history data by analyzing a stack memory each time the condition is satisfied, and storing the function execution history data in a function execution history data storage unit that stores function execution information in the order of execution of the functions. To provide.

[Operation] According to the present invention, a breakpoint setting management unit (1 in FIG. 1) for setting a software break at a start address and an end address of an arbitrary function.
8) and a function execution history data storage unit (19 in FIG. 1) for recording argument information and return value information of the executed function, and analyze the stack data when the above software break condition occurs (when it is satisfied). By doing so, the function call stack information can be correctly generated even for the object code that has been subjected to the optimization processing of the compiler, and the execution trace can be realized at the high-level language level.

In order to accurately analyze the stack data, it is possible to always correctly analyze the stack data for the function currently being executed. Therefore, in order to correctly perform the function stack trace in any situation, it is only necessary to analyze the stack data at a timing immediately after each function is called. Therefore, the present invention uses the software break function of the emulator to set a break condition at the start address and end address of an arbitrary function, and analyzes the stack memory information immediately after the function is called to optimize the compiler. The stack data is correctly analyzed even when the optimization option is specified or when the noauto function or the norec function is used.

The break condition at the start address of the function is used to obtain the return address and argument of the function, and the break condition at the end address is used to obtain the return value. The acquired return address (function name), argument, and return value are registered as function execution history data in the function execution history data storage unit. Function call stack information can be created from the function execution history data, and a program execution trace of a function can be realized at the function level of a high-level language.

As described above, according to the present invention, function call stack information can be correctly generated even for object code that has been subjected to compiler optimization processing.
Further, the present invention is characterized in that an execution trace at a high-level language level is realized.

Hereinafter, the function and effect of the present invention will be further described.

The function call stack function supported by the conventional high-level language debugger has a problem that under certain conditions, the call stack information of a function cannot be correctly obtained.

Further, the entire flow (history) of the processing of the function executed in the program cannot be followed.

This is because, for example, when the optimization option of the compiler is specified or when the noauto and norec functions are used, the stack data cannot be correctly analyzed.

The reason is that the stack memory is analyzed while the program execution is stopped (break).

Therefore, in the present invention, by setting software break conditions at the start address and end address of an arbitrary function based on the symbol information output from the compiler, the order in which each function is called and the argument By storing and analyzing information and return value information in a memory, a call stack history of functions at the C language level is generated.

The noauto function and the norec function pass arguments to registers, and in this case, the arguments are obtained from the registers. The acquired argument is registered in the function execution history data storage (19 in FIG. 1) together with the function name.

That is, in the present invention, a software break event is set at the start address of each function, and at the time of an event break, a software break event is set at the return address of the function. When the break is caused by the start address, the argument information is stored, and when the break is caused by the return address, the return value information is stored, and the function call stack information is generated.

In the present invention, since the stack memory information is analyzed immediately after the function is called, noauto,
The correct stack information can always be obtained even when using the norec function or when specifying the optimization option of the compiler.

Thus, according to the present invention, function call stack information can be correctly generated under any conditions.

Further, since it is possible to follow the flow of program processing at a high-level language level such as C instead of the conventional trace information at the assembler level, a programmer developing with a high-level language such as C can use Improvements in development efficiency are expected.

[0039]

An embodiment of the present invention will be described with reference to FIG. FIG. 1 is a block diagram showing the configuration of a software debug device for implementing the present invention. In FIG. 1, the software debug device includes a computer 10 including a source debugger 11 which is an application program for debugging, and an emulator 12 which emulates a program under test under the control of the source debugger 11. The object file 27, which is the program under test, is created by processing the C language source file 24 with the compiler 25 and the linker 26. The source debugger 11 is the object file 2
7 is read, the symbol information analysis unit 17 tabulates information on the start and end addresses of all functions, and creates a function address information table.

The source debugger 11 sets software break conditions from the breakpoint setting management unit 18 for the start address and end address of each function based on the function address information table. The software break is a function of the emulator, and is characterized in that the number of breakpoints that can be set is sufficiently larger than the number of hardware breakpoints. The emulator 12 includes an emulation unit 15 for emulating the execution of the object code, and a trace data storage unit 16 for storing the execution result of the instruction and the access result of the memory. The source debugger 11 creates function execution history data in the stack information analysis unit 23 from the stack data read from the stack memory in the emulation unit 15 and the symbol information created in the symbol information analysis unit 17 by reading the object file 27.
It is stored in the function execution history data storage unit 19. Based on this data, the function call stack information is displayed on the function call stack display section 20, and the execution trace result at the high-level language level is displayed on the execution trace display section 21. Also, the trace at the assembler level is displayed on the execution trace display unit 22 as in the conventional case.

The details will be described with reference to an example of a C language source program shown in FIG. The object file 27 output from the compiler 25 and the linker 26 for the C language source program in FIG. 4 is read by the source debugger 11 and downloaded to the emulator 12.

The source debugger 11 creates a function address information table in the symbol information analyzer 17. The source debugger 11 sets software break conditions from the breakpoint setting management unit 18 for all of the start address and end address of an arbitrary function based on the information in the function address information table.

After the software break conditions are set, the program under test is executed.
Break at the start address of the ain function. Here, the value of the PC is read from the emulation unit 15 and the function currently being executed is m from the data in the function address information table.
Specifies that the function is an ain function.

Further, the stack information analysis section 23 reads and analyzes the stack data in the emulation section 15 and the output information of the symbol information analysis section 18, and registers the function name and the argument in the function execution history data storage section 19. After acquiring the function execution history data, the source debugger 11 executes the program again.

Next, a break occurs at the start address of the funcA function on line 15 in FIG. At this time, the data of 60, 61 and 62 in FIG. 5 is stored in the stack memory.
Similarly to the above, it is specified from the PC value that the function is the funcA function. funcA which is a noauto function
In this case, the argument is obtained from the register because the function passes the argument to the register. The acquired argument is registered in the function execution history data storage unit 19 together with the function name.

When the program is further executed, 10 in FIG.
Break at the start address of the funcB function on the line.
At this time, 63, 64 and 65 of FIG. 5 are stacked on the stack memory. Since the norec function also passes arguments to registers, the arguments are similarly acquired from the registers and registered in the function execution history data storage unit 19 together with the function names.

When the program is further executed, a break occurs at the end address of the funcB function on the thirteenth line. Here, it is specified that the function being executed is a funcB function based on the PC value. After acquiring the return value from the register storing the return value, the source debugger 11 registers it in the function execution history data storage unit 19 together with the function name. After the return, the location to be passed is determined in advance by the type of the return value of the function.

Subsequently, when the program is re-executed,
Break at the end address of the funcA function on the line.
Here, similarly, the function name and the return value are registered in the function execution history data storage unit 19. The same processing is performed for the end address of the main function, and all data is registered in the function execution history data storage unit 19.

Also, based on the data in the function execution history data storage unit, the function call stack information is displayed on the function call stack display unit 20, and the execution trace result at the high-level language level is displayed on the execution trace display unit 21. Also, the trace at the assembler level is displayed on the execution trace display unit 22 as in the conventional case.

Finally, a display example of data registered in the function execution history data storage unit 19 will be described. F on line 10 in FIG.
When the uncB function is called, the data displayed on the function call stack display section 20 is as shown in FIG. The data displayed on the C language level execution trace display section 21 on the 18th line in FIG. 4 is as shown in FIG. 6B.
70 is the value of the argument, and 71 is the value of the return value. If the argument is a pointer, the address value is displayed.
return>.

[0051]

As described above, according to the present invention, when an optimizing option is specified at the time of compiling, or when a noauto function declaration, nor
Using the ec function declaration, function call stack data can be correctly generated even for a function whose object code is more efficient.

Further, high-level language-level program execution trace data can be generated using the function execution history data. As a result, debugging at the same high-level language level as the program under test can be performed, and the efficiency of the debugging operation can be improved.

[Brief description of the drawings]

FIG. 1 is a block diagram showing an embodiment of an apparatus for implementing the present invention.

FIG. 2 is a block diagram showing an example of a conventional apparatus.

FIG. 3 is a state diagram of a stack memory when a function is called;

FIG. 4 is an example of a C language source program.

FIG. 5 is a stack state diagram in the source program of FIG. 4;

FIG. 6 shows a display example of a function call stack and a display example of an execution trace.

[Explanation of symbols]

Reference Signs List 10 computer 11 source debugger 12 emulator 13 communication interface unit (computer side) 14 communication interface unit (emulator side) 15 emulation unit 16 trace data storage unit 17 symbol information analysis unit 18 breakpoint setting management unit 19 function execution history data storage unit 20 Function call stack display section 21 Execution trace display section (C language level) 22 Execution trace display section (assembler level) 23 Stack information analysis section 24 C language source file 25 Compiler 26 Linker 27 Object file 50 Work register save area 51 Argument area 52 Return address area 53 OLD FP area 54 Automatic variable area 55 Register variable save area 56 Stack frame size 57 Call End of stack area of original function (= OL
D FP) 58 Frame pointer 59 Stack pointer 60 Work register save area loaded with main function 61 Argument register save area loaded with main function 62 Return address area loaded with main function 63 Work register save loaded with funcA function Area 64 Register save area for arguments loaded by funcA function 65 Return address area loaded by funcA function 70 Argument information of program execution trace 71 Return value information of program execution trace

Claims (6)

[Claims] 1. A software debugging apparatus for converting a source program to be inspected into an object code by a compiling process and verifying the source program by sequentially executing a process according to the object code, wherein: A break point setting management unit for setting a software break condition at a start address and an end address of the function; and a function execution history data storage unit for storing function execution information in the order of execution of the functions. A software debug device comprising means for generating the function execution history data by analyzing a stack memory each time a condition is satisfied. 2. The software debugging apparatus according to claim 1, further comprising means for generating function call stack information from information registered in the function execution history data storage. 3. The software debugging apparatus according to claim 1, further comprising: means for generating execution trace information at a high-level language level from information registered in the function execution history data storage unit. 4. A software debugging method for converting a source program to be inspected into an object code by a compiling process and verifying the source program by sequentially executing a process according to the object code, wherein: A software break condition is set at a start address and an end address of a function, and each time the software break condition is satisfied, function execution history data is generated by analyzing a stack memory, and the function execution information is stored in the execution order of the function. A software debugging method characterized by storing a function execution history data storage unit to be stored. 5. The software debugging method according to claim 4, wherein function call stack information is generated from information registered in the function execution history data storage. 6. The software debugging method according to claim 4, wherein high-level language-level execution trace information is generated from the information registered in the function execution history data storage unit.