JPS6292033A - Program debugging device - Google Patents

Abstract

PURPOSE:To catch the abnormal flow of a program to be debugged by displaying the coincidence if the designating order of point coincides with the executing order of point. CONSTITUTION:A debugging system consists of an engineering work station 11, a terminal equipment 12 and a debug executing device 13. In such constitution, the positions of plural points set on a source program stored in an internal storage 22 and the executing order of set points can be designated properly when the break point is set to a program to be debugged. While a break is produced on a CRT27 only when it is decided that the points on the program are executed in the designated order. Then the information on the break is informed to an operator. In such a way, the abnormal flow of the program to be debugged can be caught.

Description

DETAILED DESCRIPTION OF THE INVENTION Technical Field of the Invention The present invention relates to a program debugging device, and more particularly to a program debugging device with an improved break function at the source program level of a high-level language.

<Summary of the Invention> When setting breakpoints in a program to be debugged, the present invention makes it possible to appropriately specify multiple point positions to be set on the source program and the execution order of the set points. By notifying the operator by generating a break only when it is determined that the points on the program have been executed in the order specified, it is possible to detect abnormal flows in the program being debugged.

<Background of the Invention> Currently, so-called "Simporinokudehagga" is often used as a program development support means at a high-level language level. Furthermore, as one of the debugging functions of such a simple debugger, there is a known function that, when a program to be debugged is executed, forcibly stops the execution of the program →1 in the middle.

By the way, conventionally, the break function described above uses a breakpoint setting command to specify the line number in the source program that is likely to cause a particular problem in the program flow. It was common to detect this and immediately stop the program when it was executed.

However, during actual debugging work, it is not enough to simply grasp the flow of the program in terms of points as described above; it is necessary to observe the program execution process in the entire flow to detect abnormalities in the program being debugged. can often be found.

<Purpose of the Invention> The present invention has been made by focusing on the above-mentioned problem, and is capable of generating a break only when multiple points set on a source program are executed in one pre-specified sequence. Therefore, it is an object of the present invention to provide a debugging device that can precisely define and capture abnormal flows of a program to be debugged.

<Structure and Effects of the Invention> In order to achieve the above object, the program debugging device of the present invention includes means for setting a plurality of points on a source program to be debugged, and means for specifying the execution order of the set points. , when the program is executed, means for detecting the execution order of points, and means for displaying a coincidence when the specified order of points and the execution order match.

According to the above configuration of the present invention, it becomes possible to define and capture abnormal behavior of the program to be debugged in detail at the level of the source program, which has the effect of improving program development efficiency.

<Description of Examples> The present invention will be specifically described below based on examples shown in the drawings.

In this example, a general-purpose combinator is used, and peripheral devices and software are tested for debugging purposes. An example in which the present invention is implemented in a C'RAfi river debugging system, which expands the scope of application by replacing the
The present invention is not limited to this, and can be implemented in almost the same way on a dedicated debugging machine that operates on its own, and of course can be implemented by changing the language for the program to be debugged to various high-level languages other than "c". .

As shown in FIG. 3, a debug system implementing the present invention includes an engineering workstation 11 using a general-purpose computer, a terminal device 12 that allows an operator to directly access the workstation 11, and a workstation 11. The debug execution device 13 executes a program to be debugged developed using the debugger under control from the workstation 11 side, and enables debugging at the assembler level.

The workstation It mainly includes an arithmetic and control unit 21 using a microprocessor, an internal storage device 22 consisting of RAM, an external storage device 23 such as a hard disk drive, and an input/output device 24 equipped with an interface circuit for peripheral devices. It is connected via various buses 25, and is further connected to the workstation 11.
The terminal device 12 and the debug execution device 13 are connected through the input/output device 24.

The terminal device 12 includes a keyboard 26 that allows direct access to the workstation 11, and a display device 27 such as a CRT that visually displays the data processing status within the workstation 11.
By inputting a command from the keyboard 26, the compiler 3 shown in FIG. 4 stored in the external storage device 23 is activated.
After loading the data created from the execution program such as the Toshinpolink Devasoga 32, the source program 33, the load module 34, etc. into the internal storage jiff device 22, the programs 31 and 32 are sequentially executed in the arithmetic and control device 21. The workstation 11 operates as a debug system as a whole while controlling the debug execution device 13.

The debug execution device 13 is located between a device to be debugged 28, such as an electronic cash register, whose control unit is a microprocessor capable of running a program to be debugged, and the device to be debugged 28 and the workstation 11. The emulator 29 directly controls the debugged device 28 in place of the CPU. The emulator 29 can perform debugging at the assembler level by itself, but in this embodiment, the emulator 29 debugs the debugged object in response to commands given from the workstation 11 through the input/output device 24. After displaying and updating the contents of the memory on the device 28, or performing various controls such as executing and stopping the program on the device 28 to be debugged, the results are sent back to the workstation 11, thereby debugging the workpiece. This enables debugging processing at the level of a source program 33 using a high-level language on the station 11 side.

FIG. 4 schematically shows the flow of software processing mainly within the workstation 11 from when a source program 33 written in the C language is translated into machine language to when it is run by a symbolic debugger.

First of all, a source program 33 consisting of a plurality of files is run by a compiler 31 inside the workstation 11.
is compiled to form the load module 34. In addition to the machine language that can be executed by the microprocessor of the device to be debugged 28 , the load module 34 contains line number information that indicates the correspondence between the address of the machine language and the line number of the source program 33 , and information that is written on the source program 33 . The file format includes, for example, the operating system UNIX SYSTEM '7 (7) COFF.
(Common 0bject File Fo
rmat).

Next, when the symbolic debugger 32 is activated and a predetermined command is input from the keyboard 26 of the terminal device 12, emulator commands necessary for processing the command are sent to the emulator 29. Emulator 29
interprets and executes the emulator command, and then sends the result back to the debugger 32.

The symbolic debugger 32 has on its internal memory,
Based on the line number information of the load module 34, a line number table consisting of a record group consisting of machine language addresses, corresponding file names, function names, and line numbers is created in advance, and the debugger 32 uses the emulator The processing results returned from 29 are edited with reference to the line number table and source program file 33, and are displayed on the display device 27 of the terminal device 12.

The present invention is a debugging system having the above structure, and is characterized by a method of setting breakpoints for a program to be debugged.

FIG. 1 shows the procedure for setting breakpoints on a program to be debugged using the terminal device 12. The symbolic debugger 32 has a function of setting a plurality of points 41 on the source program 33 for defining the execution order of the program to be debugged, as in the conventional case.
)” and define the point 41 on the display screen 48 of the display device 27, the function mai
A breakpoint is set for the third line of n using the software breakpoint technique. In the illustrated example, the 10th line of the function main and the function fun
Point 4°1 is set at three locations on the 13th line of c.

Further, the debugger 32 inputs a command 43 "disp" that refers to the point number 42, and then assigns a different point number 42, for example 1 to 3, to the point 41 defined above according to the type of point. Assign automatically.

Next, using the point number 42 and the command 44 "seq" for defining the execution order of the points 41, the execution order of the points 41 is defined as "seq 1321". At this time, on the memory of the debug 32, a seq table 45 and an execution table 46 of a predetermined number of digits are provided in advance as shown in FIG. 5, and when the execution order of the point 41 is input using the seq command 44,
The data 47 with the specified number 42 is stored right-aligned in the seq table 45, and the remaining left column is filled with "0". In this example, ro1321 is on the seq table 45.
J data 47 is set, and the execution order is set so that a break occurs only when point number 42 is executed in the order of 1 → 3 → 2 → 1, and the occurrence of the break is displayed to the operator. to show that

FIG. 2 shows point 41 and point 4 as described above.
1 shows the flow of processing for detecting whether or not point 41 on the debugged program is executed in the specified order 47 when the debugged program is executed after the execution order 47 of No. 1 is defined. .

Step 51 indicates the "beginning" of execution, and the process is started by inputting a predetermined command to the debugger 32. In conjunction with the start of such processing, in step 52, all digits of the execution table 46 are initialized to rOJ as shown in FIG. 5(a).

Next, the program to be debugged is executed until it passes through any of the points 41 set in the above procedure and a break occurs (step 53). When it is detected that a break has occurred, in step 54, the contents of the execution table 46 are shifted to the left by one digit, as shown in Figure 5(b), and the contents of the execution table 46 are shifted to the left by one digit, and the point number "3" of the break that occurred this time is
” is set at the right end. Next, in step 55, the contents of the execution table 46 are compared with the seq table 45 for each digit, and rO of the data 47 on the seq table 45 is
It is determined whether all digits other than J match each other. If this determination is "NO", the debugger 32 automatically re-executes the program to be debugged and proceeds to step 53.
By returning to and repeating the above processing, the execution history of point 41 is recorded on execution table 46.

On the other hand, as shown in FIG. 5(C), the content 4 of the seq table 45
7 and the execution history of the execution table 46, and the determination in step 55 is "YES", the user has previously set
It is determined that points 41 on the debugged program were executed in the order defined by the q command 44, so in step 56 a message is sent to the user stating that the program was executed in the order defined by the rseq command. is displayed to notify the user that a break has occurred.

[Brief explanation of drawings]

Fig. 1 is a front view of a display screen showing an example of the procedure for specifying the execution order of points, Fig. 2 is a flowchart showing the procedure for detecting the execution order of points, and Fig. 3 is a debugging process for implementing the present invention. A block diagram showing an example of the system, FIG. 4 is a schematic diagram explaining the flow of processing in the system of FIG. 3, and FIG. 5 is an explanatory diagram showing the procedure for detecting the execution order of points. 11... Workstation 12... Terminal device 27... Display device 33... Source program 41... Point 46... Execution table patent Applicant: Near Tateishi Electric Co., Ltd. f3> Otonia flA fan// Fuksten//!

Claims (2)

[Claims] (1) means for setting multiple points on a source program to be debugged; means for specifying the order of execution of the set points; means for executing the program and detecting the order of the executed points; A program debugging device comprising: means for displaying a match when a specified order of points and an execution order match. (2) The point execution order detection means sets an execution table of a predetermined number of digits on the memory, shifts the contents of the execution table by one digit each time it passes through each set point, and adds a new one to the lowest digit. 2. A program debugging device according to claim 1, wherein values of passed points are set.