JP2007004516A - Program debugging method of built-in system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a stepwise execution of a program under trial simply and at a low cost for a trial of software, improvement of efficiency of debugging works, and expansion for application object without a need of a monitor or a debugger. <P>SOLUTION: Codes which decide necessity of a break request according to a state of a stepwise execution activation flag to a plurality or all of execution process units of an execution program corresponding to process sections of which stepwise execution is desired to be performed on a source program, are inserted into the execution program. When the stepwise execution activation flag is in activated state, the break request in the execution program is detected, the break request is replaced with (read as) a standard input waiting code, and the stepwise execution is achieved by performing a break function, an updating function of variables, and a re-execution start. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a method for debugging a program in an embedded system, and more particularly to setting a breakpoint for interrupting program execution during debugging.

In program development, it is essential to monitor how a program behaves on a computer during execution. As a basic method for such monitoring, for example, by embedding the output code of the log in the source program, compiling it, and executing the module after compilation, obtaining the running log and monitoring It has been known.
A debugger having a function of displaying the execution state while executing a program is generally used. The debugger is a tool used for verifying that there is no bug in the program code created by the developer.
Using the debugger, the source code (source program) can be displayed and the operator can specify what information is displayed at which point in the code. As a result, the source code can be executed while executing the source code. Information (variables, arguments, changes in register values) can be displayed, and the soundness of the program or code to be debugged can be checked.
In a conventional debugger, it is necessary to embed an instruction for generating a software interrupt directly in a program to be debugged, the interrupt instruction is executed, an interrupt is generated, and the target program is interrupted (break). . In addition to this, the debugger has a function of referring to values of variables, memory areas, and registers at the time of interruption, a function of setting these values, and a function of resuming execution of an interrupted program.

  In many cases, a debugger has a function of step execution by providing interruption points in detail and repeating interruption and restart. This function makes it easier to grasp the execution behavior of the program in detail. A typical embodiment for implementing known step execution is that the debugger inserts a breakpoint at the next instruction for each line of code, runs the process, catches the associated exception, and sets the instruction pointer. Examine to determine if pre-configured step points have been reached (or do these until the debugger is manually stopped).

Unlike the above-described system having abundant computer resources such as memory, CPU power, and the like, a built-in control system (embedded system) that is incorporated in various devices and controlled by a microprocessor has become widespread.
When debugging a program installed in an embedded system, 1) A general-purpose OS cannot be installed in an embedded system. 2) Due to strict memory capacity restrictions, a conventional debugger must be installed under the actual operating environment of the device. There was a problem that it could not be used.
For this reason, developers of various devices themselves have to develop debugging functions such as outputting the values of variables of the target program to a display device or a file, or writing them to an internal memory. In other words, it is necessary to embed original software in the target program, execute it after assembling / compiling, and track changes in data processed by the embedded system. Such a debug function is deleted when a product is released or is switched by a compile flag, and is excluded from a final product (object code) (Patent Document 1).
In an embedded system, debugging with relatively high functionality called remote debugging may be performed (Patent Document 2). Generally, the following method is used (FIG. 11).
The monitor program 25 is incorporated into the ROM 26 of the target system 23 that is the object of debugging. The debugger 21 on the host computer 22 communicates with the monitor program 25 via the interface 29. The CPU 24 is a central processing unit in the microcomputer in the embedded system. Here, the user program 27 is stored in the RAM 28.
The host computer 22 transmits a command to the monitor program 25, and the monitor program 25 receives the command and executes break, trace, and other processes. In response to a break command, the monitor program 25 stores the address of the breakpoint in a register, causes the CPU 24 to generate an address match exception, transfers control from the user program 27 to the monitor program 25, and performs break processing (hardware) break).
In a microcomputer without a hardware break function, the monitor program 25 writes a trap instruction that causes an exception at a breakpoint into the user program 27, causes the user program 27 to generate an exception, and transfers control to the monitor program 25. Then, break processing is performed, and after the processing is completed, the trap instruction is returned to the original instruction (software break).
The monitor program 25 uses the trace function of the microcomputer in response to the trace command, so that the CPU 24 shifts to the trace mode and the user program 27 is traced. For a microcomputer without a trace mode, a breakpoint is set at an address one instruction ahead by the method described in the software break, an exception is generated when the user program 27 executes one instruction, and this is repeated. As a result, the user program 27 is traced.

In the conventional remote debugging, at the time of execution, the monitor program on the system to be debugged or the debugger on the host computer writes a trap instruction for causing an exception at a breakpoint to the user program developed on the RAM. Therefore, it cannot be applied to an embedded system that operates a user program on a ROM. This is because the ROM cannot be written.
In order to deal with this problem, in Patent Document 2, a trap instruction is embedded at the time of translation of the source code, stored in the ROM, and executed as it is on the ROM before the ROM.

  Performing an embedding operation such as a trap instruction before expansion into the RAM is also described in Patent Document 3, for example. Here, the source code of the execution program or the information related to the source code is displayed in conjunction with the execution program execution without using the debugger function in order to easily grasp the appropriate specified position information of the breakpoint. A source code display system and a program that can make it easy to grasp the meaning of an execution program are provided.

JP 2001-222447 A JP 2004-013880 A JP 2004-139313 A

  In Patent Document 2, since it is executed in combination with a debugger, there are few restrictions on the display / reference function. However, the use of a debugger requires computer resources, increases operating environment restrictions, and limits application to embedded devices.

  On the other hand, Patent Document 3 can be widely applied in that it does not require a debugger, but it has only a display function and cannot change parameters or update variable values. Moreover, in patent document 3, it can be judged that the implementation | achievement of step execution is not assumed.

  An object of the present invention is to provide a step execution function without requiring addition of a dedicated monitor program or debugger.

  A function to detect whether or not a break request is described in the execution program in the execution state of the execution program to be debugged, and to stop the program being executed if the break request is described In the arithmetic processing unit that is read as code, the break request code is read associating with the standard input wait code (standard input wait instruction), and it is easy and control method with break function without installing a debugger. Can be realized. In such a control method, a function for inserting a break request code at a point immediately before or immediately after two or more processes existing continuously or discontinuously in the execution program is provided. This is equivalent to providing an interruption point at which the program pauses in small steps, and it is possible to provide a step execution function without installing a debugger. In addition, although it describes as a standard input waiting code as the replacement content of a break request code, if a function which a program pauses is implement | achieved, it will not be limited to this.

  By executing this function, even in step execution, the standard input is waited (temporarily stopped), and input from the user is accepted. Therefore, command identification means for identifying such input and means for executing the identified command, for example, execution Information acquisition means for acquiring program source code, variables, and other related information of the execution program, display means for displaying part or all of the related information, and update means for updating values stored in the variables .

  Here, the presence of the break request may be synonymous with the presence of the call code of the break method. In that case, if a call to the standard input wait function is described in the definition part of the break method, the standard input wait is executed in conjunction with the call to the break method. As a result, steps equivalent to the temporary stop or step execution can be realized in the execution of the execution target program to be debugged.

Further, in the execution state of the execution program to be debugged, a function for detecting whether or not a step execution break request is described in the execution program, and step execution if a step execution break request is inserted. Only when the activation flag is in the activated state (on), a function for executing the program by replacing it with a code that makes it possible to stop the program being executed, such as a standard input waiting code (if it is off, does not stop it) is provided.
The standard input is a standard library function for inputting from the keyboard, and corresponds to, for example, a scanf function in which a C standard input library exists.

  Without requiring a conventional debugger, program execution can be paused easily, and source code (all or part), variable values used, and other information related to source code can be displayed, updated, and program In addition to execution, step execution is possible.

The program execution unit in the present invention has an execution function of an execution program and a function of executing a standard input waiting code when a break request appears in the execution process. The standard input waiting code calls the standard input control unit.
The standard input control unit temporarily stops execution of the program. It also displays the program execution status. Further, the display information control unit is requested to display a screen waiting for input to the user.

  The standard input control unit reads and interprets standard input control commands input by the user on the input waiting screen. That is, the command input by the user is called from the standard input control command library. Perform the necessary execution. The processing result returned from the standard input control command library is transferred to the display information control unit. Such a display information generation processing request function is provided.

  As an example of the code that can stop the program being executed, an example of the standard input waiting code is shown. However, the code is limited to this as long as the program that is being executed can be stopped. It is not a thing.

As a characteristic component of the embodiment of the present invention, a break request code is embedded at a plurality of locations in a program execution unit (line) to enable step execution. To do. Here, when performing source level debugging, the execution unit means the processing content corresponding to one line of the source program.
These break request codes are provided with two types of codes, a first break request and a second break request. The first break request exists to cause a break regardless of whether or not step execution is necessary, and the second break request additionally exists for step execution.

Such an embodiment is characterized in that step execution ON (activation) / OFF (deactivation) is realized by these two types of break requests. This is called selective step execution. The first break request causes a break regardless of the necessity of step execution, while the second break request realizes an operation that breaks in the activated state of step execution and does not break in the inactivated state. And a step execution activation flag is provided as an indication of the step execution activation state.
When the program is stopped by the first and second break requests, the step execution activation state can be manipulated (reversed). For example, in the standard input waiting (pause) state, input from the user is accepted, so if a command identified as indicating the intention to execute step is input, the step execution activation flag is set to ON (activated) To do. On the other hand, when a command indicating an intention not to perform step execution, that is, a user intention not to stop execution up to the first break request point is input, the step execution activation flag is set to OFF (inactivation). This allows selective step execution.
The first break request code breaks regardless of whether or not step execution is necessary. If this first break request code is inserted at the breakpoint setting location, the step execution activation flag is turned off (deactivated) The break setting continues to work even if step execution is disabled.

FIG. 1 is a system configuration diagram of an information processing apparatus that performs debugging support, to which the present invention is applied.
The execution program file 101 to be debugged is executed by the program execution unit 107 using the execution program database 110 as necessary. The source code file 102, the display information resource file 103, and the variable value storage table 105 used to create the execution program are appropriately referred to by the arithmetic processing unit 106.
The display information resource file 103 is a file describing description information of source code and other display information related to the source code. The variable value storage table 105 stores the values of variables used in the source code in the file 102 in time series.

The arithmetic processing unit 106 of this system includes a program execution unit 107, a break execution unit 1072, a standard input control unit 111, and a display information control unit 108.
The break execution unit 1072 has a function of executing a standard input wait instruction, and the break execution unit 1072 replaces the break request code with a standard input wait instruction to realize break processing. The unit 1072 is activated when the program execution unit 107 detects a break request code in the execution process, reads the break request code as a standard input wait instruction, and passes the processing to the program execution unit 107.

  The standard input wait instruction read by the break execution unit 1072 calls the standard input control unit 111. The unit 111 suspends execution of the program, displays the state of the execution program, and instructs the display information control unit 108 to display an input waiting screen for the user.

Further, in relation to execution of a break, a step execution activation flag is provided, although it does not exist in the figure. This is referenced and updated as a guideline for step execution.
The standard input control unit 111 interprets the standard input control command input by the user on the input waiting screen. That is, the command is called from the standard input control command library 104. In addition, the processing result returned from the library 104 is transferred to the display information control unit 108. The standard input control command library 104 is a command library of the present invention embedded in an execution program.

  Based on the processing instruction from the program execution unit 107, the display information control unit 108 displays information to be displayed from the source code of the file 102, the message resource of the display information resource file 103, and the variable information in the variable value storage table 105. Generate and instruct the display device 109. Further, the display device 109 is instructed to display the execution state of the execution program of the file 101.

FIG. 2A shows an example of a data structure stored in the variable value storage table 105.
The variable name 202 is a name of a variable used in the source code of the execution program, and specifically corresponds to index, amount, day, and the like. In the figure, AAA, BBB, and CCC are described. A variable 203 indicates an area in which the value is stored.
FIG. 2B shows an example of a break request instruction file not shown in FIG. This is a definition file in which the break request insertion position is described in the execution program.

The break request code is inserted with reference to this instruction file. Specifically, (1) the compiler generates an execution program equivalent to the source program in which the break request code is inserted. (2) The conversion tool analyzes the execution program and embeds it in the execution program. Or (3) An interpreter or other program execution unit that performs sequential interpretation processing at the time of execution inserts a break request code at the time of interpretation.
For the insertion location, break position information description data is separately prepared and referred to by the subject of the insertion operation (compiler, conversion tool, or program execution unit).
In item numbers 1 and 2 of FIG. 2B, a plurality of break request codes are collectively described in one insertion position file and designated collectively. Unlike this, it may be specified interactively one by one. When specifying interactively, the source program may be displayed on the screen by a GUI operation.

FIG. 3 shows an example of the display screen of the display device 109.
This screen shows the stopped state displayed as a result of the break request. It is an input waiting screen waiting for an interactive input operation from the user. In this interactive operation screen, the user can acquire or update predetermined information by inputting a predetermined command for the program to be debugged. The command input is input by a keyboard (not shown).
There are the following types of standard input control commands that can be input by the user on the screen waiting for an input operation.

Command name Meaning p Display variable value s Update variable value c Restart processing (does not execute step)
l Display source code
ST Step Execution 301 in FIG. 3 is the file name and line number of the source code of the program being executed, and indicates the break position. Reference numeral 302 denotes a display that prompts an interactive input operation from the user, and indicates that the next command can be received. These correspond to standard input control commands and are realized by the standard input control command library 104 (FIG. 1).

FIG. 4 is a flowchart showing an outline of break processing for enabling step execution characteristic of the present invention.
The program execution unit 107 (FIG. 1) starts executing a program to be debugged (an execution program in the execution program file 101) (step 401).
Next, as long as the break request code and the step execution break request code are described in the execution program, the following processing from step 403 to step 407 is repeatedly executed (step 402).

  In step 403, the program processing is executed up to the next break request code (or step execution break request code). The program execution unit 107 interprets and executes according to the type of the break request code (step 4031). In step 4031, if it is the first break request code (denoted as type 1 break request in the figure), the program execution unit 107 executes the standard input wait command, and in the processing of the standard input wait code, The standard input control unit 111 is called (step 404).

In step 405, the standard input control unit 111 stops the execution of the program. Next, the display information control unit 108 is instructed to display a screen waiting for input to the user.
The display information control unit 108 generates display information for the input waiting screen based on the transferred information (step 406), and displays the display information on the display device 109 (step 407).
The standard input control unit 111 reads and interprets a standard input control command input by the user on the input waiting screen. Here, when an operation for advancing the process to the next step position, for example, the input of the process resumption command “c” in FIG. 3 is performed, the step execution activation flag is set to OFF (activation), and the next Proceed to processing. When the command “ST” is input, the step execution activation flag is set to ON (activation), and the process proceeds to the next process.

  On the other hand, if it is the second break request code (denoted as a type 2 break request in the figure) at step 4031, the program execution unit 107 refers to a step execution activation flag that does not exist in the figure. If it is in the activated state (step 4032), it is temporarily stopped and the process is the same as the first break request code (the process proceeds to step 404). In the case of deactivation, steps 405 to 407 are skipped and the process proceeds to the next process.

  Such a series of operations is executed until the target program ends (step 408).

  In step 406 of FIG. 4, when the user inputs the step execution command “ST”, the execution of the program is resumed (return from the stop). The program execution unit 107 sets the step execution activation flag to activation (on). Then, the program execution unit 107 resumes the execution of the stopped program and returns to the iterative process from step 402 in FIG. This immediately leads to the next second break request code (denoted as a type 2 break request in the figure), so the path from step 4031 to step 4032 and step 404 in FIG. Pause. By repeating this, step execution is realized.

FIG. 5 is a flowchart of the process of displaying the source code around the stop point after the program is stopped in step 406 of FIG. This occurs when the user inputs the source display command “l” on the input waiting screen.
The program execution unit 107 transfers the program name of the program being executed and the line number being executed to the display information control unit 108. The display information control unit 108 acquires a file being executed that matches the program name from the source code file 102 (step 501).
The display information control unit 108 acquires several lines before and after the line number instructed by the program execution unit 107, for example, 10 lines of source code as a character string from the source code of the file acquired in step 501 (step 502). ). Next, the same unit 108 displays the source code file name (FIG. 3, 301) on the display device 109 (step 503). The part 108 displays part or all of the source code (step 504). FIG. 6 shows an example of a source display screen generated as a result of the flow of FIG.

FIG. 7 is a flowchart of processing for displaying the value of a variable designated in a predetermined area by inputting a variable display command “p” after the program is stopped in step 406 of FIG. In this embodiment, the variable name to be monitored is designated in advance for each break request code. However, a variable designation command may be provided separately and designated on the input waiting screen at the time of stop.
The program execution unit 107 extracts the monitoring target variable name specified in the break request code in the program being executed (step 701). If the variable name to be monitored is not designated, step 702 and subsequent steps are terminated without executing.
The program execution unit 107 acquires the value of the variable name to be monitored from the variable value storage table 105 (step 702). Then, the same unit 107 instructs the display information control unit 108 to create display information for displaying the variable name and its value. The same unit 108 generates display information for displaying variable names and variable values based on the instructed information, and displays the generated display information on the display device 109 (step 703).
The program execution unit 107 waits for a standard input to accept the next input (step 704), and ends the series of processes. FIG. 8 shows an example of a display screen of variable values generated as a result of the flow of FIG.

FIG. 9 is a flowchart of processing for updating the value of a designated variable by inputting a variable value update command after the program is stopped in step 406 of FIG.
The program execution unit 107 extracts the monitoring target variable name specified in the break request code in the program being executed (step 901). If the variable name to be monitored is not specified, step 902 and subsequent steps are terminated without executing.
The program execution unit 107 acquires the value of the variable name to be monitored from the variable value storage table 105 (step 902).
The program execution unit 107 instructs the display information control unit 108 to create display information that displays variable names and their values. The same unit 108 generates display information for displaying variable names and variable values based on the instructed information, and displays the generated display information on the display device 109. The program execution unit 107 instructs the display information control unit 108 to create an input waiting screen for designating the variable name and variable value to be updated. The same unit 108 generates display information for displaying the variable name and the value of the variable based on the instructed information, and displays it on the display device 109 (step 903).

  The program execution unit 107 calls the standard input control unit 111. The unit 111 displays a standard input waiting screen, enters a variable value update waiting state, and stops the screen display (step 904). If there is an input from the user on the input waiting screen (step 905, Yes), the standard input control unit 111 receives the updated value of the variable related to the input and passes it to the program execution unit 107. When there is no input from the user (step 905, No), the input waiting state is maintained.

  The program execution unit 107 stores and updates the updated value in the storage location corresponding to the corresponding variable name (step 906). The unit 107 waits for a standard input to accept the next input (step 907), and ends a series of processing. FIG. 10 shows an example of a variable value update operation screen generated as a result of the flow of FIG.

  When the present invention is implemented in the form of remote debugging in which the debug target is debugged from the host PC via communication (interface) as shown in FIG. 11, various types of information generated by the display information control unit 108 (FIG. 1) are used. The display information may be transmitted to the host PC via communication and displayed on the display device (109, FIG. 1) connected to the host PC. Similarly, input to the input waiting screen may be realized by a form in which input from a keyboard connected to the host PC is transmitted to the execution program 101 via communication.

  In the present invention, the program execution unit 107 may be realized by an interpreter processing system, and accompanying this, the execution program 101 is an intermediate language program converted from a source program and interpreted and executed by the interpreter processing system. Form may be sufficient.

  Even in an environment where computer resources are insufficient, it is possible to improve the efficiency and accuracy of software development.

1 is a system configuration diagram of an information processing apparatus that performs debugging support, to which the present invention is applied. FIG. It is a figure which shows an example of the data structure preserve | saved at the variable value storage table 105, and an example of a break request instruction | indication file. 6 is a diagram showing an example of an input waiting screen on the display screen of the display device 109. FIG. It is a flowchart which shows the outline | summary of the break process which enables step execution. FIG. 5 is a flowchart of processing for displaying source code around a stop point after the program is stopped in step 406 of FIG. 4. It is a figure which shows an example of the source display screen produced | generated as a result of the flow of FIG. It is a flowchart of the process which inputs the variable display command "p" and displays the value of the variable designated to the predetermined area. It is a figure which shows an example of the display screen of the variable value produced | generated as a result of the flow of FIG. It is a flowchart of the process which inputs the variable value update command and updates the value of the designated variable. It is a figure which shows an example of the update operation screen of the variable value produced | generated as a result of the flow of FIG. It is a conceptual diagram of the system configuration which performs the conventional debugging method.

Explanation of symbols

101 ... execution program,
102 ... Source code file,
103 ... display information resource file,
104: Command library for standard input control,
105 ... Variable value storage table,
106: Calculation control unit,
107: Program execution unit, 1072: Break execution unit,
108: Display information control unit,
109 ... Display device,
111: Standard input control unit.

Claims (4)

  A function to detect whether or not a break request is described in the execution program in the execution state of the execution program to be debugged, the source code file of the execution program that can be referenced, and the execution state of the execution program to be debugged; and If the break request has been described, the control method of the arithmetic processing unit having a function to read and execute the code for stopping the program being executed, and the execution program is not yet started, Have a function to insert a break request code at a point immediately before or after two or more processes existing continuously or discontinuously in the execution program, and execute the execution program in the inserted state A method for controlling an arithmetic processing unit, characterized in that step execution is realized.   2. The method of controlling an arithmetic processing unit according to claim 1, wherein the arithmetic processing unit has a function of inserting a code that makes the arithmetic processing unit refer to the step execution activation flag, and the arithmetic processing unit is configured to execute the inserted code when the inserted code is executed. If the step execution activation flag is in an activated state, the break request code according to claim 1 is executed to realize temporary suspension of the execution program, while the step execution activation flag is in an inactivated state. A control method for an arithmetic processing unit, wherein step execution is selectively realized by avoiding temporary suspension of the execution program without executing the break request code according to claim 1.   The control method of the arithmetic processing unit according to claim 1 or 2, wherein the input from the standard input is identified in a state of being paused by step execution, and a predetermined variable value is displayed according to the input, or The control method of the arithmetic processing unit to be updated. In the control method of the arithmetic processing unit according to claim 1 or 2,
A control method for an arithmetic processing unit that identifies an input from a standard input and displays a part of a predetermined source code according to the input in a state of being paused by step execution.

Images