WO2024069730A1

WO2024069730A1 - Debugging device and debugging method

Info

Publication number: WO2024069730A1
Application number: PCT/JP2022/035836
Authority: WO
Inventors: 勝己奥田
Original assignee: 三菱電機株式会社
Priority date: 2022-09-27
Filing date: 2022-09-27
Publication date: 2024-04-04

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

Debugging device and debugging method

This invention relates to debugging programs executed on a computer.

Debugging is essential in computer program development. Even experienced programmers find it difficult to create a program that works 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 errors. A debugger provides the ability to stop a running program and step through it. Using a debugger, a programmer can freely read and write data while the program is stopped. In this case, the user does not need to rewrite the program to debug, allowing the work to proceed more efficiently.

Step execution can be performed on a per-instruction basis in machine language programs, or on a per-statement basis in high-level languages. When debugging a high-level language program, step execution on a per-statement basis is essential. One method for performing step execution on a per-statement basis is disclosed in Patent Document 1. In the high-level language step execution method disclosed in Patent Document 1, which causes a computer that operates based on a source program written in a high-level language to step execute, one statement in the high-level language is executed by successively executing the machine code corresponding to one line of the source program as a step execution unit.

JP 61-180342 A

In this way, conventional step execution means were realized by successively executing a series of machine language instructions equivalent 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 whose order is jumbled up, making it impossible to step through each line in the correct order. As a result, in order to support step execution, it is necessary to use a program without optimization, which results in a problem of slow execution speed. In order to solve this problem, the object of this invention is to provide users with the same debugging functionality as programs without optimization, while primarily executing programs with optimization.

The debugging device according to the present invention is a debugging device that includes a program execution means for 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 means for setting breakpoints at the instruction level in two locations, the optimized code and the non-optimized code, when a breakpoint is specified at a position 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 a breakpoint in the optimized code set by the breakpoint setting means.

The debugging method according to the present invention is a debugging method including 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 the instruction level in two locations, the optimized code and the non-optimized code, when the breakpoints are specified at the position of the source code, and 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 a breakpoint in the optimized code set by the breakpoint setting means.

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.

FIG. 1 is a block diagram showing an example of a debugging device according to a first embodiment. FIG. 2 is a diagram showing an example of a program that is assumed to be the target of debugging. FIG. 3 shows an example of the result of disassembling the optimized code. FIG. 4 is an example of a line number table for optimized code. FIG. 5 is a diagram showing an example of the disassembled result of code without optimization. FIG. 6 is a diagram showing an example of a line number table for non-optimized code. FIG. 7 is an example of a flowchart of the breakpoint management means. FIG. 8 is an example of a flowchart of a breakpoint setting process. FIG. 9 is an example of a flowchart of a breakpoint clear process. FIG. 10 is an example of a flowchart of the breakpoint management means.

Embodiment 1
In this invention, a 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, etc., instead of a real CPU. The program 102 to be debugged is a program obtained by compiling a program in a high-level language. The program 102 to be debugged is composed of various data 103, code 104, etc., and is stored in a storage device such as a memory.

The code 104 is composed of optimized code 105 and non-optimized code 106. The optimized code 105 and non-optimized code 106 are machine code 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 non-optimized code 106. The code 104 that is normally executed by the program execution means 101 is optimized code 105. On the other hand, while providing interactive operations to the user, the program execution means 101 executes the non-optimized code 106. In other words, the program execution means 101 executes the debug target program 102 that includes optimized code 105 and non-optimized code 106 that correspond to the same source code, as well as a line number table 109 for the optimized code 105 and a line number table 109 for the non-optimized code 106.

The breakpoint management means 107 is composed of a breakpoint setting means 120 and a breakpoint switching means 121. The breakpoint setting means 120 accepts breakpoints by the high-level language source file name and line number, and sets breakpoints in both the optimized code 105 and the non-optimized code 106 using the line number table 109 and the symbol table 110. In other words, 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.

The execution control means 108 switches the code to be executed by the program execution means 101 from optimized code 105 to non-optimized code 106 based on the set breakpoint. In addition, the line number table 109 holds the correspondence information between the line numbers of the source program and the instruction addresses of the non-optimized code 106.

The 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. Here, for one function name in the source code, the symbol table 110 holds both the address of the optimized code 105 and the address of the non-optimized code 106. The symbol table 110 also includes the start address and size of the function. For this reason, the function can be identified by searching the symbol table 110 for the address of an instruction that constitutes part of the function. For example, if an entry in the symbol table 110 has a start address f and a size s of a function, it is possible to confirm whether the instruction at address a is part of a function by determining whether a 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, etc. can be obtained from the address of part of the function.

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

Figure 2 is an example of a program that is intended to be debugged. As an example, let us consider the case of debugging part of a payroll calculation program. Here, we 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 the programmer intended.

To perform this type of step execution, the programmer sets a breakpoint on line 8 and then starts running the program. After a while, when the program stops at the breakpoint on line 8, the debugger will offer the programmer interactive operations such as stepping through the program. If 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.

If you try to achieve the above debugging using conventional debugging methods, you need to use non-optimized code 106. In other words, if the optimized code 105 of the function wage in FIG. 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.

First, FIG. 3 shows the result of disassembling optimized code 105 generated from the source program in FIG. 2. The format of FIG. 3 conforms to the format of the disassembly result by the objdump command of GNU binutils. The first line indicates that the function wage starts at address 0x740. Furthermore, lines 2 to 10 show the result of disassembling the instruction sequence contained in wage. For example, line 2 indicates that the instruction code at address 740 is 0xd2e80880, and its mnemonic is mov. Furthermore, this mov instruction means that the immediate value 0x4044000000000000 is stored in register x0. Note that the details of each instruction are not directly related to this invention, so an explanation will be omitted.

Next, FIG. 4 shows line number table 109 for optimized code 105 corresponding to function wage in FIG. 2. The format of line number table 109 in FIG. 4 conforms to the output format of the line number information dump result by the readelf command of GNU binutils. Lines 3 to 16 show the correspondence between each line of the actual source code and an address, 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 shows that line 5 of file name wage.c exists at address 0x740 in optimized code 105. It can be seen from FIG. 4 that the debugger cannot perform step execution at the source code level using optimized code 105. For example, lines 3 to 5 in FIG. 4 show that address 0x740 corresponds to

lines

5, 6, and 7 of the source code. For this reason, even if the instruction at address 0x740 is executed with the intention of executing

only lines

5 and 6, it turns out that part of the processing corresponding to

lines

5, 6, and 7 is also executed. Therefore, with the conventional debugging method, when optimized code 105 is used, the problem is that it is not possible to step through the source code line by line.

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

Interactive interaction with the user begins when the program stops at a breakpoint.

Below, we first show a concrete example of non-optimized code 106 and its line number table 109, and then show how to switch to non-optimized code 106. Note that line number table 109 is made up of an address correspondence table for non-optimized code 106 and an address correspondence table for optimized code 105.

First, the disassembly result of the non-optimized code 106 corresponding to the wage function in FIG. 3 is as shown in FIG. 5. Also, the line number table 109 for the non-optimized code 106 is shown in FIG. 6. Note that in FIG. 6, _O2 is added to the end of the base name wage of the original file name wage.c, such as wage_O0.c, so that it can be seen that this is for the non-optimized code 106 generated from wage.c. Lines 2 to 27 in FIG. 5 are the code corresponding to the processing of the function wage, and start from address 0x780. Lines 3 to 10 in FIG. 6 indicate which addresses in the non-optimized code 106 in FIG. 5 correspond to lines 5 to 13 in the program in FIG. 2. Unlike the case of the optimized code 105, each address always corresponds to only one line, and it can be seen that the order of the line numbers in the source code and the order of the addresses in the non-optimized code 106 are arranged in the same order.

In other words, the line numbers of the non-optimized code 106 in FIG. 6 are all different numbers, and the instruction sequence is arranged in ascending order. In contrast, the line numbers of the optimized code 105 in FIG. 4 include some identical numbers and some numbers that are swapped, and the lines of the source program are converted into multiple instruction sequences with their order jumbled up, making it impossible to execute each line in the correct order. For this reason, while it is easy to trace the line numbers of the source code from the non-optimized 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 non-optimized code 106.

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

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.

However, since the program execution means 101 normally executes 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 stopped at the auxiliary breakpoint, the execution control means 108 switches from the optimized code 105 to the non-optimized code 106.

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.

Figure 7 is a flowchart of the breakpoint management means 107. The input is 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.

First, in step S701, the address x corresponding to the file name s and line number n is searched and obtained from the line number table 109 for the non-optimized code 106. For example, when the 8th line 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 the 6th line in FIG. 6 that the 8th line 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.

Next, in step S702, function f containing instruction address x is searched for in symbol table 110, and the starting address y of function f in non-optimized code 106 is obtained. For example, if function f is wage, the starting address y starts from address 0x780 as shown in the second line of FIG. 5. This wage and 0x780 are obtained by searching symbol table 110 using instruction address x, i.e., 0x7b0.

Next, in step S703, the starting address y' of the optimized code 105 of function f is obtained from the symbol table 110. When searching the symbol table 110 in step S703, the symbol name of 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 non-optimized 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 is obtained by searching the symbol table 110 for the starting address of the optimized wage function.

When a breakpoint is specified, the breakpoint setting means 120 sets an auxiliary breakpoint at the beginning of a subroutine that includes the location of the specified breakpoint as a part of it. 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 it is possible to switch from the optimized code 105 to the non-optimized code 106, and which includes a source code level breakpoint at a position relatively close to the source code level breakpoint specified by the user.

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 specified breakpoint as part of it.

In step S704, depending on whether the user operation is to set or clear (delete) a breakpoint, the process proceeds to step S705 or step S706, respectively. Both steps S705 and S706 are processes that take as 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).

Below, the procedure for setting a breakpoint and the procedure for clearing a breakpoint are explained using the flowcharts in Figures 8 and 9, respectively.

FIG. 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 non-optimized code 106, y is the start address of function f in the non-optimized code 106, 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 FIG. 2, which has been used as an example so far, is (0x7b0, 0x780, 0x740).

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 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.

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 Figure 3.

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

FIG. 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 non-optimized code 106 is cleared.

Next, in step S903, it is confirmed whether or not there is an entry corresponding to address y in auxiliary breakpoint table 111. If there are entries corresponding to addresses y, y' of function f in 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 optimized code 105 is cleared and the process ends. The method of clearing the instruction level breakpoint is the same as conventional, whether it is implemented as a hardware breakpoint or a software breakpoint.

When deleting an auxiliary breakpoint, the breakpoint setting means 120 checks whether the auxiliary breakpoint is shared. In step S903, it is checked whether there is an entry corresponding to address y in the auxiliary breakpoint table 111, because auxiliary breakpoint y allows multiple source level breakpoints to share a single auxiliary breakpoint.

For example, if two source-level breakpoints are set in

lines

8 and 9 of the source code wage.c in FIG. 8, both auxiliary breakpoints will be the start address of the function wage in the optimized code 105. In this case, if there is no confirmation process in step S903, 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 there is confirmation process in step S903, the clearing of the auxiliary breakpoints is skipped, so the source-level breakpoint on line 9 will remain valid even after the source-level breakpoint on line 8 is cleared.

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 non-optimized code 106y'. Immediately after a function call, arguments and a return address are stored at the top of the CPU stack, and the stack for saving local variables and registers has not yet been used. Therefore, the optimized code 105 can continue execution by taking over the stack frame initialized by the optimized code 105.

Next, the operation of the breakpoint management means 107, and in particular the breakpoint switching means 121, is shown using the flowchart in FIG. 10.

The breakpoint switching means 121 is a procedure means that is executed when the program stops at an instruction breakpoint. If the input of the process in the flowchart in 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 in FIG. 3, B is 0x740.

In step S1001, a check is made to see if the instruction address B at which 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. Note that 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 non-optimized code 106, the start address y' of the function in the optimized code 105, and the start address y of the function in the non-optimized code 106.

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

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

Here, an entry where y' = B is searched for, and the start address y of the function in the non-optimized 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.

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.

On the other hand, in step S1004, interactive operations are offered to the user to start interactive processing in order to stop 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 non-optimized code 106, so operations such as step execution and display of local variables can be offered to the user.

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 stopped instruction address B is an auxiliary breakpoint, then at this point the code 104 has switched from optimized code 105 to non-optimized code 106. After the program continues to run for a while, it stops at the breakpoint in 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 non-optimized code 106, so variable values can be displayed and step execution can be performed in the same manner as before.

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 the descriptive language of the program that is to be converted into a machine language program. The source language includes not only programming languages with textual expressions, but also visual programming languages. Examples of visual languages include the FBD language of IEC 61131-3 and block diagrams such as those used in MATLAB (registered trademark)/Simulink.

In this embodiment, the line number is a kind of address for specifying a specific statement in the 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 the 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.

As another example of a conversion unit, in the case of a block diagram such as MATLAB (registered trademark)/Simulink, the conversion unit can be a subsystem. Furthermore, when the source language is another machine language, basic blocks and superblocks, in addition to subroutines of a machine language program, can be considered as conversion units. 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. Furthermore, when the source language is a machine language, the address of the machine language corresponds to the line number in this embodiment.

In addition, the above explanation is based on the assumption that the optimized code 105 and the non-optimized code 106 contain the same functions. However, there are cases in which a function is inline-expanded into another function due to optimization. For example, if function f is inline-expanded into function g due to optimization, an auxiliary breakpoint cannot be set at the beginning of function foo in optimized code 105. Even if it were possible to set a breakpoint, the inline-expanded code 104 would be executed, so the program would not stop at the auxiliary breakpoint. To deal with such cases, when setting a breakpoint in function f, an auxiliary breakpoint can be set at the beginning of function g, which is the destination of the inline expansion of function f.

In addition, this embodiment has been described assuming that the non-optimized code 106 is pre-loaded in the main memory, but 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 start of debugging operations.

As described above, the debugging device is equipped with a program execution means for executing a program having 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 means for setting breakpoints at the instruction level in two locations, the optimized code and the non-optimized code, when a breakpoint is specified at a position 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 a breakpoint in the optimized code set by the breakpoint setting means.

The debugging method also includes a program execution step 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, a breakpoint setting step for setting breakpoints at the instruction level in two locations, the optimized code and the non-optimized code, when the breakpoints are specified at the position of the source code, and a breakpoint switching step for switching the code to be executed from the optimized code to the non-optimized code when the program stops at a breakpoint in the optimized code set by the breakpoint setting means.

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

Embodiment 2.
In the first embodiment, no mention is made of the function call configuration of the optimized code 105 and the non-optimized code 106. When function A calls function B, the call of function B in the non-optimized code 106A usually becomes a call of function B in the non-optimized code 106. However, there is a problem that the execution speed decreases if function A is executed line by line in the non-optimized code 106 in order to execute function A in a stepwise manner up to function B. Therefore, in this embodiment, non-optimized code 106 is used in which any call of f in the non-optimized code 106 becomes a call to function f in the optimized code 105.

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

Here, there may be a case where you want to step into function B. Therefore, when you step into function B, you switch from optimized code 105 to non-optimized code 106 at the beginning of function B. One way to achieve this kind of switching is to implement the step-in operation with 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, and clearing breakpoint B after stopping at breakpoint B. By directly applying the method shown in embodiment 1 to setting the breakpoint, function B can be step-executed as non-optimized code 106.

101 program execution means, 102 program to be debugged, 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

a program execution means for executing a program having an optimized code and a 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, one in the optimized code and the other in 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. A debug device according to claim 1, comprising:
When the breakpoint is specified, the breakpoint setting means
A debugging device comprising: a step of setting an auxiliary breakpoint at the beginning of a subroutine located higher in a call graph than a subroutine that includes the location of the breakpoint as a part of the subroutine;
2. A debug device according to claim 1, comprising:
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 which includes the position of the specified breakpoint as a part of the subroutine.
4. A debug device according to claim 2, further comprising:
Debugging device according to claim 1, wherein said breakpoint setting means, when deleting said auxiliary breakpoint, checks whether said auxiliary breakpoint is shared or not.
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 breakpoints at an instruction level at two locations in the optimized code and the non-optimized code when the breakpoints are specified at a location in the source code;
and a breakpoint switching step of switching a 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.