Debugging device and debugging method

Abstract

The debugging device comprises: a program execution means (101) which executes a program including an optimized code (105) and an unoptimized code (106) corresponding to the same source code and a line number table for the optimized code and a line number table for the unoptimized code; a breakpoint setting means (120) which, when a breakpoint is designated at a position in the source code, sets the breakpoint in two portions of the optimized code (105) and the unoptimized code (106) at a command level; and a breakpoint switching means (121) which, when the program stops at the breakpoint, which is set by the breakpoint setting means (120), in the optimized code (105), switches the code to be executed from the optimized code (105) to the unoptimized code (106).

Description

[Technical Field]

[0001] The present invention relates to debugging of a program executed on a computer.

[0002] Debugging is essential in developing computer programs. Even experienced programmers find it difficult to create programs that work as expected from the start. Usually, a program is written once, then run and tested, and the program is rewritten while checking the test results. If a program does not work as expected, the programmer debugs the program to find the error. A debugger provides functions to stop and step through a running program. By using a debugger, programmers can freely read and write data while the program is stopped. In this case, users do not need to rewrite the program for debugging, allowing them to work more efficiently.

[0003] There are two types of step execution: step execution on an instruction-by-instruction basis in machine language programs, and step execution on a statement-by-statement basis in high-level languages. When debugging high-level language programs, step execution on a statement-by-statement basis is essential. A method for step execution on a statement-by-statement basis is disclosed in Patent Document 1. The high-level language step execution method disclosed in Patent Document 1 is a high-level language step execution method for stepping a computer that operates based on a source program written in a high-level language, in which one line of the source program is treated as a step execution unit and machine code corresponding to that line is successively executed to step execute one statement in the high-level language. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent Publication No. 61-180342 Summary of the Invention [Problem to be solved by the invention]

[0005] As described above, conventional step execution means achieve this by successively executing a series of machine language instructions corresponding to one line of a source program. However, when a source program is optimized, the lines of the source program are converted into multiple instruction sequences with a jumbled order, making it impossible to execute each line step by step in the correct order. As a result, to support step execution, it is necessary to use a program without optimization, which results in a problem of slow execution speed. To solve this problem, the present invention aims to provide users with the same debugging capabilities as for programs without optimization, while primarily executing optimized programs. [Means for solving the problem]

[0006] A debugging device according to the present invention is a debugging device comprising: program execution means for executing a program having optimized code and non-optimized code corresponding to the same source code, and a line number table for the optimized code and a line number table for the non-optimized code; breakpoint setting means for setting breakpoints at the instruction level in two locations, in the optimized code and the non-optimized code, when the breakpoints are specified at a position in the source code; and breakpoint switching means for switching the code to be executed from optimized code to non-optimized code when the program stops at a breakpoint in the optimized code set by the breakpoint setting means.

[0007] A debugging method according to the present invention includes a program execution step of executing a program having optimized code and non-optimized code corresponding to the same source code, and a line number table for the optimized code and a line number table for the non-optimized code; a breakpoint setting step of setting breakpoints at instruction levels at two locations in the optimized code and the non-optimized code when breakpoints are specified at positions in the source code; Step by stepThis is a debugging method that includes a breakpoint switching step of switching the code to be executed from optimized code to non-optimized code when the program stops at a breakpoint that has been set in the optimized code. [Effects of the Invention]

[0008] In this invention, a program can be executed at high speed using optimized code until a source code level breakpoint is set, and after the breakpoint is set, interactive debugging operations such as step execution can be provided using non-optimized code. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a block diagram showing an example of a debugging device according to a first embodiment. [Figure 2] FIG. 2 is a diagram showing an example of a program that is assumed to be the target of debugging. [Figure 3] FIG. 3 shows an example of the results of disassembling the optimized code. [Figure 4] FIG. 4 shows an example of a line number table for optimized code. [Figure 5] FIG. 5 shows an example of the disassembled result of code without optimization. [Figure 6] FIG. 6 is a diagram showing an example of a line number table for code without optimization. [Figure 7] FIG. 7 is an example of a flowchart of the breakpoint management means. [Figure 8] FIG. 8 is an example of a flowchart of a breakpoint setting process. [Figure 9] FIG. 9 is an example of a flowchart of a breakpoint clearing process. [Figure 10] FIG. 10 is an example of a flowchart of the breakpoint management means. DETAILED DESCRIPTION OF THE INVENTION

[0010] Embodiment 1 In this invention, program execution means 101 executes a program 102 to be debugged. The program execution means 101 is a CPU (Central Processing Unit), but may be a CPU emulator, a virtual machine, an interpreter, an instruction set simulator, or the like, instead of an actual CPU. The program 102 to be debugged is a program obtained by compiling a program written in a high-level language. The program 102 to be debugged is composed of various data 103, code 104, and the like, and is stored in a storage device such as a memory.

[0011] The code 104 is composed of optimized code 105 and unoptimized code 106. The optimized code 105 and unoptimized code 106 are machine language codes 104 generated from the same source program, and there are two types of code for each function of the original source program: optimized code 105 and unoptimized code 106. The code 104 normally executed by the program execution means 101 is the optimized code 105. On the other hand, while providing interactive operations to the user, the program execution means 101 executes the unoptimized code 106. That is, the program execution means 101 executes the debug target program 102 which includes the optimized code 105 and unoptimized code 106 corresponding to the same source code, as well as the line number table 109 for the optimized code 105 and the line number table 109 for the unoptimized code 106.

[0012] The breakpoint management means 107 is composed of a breakpoint setting means 120 and a breakpoint switching means 121. The breakpoint setting means 120 receives a breakpoint by a source file name and a line number in a high-level language, and sets a breakpoint in both the optimized code 105 and the non-optimized code 106 using the line number table 109 and the symbol table 110. That is, when a breakpoint is specified by a position in the source code, the breakpoint setting means 120 sets breakpoints at the instruction level in two locations: the optimized code 105 and the non-optimized code 106. The locations at which breakpoints are set will be explained in detail later.

[0013] Based on the set breakpoint, execution control means 108 switches the code to be executed by program execution means 101 from optimized code 105 to unoptimized code 106. Furthermore, line number table 109 holds correspondence information between line numbers of the source program and instruction addresses of unoptimized code 106.

[0014] Symbol table 110 holds the address and area size corresponding to each symbol, such as a variable name or a function name, in the source code. For each function name in the source code, symbol table 110 holds both the address of optimized code 105 and the address of unoptimized code 106. Symbol table 110 also includes the start address and size of the function. Therefore, a function can be identified by searching symbol table 110 for the address of an instruction that constitutes part of the function. For example, if an entry in symbol table 110 specifies that the start address of a function is f and its size is s, it is possible to determine whether the instruction at address a is part of the function by determining whether the given address a is greater than or equal to f and less than f+s. By repeating this process for all symbol table 110 entries, the start address of the function, the symbol name, and the like can be obtained from the address of part of the function.

[0015] Below, we will first show a step execution scenario that can be realized in this embodiment using the example of debugging a simple program, and then we will explain in detail the problems with conventional debugging methods and the breakpoint management means 107 and execution control means 108 unique to this invention that solve these problems.

[0016] Figure 2 is an example of a program that can be debugged. As an example, consider the case where part of a payroll calculation program is being debugged. Here, assume that the programmer wants to step through lines 8 and 9 of the program in Figure 2 and check whether the overtime salary has been calculated correctly. In this case, the programmer can step through lines 8 and 9 and obtain the values ​​of the variables overtime and salary to check whether the salary, including the overtime salary, has been calculated as intended by the programmer.

[0017] To perform this type of step execution, the programmer sets a breakpoint on line 8 and then starts executing the program. After a while, when the program stops at the breakpoint on line 8, the debugger will allow the programmer to perform interactive operations such as stepping through the program. When the programmer instructs the debugger to step through line 8, the program will stop at line 9. If the programmer then instructs the debugger to step through the program again, the program will stop at line 10.

[0018] If you try to achieve the above debugging using a conventional debugging method, you need to use non-optimized code 106. In other words, if the optimized code 105 of the function wage in Figure 2 is the debugging target, you cannot perform the above debugging. This problem will be explained below using the optimized code 105 of wage and the corresponding line number table 109.

[0019] First, Figure 3 shows the results of disassembling optimized code 105 generated from the source program in Figure 2. The format of Figure 3 conforms to the format of the disassembly results using the objdump command of GNU binutils. Line 1 indicates that the function wage starts at address 0x740. Lines 2 through 10 show the results of disassembling the instruction sequence included in wage. For example, line 2 indicates that the instruction code at address 740 is 0xd2e80880, which means that the mnemonic is mov. Furthermore, this mov instruction stores the immediate value 0x4044000000000000 in register x0. Note that the details of each instruction are not directly related to this invention, so a detailed explanation will be omitted.

[0020] Next, Figure 4 shows the line number table 109 for the optimized code 105 corresponding to the wage function in Figure 2. The format of the line number table 109 in Figure 4 conforms to the output format of the line number information dump result using the GNU binutils readelf command. Lines 3 to 16 show the correspondence between each line and address in the actual source code, with the first column showing the file name, the second column showing the line number, and the third column showing the corresponding address. For example, line 3 indicates that line 5 of the file named wage.c is located at address 0x740 in the optimized code 105. Figure 4 shows that the debugger cannot perform source code level step execution using the optimized code 105. For example, lines 3 to 5 in Figure 4 indicate that address 0x740 corresponds to lines 5, 6, and 7 in the source code. Therefore, even if you execute the instruction at address 0x740 intending to execute only lines 5 and 6, some of the processing corresponding to lines 5, 6, and 7 will also be executed. Therefore, in the conventional debugging method, when the optimized code 105 is used, the problem is that it is not possible to execute the source code line by line.

[0021] The basic idea of ​​this invention is to switch to and execute the unoptimized code 106 only while debugging is providing interactive operations to the user. This switching is automatically performed by the breakpoint switching means 121, so the user can perform general debugging operations such as step execution and variable display as if the unoptimized code 106 had been executed from the beginning.

[0022] Interactive operation with the user begins when the program stops at a breakpoint.

[0023] Below, we will first show a specific example of the non-optimized code 106 and its line number table 109, and then show how to switch to the non-optimized code 106. The line number table 109 is made up of an address correspondence table for the non-optimized code 106 and an address correspondence table for the optimized code 105.

[0024] First, Figure 5 shows the disassembled result of the unoptimized code 106 corresponding to the wage function in Figure 3. Figure 6 also shows the line number table 109 for the unoptimized code 106. Note that in Figure 6, _O2 is added to the end of the base name "wage" in the original file "wage.c," e.g., "wage_O0.c," to indicate that this is for the unoptimized code 106 generated from "wage.c." Lines 2 to 27 in Figure 5 are the code corresponding to the processing of the function "wage," and begin at address 0x780. Lines 3 to 10 in Figure 6 also indicate the correspondence between lines 5 to 13 in the program in Figure 2 and the addresses in the unoptimized code 106 in Figure 5. Unlike the optimized code 105, each address corresponds to only one line, and the order of the line numbers in the source code and the order of the addresses in the unoptimized code 106 are the same.

[0025] In other words, the line numbers in the unoptimized code 106 in Figure 6 are all different numbers, and the instruction sequences are arranged in ascending order. In contrast, the line numbers in the optimized code 105 in Figure 4 include some duplicated numbers and some numbers being swapped, and the source program lines are converted into multiple instruction sequences with a jumbled order, making it impossible to execute each line step in the correct order. For this reason, while it is easy to trace the line numbers of the source code from the unoptimized code 106, it is not easy to trace the line numbers of the source code from the optimized code 105. Naturally, the execution speed of the optimized code 105 is faster than that of the unoptimized code 106.

[0026] The following describes the procedure for setting a source code-level breakpoint when the user sets one on line n of the source code of file name s. Here, we will show a solution method using an example of this embodiment. Hereinafter, in this specification, we will refer to a breakpoint specified by a pair of a file name and a line number as a source-level breakpoint, and a breakpoint specified by the memory address of the instruction at which program control means 108 actually stops as an instruction-level breakpoint, to distinguish between the two.

[0027] The breakpoint setting means 120 sets an instruction level breakpoint at an instruction address in the unoptimized code 106 that corresponds to the source file name s and line number n specified by the user.

[0028] However, since the program execution means 101 normally executes the optimized code 105, the non-optimized code 106 is never executed. Therefore, the breakpoint management means 107 also sets an auxiliary instruction-level breakpoint in the optimized code 105 so that the execution control means 108 can switch the code 104 to be executed from the optimized code 105 to the non-optimized code 106. When the execution control means 108 stops at the auxiliary breakpoint, it switches from the optimized code 105 to the non-optimized code 106.

[0029] In other words, when the program stops at a breakpoint in the optimized code 105 set by the breakpoint setting means 120, the breakpoint switching means 121 switches the code to be executed from the optimized code 105 to the non-optimized code 106.

[0030] 7 is a flowchart of the breakpoint management means 107. The inputs are the file name s, line number n, and type of breakpoint operation specified by the user. There are two types of breakpoint operations that can be specified: set or clear.

[0031] First, in step S701, the address x corresponding to the file name s and line number n is searched for and obtained from the line number table 109 for the non-optimized code 106. For example, if line 8 of the program wage.c in FIG. 2 is specified, s is wage.c and n is 8. In this case, it can be seen from line 6 in FIG. 6 that line 8 of wage.c starts at address 0x7b0. Therefore, in this case, x is 0x7b0. Note that in FIG. 6, wage.c has been renamed to wage_O0.c to indicate that this is non-optimized code 106.

[0032] Next, in step S702, function f including instruction address x is searched for in symbol table 110, and the start address y of function f in unoptimized code 106 is obtained. For example, if function f is wage, the start address y starts from address 0x780 as shown in the second line of Figure 5. Wage and 0x780 are obtained by searching symbol table 110 using instruction address x, i.e., 0x7b0.

[0033] Next, in step S703, the starting address y' of the optimized code 105 of the function f is obtained from the symbol table 110. When searching the symbol table 110 in step S703, the symbol name of the function f obtained when searching the symbol table 110 in step S702 can be used. As described above, the symbol table 110 holds the addresses of both the optimized code 105 and the unoptimized code 106 for each function. For example, when the function f is wage, the starting address y' of the optimized function wage is 0x740 from the second line in FIG. 3. This 0x740 can be obtained by searching the symbol table 110 for the starting address of the optimized wage function.

[0034] When a breakpoint is specified, the breakpoint setting means 120 sets an auxiliary breakpoint at the beginning of a subroutine that includes the breakpoint position as a part of the specified breakpoint. This allows the program to be executed at high speed by executing the optimized code 105 up to a position as close as possible to the source code level breakpoint. Here, the beginning of the subroutine is a position where switching from the optimized code 105 to the non-optimized code 106 is possible, and a position relatively close to the source code level breakpoint specified by the user includes the source code level breakpoint.

[0035] In other words, when a breakpoint is specified, the breakpoint setting means 120 sets an auxiliary breakpoint at the beginning of a subroutine that is higher in the call graph than the subroutine that includes the location of the breakpoint as part of it.

[0036] In step S704, the process proceeds to step S705 or step S706 depending on whether the user operation is to set or clear (delete) a breakpoint. Both step S705 and step S706 are processes that input the address x in the non-optimized code 106, the start address y of function f in the non-optimized code 106, and the address y' of function f in the optimized code 105. In step S705, a breakpoint is set, and in S706, the breakpoint is cleared (deleted).

[0037] Below, the procedure for setting a breakpoint and the procedure for clearing a breakpoint will be explained using the flowcharts in Figures 8 and 9, respectively.

[0038] Figure 8 is a flowchart of the breakpoint setting process. The input is a triplet of addresses (x, y, y'). Here, x is an address in the unoptimized code 106, y is the start address of function f in the unoptimized code 106, and y' is the start address of function f in the optimized code 105, and function f is a function that includes the instruction at address x as part of it. For example, the triplet corresponding to line 8 of the program wage.c in Figure 2, which has been used as an example so far, is (0x7b0, 0x780, 0x740).

[0039] In step S801, an instruction-level breakpoint is set at address x. The method for setting an instruction-level breakpoint is the same as in the past, and either a hardware breakpoint or a software breakpoint can be used. For example, if x is 0x7b0, a breakpoint is set at the instruction corresponding to line 14 in Figure 5.

[0040] Next, in step S802, an instruction-level breakpoint is set at the starting address y'. For example, if y' is 0x740, a breakpoint is set at the instruction corresponding to the second line in FIG.

[0041] Finally, in step S803, the information of (x, y, y') is added to the auxiliary breakpoint table. The triplet (x, y, y') is stored in the auxiliary breakpoint table 111.

[0042] 9 is a flowchart of the breakpoint clearing process. The input is the same as in the breakpoint setting process. In step S901, the triplet (x, y, y') is deleted from the auxiliary breakpoint table 111. Next, in step S902, the instruction-level breakpoint at address x in the unoptimized code 106 is cleared.

[0043] Next, in step S903, it is checked whether there is an entry corresponding to address y in the auxiliary breakpoint table 111. If there is an entry corresponding to addresses y, y' of function f in the auxiliary breakpoint table 111, step S904 is skipped and the process ends. On the other hand, if there is no entry, the process proceeds to step S904. In step S904, the instruction-level breakpoint at the start address y of function f in the optimized code 105 is cleared and the process ends. The method of clearing an instruction-level breakpoint is the same as conventional, whether it is implemented as a hardware breakpoint or a software breakpoint.

[0044] When deleting an auxiliary breakpoint, the breakpoint setting means 120 checks whether the auxiliary breakpoint is shared. The reason for checking in step S903 whether there is an entry corresponding to address y in the auxiliary breakpoint table 111 is that auxiliary breakpoint y allows multiple source-level breakpoints to share a single auxiliary breakpoint.

[0045] For example, if two source-level breakpoints are set in lines 8 and 9 of the source code wage.c in Figure 8, both auxiliary breakpoints will be set to the start address of the function wage in the optimized code 105. In this case, if the confirmation process of step S903 is not performed, clearing the breakpoint on line 8 of wage.c will also clear the auxiliary breakpoint for the source-level breakpoint on line 9. As a result, the source-level breakpoint on line 9 will also be disabled. If the confirmation process of step S903 is performed, the clearing of the auxiliary breakpoints is skipped, and the source-level breakpoint on line 9 will remain valid even after the source-level breakpoint on line 8 is cleared.

[0046] When the program stops at the start address y of function f, the execution control means 108 can switch from the start address y of the optimized code 105 of function f to the unoptimized code 106y'. Immediately after a function call, arguments and a return address are stored at the top of the CPU stack, and the stacks for saving local variables and registers are not yet in use. Therefore, the optimized code 105 can continue execution by taking over the stack frame initialized by the optimized code 105.

[0047] Next, the operation of the breakpoint management means 107, particularly the breakpoint switching means 121, will be described using the flowchart of FIG.

[0048] The breakpoint switching means 121 is a means of a procedure executed when a program stops at an instruction breakpoint. If the input of the process in the flowchart of Fig. 10 is the instruction address B at which the program stopped, for example, if the program stopped at the instruction level breakpoint on the second line of Fig. 3, B is 0x740.

[0049] In step S1001, it is checked whether the instruction address B where the program stopped is an auxiliary breakpoint. This can be confirmed by checking whether there is an entry in the auxiliary breakpoint table 111 where the third element y' of the triplet is the instruction address B. The triplet of entries in the auxiliary breakpoint table 111 updated in step S803 of FIG. 8 is the address x of the instruction breakpoint in the unoptimized code 106, the start address y' of the function in the optimized code 105, and the start address y of the function in the unoptimized code 106.

[0050] If the stopped instruction address B is an auxiliary breakpoint, execute steps S1002 and S1003; otherwise, execute step S1004. For example, when the stopped instruction address B is 0x740, if the auxiliary breakpoint table 111 contains (0x7b0, 0x780, 0x740), the stopped instruction address B is an auxiliary breakpoint.

[0051] In step S1002, the switch destination address B' is obtained from the auxiliary breakpoint table 111.

[0052] Here, an entry where y'=B is searched for, and the start address y of the function in the unoptimized code 106 of that entry is used as the switch destination address B'. If the stopped instruction address B is 0x740 and the entry obtained from the auxiliary breakpoint table 111 is (0x7b0, 0x780, 0x740), the switch destination address B' is 0x780.

[0053] Next, in step S1003, the program execution means 101 switches the current program counter of the program to be debugged from the stopped instruction address B to the switch destination address B', and the process proceeds to step S1005.

[0054] Meanwhile, in step S1004, interactive processing is started by offering the user interactive operations to stop the program at a normal breakpoint. For example, if a breakpoint is set on line 8 of the program in Figure 3 used as an example so far, the program will stop at address 0x7b0, which corresponds to line 14 in Figure 5, as a normal breakpoint. At this point, the program has already switched to the non-optimized code 106, so the user can perform operations such as step execution and display of local variables.

[0055] When step S1004 is completed, the process proceeds to step S1005. In step S1005, execution of the debug target program 102 is resumed. If the instruction address B where the debug target was stopped is an auxiliary breakpoint, the code 104 has switched from the optimized code 105 to the non-optimized code 106 at this point. After the program continues to run for a while, it stops at the breakpoint in the non-optimized code 106, and processing stops again. This series of processes is performed automatically, so the user does not notice that the program has stopped. On the other hand, if the breakpoint is not an auxiliary address, the execution control means 108 enters a state where it waits for an operation from the user. In this state, the debug target has already switched to the non-optimized code 106, so it is possible to display variable values ​​and perform step execution in the same way as before.

[0056] In this embodiment, C language is used as an example of a high-level language, but the present invention does not limit the high-level language to C language. In this invention, the high-level language is assumed to be a program description language that is to be converted into a machine language program. The conversion source language includes not only programming languages ​​with textual representation but also visual programming languages. Examples of visual languages ​​include the FBD language of IEC61131-3 and block diagrams such as those used in MATLAB (registered trademark) / Simulink.

[0057] In this embodiment, a line number is a kind of address for specifying a specific statement in source code. If the high-level language is a visual programming language, the line number corresponds to the address of a visual program element. For example, if the high-level language is a block diagram in MATLAB (registered trademark) / Simulink, the block identifier is the line number. Correspondingly, the line number table holds the correspondence between the address of a program element and the instruction address. Furthermore, the source language may be machine language. Even if the source language is different, each reusable conversion unit is converted into a machine-language-level subroutine. In this embodiment, the conversion unit is a C language function.

[0058] As another example of a conversion unit, in the case of a block diagram such as MATLAB (registered trademark) / Simulink, a subsystem can be considered as a conversion unit. Furthermore, when the source language is another machine language, basic blocks and superblocks can be considered as conversion units in addition to subroutines of a machine language program. Furthermore, the language described as a machine language in this embodiment does not need to be a machine language with a real processor, but can also be a virtual machine. Note that when the source language is a machine language, the addresses of the machine language correspond to the line numbers in this embodiment.

[0059] The above explanation is based on the assumption that the optimized code 105 and the unoptimized code 106 contain the same function. However, optimization may generally result in a function being inline-expanded into another function. For example, if function f is inline-expanded into function g through optimization, an auxiliary breakpoint cannot be set at the beginning of function foo in optimized code 105. Even if an auxiliary breakpoint could be set, the inline-expanded code 104 would be executed, and the program would not stop at the auxiliary breakpoint. To address this situation, when setting a breakpoint in function f, the auxiliary breakpoint should be set at the beginning of function g, which is the inline-expanded version of function f.

[0060] Although this embodiment has been described assuming that the non-optimized code 106 is pre-loaded in the main memory, it may be dynamically loaded when the user sets a breakpoint. By dynamically loading the non-optimized code 106 as needed, it is possible to reduce the capacity of the main memory until the debugging operation begins.

[0061] As described above, this debugging device comprises: program execution means for executing a program that has optimized code and non-optimized code corresponding to the same source code, and a line number table for the optimized code and a line number table for the non-optimized code; breakpoint setting means for setting breakpoints at the instruction level in two locations, in the optimized code and the non-optimized code, when the breakpoint is specified by a position in the source code; and breakpoint switching means for switching the code to be executed from optimized code to non-optimized code when the program stops at a breakpoint in the optimized code set by the breakpoint setting means.

[0062] The debugging method also includes a program execution step of executing a program that includes optimized code and non-optimized code corresponding to the same source code, as well as a line number table for the optimized code and a line number table for the non-optimized code; a breakpoint setting step of setting breakpoints at the instruction level at two locations in the optimized code and the non-optimized code when the breakpoints are specified at the position in the source code; and a breakpoint switching step of switching the code to be executed from optimized code to non-optimized code when the program stops at a breakpoint in the optimized code that was set by the breakpoint setting means.

[0063] This allows the program to run quickly using optimized code until a source code level breakpoint is set, and after the breakpoint is set, allows interactive debugging operations such as step execution using non-optimized code.

[0064] Embodiment 2 In the first embodiment, no mention is made of the function call configuration between optimized code 105 and unoptimized code 106. When function A calls function B, the call to function B in unoptimized code 106A typically becomes a call to function B in unoptimized code 106. However, there is a problem in that the execution speed decreases if unoptimized code 106 is used to execute function A line by line of source code up to function B. Therefore, in this embodiment, unoptimized code 106 is used in which any call of any f in unoptimized code 106 becomes a call to function f in optimized code 105.

[0065] By using such non-optimized code 106, when a call to function B is executed by stepping over when debugging function A, in this embodiment function B can be executed at a higher speed because it has been optimized.

[0066] Here, there may be a case where you want to step into function B. Therefore, when you perform a step-in operation, you switch from optimized code 105 to unoptimized code 106 at the beginning of function B. One way to achieve this kind of switching is to implement the step-in operation using a breakpoint. In this case, the step-in operation into function f is achieved by a series of processes: setting breakpoint B at the first line of function f, executing the program, stopping at breakpoint B, and then clearing breakpoint B. By directly applying the method shown in the first embodiment to setting the breakpoint, function B can be step-executed as unoptimized code 106. [Explanation of symbols]

[0067] 101 program execution means, 102 debug target program, 103 data, 104 code, 105 optimized code, 106 non-optimized code, 107 breakpoint management means, 108 execution control means, 109 line number table, 110 symbol table, 111 auxiliary breakpoint table, 120 breakpoint setting means, 121 breakpoint switching means.

Claims

1. a program execution means for executing a program including optimized code and non-optimized code corresponding to the same source code, and a line number table for the optimized code and a line number table for the non-optimized code; a breakpoint setting means for setting breakpoints at instruction levels at two locations in the optimized code and the non-optimized code when a breakpoint is specified at a location in the source code; and a breakpoint switching means for switching the code to be executed from the optimized code to the non-optimized code when the program stops at the breakpoint in the optimized code set by the breakpoint setting means.

2. 2. The debug device according to claim 1, When the breakpoint is designated, the breakpoint setting means A debugging device characterized in that an auxiliary breakpoint is set at the beginning of a subroutine that is located higher in a call graph than a subroutine that includes the position of the breakpoint as a part of the subroutine.

3. 2. The debug device according to claim 1, A debugging device characterized in that, when the breakpoint is specified, the breakpoint setting means sets an auxiliary breakpoint at the beginning of a subroutine that includes the position of the breakpoint as a part thereof.

4. 4. The debugging device according to claim 2 or 3, The debugging device is characterized in that, when deleting the auxiliary breakpoint, the breakpoint setting means checks whether the auxiliary breakpoint is shared or not.

5. a program execution step of executing a program having optimized code and non-optimized code corresponding to the same source code, and a line number table for the optimized code and a line number table for the non-optimized code; a breakpoint setting step of setting the breakpoint at an instruction level at two locations in the optimized code and the non-optimized code when the breakpoint is specified at a location in the source code; a breakpoint switching step of switching the code to be executed from the optimized code to the non-optimized code when the program stops at the breakpoint in the optimized code set in the breakpoint setting step.

Images