JP5906609B2 - Debug support program, debug support method, and debug support system - Google Patents

Description

  The present invention relates to a debugging support program, a debugging support method, and a debugging support system that support correction of a bug (defect) included in an application program (hereinafter referred to as “application”).

  When the operation result of the application is different from the intended one, for example, when the application terminates abnormally, there is a high possibility that the cause is a bug included in the application. For this reason, in the application development process, unless the application is small, debugging work to remove bugs is indispensable. In the case of a large-scale application, when a load module is rebuilt from the corrected source code and the debugging operation is restarted from the beginning of the application, a certain amount of time is required from the correction of the source code to the restarting of the debugging operation. Accordingly, there is a debugging technique for correcting an application while operating the application to be debugged in order to support debugging work.

JP-A-8-179940

  However, with the technology that dynamically modifies the conventional application, the problem is that the value of the static variable nested in the modification part (function / procedure) is not inherited although the link is dynamically generated and the modification part is called. There is a point.

Therefore, as one aspect of the present invention, in the dynamic modification of an application, an object is to enable inheritance of values of local static variables including static variables nested in a function, which are included in a modification part. And

The computer changes local static variables, including static variables nested in functions , included in the source code obtained by modifying the source code corresponding to a part of the application program to global variables. The address where the variable value of the static variable is stored by the processing of the program and the global variable are associated and stored in the storage means. Further, when a part of the application program is called in the processing of the application program, the computer is set so that the program obtained by compiling the source code obtained by replacing the static variable with the global variable is executed. Further, when the global variable is called in the processing of the application program, the computer sets so that the variable value is read from the address associated with the global variable and stored in the storage means.

In the dynamic modification of an application, the value of a local static variable including a static variable nested in a function, which is included in the modification part, can be inherited.

It is a block diagram of a computer system in which a debugger is incorporated. It is explanatory drawing of the internal structure of a host computer and a user terminal. It is a procedure figure explaining the procedure of debugging work. It is a conceptual diagram of the method of applying the corrected source code to an application. It is explanatory drawing of the variable contained in the corrected source code. It is a flowchart of the main routine of an application application process. It is a flowchart of a subroutine for building a patch. It is a flowchart of the subroutine which transfers a patch. It is a flowchart of the subroutine which applies a patch to an application. It is explanatory drawing explaining how the corrected source code is processed.

Hereinafter, embodiments for carrying out the present invention will be described in detail with reference to the accompanying drawings.
The application program to be debugged in this embodiment is composed of a plurality of program parts obtained by compiling a plurality of source codes. When each program part is called, processing corresponding to each program part is executed.

In this embodiment, in dynamic modification of an application, a computer operating as a debugger executes the following process in order to inherit the value of a static variable.
First, a computer generates a dynamic link library based on a modified source code of an application to be debugged, and performs processing for replacing a static variable with a global variable for the generated dynamic link library. Here, the “static variable” is a variable whose value is held until the application is terminated, such as a “static variable” in C language. On the other hand, a “global variable” is an external variable declared to use a variable defined in another file, such as an “extern variable” in C language. Further, the computer links the dynamic library to the application by associating the actual address (real address) of the area holding the static variable with the global variable. Then, the computer changes the application so that the procedure of the dynamic link library is executed.

Next, an example of this embodiment will be described.
An integrated development environment exists as a tool for supporting application development. The integrated development environment has functions such as source code editing, source code management, application build method management, build execution, application execution, and a debugger for debugging. In response to a user instruction, the debugger can stop and restart the application, and reference and change the value of the variable. An application to be debugged is described in a high-level language such as C language or FORTRAN language, and a debugger capable of debugging a program written in such a high-level language is called a “source level debugger”. . Here, it is assumed that the source level debugger handles the high-level language C as the debugger.

  FIG. 1 is constructed by a computer system having a host computer 200 (second device) for executing the application 100 and at least one user terminal 300 (first device) for operating the host computer 200. An example of the integrated development environment 400 is shown.

  The debugger of the integrated development environment 400 includes an internal debugger 410 and an external debugger 420 provided in the host computer 200, and a debugger control device 430 provided in the user terminal 300. The internal debugger 410 is a module integrated with the application 100 and controls execution / stop of the application 100 in response to an instruction from the external debugger 420. The external debugger 420 is a module that is activated as a process separate from the application 100 and is attached to the application 100 via the internal debugger 410 and controlled in response to an instruction from the debugger control device 430. The debugger control device 430 is a module that provides a user interface to the user, and transmits various instructions to the external debugger 420 in response to the user's instructions.

  Here, the host computer 200 and the user terminal 300 include a memory A, a processor B such as a CPU (Central Processing Unit), a hard disk C, a drive device D, and a communication device E, as shown in FIG. The memory A, the processor B, the hard disk C, the drive device D, and the communication device E are connected to each other by a bus F such as serial ATA (AT Attachment). The drive device D reads data from a removable disk G such as a CD-ROM (Compact Disk Read Only Memory) and a DVD-ROM (Digital Versatile Disk Read Only Memory). Instead of the removable disk G, a USB (Universal Serial Bus) memory with a built-in flash memory may be used. The communication device E is, for example, a NIC (Network Interface Card) that connects the host computer 200 and the user terminal 300.

  FIG. 3 shows a rough procedure for debugging the application 100 using the debugger. It is assumed that the application 100 to be debugged is already built as a premise for the debugging work.

  In step 1 (abbreviated as “S1” in the figure, the same applies hereinafter), the user causes the debugger to execute the application 100 and verifies its operation. The debugging work can be started from the middle of the application 100.

  In step 2, the user determines whether or not there is a bug in the application 100 based on the operation verification result of the application 100. If the user determines that the application 100 has a bug, the process proceeds to step 3 (Yes), while if the user determines that the application 100 has no bug, the debugging operation is terminated (No).

In step 3, the user investigates the cause of the bug, for example, by referring to or changing the value of the variable.
In step 4, the user corrects the source code.

  In step 5, in response to an instruction to rebuild the application 100 by the user, the debugger rebuilds the corrected portion of the source code and applies it to the application 100 being executed. Then, the procedure after step 1 is repeated.

  The debugging operation described above can be executed in the same processing procedure as the debugging method using a known debugger, except for the procedure in step 5. The debugging process procedure of steps 1 to 4 may cause a computer to execute a tool for automating the debugging process. Further, the rebuild instruction in step 5 may be performed by a process of a tool that executes a debugging process.

FIG. 4 shows the concept of the process of step 5 in FIG. 3, that is, a method of applying the modified source code to the application 100 being executed.
The builder compiler 440 included in the integrated development environment 400 generates a dynamic link library 600 that functions as a patch from the source code 500 modified by the user.

  The source code 500 is program code that defines the operation of the application 100. The entities defined by the source code 500 include global variables, local variables, global procedures, and local procedures. As shown in FIG. 5, there are local variables X in the file, local variables A and Y in the procedure, and local variables B and Z in the block. For variables that are local to a procedure or block, there are auto and static storage classes. The auto variable (automatic variable) is generated and initialized every time it is referenced, but only one entity exists between the start and end of the application 100 as the static variable (static variable).

  The dynamic link library 600 is a load module that is a part of the application 100, and includes entities such as global variables, local variables, global procedures, and local procedures, name information such as variable names and procedure names (relocation information), and debugging. Contains information.

The dynamic link library 600 generated by the builder compiler 440 is transferred to the internal debugger 410 by the debugger control device 430 and the external debugger 420 . The internal debugger 410 dynamically links the dynamic link library 600 to the load module 110 of the application 100 via the dynamic linker 450.

  Next, a specific example of processing (application application processing) for applying the corrected source code 500 to the application 100 being executed will be described with reference to the flowcharts of FIGS.

FIG. 6 shows an example of the main routine of application application processing.
In step 11, the builder compiler 440 executes a subroutine described later, which builds the dynamic link library 600 as a patch from the corrected source code 500.

  In step 12, the debugger control device 430 and the external debugger 420 cooperate to execute a subroutine to be described later, which transfers the dynamic link library 600 generated by the builder compiler 440 to the internal debugger 410.

In step 13, the internal debugger 410 executes a subroutine to be described later that is applied to the application 100 that is executing the dynamic link library 600.
FIG. 7 shows an example of a subroutine executed by the builder compiler 440.

  In step 21, the builder compiler 440 identifies the source code 500 modified by the user from all the source codes 500 related to the application 100. The identification of the source code 500 can be easily realized by comparing the time stamp of each source code 500 with the time stamp of the object code compiled from each source code 500, as in the known differential build method. it can. The specific unit of the source code 500 may be a file unit.

  In step 22, the builder compiler 440 generates a dynamic link library 600 from the source code 500 specified in step 21 as a patch of the application 100. At this time, the builder compiler 440 dynamically replaces the modified source code 500 by replacing the static variable with a global variable with a unique name and the global procedure with a global procedure with a unique name. A library 600 is generated. Here, the reason for replacing the static variable name and the global procedure name with a unique name is to guarantee the uniqueness of the static variable and the global procedure in the application 100. The generation of the dynamic link library 600 may be executed by replacing static variables and global procedures in the temporary source code 500, or without actually replacing static variables and global procedures. , And may be executed as if they were replaced.

Here, replacement processing of static variables and global procedures in the source code 500 will be described using a specific example.
In the source code shown in FIG. 5, the static variables are a variable X local to the file, a variable Y local to the procedure, a variable Z local to the block, and the global procedure is the procedure “func”. For static variables X, Y, and Z, as shown in FIG. 10, “static” is replaced with “extern” to make it a global variable, and variables X, Y, and Z that have been made global variables are given unique names. Replace with the name. Also, replace the global procedure “func” with a unique name “XX_func”. The replacement of the static variable and the global procedure is not limited to the name as shown in FIG. 10, but may be performed according to a predetermined rule.

FIG. 8 shows an example of a subroutine that the debugger control device 430 and the external debugger 420 execute in cooperation.
In step 31, the debugger controller 430 and the external debugger 420 cooperate to transfer the dynamic link library 600 generated by the builder compiler 440 to the internal debugger 410 of the application 100. Specifically, the debugger control device 430 transfers the dynamic link library 600 to the external debugger 420, and the external debugger 420 transfers the dynamic link library 600 transferred from the debugger control device 430 to the internal debugger 410.

FIG. 9 shows an example of a subroutine executed by the internal debugger 410.
In step 41, the internal debugger 410 refers to debug information such as DWARF information for a static variable that has been converted to a global variable, and obtains a real address in the application 100 being executed.

  In step 42, the internal debugger 410 associates the real address of the static variable obtained in step 41 with the global variable and transmits it to the dynamic linker 450 to make the dynamic link library 600 available for dynamic link processing.

  In step 43, the internal debugger 410 calls the dynamic linker 450 to dynamically link the dynamic link library 600 to the load module 110 of the application 100. By this dynamic linking, it is possible to refer to global variables in the dynamic link library 600 and to refer to static variables that have been globalized.

  In step 44, the internal debugger 410 changes the procedure included in the application 100 being executed so that the global procedure included in the dynamic link library 600 as a patch is executed. Specifically, the internal debugger 410 changes the procedure of the application 100 being executed to branch to the global procedure of the dynamic link library 600. Thereby, the global procedure defined in the dynamic link library 600 can be referred to.

  According to such a debugger, when the source code 500 is corrected in order to solve the bug of the application 100 in a state where the application 100 being executed is temporarily stopped, the dynamic link that can be dynamically linked from the corrected source code 500 to the application 100 is possible. A library 600 is generated. At this time, in the modified source code 500, a local static variable is replaced with a global variable with a unique name, and the global procedure is rewritten with a procedure with a unique name, so that the dynamic link library 600 is generated.

  Further, the generated dynamic link library 600 is applied to the application 100 being executed as follows. That is, by associating the real address of the static variable converted to the global variable with the global variable and calling the dynamic linker 450, the global variable can inherit the value of the static variable. Furthermore, by changing the procedure of the application 100 being executed so that the global procedure of the dynamic link library 600 is executed, the global procedure of the dynamic link library 600 is executed instead of the procedure of the application 100. To.

  Here, the mechanism by which a global variable can inherit the value of a static variable will be described. For the source code 500 shown in FIG. 5, it is assumed that the real address of the static variable X is “XXXX”. By making the static variable X in the source code 500 a global variable, the static variable X becomes a global variable X_001 as shown in FIG. Since the real address XXXX and the global variable X_001 are associated with the static variable X, referring to the global variable X_001 is the same as referring to the address XXXX. Since the address XXXX is the real address of the static variable X, referring to the global variable X_001 refers to the static variable X, and the value of the static variable X can be inherited.

  Then, when the execution of the application 100 that has been suspended is resumed, the application 100 is changed so that the procedure of the dynamic link library 600 is executed. Therefore, the procedure specified by the modified source code 500 is executed. It becomes. Therefore, dynamic application correction can be realized.

Therefore, the value of the static variable can be inherited in the dynamic modification of the application.
The present embodiment is not limited to a computer system having the host computer 200 and at least one user terminal 300, but can be applied to a computer system such as a PC (Personal Computer) or WS (Work Station). Further, the high-level language is not limited to the C language, and can be applied to a C ++ language, a FORTRAN language, or the like that can handle static variables, global variables, and the like.

DESCRIPTION OF SYMBOLS 100 Application 200 Host computer 300 User terminal 400 Integrated development environment 410 Internal debugger 420 External debugger 430 Debugger controller 440 Builder compiler 450 Dynamic linker 500 Source code 600 Dynamic link library

Claims (5)

On the computer,
Change local static variables, including static variables nested in functions , included in the source code obtained by modifying the source code corresponding to a part of the application program to global variables.
An address where the variable value of the static variable is stored by the processing of the application program and the global variable are associated and stored in the storage means,
When the part of the application program is called in the processing of the application program, the program obtained by compiling the source code obtained by replacing the static variable with the global variable is set to be executed,
When the global variable is called in the processing of the application program, the variable value is set to be read from the address stored in the storage means in association with the global variable.
A debugging support program characterized by causing processing to be executed. The global variable is given a unique name,
The debugging support program according to claim 1, wherein: The process of correcting the source code corresponding to the part is a process of changing the name of the procedure in the source code to a unique name.
The setting process includes a process of setting to branch to the unique name procedure when the procedure in the source code is called.
The debugging support program according to claim 1 or 2, characterized by the above-mentioned. Computer
Change local static variables, including static variables nested in functions , included in the source code obtained by modifying the source code corresponding to a part of the application program to global variables.
An address where the variable value of the static variable is stored by the processing of the application program and the global variable are associated and stored in the storage means,
When the part of the application program is called in the processing of the application program, the program obtained by compiling the source code obtained by replacing the static variable with the global variable is set to be executed,
When the global variable is called in the processing of the application program, the variable value is set to be read from the address stored in the storage means in association with the global variable.
A debugging method characterized by executing processing. A debugging support system including a first device and a second device that executes an application program,
The first device comprises:
Change local static variables, including static variables nested in functions, in the source code obtained by modifying the source code corresponding to some of the application programs to global variables Change means to
Transmission means for transmitting a correction program obtained by compiling the changed source code to the second device,
The second device comprises:
Association means for associating the global variable with the address where the static variable is stored by the processing of the application program;
Setting means for setting the correction program in which the static variable is replaced with the global variable to be executed when the part of the program is called in the processing of the application program;
This is a debugging support system.