JPH10301804A - Debugging method and recording medium for recording debugging program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To execute the debugging work of a large scale with a little memory capacity by performing the debugging work by using only one symbol used in common among respective source files. SOLUTION: A CPU reads a symbol program list for debugging from debugging information to a debugger. Symbol information is read to the prescribed address of symbol address/correspondence information 21 and the address is stored in a symbol address/correspondence information index 20. Whether or not a read EQU symbol is already registered in a hash table 22 is retrieved, and when the symbol of the same name and same value is present in the hash table 22, the attribute of the already registered symbol of the same name and same value is changed to be public. Information relating to the symbol is distributed in a final shape from a work area. In such a manner, since the common symbol is not repeatedly stored among the plural source files, large-scale debugging is executed even with the main memory of a little capacity.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a debugging method and a recording medium for recording a debugging program used in computer program development and the like, and more particularly to a debugging method and a debugging program capable of performing a debugging operation with a small memory capacity. It relates to a recording medium for recording.

[0002]

2. Description of the Related Art Conventionally, in developing a program in a personal computer or the like, an execution program is created by compiling and linking a source program created in a high-level language such as the C language or an assembler language. By the way, it is rare that a source program created in this way operates completely from the beginning. That is, an error may occur during compilation or execution of the program due to a description error or the like (hereinafter referred to as a bug) included in the source program. Therefore, conventionally, in program development, an operation of removing a bug using a tool called a debugger (hereinafter, referred to as debugging) has been performed.

First, a conventional computer will be described. FIG. 6 is a block diagram showing the configuration of a conventional computer. 6, the computer 1 includes a CPU 3 as a central processing unit, a memory 4 as a main memory, an HDD 5 as a hard disk drive, a CD-ROM drive 6, and the like. Further, the computer 1 is connected with a CRT 2 as a display device, a keyboard 7 and a mouse 8 as input devices via an IO bus. Usually, a program for debugging (hereinafter, referred to as a debugger) is stored and held in the HDD 5 or a CD-ROM mounted on the CD-ROM drive 6, and is read out to the memory 4 and executed as needed. .

Next, a series of procedures from compiling a source program to debugging will be described with reference to the drawings. FIG. 7 is an explanatory diagram showing a series of procedures from compiling a source program created by a user to debugging.

As shown in FIG. 7, in this example, a common file (.INC) is included for each of four source files (.ASM) described in the assembler language. Then, each source file is compiled by a compiler, and each source file is composed of a machine language.
Is converted into the number of object modules (OM). Thereafter, each object module is linked by the linker, and the debug information and the load module (LM)
Is created.

Next, the debugging operation will be described in detail. The debugging operation is performed using the debug information and the load module shown in FIG. 7 and a debugger which is a tool for performing the debugging operation. First, a specific example (file name is test.asm) of a source program described in an assembler language is shown.
The numbers on the left end indicate line numbers, and the source program is described on the right side of these line numbers.

1 @PC (054) 2; 3; comment 4; 5 name imai 6 public start 7 ＄ include 'a. inc '8 vector cseg at 09 dw start 10 11 mac01 macro 12 local l_lab 13 mova, #TEN 14 l_lab: 15 deca 16lob albomac embalm 21m02a1m18m18 loop: 24 dec a 25 bnz ＄ loop 26 endm 27 28 text cseg 29 start: 30 nop 31 mac01 32 nop 33 mac02 34 nop 35 call! func 36 nop 37 'include' b. inc '38' include 'g. inc '39' include 'c. inc '40 nop 41 work: 42 nop 43 func: 44 nop 45 ret 46 end

The source program test. In the asm, a plurality of symbols are described in addition to instructions in assembler language such as "mov", "dec", and "ret".

Here, the attribute of "start" is public (hereinafter, referred to as public symbol). Therefore, a plurality of source files (.ASM) shown in FIG.
This is a symbol that is commonly used between. Also,
“Vector, text” is a segment symbol, and “ma
“c01, mac02” represents a macro symbol, and the attribute effective only in the source file “test.asm” is a local symbol (hereinafter, referred to as a local symbol). Similarly, “l_lab, loop, w
“ork, func” is also a local symbol.

By the way, test. Asm has four files (a. inc, b. inc, g. inc, c.
inc) is included. These include files are stored in test. asm
As well as shared by multiple source files (.ASM). For example, a. The specific example of inc is as follows.

[0011] 1 TEN EQU 10 2 FIVE EQU 5 ···

Here, "TEN" is an EQU symbol whose value is "10", and its attribute is local. Therefore, this EQU symbol “TEN” is assigned to test.
This symbol is valid only within the asm. Similarly, "FIVE" is an EQU symbol whose value is "5". That is, the EQU symbol included by the include file is treated as a local symbol in each included source file.

The source program described in this manner is converted into a data structure of a predetermined format at the time of debugging and then debugged. FIG. 8 is a block diagram showing a conventional data structure created at the time of debugging. In FIG. 8, a program information index 10 is created from a symbol program list in the debug information.
The program information index 10 is a set of pointers indicating addresses where program information 11, 12 and the like are stored.

The program information 11 is a set of information on load modules downloaded from the memory 4 in FIG. 6 to the debugger. That is, it has pointers to the external function information index 13, the external symbol information index 18, and the symbol / address correspondence information index 20.

The external function information index 13 is a set of pointers to the function information 14. The function information 14 is
It is a set of pointers indicating the argument information table 15 and the local variable information index 16. Note that the local variable information index 16 is configured by a pointer that points to local variable information 17 that is symbol information on local variables.

The external symbol information index 18 is a set of pointers pointing to the external symbol information 19. The symbol / address correspondence information index 20 is a set of pointers to the symbol / address correspondence information 21.
The symbol / address correspondence information 21 includes information on the symbol name and the address.

The program information 12 has the same configuration as the program information 11. However, the program information 12 in FIG. 8 further includes a file information index 23. File information index 23
Is file information 24 which is information about the source file.
Is a set of pointers to

The file information 24 is constituted by a set of pointers indicating a static function information index 26, a static symbol information index 30, a macro information index 32, a segment information index 34, and an include information index 36. The static function information index 26 is configured by a pointer pointing to the static function information 27, and the static function information 27 points to the argument information table 28 and the local variable information table 29.

The static symbol information index 3
0, macro information index 32, segment information index 34, and include information index 36
Each is constituted by pointers indicating static symbol information 31, macro information 33, segment information 35, and include information 37. Further, file information 24
Indicates auxiliary line information 25 which is line information of the source program. At the time of symbol loading, an area covered by hatching is formed, and at the time of symbol access, a portion not covered by hatching is formed.

Next, a specific procedure of the conventional debugging will be described. FIG. 9 is an explanatory diagram showing a conventional debugging procedure. In debugging, the symbol / address correspondence information index 20 and the symbol / address correspondence information 21 are used.

First, at the start of debugging, a work area of a predetermined size is secured in the memory 4 and every time a symbol is loaded, the symbol / address correspondence information index 2
0 and symbol / address correspondence information 21 are formed. In FIG. 9, the local symbols L1, L2,
Public symbols P1, P2, etc. are stored and held in the work area. And now, a new local symbol L2
Is read.

Then, the read symbol L2 is
It is stored and held at the address next to the symbol P3. Therefore, the symbol L2 is redundantly stored and held at the second address and the seventh address of the work area.

Thereafter, when all the symbols are read, all the symbols temporarily stored and held in the work area are distributed to the final form for each file. That is, for example, ASM local symbols are L1, L2, L5,
B. ASM local symbols are L3, L2, L6,
C. ASM local symbols are distributed as L4, L2 and L7, and public symbols are distributed as P1, P2 and P3. However, as described above, A.I. ASM, B .; A
SM, C.I. In the ASM, the local symbol L2 is redundantly stored and held.

[0024]

As described above, conventionally, symbols output from a language system (for example, EQU symbols, etc.)
, The symbols having the same name and the same value were sometimes read in duplicate, and a lot of memory was required for debugging. Therefore, in an environment where the memory capacity is limited, such as a personal computer, the size that can be secured as a work area is limited. There was a problem that it was difficult. An object of the present invention is to solve such a problem, and an object of the present invention is to provide a debugging method and a recording medium for recording a debugging program which can perform a large-scale debugging operation with a small memory capacity. .

[0025]

In order to achieve the above object, a debugging method and a recording medium for recording a debugging program according to the present invention provide one symbol commonly used between source files. Is used to perform debugging work. With this configuration, the present invention can perform debugging with a small memory capacity without reading the same symbol repeatedly.

[0026]

Next, one embodiment of the present invention will be described with reference to the drawings. The configuration of the computer and the like according to the present invention is the same as that of FIG. 6, and the program such as the debugger is stored and held in the HDD 5 or the CD-ROM mounted on the CD-ROM drive 6. Therefore, the debug program according to the present invention can be provided in a state recorded on a recording medium such as a CD-ROM. Then, insert this CD-ROM into CD-RO
By attaching the debug program to the M drive 6, the debug program is read into the memory 4 and executed as needed.

FIG. 1 is a block diagram showing a data structure created at the time of debugging. In FIG. 1, components having the same reference numerals as those in FIG. 8 indicate the same or equivalent components. The hash table 22 is a table for registering the read symbols by the hash method before registering them in the symbol / address correspondence information index 20.

Next, a debugging procedure according to the present invention will be described. FIG. 2 is a flowchart showing a series of debugging procedures. In step 101, the CPU 3 reads device-dependent information. That is, the device file storing the dependency information of the target CPU is read from the HDD 5 into the memory 4. This device file contains one CP
One file exists for each U. However, if an error occurs in the middle, the process ends.

In step 102, the operator uses the keyboard 7 or the mouse 8 to input debug conditions. That is, a dialog box is displayed on the screen of the CRT 2 and the target C to be debugged by the operator is displayed.
Settings such as PU and voltage are input.

In step 103, the CPU 3 performs hardware initialization. That is, a setting for communicating with an in-circuit emulator (hereinafter, referred to as ICE) (not shown) is performed. The information of the target CPU and the monitor program are downloaded from the HDD 5 to the ICE. However, if an error occurs in the middle, the process ends.

In step 104, the CPU 3 initializes the debugger body. That is, G of the debugger
All the modules below the UI section are activated, and the debugger window and menu are displayed on the CRT 2 screen. However, if an error occurs in the middle, the process ends. In step 105, the CPU 3 executes a message receiving loop. That is, when the operator selects the end menu using the keyboard 7 or the mouse 8, the step is 10 steps.
Move to 6. When the LM load menu is selected, the step moves to 107. However, if an error occurs in the middle, the process ends.

In step 106, the CPU 3 executes an end process because the end menu is selected by the operator. In step 107, the CPU 3 executes the LM loading process because the operator has selected the LM loading process. The details of the LM loading process will be described later.

Next, the LM load processing will be described in detail. FIG. 3 is a flowchart showing the procedure of the LM load process. In step 201, the CPU 3
From 5, the code and data of the load module to be debugged are downloaded to the memory 4. In step 202, the CPU 3 reads a symbol program list for debugging from the debug information into the debugger.

Next, the symbol loading procedure will be described in detail. FIG. 4 is a flowchart showing a symbol loading procedure. In step 301, the CPU 3 determines whether all the symbols have been read from the debug information. If all of them have been read, the process proceeds to step 308, and if not, the process proceeds to step 302. In step 302, the CPU 3 reads the symbol information into a predetermined address of the symbol address / correspondence information 21, and reads the symbol / address correspondence information index 2
0 stores the address.

In step 303, the CPU 3 determines whether the read symbol is an EQU symbol. E
If it is a KU symbol, proceed to step 304,
If it is not a symbol, the process proceeds to step 301. In step 304, the CPU 3 searches whether or not the read EQU symbol is already registered in the hash table 22. If it is registered in the hash table, the process proceeds to step 306;
Move to 05.

At step 305, the CPU 3 sets the EQ
The U symbol is registered in the hash table 22, and the process proceeds to step 301. In step 306, the CPU
No. 3 determines whether there is a symbol having the same name and the same value in the hash table 22. If there is a symbol having the same name and the same value, the process proceeds to step 301; otherwise, the process proceeds to 307.

In step 307, the CPU 3 changes the attribute of the registered symbol having the same name and the same value to public. In step 308, the CPU 2 distributes information on symbols from the work area to the final form.

FIG. 5 is an explanatory diagram showing a debugging procedure.
Note that the symbol / address correspondence information index 20 and the symbol / address correspondence information 21 are used in debugging, as in the case of FIG. Further, in the present invention, a hash table 22 is also used.

At the start of debugging, a work area of a predetermined size is secured in the memory 4 and a symbol / address correspondence information index 20 and a symbol / address correspondence information 21 are formed every time a symbol is loaded. Further, in the present invention, a hash table 22 (not shown in FIG. 5) is also created, and it is first determined whether or not the read symbols are registered in the hash table.

Now, as shown in FIG. 5, local symbols L1 and L2 and public symbols P are already stored in the work area.
1, P2, etc. are stored. Now, assume that the local symbol L2 is newly read.

Then, by searching the hash table 22, it is known that the read local symbol L2 has already been registered at the second address. Therefore, no additional registration is newly performed, and the attribute of the second local symbol L2 already registered is changed to public. That is, the local symbol L2 is set as the public symbol P4.

Thereafter, when all the symbols are read, all the symbols temporarily stored in the work area are distributed to the final form for each file. That is, for example, ASM local symbols are L1, L5, B.
ASM local symbols are L3, L6, C.I. ASM local symbols are distributed as L4 and L7, and public symbols are distributed as P1, P2, P3 and P4. As a result, the same local symbol is not redundantly stored and held.

[0043]

As described above, according to the present invention, a common symbol used between a plurality of source files is not redundantly stored, so that large-scale debugging can be performed even with a small-capacity main memory. be able to.

[Brief description of the drawings]

FIG. 1 is a block diagram showing one embodiment of the present invention.

FIG. 2 is a flowchart showing a debugging procedure according to the present invention.

FIG. 3 is a flowchart showing a debugging procedure according to the present invention.

FIG. 4 is a flowchart showing a debugging procedure according to the present invention.

FIG. 5 is an explanatory diagram showing a debugging procedure according to the present invention.

FIG. 6 is a block diagram illustrating a configuration of a computer.

FIG. 7 is an explanatory diagram showing a procedure from compiling to debugging.

FIG. 8 is a block diagram showing a conventional example.

FIG. 9 is an explanatory diagram showing a debugging procedure according to a conventional example.

[Explanation of symbols]

10, 12 ... program information index, 11 ... program information, 13 ... external function information index, 14 ...
External function information, 15: Argument information table, 16: Local variable information index, 17: Local variable information index, 18: External symbol information index, 19
... external symbol information, 20 ... symbol / address correspondence information index, 21 ... symbol address correspondence information, 2
2 ... Hash table, 23 ... File information, 24 ... File information, 25 ... Auxiliary line information, 26 ... Static function information index, 27 ... Static function information, 28 ... Argument information table, 29 ... Local variable information table, 30 ... Static symbol information index, 31 ... Static symbol information, 3
2 macro information index, 33 macro information, 34
... Segment information index, 35 ... Segment information, 36 ... Include information index, 37 ... Include information.

Claims (4)

[Claims] 1. A debugger for converting a plurality of source files into object modules according to a predetermined language system, and performing a debug operation using debug information and a load module obtained by linking these object modules. The debugging method according to claim 1, wherein the debugging is performed by using only one symbol commonly used between the source files. 2. The method according to claim 1, wherein each time symbol information is read from the debug information, it is determined whether or not the symbol information is registered in a predetermined hash table. When the symbol information is newly registered in the hash table, and when the symbol information is registered in the hash table, the attribute of the same symbol previously registered is made public instead of registering the symbol information in the hash table. A debugging method characterized by converting. 3. A debugger for converting a plurality of source files into object modules according to a predetermined language system, and performing a debugging operation using debug information and a load module obtained by linking these object modules. A recording medium for recording a debug program, wherein a debug operation is performed by using only one symbol commonly used between the source files. 4. The method according to claim 3, wherein each time symbol information is read from the debug information, it is determined whether or not the symbol information is registered in a predetermined hash table. When the symbol information is newly registered in the hash table, and when the symbol information is registered in the hash table, the attribute of the same symbol previously registered is made public instead of registering the symbol information in the hash table. A recording medium for recording a debug program characterized by conversion.