Debugging device and debugging method

Abstract

A debugging device is provided with: a program execution unit (101) that executes a program having an optimized code (105) and an unoptimized code (106) corresponding to the same source code, a row number table for the optimized code, and a row number table for the unoptimized code; a breakpoint setting means (120) that, when a breakpoint is specified at the position of the source code, sets the breakpoint at both the optimized code (105) and the unoptimized code (106) at a command level; and a breakpoint switching unit (121) that switches the code to be executed from the optimized code (105) to the unoptimized code (106) when the program stops at a breakpoint in the optimized code (105) set by the breakpoint setting unit (120).

Description

Technical Field

[0001] The present invention relates to debugging of programs executed by computers. Background Art

[0002] Debugging is indispensable in the development of computer programs. Even for skilled programmers, it is difficult to create a program that works as expected from the beginning. Usually, a written program is executed once for testing, and the program is rewritten while confirming the test results. In the case where the program does not work as expected, the programmer debugs the program to find the error. The debugger provides the function of stopping the executing program and executing it step by step. By using the debugger, the programmer can freely read and write data while the program is stopped. At this time, since the user does not need to rewrite the program for debugging, the work can be carried out efficiently.

[0003] In the step-by-step execution, there is the step-by-step execution of one command unit of a machine language program and the step-by-step execution of one statement unit of a high-level language. When debugging a high-level language program, the step-by-step execution of one statement unit is indispensable during debugging. As a method of step-by-step execution of one statement unit, there is the method of Patent Document 1. In the case of the step-by-step execution method of a high-level language involved in the technical solution of Patent Document 1, in the step-by-step execution method of a high-level language that causes a computer to perform operations based on a source program described in a high-level language to perform step-by-step execution, one line of the source program is used as a step-by-step execution unit, and the machine language corresponding to the one line is continuously executed, thereby step-by-step executing one statement of the high-level language.

[0004] Patent Document 1: Japanese Patent Application Laid-Open No. 61-180342 Summary of the invention

[0005] As described above, in the existing step-by-step execution unit, a series of machine language command sequences equivalent to one line of the source program are continuously executed to achieve the desired result. However, when the source program is optimized, since the lines of the source program are converted into a plurality of command sequences whose order is disrupted, it is impossible to perform step-by-step execution of each line in the correct order. Therefore, in order to support step-by-step execution, it is necessary to use an unoptimized program, which results in a slow execution speed. In the present invention, in order to solve this problem, the purpose is to mainly execute the optimized program and provide the user with the same debugging function as the unoptimized program.

[0006] The debugging device of the present invention comprises: a program execution unit which executes 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 unit which sets breakpoints at both the optimized code and the non-optimized code at a command level when a breakpoint is specified at a position of the source code; and a breakpoint switching unit which switches 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 unit.

[0007] In addition, the debugging method of the present invention comprises: 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 both the optimized code and the non-optimized code at a command level when a breakpoint is specified at a 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 a breakpoint setting unit.

[0008] Effects of the Invention

[0009] In the present invention, before setting breakpoints at the source code level, the program can be executed at high speed with optimized code, and after setting breakpoints, interactive debugging operations such as step-by-step execution can be provided using non-optimized code. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 This is a block diagram showing an example of the debugging device according to the first embodiment.

[0011] Figure 2 This is a diagram showing an example of a program assumed to be debugged.

[0012] Figure 3 This is a diagram showing an example of the result of disassembling the optimized code.

[0013] Figure 4 This is a diagram showing an example of a line number table for optimized code.

[0014] Figure 5 This is a diagram showing an example of a disassembly result of a non-optimized code.

[0015] Figure 6 This is a diagram showing an example of a line number table for non-optimized code.

[0016] Figure 7 This is an example of a flowchart of a breakpoint management unit.

[0017] Figure 8 This is an example of a flowchart of the breakpoint setting process.

[0018] Fig. 9 This is an example of a flowchart of the breakpoint clearing process.

[0019] Fig.10 This is an example of a flow chart of a breakpoint management unit. DETAILED DESCRIPTION

[0020] Implementation Method 1

[0021] In the present invention, the program execution unit 101 executes the debug target program 102. The program execution unit 101 is a CPU (Central Processing Unit), but it can also replace the actual CPU, such as a CPU emulator, a virtual machine, an interpreter, an instruction set simulator, etc. The debug target program 102 is a program obtained by compiling a program in a high-level language. In addition, the debug target program 102 is composed of various data 103 and codes 104, etc., and is stored in a storage device such as a memory.

[0022] The code 104 is composed of an optimized code 105 and a non-optimized code 106. The optimized code 105 and the non-optimized code 106 are machine language codes 104 generated from the same source program, and there are two types of optimized code 105 and non-optimized code 106 for each function of the original source program. The code 104 that the program execution unit 101 normally executes is the optimized code 105. On the other hand, during the period of providing a dialog-style operation to the user, the program execution unit 101 executes the non-optimized code 106. That is, the program execution unit 101 executes the debug target program 102, which has the optimized code 105 and the non-optimized code 106 corresponding to the same source code, the line number table 109 for the optimized code 105, and the line number table 109 for the non-optimized code 106.

[0023] The breakpoint management unit 107 is composed of a breakpoint setting unit 120 and a breakpoint switching unit 121. The breakpoint setting unit 120 receives a source file name of a high-level language and a breakpoint as a 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. That is, when the breakpoint is specified at the position of the source code, the breakpoint setting unit 120 sets the breakpoint at both the optimized code 105 and the non-optimized code 106 at the command level. The setting position of the breakpoint will be described in detail later.

[0024] The execution control unit 108 switches the code to be executed by the program execution unit 101 from the optimized code 105 to the non-optimized code 106 based on the set breakpoint. The line number table 109 stores the correspondence information between the line number of the source program and the instruction address of the non-optimized code 106.

[0025] The symbol table 110 stores the addresses and sizes of the areas corresponding to symbols such as variable names and function names in the source code. Here, the symbol table 110 stores both the addresses of the optimized code 105 and the addresses of the unoptimized code 106 for one function name in the source code. In addition, the symbol table 110 includes the starting address and size of the function. Therefore, if the address of the command that constitutes a part of the function is retrieved using the symbol table 110, the function can be determined. For example, when the entry of the symbol table 110 is a function with a starting address of f and a size of s, by determining whether the assigned address a is greater than or equal to f and less than f+s, it is possible to confirm whether the command at address a is a part of the function. By repeating the above operation for all entries of the symbol table 110, the starting address, symbol name, etc. of the function can be obtained from a part of the address of the function.

[0026] Below, the step-by-step execution scenario that can be achieved in this embodiment is first illustrated by taking the debugging of a simple program as an example, and then the details of the problems in the previous debugging method and the breakpoint management unit 107 and execution control unit 108 inherent in the present invention for solving the problems are shown.

[0027] Figure 2 is an example of a program that is considered to be debugged. Here, as an example, consider the case where a part of a salary calculation program is debugged. Here, it is assumed that the programmer executes the program step by step. Figure 2 In the 8th and 9th lines of the program, the programmer hopes to confirm whether the salary of the overtime amount is calculated correctly. In this case, by executing lines 8 and 9 step by step and obtaining the values ​​of the variables overtime and salary, the programmer can confirm whether the salary including the overtime amount is calculated as the programmer intends.

[0028] If such step-by-step execution is desired, the programmer sets a breakpoint at line 8 and starts executing the program. If the program stops at the breakpoint at line 8 soon after, the debugger provides the programmer with interactive operations such as step-by-step execution of the program. If the programmer instructs the debugger to step-by-step execution at line 8, the program stops at line 9. Then, if the programmer instructs the debugger to step-by-step execution again, the program stops at line 10.

[0029] If the above debugging is to be implemented by a conventional debugging method, it is necessary to use the unoptimized code 106. Figure 2When the optimized code 105 of the function wage is set as the debugging target, the above-mentioned debugging cannot be performed. Next, this problem is explained using the optimized code 105 of wage and the line number table 109 corresponding thereto.

[0030] first, Figure 3 It means from Figure 2 A diagram showing the result of disassembling the optimized code 105 generated by the source program. Figure 3 The format is based on the format of the disassembly result implemented by the objdump command of GNU binutils. The first line indicates that the function wage starts from address 0x740. In addition, from the second line to the tenth line is the result of disassembling the command sequence contained in wage. For example, the second line means that the command code of address 740 is 0xd2e80880, and the mnemonic is mov. In addition, the mov command means storing the immediate value 0x4044000000000000 in register x0. In addition, since the details of each command are not directly related to the present invention, the description is omitted.

[0031] then, Figure 4 It means Figure 2 FIG. 109 is a diagram of a line number table 109 used for the optimized code 105 corresponding to the function wage. Figure 4 The format of the line number table 109 is based on the output format of the dump result of the line number information implemented by the readelf command of GNU binutils. Lines 3 to 16 indicate the correspondence between each line of the actual source code and the address. The first column indicates the file name, the second column indicates the line number, and the third column indicates the corresponding address. For example, line 3 indicates that line 5 of the file name wage.c exists at address 0x740 in the optimized code 105. From Figure 4 It can be seen that the debugger cannot use the optimized code 105 to perform step-by-step execution at the source code level. For example, Figure 4 The 3rd to 5th lines of the source code indicate that the address 0x740 corresponds to the 5th, 6th, and 7th lines of the source code. Therefore, even if the command at address 0x740 is executed for the purpose of executing only the 5th and 6th lines, the processing corresponding to the 5th, 6th, and 7th lines will be partially executed. Therefore, in the conventional debugging method, when the optimized code 105 is used, there is a problem that each line of the source code cannot be executed step by step.

[0032] The basic concept of the present invention is to switch to the unoptimized code 106 and execute it only during the period when the debugger provides interactive operations to the user. Since the switch is automatically performed by the breakpoint switching unit 121, the user can perform normal debugging operations such as step-by-step execution and variable display as if the unoptimized code 106 was executed from the beginning.

[0033] The start of a dialog with the user is when the program stops at a breakpoint.

[0034] Next, after first showing a specific example of the non-optimized code 106 and its line number table 109, how to switch to the non-optimized code 106 is shown. In addition, the line number table 109 is composed of an address correspondence table for the non-optimized code 106 and an address correspondence table for the optimized code 105.

[0035] first, Figure 5 Shown with Figure 3 The disassembly result of the unoptimized code 106 corresponding to the wage function. In addition, Figure 6 The line number table 109 for the unoptimized code 106 is shown in FIG. Figure 6 In order to make it easy to recognize that it is an element for the unoptimized code 106 generated from wage.c, _O2 is added to the end of the base name of the original file name wage.c, such as wage_O0.c. Figure 5 Lines 2 to 27 of the code are the code corresponding to the processing of the function wage, starting from address 0x780. In addition, Figure 6 Lines 3 to 10 of Figure 2 Lines 5 to 13 of the program are the same as Figure 5 It can be seen that, unlike the case of the optimized code 105, each address does not necessarily correspond to only one line, and the order of the line numbers of the source code and the order of the addresses of the unoptimized code 106 are arranged in the same order.

[0036] In other words, Figure 6 The line number (Line number) of the unoptimized code 106 is a sequence of commands arranged in ascending order with different numbers for all lines. Figure 4 The same number appears in the line numbers of the optimized code 105, the numbers are interchanged, and the lines of the source program are converted into multiple command sequences with the order disrupted, so each line cannot be executed step by step in the correct order. Therefore, the line numbers of the source code can be easily found from the unoptimized code 106, while it is difficult to find the line numbers of the source code from the optimized code 105. Of course, the execution speed of the optimized code 105 is faster than that of the unoptimized code 106.

[0037] The following is a flow of setting a breakpoint when a user sets a source code level breakpoint on the nth line of the source code of the file name s. Here, a solution implemented based on an example of this embodiment is shown. Hereafter, in this specification, a breakpoint specified by a pair of a file name and a line number is referred to as a source level breakpoint, and a breakpoint specified by a memory address of a command where the program control unit 108 actually stops is referred to as a command level breakpoint, and the two are distinguished.

[0038] The breakpoint setting unit 120 sets a command level breakpoint at a command address in the non-optimized code 106 corresponding to the source file name s and line number n specified by the user.

[0039] However, the program execution unit 101 usually executes the optimized code 105, and therefore does not execute the non-optimized code 106. Therefore, in the breakpoint management unit 107, an auxiliary instruction level breakpoint is also set in the optimized code 105 so that the execution control unit 108 switches the code 104 to be executed from the optimized code 105 to the non-optimized code 106. When the execution control unit 108 stops at the auxiliary breakpoint, it switches from the optimized code 105 to the non-optimized code 106.

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

[0041] Figure 7 This is a flowchart of the breakpoint management unit 107. The input is the file name s, line number n, and type of breakpoint operation specified by the user. The breakpoint operation that can be specified is either set or clear.

[0042] First, in step S701, the address x corresponding to the file name s and the line number n is retrieved from the line number table 109 for the unoptimized code 106. Figure 2 In the case of line 8 of the program wage.c, s is wage.c and n is 8. At this time, according to Figure 6 From line 6 of wage.c, we know that line 8 starts at address 0x7b0. Therefore, x is 0x7b0 in this case. Figure 6 It is shown that the code 106 is not optimized, so it is necessary to pay attention to renaming wage.c to wage_O0.c.

[0043] Next, in step S702, the function f including the instruction address x is searched from the symbol table 110 to obtain the starting address y of the function f in the unoptimized code 106. For example, when the function f is wage, the starting address y is Figure 5The wage and 0x780 are obtained by searching the symbol table 110 using the command address x, that is, 0x7b0.

[0044] Next, in step S703, the starting address y' of function f in the optimized code 105 is obtained from the symbol table 110. In the search of 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. In addition, as described above, the symbol table 110 stores the addresses of both the optimized code 105 and the non-optimized code 106 for each function. For example, when function f is wage, according to Figure 3 In the second line of , the starting address y' of the optimized function wage is 0x740. This 0x740 is obtained by searching the starting address of the optimized wage function using the symbol table 110.

[0045] When a breakpoint is specified, the breakpoint setting unit 120 sets an auxiliary breakpoint at the beginning of a subroutine that includes the position of the breakpoint as a part. Thus, the optimized code 105 is executed to a position as close as possible to the breakpoint at the source code level, and the program can be executed at a high speed. Here, the beginning of the subroutine is a position where the optimized code 105 can be switched to the non-optimized code 106, and a position relatively close to the breakpoint at the source code level specified by the user includes the breakpoint at the source code level.

[0046] In other words, when a breakpoint is specified, the breakpoint setting unit 120 sets an auxiliary breakpoint at the beginning of a subroutine located higher in the call graph than a subroutine that includes the position of the breakpoint as a part.

[0047] 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 take the address x in the non-optimized code 106, the start address y of the function f in the non-optimized code 106, and the address y' of the function f in the optimized code 105 as inputs. In step S705, a breakpoint is set, and in step S706, the breakpoint is cleared (deleted).

[0048] Next, use Figure 8 and Fig. 9 The flowcharts in the figure respectively illustrate the breakpoint setting process and the breakpoint clearing process.

[0049] Figure 8is a flowchart of the breakpoint setting process. The input is a 3-tuple of addresses (x, y, y'). Here, x is an address in the unoptimized code 106, y is the start address of the function f in the unoptimized code 106, y' is the start address of the function f in the optimized code 105, and the function f is a function that includes the command of address x as a part. For example, Figure 2 The corresponding 3-tuple of line 8 of the program wage.c is (0x7b0, 0x780, 0x740).

[0050] In step S801, a command level breakpoint is set at address x. The method for setting a command level breakpoint is the same as in the prior art, and hardware breakpoints and software breakpoints can be used. For example, when x is 0x7b0, Figure 5 Set a breakpoint at the command corresponding to line 14.

[0051] Next, in step S802, a command level breakpoint is set at the starting address y'. For example, when y' is 0x740, Figure 3 Set a breakpoint at the command corresponding to line 2.

[0052] Finally, in step S803, the information of (x, y, y') is added to the auxiliary breakpoint table. The auxiliary breakpoint table 111 stores the 3-tuple (x, y, y').

[0053] Fig. 9 This is a flowchart of the breakpoint clearing process. The input is the same as the breakpoint setting process. In step S901, the 3-tuple (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.

[0054] Next, in step S903, it is confirmed whether there is an entry corresponding to the address y in the auxiliary breakpoint table 111. If there is an entry corresponding to the address y, y' of the 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 command level breakpoint of the start address y of the function f in the optimized code 105 is cleared and the process ends. The method of clearing the command level breakpoint is the same as that of the prior art in both the case of configuring as a hardware breakpoint and the case of configuring as a software breakpoint.

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

[0056] For example, in Figure 8 In the case where source-level breakpoints are set at two locations, namely, line 8 and line 9 of the source code wage.c, the auxiliary breakpoints of both are the start address of the function wage in the optimized code 105. In this case, if the breakpoint at line 8 of wage.c is cleared without the confirmation process of step S903, the auxiliary breakpoint for the source-level breakpoint at line 9 will also be cleared. As a result, the source-level breakpoint at line 9 will also be invalidated. If the confirmation process of step S903 is present, the clearing of the auxiliary breakpoints is skipped, so after the source-level breakpoint at line 8 is cleared, the source-level breakpoint at line 9 is also valid.

[0057] When the program stops at the starting address y of function f, the execution control unit 108 can switch from the beginning y of the optimized code 105 of function f to the non-optimized code 106y'. Immediately after the function call, the parameters and return address are accumulated at the top of the CPU stack, and the stack for local variables and registers is unused. Therefore, the optimized code 105 can be continued to be executed by inheriting the stack frame initialized by the optimized code 105.

[0058] Next, use Fig.10 The flowchart shows the operation of the breakpoint management unit 107 , and in particular, the operation of the breakpoint switching unit 121 .

[0059] The breakpoint switching unit 121 is a unit that controls the flow of execution when the program stops at a command breakpoint. Fig.10 The input of the processing of the flowchart is set to the command address B of the program stop. For example, Figure 3 In the case of a command level breakpoint stop at line 2, B is 0x740.

[0060] In step S1001, it is checked whether the command address B to be stopped is an auxiliary breakpoint. This can be confirmed by whether there is an entry in the auxiliary breakpoint table 111 in which the third element y' of the 3-tuple is the command address B. Figure 8 The 3-tuple of entries of the auxiliary breakpoint table 111 updated in step S803 is the address x of the command breakpoint in the non-optimized code 106 , the starting address y′ of the function in the optimized code 105 , and the starting address y of the function in the non-optimized code 106 .

[0061] If the stopped command address B is an auxiliary breakpoint, steps S1002 and S1003 are executed, and if not, step S1004 is executed. For example, if (0x7b0, 0x780, 0x740) exists in the auxiliary breakpoint table 111 when the stopped command address B is 0x740, the stopped command address B is an auxiliary breakpoint.

[0062] In step S1002 , the switch target address B′ is obtained from the auxiliary breakpoint table 111 .

[0063] Here, the entry y'=B is searched, and the start address y of the function in the unoptimized code 106 of the entry is used as the switch target address B'. When the stopped instruction address B is 0x740 and the entry obtained from the auxiliary breakpoint table 111 is (0x7b0, 0x780, 0x740), the switch target address B' is 0x780.

[0064] Next, in step S1003 , the current program counter of the debug target program is switched from the stopped instruction address B to the switching target address B′ through the program execution unit 101 , and the process proceeds to step S1005 .

[0065] On the other hand, in step S1004, in order to stop at a normal breakpoint, a dialog-style process is started to provide the user with an interactive operation. Figure 3 If a breakpoint is set on line 8 of the program, Figure 5 The address 0x7b0 corresponding to the 14th line of is used as a normal breakpoint and stops. At this time, since the program has been switched to the unoptimized code 106, operations such as step-by-step execution and display of local variables can be provided to the user.

[0066] If step S1004 is completed, then enter step S1005. In step S1005, the execution of the debug object program 102 is restarted. In the case where the stopped command address B is an auxiliary breakpoint, the code 104 is switched from the optimized code 105 to the unoptimized code 106 at this point in time. Then, if the program continues to execute for a period of time, it stops at the breakpoint of the unoptimized code 106, and the processing stops again. Since this series of processing is performed automatically, the user will not notice that the program has stopped. On the other hand, in the case where the breakpoint is not an auxiliary address, the execution control unit 108 becomes a state of waiting for an operation from the user. In this state, the debug object has been switched to the unoptimized code 106, so the value of the variable can be displayed and executed step by step in the process as in the prior art.

[0067] In this embodiment, C language is used as an example as a high-level language, but the high-level language of the present invention is not limited to C language. In the present invention, as a high-level language, the description language of the program that will become the conversion source to the machine language program is assumed to be a high-level language. The language that becomes the conversion source includes not only programming languages ​​expressed in text but also visual programming languages. Examples of visual languages ​​include FBD language of IEC61131-3, block diagrams such as those used in MATLAB (registered trademark) / Simulink, and the like.

[0068] The line number in this embodiment is an address used to specify a specific statement in the source code. When the high-level language is a visual programming language, the line number is equivalent to the address of the visualized program element. For example, when the high-level language is a block diagram of MATLAB (registered trademark) / Simulink, the identifier of the block is the line number. Correspondingly, the line number table stores the correspondence between the address of the program element and the command address. In addition, the language of the transformation source can also be a machine language. Even if the language of the transformation source is different, it is transformed into a subroutine at the machine language level according to a reusable transformation unit. In this embodiment, the case where the transformation unit is a function in C language is shown.

[0069] As an example of other conversion units, in the case of a block diagram such as MATLAB (registered trademark) / Simulink, the conversion unit is conceivable to be a subsystem. In addition, in the case where the conversion source language is other machine languages, it is conceivable to set a basic module and a super module as the conversion unit in addition to the subroutine of the machine language program. In addition, the language described as the machine language in this embodiment does not necessarily have to be a machine language for which an actual processor exists, and it can also be a virtual machine. In addition, in the case where the language of the conversion source is a machine language, the address of the machine language corresponds to the line number in this embodiment.

[0070] In addition, in the above description, it is assumed that the same function exists in the optimized code 105 and the non-optimized code 106. However, usually, functions are sometimes inlined and expanded into other functions during optimization. For example, when function f is inlined and expanded into function g through optimization, it is impossible to set an auxiliary breakpoint at the beginning of function foo in the optimized code 105. In addition, in the case where it can be set, since the code 104 that is inlined and expanded is executed, the program will not stop at the auxiliary breakpoint. In order to cope with such a situation, when setting a breakpoint in function f, it is sufficient to set an auxiliary breakpoint at the beginning of function g obtained by inline expanding function f.

[0071] In addition, in this embodiment, the non-optimized code 106 is pre-loaded into the main storage device, but it can also be dynamically loaded when the user sets a breakpoint. By dynamically loading the non-optimized code 106 as needed, the capacity of the main storage device can be reduced before starting the debugging operation.

[0072] As described above, the debugging device comprises: a program execution unit that executes a program having optimized code and non-optimized code corresponding to the same source code, a line number table for the optimized code, and a line number table for the non-optimized code; a breakpoint setting unit that sets breakpoints at both the optimized code and the non-optimized code at a command level when a breakpoint is specified at a position in the source code; and a breakpoint switching unit that switches 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 unit.

[0073] In addition, the debugging method comprises: 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 both the optimized code and the non-optimized code at a command level when a breakpoint is specified at a source code position; 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 a breakpoint setting unit.

[0074] Thus, before setting breakpoints at the source code level, the program can be executed at high speed using the optimized code, and after setting the breakpoints, interactive debugging operations such as step-by-step execution can be provided using the non-optimized code.

[0075] Implementation Method 2

[0076] In the first embodiment, the structure of the function call of the optimized code 105 and the non-optimized code 106 is not mentioned. When calling function B from function A, the call of function B in the non-optimized code 106A is usually a call of function B in the non-optimized code 106. However, if the non-optimized code 106 is executed to function B in order to execute function A step by step in units of source code lines, there is a problem of reduced execution speed. Therefore, in this embodiment, all calls using any f in the non-optimized code 106 become non-optimized code 106 like the call of function f in the optimized code 105.

[0077] By using such non-optimized code 106, when function A is debugged and a call to function B is executed in a step-over manner, function B is optimized in this embodiment and can be executed at a correspondingly high speed.

[0078] Here, sometimes it is desired to execute the inside of function B step by step in a step-in manner. Therefore, during the step-in operation, the optimized code 105 is switched to the non-optimized code 106 at the beginning of function B. One of the methods for implementing such a switch is to use a breakpoint to equip the step-in operation. In this case, the step-in operation on function f is implemented by setting breakpoint B at the start line of function f, executing the program, and clearing breakpoint B after stopping at breakpoint B. By directly applying the method shown in Implementation 1 in the setting of breakpoints, function B can be executed step by step as non-optimized code 106.

[0079] Description of the label

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

Claims

1. A debugging device, comprising: a program execution unit that executes a program having an optimized code and a non-optimized code corresponding to the same source code, a line number table for the optimized code, and a line number table for the non-optimized code; a breakpoint setting unit that sets the breakpoint at both the optimized code and the non-optimized code at a command level when the breakpoint is specified at a position of the source code; as well as A breakpoint switching unit switches 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 unit.

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

3. The debugging device according to claim 1, characterized in that: The breakpoint setting unit sets an auxiliary breakpoint at the head of a subroutine that includes the position of the breakpoint as a part when the breakpoint is specified.

4. The debugging device according to claim 2 or 3, characterized in that: When deleting the auxiliary breakpoint, the breakpoint setting unit confirms whether the auxiliary breakpoint has been shared.

5. A debugging method, comprising: A program execution step, executing a program, the program having an optimized code and a non-optimized code corresponding to the same source code, a line number table for the optimized code, and a line number table for the non-optimized code; A breakpoint setting step, when a breakpoint is specified at a position of the source code, setting the breakpoint at both the optimized code and the non-optimized code at a command level; as well as The breakpoint switching step switches 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 unit.

Images