JP2001290674A - Device and method for setting program breakpoint - Google Patents

Abstract

PROBLEM TO BE SOLVED: To solve the problem where a range to set a breakpoint cannot be designated and breakpoint setting conditions are limited to a function unit concerning a conventional breakpoint setting method for setting the breakpoint to a function callout point. SOLUTION: A compiler 202 analyzes a source file 201, position information composed of class name, object name, function name, argument list, file scope, class scope, function scope, row number and address is extracted by a position information extracting part 404 and a position information table 1000 is prepared. A debugger 600 collates the position information table 1000 with each of items in the position information, which is inputted by a user as breakpoint setting conditions, in a breakpoint setting condition collating part 602, and the breakpoint is simultaneously set to one or plural relevant addresses.

Description

DETAILED DESCRIPTION OF THE INVENTION <Explanation of Terms> Before entering into details of the invention, words used in the description will be explained. -Address label The address to be accessed when the program is actually executed on the computer is determined at the time of linking. Therefore, in the assembly file output by the compiler, the address is represented by a label, and the label is replaced with the address at the time of linking to generate an executable file. This label is called an address label. -Argument list Argument list is a list of arguments of the function. In a language in which functions can be overloaded (such as C ++ language), if the function names are the same, the functions are distinguished by differences in arguments. The present invention uses this argument list to limit overloaded functions. -Scope Generally, the scope in which the names of declared functions and objects can be used. The file scope is the effective range in file units (translation units), the function scope is the effective range in function units, and the class scope is the effective range in class units. -Position information A set of information that is candidates for the position (address) at which to set a break point. The elements of the set include the class name of the object, the object name, the name of the function to be called, the argument list that lists the arguments for limiting the function, the file scope to which it belongs, the class scope, the function scope, and the line number in the source file , There is an address on the executable file.・ Lexical analysis This is an analysis process that divides a character string of a program into minimum units (called tokens) that have meaning as a language.・ Parsing Parsing tokenized programs by lexical analysis
It refers to the process of analyzing according to the syntax that is the composition of the language, and checking which part of the program corresponds to which syntax, and whether there is a syntax error.・ Semantic analysis The process of identifying variables and operators in a program processed by syntax analysis, checking for semantic errors, and analyzing the meaning of the language. The main processing contents include associating the use of variables with declarations, checking type information, identifying operator types and operands, and the like. -Intermediate code This is an intermediate level program equivalent to the program in the source file, such as an abstract syntax tree or Polish code. It is created to facilitate optimization of the target code and code generation for multiple target machines. -Implicit member function call In C ++, this is a call to a member function that is called implicitly instead of explicitly using the dot operator (.) Or pointer operator (->). Calls to member functions such as constructors, destructors, and assignment operators.

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method for setting a break point at which execution of a program is interrupted during debugging.

[0002]

2. Description of the Related Art When debugging a program, a break point of program execution is often set to check the type and value of a variable in a certain state during execution. FIG. 11 shows a conventional example of setting an interruption point.
As a means for setting a breakpoint provided in a conventional debugger, setting using a line number of a source program 11
01, 1102, and setting methods 1103, 1104 using absolute addresses in an object program.

There are also methods 1105 and 1106 for setting a break point by designating a function name. In this case, the interruption point is generally set to the start point or the end point of the designated function. Considering that the basic unit of processing in a procedural language is a function, it is considered effective to set a break point by a function name. However, depending on the language, it may be more effective to suspend processing at a function call point than to suspend processing at a function start point. An example is a virtual function in the C ++ language. FIG. 12 shows an example of calling a virtual function in the C ++ language. This function has a feature of being dynamically called, and calls a function corresponding to an object type at the time of execution, not at the time of compilation, from among a plurality of functions defined as virtual functions. In the example of FIG. 12, a virtual function call 1201 calls a virtual function of class B, which is a runtime type, and a virtual function call 1202 calls a virtual function of class C, which is a runtime type. In this way, it is important which object is called at execution time. Therefore, rather than setting a break point at the start point of the function whose control has been transferred to the caller, the process is interrupted before control is transferred, that is, at the function call point Need to be done. In particular, it is up to the user to check the functions to be subjected to specific dynamic binding and to confirm the call point where the dynamic binding is performed. This function is highly likely to be used incorrectly. Therefore, it is necessary to set a break point at the function call point. Also, when the function of implicit member function call is provided, the member function may be called from an unexpected part due to the implicit call. Confirmation of this call point is left to the user, and therefore, it is necessary to set a break point at the function call point.

[0004]

A method of setting a break point at all relevant call points by specifying a function has already been proposed in Japanese Patent Laid-Open No. 6-290077. However, the proposed approach has several problems.

First, there is no mechanism for designating a range for setting an interruption point. Since a range cannot be specified, an interruption point is set for all corresponding function call points. This means that an interruption point is set at an unnecessary portion outside the range to be debugged, which hinders efficient debugging.

Further, the setting unit of the interruption point is limited to the function unit. In the case of a procedural language, there is no problem because the basic unit of processing is a function unit. However, in the case of an object-oriented language, since processing is performed in units of objects, a mechanism for setting a break point is required not only in units of functions but also in units of objects or classes that represent the types of objects. However, the above proposed method only supports processing on a function-by-function basis, and is insufficient as a method for setting a break point in an object-oriented language debugger.

Therefore, an object of the present invention is to take into account the characteristics of an object-oriented language, specify information on a class basis, an object basis, and a function basis, and provide a range for executing the setting of a break point. An object of the present invention is to provide an efficient program execution interruption point setting method for setting one or a plurality of interruption points only in a necessary range at a time.

[0008]

In order to achieve this object, a program interruption point setting device according to the present invention comprises position information extracting means for extracting position information for a specific processing unit. By providing this means, when a specific process is executed in the program of the source file, information on a position corresponding to the process is extracted and recorded as information that enables a debugger to efficiently set a break point. Can be. The apparatus further includes a break point setting condition matching unit that checks the position information extracted by the position information extracting unit with a break point setting condition input by a user. By providing this means, the position information extracted by the position information extracting means is compared with the break point setting condition input by the user, and the position information that satisfies all of the break point setting conditions is determined as the break point. The position to be set can be determined. The apparatus further includes an interruption point setting unit configured to set an interruption point at one or a plurality of positions corresponding to the interruption point setting condition based on a result of the comparison by the interruption point setting condition comparison unit. By providing this means, it is possible to provide an efficient program execution interruption point setting method for setting one or a plurality of interruption points only in a necessary range at a time.
FIG. 1 shows an embodiment of the present invention.

[0009]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS FIG. 2 shows a source file 201 to an assembly file 203 and a relocatable file 20.
5 and a flowchart until the execution format file 207 is created. First, the source file 201 is converted into an assembly file 203 by the compiler 202. Thereafter, the assembly file 203 is subjected to machine language conversion by the assembler 204, and a relocatable file 205 is generated. At this stage, the execution address of each machine language instruction is represented by a label. Thereafter, the address of the memory is assigned to each label by the address resolution processing in the linker 206, and the executable file 2
07 is generated. Assembler 204 and linker 2
06 is not the focus of the present invention, and a detailed description thereof will be omitted.

<Structure of Compiler Apparatus> FIG.
FIG. 3 is a configuration diagram of a compiler device 202. The compiler includes a data analysis unit 301, an intermediate code generation unit 302, an optimization unit 303, a resource allocation unit 304, and a code generation unit 305.

The data analyzer 301 performs lexical analysis, syntax analysis, and semantic analysis on the source file 201 stored in the storage device. It is also this part that extracts the position information, which is the information according to the present invention, and generates the position information table 1000. Details of the data analysis unit 301 will be described later.

The intermediate code generation unit 302 deletes information unnecessary for subsequent analysis from information passed from the data analysis unit, and generates an intermediate code so that analysis can be performed more easily.

The optimizing unit 303 optimizes the intermediate code to reduce the size of the target program to be generated and to improve the execution efficiency.

The resource allocating unit 304 allocates variables in the intermediate program to registers and memories that are storage resources on the microprocessor.

The code generator 305 converts the intermediate program into a machine language instruction program.

Intermediate code generator 302, optimizer 30
3. Since the resource allocation unit 304 and the code generation unit 305 are not the main subject of the present invention, detailed description will be omitted.

In the configuration of the compiler shown here, the data analysis unit is a component according to the present invention, and the configuration of the compiler excluding this is the same as that of the conventional compiler.

FIG. 3B is a flowchart in the compiler 202. Input source file 2
For 01, data analysis processing is executed in step 306. Next, in step 307, an intermediate code generation process is executed. Next, in step 308, an optimization process is performed. Next, in step 309, resource allocation processing is executed. Next, in step 310, a code generation process is executed to generate an assembly file 203. The data analysis processing is performed by the data analysis unit 301, and the intermediate code generation processing is performed by the intermediate code generation unit 3.
02, the optimizing unit 303 for the optimizing process, the resource allocating unit 304 for the resource allocating process, and the code generating unit 305 for the code generating process.
It is done in. Note that the processing in FIG. 3B may be executed after reading all the contents of the source file 201, or may be executed by sequentially reading a part of the source file 201.

Next, the details of the data analyzer 301 will be described. FIG. 4A is a configuration diagram of the data analysis unit 301. The data analysis unit 301 includes a lexical analysis unit 401, a syntax analysis unit 402, a semantic analysis unit 403, and a position information extraction unit 404, which is a component according to the present invention.

The lexical analysis unit 401 performs lexical analysis processing for dividing a character string of a source program into minimum units having a meaning as a language.

The syntax analysis unit 402 analyzes which part of the lexically analyzed source file corresponds to which syntax, and checks whether the source file has a syntax error. Perform

The semantic analysis unit 403 identifies the variables and operators of the parsed source file, checks for semantic errors, and analyzes the meaning of the language. Perform processing.

The position information table extractor 404 has a configuration according to the present invention. The position information table extractor 404 extracts position information for a specific processing unit from the result of the semantic analysis processing, and allows a debugger to efficiently set a break point. Position information table 10 which is information
00 is generated.

FIG. 4B is a flowchart in the data analyzer 301. First, a lexical analysis process is performed in step 405, and the process proceeds to step 406 where a syntax analysis process is performed. Next, semantic analysis processing is executed in step 407, and position information extraction processing is executed in step 408. The lexical analysis processing is performed by the lexical analysis unit 401, the syntactic analysis processing is performed by the syntactic analysis unit 402, the semantic analysis processing is performed by the semantic analysis unit 403, and the position information extraction processing is performed by the position information extraction unit 404. Even if each process is executed after reading all the contents of the source file 201, the source file 20
1 may be sequentially read and the execution may be repeated.

Next, the processing of the position information table extraction unit 404, which is processing according to the present invention, will be described in detail. FIG. 5 is a flowchart in the position information extracting unit.

The location information extracting process is performed on the portion where the semantic analyzing process is completed in the semantic analyzing unit 403.
First, in step 501, it is determined whether or not a member function call is made. If the analysis target part in the source file is a call of a member function (including an implicit member function call), in step 502, the class name, object name, function name, argument list, and file scope of the member function, which is positional information, Name, class scope name, function scope name, line number in the source file, and address label assigned to the instruction to be analyzed
0 (the position information table 1000 is generated and recorded if the position information table 1000 does not exist). If the analysis target is a call to a member function,
The process proceeds to step 503 to determine whether the calling function is a virtual function of the base class. If the class of the object is a base class, step 504
Then, a process of changing the class name item to a derived class (when there are a plurality of classes, changing all of them) and recording it in the position information table 1000 is performed. This is a process for dealing with a virtual function. As described in the specific examples 1201 and 1202 in FIG. 12, even when the virtual function is activated by the object pointed to by the pointer to the base class at the time of compiler analysis, the virtual function is activated by the derived class type object at the time of execution. This is because it is possible that Therefore, since information must be recorded for every conceivable activation, it is necessary to record the position information changed to all the derived classes in the position information table 1000.

The above processing is performed every time data is sent from the semantic analysis processing 407, and is continued until all the data analysis processing 306 of the source file 201 is completed, thereby generating the position information table 1000.

<Structure of Debugger Device> FIG. 6 is a diagram showing the structure of the debugger device 600. The debugger device 600 includes an input command processing unit 601, an interruption point setting condition matching unit 60
2, a break point setting unit 603, a break point display unit 604, a program execution processing unit 605, and an information display unit 606.

The input command processing unit 601 analyzes an input command. If the command is a breakpoint setting command, the position information table 1000 which is a set of position information extracted by the position information extraction unit 404 of the compiler device 202.
And the interruption point setting condition input by the user are transferred to the interruption point setting condition collating unit 602. If the command is a program execution command, the processing is shifted to the program execution processing unit 605. If the command is an information display command, the process proceeds to the information display unit 606.

The interruption point setting condition collating unit 602 includes: a position information table 1000 generated by the compiler 202;
The information on the breakpoint setting condition input by the user is collated, and a function call point that matches the condition is extracted. Details of the interruption point setting information collation unit 602 having the configuration according to the present invention will be described later.

The break point setting unit 603 receives the result of the extraction by the collating unit, and performs a process of setting a break point at a corresponding point.

The interruption point display section 604 performs a process of displaying the location of the interruption point set by the setting section.

The program execution processing unit 605 is activated when a program execution command is input, and executes a program. When the execution of the program reaches the set interruption point, the execution of the program is interrupted.

The information display unit 606 is activated when an information display command is input, and outputs information on the input object.

The configuration of the debugging device according to the present invention is an interruption point setting information collating section 602, except for the input command processing section 601, the interruption point setting section 603, and the interruption point display section 6.
04, the program execution processing unit 605 and the information display unit 606 are the same as those provided in the conventional debugging device.

First, details of the processing of the break point setting condition collating unit 602 will be described, and then the entire debugging processing will be described. FIG. 7 is a flowchart in the interruption point setting condition matching unit 602. At the start of the debugging process, the position information table 1 corresponding to the file to be debugged
000 is read. The interruption point setting condition collation unit 602 receives the interruption point setting condition input by the user from the input command processing unit 601. First, in step 701, the break point setting condition input by the user is compared with the position information table 1000 recorded by the position information extraction processing 408. As a result of the comparison, of the position information included in the position information table 1000, the address holding the position information including all of the breakpoint setting conditions input by the user is determined as the address at which the breakpoint is set. Next, it is passed to step 702,
The position information having the determined address is passed to the break point setting unit.

Next, the entire debugging process will be described. FIG. 8 is a flowchart of the debugging device. First, in step 801, the debugger in a command input waiting state proceeds to step 802 and determines whether a command has been input from the user. If a command has been input, the process proceeds to step 803 where the debugger analyzes the input command received from the user and makes a determination. If the result of the determination is that the command is a break point setting command, the process proceeds to the break point setting condition matching unit 502 described above. In step 701 of the break point setting condition matching unit 502, the condition is compared with the position information table 1000. As a result of the comparison, of the position information included in the position information table 1000, the address holding the position information including all of the breakpoint setting conditions input by the user is determined as the address at which the breakpoint is set. Next, the process is passed to step 702, and the position information having the determined address is passed to the interruption point setting unit. Next, the process proceeds to step 804 to perform a process of setting a break point for the address. Then, the process proceeds to step 805 to display the position information on the set interruption point, and shifts to a command input waiting state. Step 803
If the result of the analysis of the command is a program execution command, the process proceeds to step 806 to execute the program according to the command. During execution, the process proceeds to step 807 to determine whether or not the interruption point has been reached at any time. If the interruption point has been reached, the process proceeds to step 808 to execute the interruption process of the program. If the interruption point has not been reached, step 80
Then, it is determined whether or not the program is completed. If the processing has been completed, the processing shifts to step 801 to shift to a command input waiting state. If not completed, the processing proceeds to step 806.
Go to and continue executing the program. If the analysis result of the command is an information display command in step 803, the process proceeds to step 810 to display information corresponding to the specified command, and then proceeds to step 801 to shift to a command input waiting state.

The above steps 801, 802, 80
3 is an input command processing unit 601, steps 701 and 70
2 is an interruption point setting condition matching unit 602, step 804 is an interruption point setting unit 603, and step 805 is an interruption point display unit 60.
4. Steps 806, 807, 808, and 809 are for the program execution processing unit 605, and step 810 is for the information display unit 6.
06.

Hereinafter, the present invention will be described in detail with reference to specific examples. FIG. 9 is an example of a source program. The programming language is C ++.

The header file "header.h" defines each class and defines member functions. The first to sixth lines define the class A, and the eighth to eleventh lines define the class B. For simplicity, the definition of the member functions of each class is omitted. Class A and class B have an inheritance relationship.

The processing performed by the position information extraction unit 404 on the part for which the semantic analysis has been completed will be described with reference to the flowchart in the position information extraction unit of FIG. 5 and the position information table of the embodiment of FIG.

The source file src1.cc defines functions and objects and processes member function calls. The first line reads the header file header.h that describes the class definition.

First, the object definition 901 of the class A is performed on the third line. Here, since the constructor A () of the class A is implicitly called, step 501 is executed.
Becomes true. Therefore, according to step 502, position information 1
001 (Class name: A, Object name: objA1, Function name: A, Argument list: void, File scope: src1.c
c, class scope: none, function scope: none, line number: 3, address label: L01) location information table 1
Record to 000. Here, L01 is a label name automatically given by the compiler, and is converted to a real address at the time of address resolution at the time of linking.

Next, the object definition 902 of the class B is performed in the eighth line. Since the class B is a derived class of the class A, the constructor of the base class is also called at the time of the constructor. Therefore, as in the third line, the constructor A () of the base class A is implicitly called.
(Class name: B, Object name: objB1, Function name:
A, argument list: void, file scope: src1.cc,
Class scope: None, Function scope: func1 (void),
(Line number 8, address label: L02) is recorded in the position information table 1000.

Next, since the call 903 of the mfunc () member function is performed in the eleventh line, the position information 1003 (class name: A, object name: objA1, function name: mfunc, argument list: void, file scope: src1.cc, class scope: none, function scope: func1 (void), line number 11, address label:
L03) is recorded in the position information table 1000.

Next, since the virtual function call 904 of vfunc () is performed on the twelfth line, the position information 1 is obtained in the same manner as described above.
004 (class name: A, object name: objA2, function name: vfunc, argument list: void, file scope: src
1.cc, class scope: none, function scope: func1 (vo
id), line number 12, and address label: L04) are recorded in the position information table 1000. Here, since this function is a virtual function of the base class A, there is a possibility that a vfunc () virtual function call of the class B, which is a derived class, has been made. Therefore, step 503 becomes true, and the process proceeds to step 504. Here, the position information 1005 in which the class name item has been changed to a derived class (in this case, class B)
(Class name: B, Object name: objA2, Function name: vf
unc, argument list: void, file scope: src1.cc,
Class scope: None, Function scope: func1 (void),
A process for recording the line number 12, address label: L04) in the position information table 1000 is performed.

Next, in the 18th line, since the class A object definition 905 is used, the class A constructor A ()
Is called. Therefore, similarly to the eighth line, the position information 10
06 (Class name: A, Object name: objA4, Function name: A, Argument list: void, File scope: src1.c
c, class scope: none, function scope: func2 (voi
d), line number 18, address label: L05) Record in the position information table 1000.

Next, since the 21st line is a vfunc () virtual function call, position information 1007 (class name: A, object name: objA3, function name: vfunc)
c, argument list: void, file scope: src1.cc, class scope: none, function scope: func2 (void), line number 21, address label: L06) and position information 1008 changed to a derived class (class name: B) , Object name: objA3, function name: vfunc, argument list: void, file scope: src1.cc, class scope: none, function scope: func2 (void), line number 21, address label: L06) and the position information table 1000. To record.

In the source file src2.cc, similarly to src1.cc, the definition of functions and objects and the processing of calling member functions are performed. Recording processing for the position information table 1000 is performed in the same manner as in src1.cc on the fifth and eighth lines.

By the above processing, the object position information table 1000 shown in FIG. 10 is generated. The address is a value replaced with an address label by the linker.

Next, details of a method of setting a break point in the debugging process will be described with reference to a specific example. Now the virtual function vfun
Let's consider a case where a start check of c is performed. The debug processing target is in the range of src1.cc. In this case, the debugger of the present invention includes "file scopes
rc1.cc "and" function vfunc ". Processing when these pieces of information are provided will be described with reference to FIG.

First, if "file scope src1.cc" and "function vfunc" are given as interruption point setting conditions in the command input waiting state of step 801, the command input determination of step 802 becomes true. 8
Shift to 03. Next, in step 803, it is determined that the interruption point setting command has been executed.
Move to 01. In step 701, a process of collating the condition specification with the position information table 10 is executed. Items that meet the conditions in the specific example are item 1004, item 1005,
Item 1007 and item 1008. Then, the process proceeds to step 702, where the interruption point setting address, file name, and line number corresponding to the condition specification are passed to the interruption point setting unit 603. That is, the file name src1.cc, line number 12, address 0x4660, and the file name src1.cc, line number 21, address 0x4740, which are break point information of the corresponding item, are passed. For these addresses, a break point is set in step 804. Through the above processing, it is possible to set a plurality of interruption points corresponding to the interruption point setting condition input by the user at a time.

In this specific example, only the condition specification of the file scope name is specified as the range specification, but the same effect can be obtained by specifying the class scope name, the function scope name, the line number, and the address. In this specific example, only the function is designated as the breakpoint setting condition. However, the same effect can be obtained by designating the class name and the object name. In the specific example, the condition of each item is specified one by one. However, the same effect can be obtained by specifying a plurality of conditions for each item such as “function mfunc or function vfunc”. In the specific example, the position information to be passed to the interruption point setting unit 603 is an address, a line number, and a file name. However, other position information may be passed.

[0054]

According to the program interruption point setting method of the present invention, one or a plurality of interruption points can be set only in a necessary range at once by simply designating a range and a condition in which a user wants to set an interruption point. be able to. In particular, it is possible to specify breakpoint setting conditions based on an object-oriented language. Specifically, it can be limited to the call points of all the member functions of a certain class, or to certain class names, object names, and member function names, and the setting range is file scope information, function scope information, class scope information, Since the line number on the source file and the address on the executable file can be specified, the user can set one or more member function call points for which a break point is desired without burdening the user. And an efficient debugging process can be realized.

Also, since it is not explicitly described in the program, it is difficult to search for a location affected by the implicit member function.
By simply designating the member function as the breakpoint setting condition, a breakpoint can be set at a location that has an effect efficiently, and efficient debugging can be realized.

[Brief description of the drawings]

FIG. 1 shows a compiler device and a debugger device according to the present invention;
Configuration diagram of location information table

FIG. 2 is a flow chart until an executable file is generated from a source file.

FIG. 3 (a) Configuration diagram of a compiler device (b) Flow chart in a compiler device

FIG. 4A is a configuration diagram of a data analysis unit. FIG. 4B is a flowchart of the data analysis unit.

FIG. 5 is a flowchart in a position information extraction unit.

FIG. 6 is a configuration diagram of a debugger device.

FIG. 7 is a flowchart of a break point setting condition matching unit;

FIG. 8 is a flowchart of a debugger device.

FIG. 9 is a diagram showing a source file according to the embodiment;

FIG. 10 is a diagram illustrating a position information table according to the embodiment;

FIG. 11 is a diagram showing a conventional example of setting a break point.

FIG. 12 is a diagram showing an example of calling a virtual function;

[Explanation of symbols]

 Reference Signs List 201 Source file 202 Compiler 203 Assembly file 204 Assembler 205 Relocatable file 206 Linker 207 Executable file 301 Data analyzer 302 Intermediate code generator 303 Optimizer 304 Resource allocation unit 305 Code generator 306 Data analysis processing 307 Intermediate code generation Processing 308 Optimization processing 309 Resource allocation processing 310 Code generation processing 401 Lexical analysis section 402 Syntax analysis section 403 Semantic analysis section 404 Location information extraction section 405 Lexical analysis processing 406 Syntax analysis processing 407 Semantic analysis processing 408 Position information extraction processing 501 Member function Call determination processing 502 Location information addition processing 503 Base class virtual function determination processing 504 Virtual function corresponding processing 600 Debugger device 601 Input command processing unit 602 Interruption Setting condition collation unit 603 Interruption point setting unit 604 Interruption point display unit 605 Program execution processing unit 606 Information display unit 701 Location information collation processing 702 Interruption point setting unit transition processing 801 Command input waiting state 802 Command input determination processing 803 Input command analysis processing 804 Interruption point setting processing 805 Interruption point display processing 806 Program execution processing 807 Interruption point arrival determination processing 808 Program interruption processing 809 Program end processing 810 Information display processing 901 Class A object definition 902 Class B object definition 903 mfunc () member function call 904 vfunc () virtual function call 905 class A object definition 906 vfunc () virtual function call 907 class B object definition 908 vfunc () virtual function call 1000 location information table 100 Position information 1002 added by the processing of 901 1002 Position information added by the processing of 902 1003 Position information added by the processing of 903 Position information added by the processing of 904 1005 Position information added by the processing of 904 1006 Position information added by the processing of 905 1007 Position information added by the processing of 906 1008 Position information added by the processing of 906 1009 Position information added by the processing of 907 1010 Position information added by the processing of 908 Position information added by the processing of step 908 1101 Interruption point setting example by line number 1102 Interruption point setting example by line number 1103 Interruption point setting example by absolute address 1104 Interruption point setting example by absolute address 1105 Interruption point setting by function Break point set by the 1106 function Example 1201 dynamic virtual function call 1202 dynamic virtual function call

 ──────────────────────────────────────────────────続 き Continued on the front page (72) Inventor Junko Sayama 1006 Kazuma Kadoma, Kazuma, Osaka Matsushita Electric Industrial Co., Ltd. F term (reference) 5B042 GA02 GA08 HH25 LA01

Claims (12)

[Claims] 1. A position information extracting means for analyzing a program and extracting position information for a specific processing unit, and collating the position information extracted by the position information extracting means with a breakpoint setting condition inputted by a user. Interrupt point setting condition matching means, and interrupt point setting means for setting an interrupt point at one or a plurality of positions corresponding to the interrupt point setting condition based on the result of comparison by the interrupt point setting condition matching means. Characteristic program interruption point setting device. 2. The program interruption point setting device according to claim 1, wherein said position information extracting means extracts position information of a call point of a function which is a specific processing unit of the program. 3. The program interruption point setting device according to claim 2, wherein said position information extracting means extracts position information of a call point of a function whose function call form is an implicit call. 4. The method according to claim 1, wherein the position information extracting means includes, as position information of the function call point, a class name, an object name, a function name, a function argument list, a file scope information, a class scope information, a function 4. The program interruption point according to claim 2, wherein at least one of scope information, a line number in a source file calling the function, and an address in an executable file calling the function is extracted. Setting device. 5. The interruption point setting condition matching means, wherein the interruption point setting condition input by the user includes a class name, an object name, a function name, and a name of an object calling a function at a function call point at which the interruption point is to be set. Argument list for limiting to defined functions, file scope information that is the scope range where you want to set breakpoints,
Of the function scope information, class scope information, line numbers in the source file, and addresses in the executable file,
At least one is input.
4. The program interruption point setting device according to item 4. 6. The interrupt point setting condition collating means uses a file name as file scope information, a class name as class scope information, and a function name including an argument as function scope information. Program break point setting device. 7. A position information extracting step of analyzing a program and extracting position information for a specific processing unit;
A breakpoint setting condition matching step of matching the position information extracted by the position information extraction step with a breakpoint setting condition input by a user; and a breakpoint setting condition based on a result of the matching by the breakpoint setting condition matching step. And a break point setting step of setting a break point at one or a plurality of positions corresponding to the above. 8. The program interruption point setting method according to claim 7, wherein said position information extracting step extracts position information of a call point of a function which is a specific processing unit of the program. 9. The method according to claim 8, wherein the step of extracting the position information extracts position information of a call point of a function whose function call form is an implicit call. 10. The method according to claim 1, wherein the position information extracting step includes, as the position information of the function call point, a class name, an object name, a function name, a function argument list, a file scope information, a class scope information, a function 10. The program interruption point according to claim 8, wherein at least one of scope information, a line number in a source file calling the function, and an address in an executable file calling the function is extracted. Setting method. 11. In the break point setting condition collating step, as a break point setting condition input by a user, a class name, an object name, a function name, a multiple name of an object calling a function of a function call point at which a break point is desired to be set. Argument list for limiting to the defined function, file scope information, function scope information, class scope information that is the scope range to set the break point, line number in source file, address in executable file 11. The method of setting a program interruption point according to claim 7, wherein at least one of them is input. 12. The method according to claim 1, wherein in the step of checking breakpoint setting conditions, a file name is used as file scope information, a class name is used as class scope information, and a function name including an argument is used as function scope information.
1. The method for setting a program interruption point according to 1.