JPH03179535A - Debug supporting device - Google Patents

Abstract

PURPOSE:To enable a machine code to use a source code debugger by gathering the ranges where the inversion occurs into a block and preventing the inversion of the correspondence between an optimized machine code and a source code. CONSTITUTION:A source code file 11 has an input to the front end processing part 21 of a language processing system 12, and an assembler source file 22 with the row information outputted from the part 21 has an input to an optimization processing part 23. The part 23 optimizes the file 22 and outputs an assembler source file 24 with the row information. An assembly processing part 25 inputs the file 24 and gathers plural source code rows into a block to output an object module file 26 including a block information entry. A link processing part 28 inputs plural files 26 and outputs a single load modulefile 13 to input it to a source code debugger 14. The file 11 is also inputted to the debugger 14, and the debugging operation is carried out via a man-machine interface terminal equipment 15.

Description

[Detailed Description of the Invention] [Field of Industrial Application] The present invention relates to a debugging support device that enables debugging at the source code level, which is a support tool in the debugging process of software development. The present invention relates to a debugging support device for realizing execution point information used between a debugger and a user when the machine code of a program has been optimized by a compiler.

[Conventional technology]

When the machine code of a program to be debugged has undergone optimization processing by a compiler, line numbers of the source code have traditionally been used as execution point information.

There were three types of such debugging support devices:

(1> The first debugging support device is applicable only to machine code that has not been optimized by a compiler. This device accommodates the machine code output by the language processing system. Object module
The source code line information is contained in the file and load module file. In addition, the machine code generation processing section includes an output processing section that assigns line numbers of the source code to multiple machine codes corresponding to each line of source code and outputs line information. have. Furthermore, the source code debugger has a processing section that uses this line information to specify and display execution points.

In this first debug support device, if you specify by line,
The first machine code of a plurality of corresponding consecutive machine codes is specified, and the line of source code to which it belongs is displayed from any machine code. Since this device does not perform optimization processing, the order in which the source code is written and the order in which the machine code is stored are, in principle, the same.

Therefore, the user can debug at the source code level.

(2> The second debug support device is a device that is applied to machine code that has undergone compiler optimization processing. In this device, like the first debug support device, the object module file In addition, the source code line information is included in the load module file.Also, before the language processing system performs optimization processing, the corresponding source code is created for all machine code.
An output processing unit that assigns code line numbers, performs optimization processing, moves, deletes, changes, etc. the machine code, and outputs the line information in the order in which the resulting machine code is accommodated. have.

The source code debugger also has a processing unit that uses this line information to specify and display execution points.

In this second debugging support device, when a line specification is made, the first machine code among a plurality of corresponding discontinuous machine codes is specified, and the corresponding source code line is extracted from any machine code. is now displayed. For this device, for example 'An Overv
iew of the PL, 8Compiler,
Marc Au5lander and 1Jart
in11opkins, 1B! JT, J, Wa
There is a description in tson Research Center.

(3) The third debug support device is a machine that has undergone compiler optimization processing in the same way as the second debug support device.
It is a device applied to the code. With this device,
Similarly to the first debug support device, in the object module file and load module file,
Contains source code line information. Also, before executing optimization processing in the language processing system, the line number information of the source code is placed in the position before the first machine code of the multiple machine codes corresponding to each line of source code. After that, perform optimization processing. Also, when moving, deleting, changing, etc. the machine code, it is done without changing the position where the line number information is placed.

As a result, the line number of the previous line number information is assigned to a plurality of machine codes sandwiched between the positions where the line number information is placed. Multiple machines caught in between
If no code exists, the line number information that precedes the multiple machine codes that are sandwiched between the line number information after this pair and the position where the next line number information is placed. and the two line numbers of the previous line number information are assigned.

Furthermore, if the position of line number information with no intervening machine code is consecutive, the previous consecutive line number with no intervening machine code will be used for the subsequent multiple machine codes. Assign multiple line numbers to the information. and,
It has an output processing unit that outputs the line number and line information corresponding to the first machine code of a plurality of machine codes to which the line number is assigned in the order in which the line number information is placed. ing. The source code debugger also has a processing section that uses this line information to specify and display execution points.

In this third debugging support device, when a line is specified, the machine code of the line information of that line is specified, and the line with the largest corresponding line number from the arbitrary machine code is displayed. For this device, for example °'DOC:
A Practical Approach.

5source-Level Debugging
of G! obally 0pti+n+zedC
ode, Deborah S., Coutant,
Sue Meloy.

Michelle Ru5cetta, Hewlett
It is described in t-Packard.

[Problem to be solved by the invention]

The first debugging support device has a problem in that a source code debugger cannot be used for machine code that has undergone optimization processing.

Further, in the second debugging support device, the lines are converted into lines of source code in accordance with the optimized machine code. Accordingly, various problems arise when a line of source code is expanded into multiple machine codes that are placed in separate locations across different lines of machine code. In other words, when the corresponding source code is displayed as the machine code is executed, the source code
In level thinking, when a line that should be executed once is executed multiple times, or when the correspondence between source code and machine code is reversed in terms of order, the corresponding source code is - When displaying code, a problem arises in that lines that should be executed first are executed later when thinking at the source code level.

Further, in the third debugging support device, the position where line information corresponding to the source code line before optimization is placed is fixed, and the machine code is moved or deleted. For this reason, there is a problem in that the source code and machine code often do not correspond correctly when specifying or displaying line information.

Therefore, an object of the present invention is to make it possible to use a source code debugger on machine code that has been subjected to optimization processing, and to avoid problems such as the number of executions of lines, irregularities in the order of lines, and source code and machine code. The purpose of the present invention is to provide a debugging support device that correctly handles the problem.

[Means to solve the problem]

In the present invention, (i) a line information adding means provided in a compiler optimization processing section of a language processing system and adding source code line information to each machine code unit; (iii) a block information output processing means provided in the generation processing unit, which collects a plurality of lines in a range where the ordering is reversed in the correspondence between the source code and the machine code into one block; The debugging support device is equipped with a processing unit that specifies and displays an execution point using this block information in the debugger.

Then, the range in which the inversion occurs is summarized using the concept of a block, and the above-mentioned purpose is achieved.

〔Example〕

Hereinafter, the present invention will be described in detail with reference to Examples.

FIG. 1 shows the configuration of a debugging support device in an embodiment of the present invention. This debug support device is
Language processing system 1 that manually creates source code files 11
2, a source code debugger 14 into which the load module file 13 output from the language processing system 12 and the source code file 11 described above are input;
A human-machine interface terminal device 15 is connected to a source code debugger 14. Man-machine interface terminal device 15
is a device for inputting instructions from the user 16 and outputting necessary data when debugging.

The language processing system 12 includes front end processing units 21 prepared for each type of language. An assembler source file 22 with line information outputted from the front end processing section 21 is input to an optimization processing section 23 . The optimization processing unit 23 changes this and outputs an assembler source file 24 with line information.

The assemble processing unit 25 inputs this assembler source file 24 and outputs an object module file 26 containing block information entries. The link processing unit 28 manually processes a plurality of object module files 26 and outputs one load module file 13.

FIG. 2 shows the contents of a portion of the source code file of the debug support device having such a configuration. Executable statements are written in the 10th to 12th lines of the source code file 11 as shown in FIG. 2, respectively.

The source code file 11 is manually input to the language processing system 12 for front-end processing! ! 21, it becomes an assembler source file 22 with line information.

FIG. 3 shows a portion corresponding to FIG. 2 as part of the contents of this assembler source file with line information. It can be seen that in the assembler source file 22 with line information before optimization, the executable statement shown in FIG. 2 is expanded with line information. That is, in each line from the 10th line to the 12th line, there is a line information assembler virtual instruction at the beginning, and one line of executable statement is expanded into a plurality of assembler instructions. The expansion order of each line is the order of the lines in the source code file 11.

FIG. 4 shows the contents of a portion of the assembler source file with line information after being processed by the optimization processing section. Assembler source with line information shown in Figure 3
It can be seen that the file 22 has been subjected to optimization processing by the optimization processing unit 23, and instructions have been moved or deleted. That is, unless an assembler instruction expanded from the same line follows, a line information assembler virtual instruction is placed before each assembler instruction. In addition, there may be a shift such that an assembler instruction on another line is inserted in the middle of an assembler instruction expanded from the same line, or the relationship between the line order of the source code file 11 and the corresponding line in the expanded assembler instruction may be incorrect. It's reversed.

FIG. 5 shows the contents of a portion of the line information section of the object module file and load module file after being processed by the assembler.

It is shown that the assembler instruction group in the range shown in FIG. 4 constitutes one block.

That is, assembler source file 24 in FIG.
Before assembler instruction 2 on line 12 in the source code file 11, there is no assembler instruction that is expanded from a line older than line 9 of source code file 11, and assembler instruction 2 on line 10 in FIG. After that, there are no assembler instructions that are expanded from lines smaller than the 13th line. Also, line e of source code file 11 from line 10 to line 12
If the assembler instructions to be expanded are reversed due to the relationship between corresponding lines, the block information entry is changed from the 10th line to the 12th line.
Line information related to the line) It is placed before the IJ group.

This entry has three items: a start line, an end line, and a link to the next block information entry. In addition, the line information entry that constitutes a block is generated for each line information assembler virtual instruction, and includes an item containing the line number and a program count value (PC) that indicates the execution location of the assembler instruction immediately following the virtual instruction. It is shown that it consists of items that contain the values of .

FIG. 6A shows an example of a display state of the man-machine interface terminal device shown in FIG. In this example, the 11th page of the source code file 11 is displayed on the terminal screen 31 of the man-machine interface terminal device 15.
The display when setting a break point for debugging is shown on line 1. The machine code is made up of the assembler instructions shown in FIG. 4 and is as shown in FIG. 6B. In the display state shown in the figure, the 11th line of the source code file 11 is displayed in reverse black and white to designate the corresponding line. With this specification, the first instruction of the block to which the relevant line belongs becomes the setting point. In this example,
As shown in FIG. 6B, instruction 2 on the 12th line becomes the setting point.

Similar to FIG. 6, FIG. 7 shows an example of the display state of the man-machine interface terminal device shown in FIG. In this example, the stop point when the machine code is used to stop is displayed on the terminal screen 31 of the man-machine interface terminal device 15. The machine code is also made up of assembler instructions in Figure 4,
The result is as shown in FIG. 7B. If you stop at a certain instruction in this way, the corresponding source code of the block to which that instruction belongs
Consecutive lines of the code file are inverted in black and white to indicate stopped blocks.

FIG. 8 shows the processing of the input processing section of the optimization processing section. The human power section in the optimization processing section 23 shown in FIG. 1 performs the pre-processing of the process of inheriting the line information of the source code of the machine code unit. Here, each time a line information assembler virtual command is input, the line number value is set in the line number work (memory) 41. The intermediate code entry 42 has an intermediate code setting item 43 and a line number setting item 44, and each time an assembler instruction is input, this is converted into an intermediate code and set in the intermediate code setting item 43. Then, the value of the line number work 41 at this time is set in the line number setting item 44, and an intermediate code file is created.

FIG. 9 shows the flow of processing operations of the human processing section of the optimization processing section shown in FIG. 8.

The line number work is first initialized (step in Figure 9),
When one instruction is input (step ■), it is determined whether or not it is a line information assembler virtual instruction (step ■). If it is a line information assembler virtual instruction (Y), the line number work 41 contains that instruction. Set the line number value (step ■)
. Then, return to step ■.

If it is not a line information assembler virtual instruction (step ■; N
), the line is an assembler instruction, so the intermediate code setting item 43 and line number setting item 44 are converted into intermediate code (step 2). Then, it is determined whether or not the line number work is in an initialized state (step ■). If it is in the initialized state, output the converted intermediate code as it is (step ■>, and return to step ■. If it is not in the initialized state, add a line number to the intermediate code and output it). (Step ■), return to Step ■.

FIG. 10 shows the processing of the output processing section of the optimization processing section. The output section of the optimization processing section 23 is a machine/
Performs the subsequent processing of inheriting source code line information on a code-by-code basis. Here, line number work (memory) 5
1 is initially cleared to "0" once. Each time an intermediate code entry 52 is input, the values of the line number setting item 53 and the line number work 51 are compared, and if they do not match, the value of the line number setting item 53 is stored in the line number work 51. A line information assembler virtual instruction is output from the value of this line number work 51.

In addition, regardless of whether the comparison results match or do not match, the intermediate code
The value of the intermediate code setting item 54 of the entry 52 is converted into assembler instructions and output.

FIG. 11 shows the flow of processing operations of the output processing section of the optimization processing section shown in FIG. 10. The line number work is first initialized (step ■ in FIG. 11), and when an intermediate code entry is input (step ■), the values of the line number setting item 53 and the line number work 51 are compared (step ■). If they match, the value of the intermediate code setting item 54 of the intermediate code entry 52 is converted to an assembler instruction, this is output (step ■), and the process returns to step ■.The comparison result does not match. In this case, the value of the line number setting item 53 is stored in the line number work 51 (step ■).

Then, a line information assembler virtual instruction is output from the value of this line number work 51 (step ≦), and the process then proceeds to step ①.

FIG. 12 shows the output processing of block information entries and line information entries in the assembler shown in FIG. 1. In the assemble processing section 25,
It performs block information entry processing in which multiple source code lines corresponding to multiple continuous machine codes are grouped together as a block, and output processing of line information (en) +7. For this purpose, input the variable 5TART containing the start index value as the index value MAX of the trailing row information entry of the block. Input the variable 5TART containing the value (step ■).

By the way, FIG. 13 shows the range corresponding to the optimization processing unit in the row information entry table.

This row information entry table 61 stores row information entries corresponding to optimization processing units in the range from index value m to index value n. In this case, as shown in FIG. 14, the index value of variable 5TART is "m", and the index value of variable END is "n".
becomes.

Returning to FIG. 12, the explanation will be continued. At step knob ■, it is determined whether the variable FROM is less than or equal to the variable END. If it is below (Y>, line information containing the line number serving as the inversion reference), set the variable FROM to the index value IX of IJ (step ■). Then, it is determined whether the index value Ix is less than or equal to the index value MAX of the trailing row information entry of the block (step ■), and if it is less than (Y), the index value Ix is EN inverted between IX and variable END) Detect the maximum index of IJ (step ■). If this detection is performed and this is greater than the index value MAX, <step ■;
Y>, manually input the detected index value as the index value MAX (step ■). Then, add "l" to the index value IX (step ■), and proceed to step ■.If the case is other than this in step ■, proceed to step ■, and add "l" to the index value IX. ,
We will proceed to step ■.

In addition, if the index 1 direct IX is larger than the index value MAX of the trailing row information entry of the block in step (2) (N), a block is created from the variable FROM with the entry of the index value MAX, and the block information entry, A group of row information entries is output (step 0).

Then, the variable FROM is set to “
Enter a value that is 1” higher (step ■) and proceed to step ■.

FIG. 15 shows the process of determining the start line and end line for displaying the execution point of the source code debugger shown in FIG.

When the program counter value is entered, this input PC
A row information entry is extracted from the value (step in FIG. 15). Then, a block information entry is extracted from the extracted line information entries (step ■), and a start line and an end line are output from this block information entry (step ■).

FIG. 16 shows a part of the line information section of the load module file. As shown in this figure, it can be seen that in the row information B71, the row information entry is extracted from the human PC value, and the block information entry is extracted based on this.

FIG. 17 shows the process for finding the program counter at the beginning of the corresponding block. When a line number is input, a block information entry is extracted based on this (step 2 in FIG. 17).Then, a line information entry immediately after the extracted block entry is extracted (step 2).

The program counter value of this extracted line information entry will be output.

FIG. 18 shows a part of the line information section of the load module file. Since the manually entered line number is between the start line and the end line, it can be seen that the block information entry is first extracted based on this, and then the line information (IJ) is extracted.

FIG. 19 shows a part of the line information portion of an object module file or a load module file when the line information assembler source file 22 is processed directly by the assemble processing section 25 without going through the optimization processing section 23. It represents the content. It corresponds to a group of assembler instructions in the range shown in FIG. 3, and is composed of l blocks corresponding to one line.

[Effects of the Invention] As explained above, according to the present invention, the range in which inversion occurs is summarized by the concept of a block, so that the machine code that has been optimized by the language processing system and the source code can be made to correspond. In this case, no reversal occurs in the correspondence for this block. Therefore, it is possible to think and debug blocks at the source code level.

Furthermore, when debugging is difficult in block units, by not optimizing only the relevant source file, it is possible to perform debugging that can be controlled on a line-by-line basis, that is, on a line-by-line basis.

[Brief explanation of drawings]

The drawings are for explaining one embodiment of the present invention. Among them, Fig. 1 is a schematic configuration diagram showing the outline of the configuration of the debugging support device, and Fig. 2 shows the contents of a part of the source code file. Figure 3 is an explanatory diagram showing part of the contents of an assembler source file with line information.
Figure 4 is an explanatory diagram showing the contents of a portion of the assembler source file with line information after processing by the optimization processing unit, and Figure 5 shows the object module file and load after processing by the assembly processing unit.・Explanatory diagram showing the contents of a part of the line information section of the module file, Part 6
Figure A is a front view showing an example of the display state of the man-machine interface terminal device shown in Figure 1, and Figure 6B shows setting points in the machine code in the display state shown in Figure A. Explanatory drawings, FIG. 7A is a front view showing another example of the display state of the man-machine interface terminal device, and FIG. 7B shows stopping points in the machine code in the display state shown in FIG. 7A. Explanatory diagram ゛, Figure 8 is an explanatory diagram showing the processing of the human processing unit of the optimization processing unit, Figure 9
The figure is a flowchart showing the flow of processing operations of the human processing unit of the optimization processing unit shown in Fig. 8, Fig. 10 is an explanatory diagram showing the processing of the output processing unit of the optimization processing unit, and Fig. 11 is 10th
FIG. 12 is a flowchart showing the flow of processing operations of the output processing section of the optimization processing section shown in the figure. FIG. 12 is a flowchart showing the output processing of block information entries and line information entries in the assembling processing section. is an explanatory diagram showing the range corresponding to the optimization processing unit in the row information entry table, Fig. 14 is an explanatory diagram showing an example of the index value of variable 5TART and variable END, and Fig. 15 is an explanatory diagram showing an example of the index value of variable 5TART and variable END. A flowchart showing the process of finding the start line and end line for displaying the execution point. Figure 16 is an explanatory diagram showing part of the line information section of the load module file. Figure 17 is the corresponding block. Figure 18 is an explanatory diagram showing a part of the line information section of the load module file. Figure 19 is the case where optimization processing is not performed. FIG. 3 is an explanatory diagram showing the contents of a part of the line information section of the object module file and load module file of FIG. 11... Source code file, 12...
...Language processing system, 13...Load module file, 1
4... Source code debugger, 15...
...Man-machine interface terminal device, 21...Front end processing section, 22...
...Assembler source file with line information, 23...Optimization processing section, 24...Assembler source file with line information, 25...Assemble processing 26...Object module file, 28...Link processing section, 31...Terminal screen, 71...Line information section.

Claims (1)

[Claims] 1. Provided in a compiler optimization processing section of a language processing system,
A line information adding means that adds source code line information to each machine code unit and a machine code generation processing unit of a language processing system are provided to prevent order reversal in the correspondence between source code and machine code. The present invention is characterized by comprising a block information output processing means that collects multiple lines in a range into one block, and a processing unit that uses this block information to specify and display an execution point in a source code debugger. A debugging support device. 2. Provided in the object module file and load module file that contain the machine code output by the language processing system, and includes a block information entry that summarizes multiple lines in addition to the line information of the source code. The debugging support device according to claim 1, characterized in that: 3. The debugging support device according to claim 1, wherein the input and output files of the compiler optimization processing section of the language processing system have the same format.