JP2010191598A - Information processor, information processing method, and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a detailed analytic result about reference and substitution to a global variables included in a source code. <P>SOLUTION: A source code analyzing device 1 extracts and analyzes the substitution of the addresses of global variables included in a source code 21 into local variables, the substitution of the arguments of functions in which any address is stored into the local variables, the substitution of the local variables in which the address of the global variables are stored into the other local variables, and the substitution of the local variables in which the arguments of the functions in which any address is stored are stored into the other local variables. Thus, it is possible to achieve more detailed analysis about reference and substitution with respect to the global variables than analysis based on only the names of the global variables. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a technique for analyzing a program code.

  In computer systems, there is an increasing demand for higher speed and higher performance. In response to this demand, in addition to improving the performance of a single processor, efforts are being made to reduce processing time, that is, increase the speed by operating programs in parallel using a plurality of processors.

  When a program is operated in parallel, there is a problem that if the same data is accessed at a plurality of locations in the program, the program becomes an unexpected operation depending on the access order.

  In this regard, in Patent Document 1, when the access order control to the global variable using the interrupt prohibition instruction is performed, the global code is analyzed by analyzing the source code of the program and checking whether the interrupt prohibition instruction is appropriately described. By judging the interference of variables, the number of man-hours for checking manually is reduced.

Many efforts have been made to automatically parallelize programs.
In Patent Document 2, when parallelizing a program in two passes and detecting a function call in the source code, reference is made to information on global variables used in each function generated in the first pass. Thus, it is determined whether or not the function call can be executed in parallel based on the reference relation to the global variable and the order relation of the assignment, and the parallelization of the program part before and after the function call and the called functions is analyzed.
Furthermore, in Patent Document 3, efficient parallelization is performed by considering class member information for an object-oriented language.

Japanese Patent Laid-Open No. 2003-241997 JP-A-5-143357 JP 2004-13184 A

However, in the above-described prior art, since the interrupt disable instruction is checked or parallelized based on the global variable name or the member variable name of the class, it is performed via the variable storing the address of the global variable. Cannot analyze global variable reference (reading) or assignment to global variable (writing).
In a relatively large program, there is a case where a global variable name or the like is not described directly in a function definition for the purpose of sharing functions, but an address given by an argument is referenced or assigned.
In the case of source code with such a description, the above-mentioned conventional technology cannot analyze the argument with the assigned address. There is a problem that each target cannot be achieved as a result, for example, the corresponding part is excluded from the parallelization target and the degree of parallelism does not increase.

The present invention has been made in view of the above, and detects a process of storing the address of a global variable, and makes the analysis and analysis of the reference and assignment of the global variable using the stored variable. The main purpose is to provide detailed analysis results for references and assignments to global variables rather than analysis based only on names.
Another object of the present invention is to visually display the relationship between a global variable and a variable in which the address is stored, using the above analysis result.

An information processing apparatus according to the present invention includes:
Since a program code including a global variable and a local variable is specified as a program code to be analyzed, a code specifying part,
Analyzes the analysis target program code specified by the code specification unit, assigns the address of the global variable to a local variable, assigns an argument that stores one of the addresses to the local variable, and sets the address of the global variable Code analysis for extracting from the analysis target program code at least one of assignment of a local variable to be stored to another local variable and assignment of a local variable to store an argument for storing any address to another local variable An extractor;
And an extraction result storage unit for storing the extraction result of the code analysis extraction unit.

  According to the present invention, by detecting the process of storing the address of the global variable and making the analysis target the reference and assignment of the global variable using the stored variable, rather than the analysis based only on the name of the global variable, Detailed analysis results for references and assignments to global variables can be provided.

FIG. 2 is a functional block diagram of an analysis system including a source code analysis device 1 according to the first embodiment. The figure which shows an example of the structure of the node 1600 which comprises the syntax tree 160. FIG. The figure which shows an example of the structure of the symbol table 161. The figure which shows an example of the structure of the argument relevant information 162. The figure which shows an example of the structure of the function definition file list. The figure which shows the source code 21a, the source code 21b, and the source code 21c. The figure which shows an example of the structure of the analysis result 22. FIG. 7 is a flowchart showing the operation of the input unit 10 7 is a flowchart showing the operation of the source file specifying unit 11. 6 is a flowchart showing the operation of the source code development unit 12 in the first embodiment. 14 is a flowchart showing the operation of the argument related information setting unit 13. 7 is a flowchart showing the operation of the analysis unit 14. 9 is a flowchart showing a declaration analysis operation by the analysis unit 14; 10 is a flowchart showing an assignment statement analysis operation by the analysis unit 14; 7 is a flowchart showing an analysis operation of a function call by the analysis unit 14. 10 is a flowchart showing the operation of the display unit 15. The figure which showed the analysis result 22 in the shape of a tree structure. The figure which showed the analysis result 22 in the tree structure form, and displayed the internal operation | movement of the specific function. The figure which selected one variable to focus on a vertical axis | shaft using the analysis result 22, arranged the function called from an analysis start function on a horizontal axis, and displayed the substitution of an address and substitution to a focused variable according to the execution order. FIG. 4 is a functional block diagram of an analysis system including a source code analysis device 1 according to a second embodiment. FIG. 10 is a diagram illustrating an example of a structure of a function definition file list 20 used in the second embodiment. 9 is a flowchart showing an operation of creating decompressed data 23 by the source code decompressing unit 12 according to the second embodiment. 10 is a flowchart showing an operation of reading expanded data 23 by the source code expanding unit 12 according to the second embodiment. The figure which shows the example of a source code. The figure which shows the hardware structural example of a source code analysis apparatus.

Embodiment 1 FIG.
In this embodiment, a source code analysis apparatus capable of providing detailed information regarding global variable reference and substitution will be described.

  First, after describing the outline of the operation of the source code analysis device according to the present embodiment, a configuration example and details of the operation of the source code analysis device according to the present embodiment will be described.

The source code analysis device analyzes a source code (program code) described in a programming language, and extracts the following elements <A> to <I> included in the source code.
<A> Reference to global variable <B> Assignment to global variable <C> Reference to argument storing any address <D> Local variable (1) Assignment of global variable address (2) Any Assignment of argument of function storing address (3) Assignment of local variable storing address of global variable (4) Assignment of local variable storing argument of function storing any address <E>
(1) Reference of local variable storing address of global variable (2) Reference of local variable storing argument storing any address <F> Via local variable of <D> above, Reference of global variable or local variable <G> Substitution to global variable or local variable via local variable of <D> above <H> Global variable or local via argument of function storing any address Variable reference <I> Assignment to a global or local variable via an argument of a function that stores any address

For example, when the source code analysis apparatus according to the present embodiment analyzes the source code illustrated in FIG. 24, the source code is analyzed using g as a global variable, as shown in the comments of FIG. The above <A> to <I> are extracted.
Note that the source code example in FIG. 24 is written in C language.
In the present embodiment, the source code analysis device generates a syntax tree and a symbol table of the source code, analyzes the source code using the syntax tree and the symbol table, and extracts the above <A> to <I>. , Memorize the extraction result.
The generation of the syntax tree and the symbol table is not essential, and the source code may be analyzed without using the syntax tree and the symbol table.

If the source code to be analyzed contains a function call, the source code analyzer extracts the dummy argument and actual argument related to the function call, and associates the extracted extracted dummy argument with the extracted actual argument. The source code of the function to be called is analyzed and the extracted dummy argument is referenced, assigned to the extracted dummy argument, the reference of the local variable that is assigned the value of the extracted dummy argument, and the value of the extracted dummy argument is assigned. Extract at least one of the substitutions of local variables to other local variables, and associate the extraction results with extracted formal arguments and extracted actual arguments.
In addition, the source code analysis device identifies a source code including a function to be called, designates the source code as a new analysis target source code, and performs analysis on the analysis target source code that has been analyzed so far. When the analysis is interrupted, the analysis for the new analysis target source code is started, and the analysis for the new analysis target source code is completed, the analysis is performed on the analysis target source code that was analyzed before the new analysis target source code. Resume analysis.

Further, the source code analysis device, in the analysis of the source code, the global variable, the variable described in the actual argument storing the address, and the variable described in the dummy argument corresponding to the actual argument storing the address When variables included in the declaration statement appear, these variables are put in the check list. A variable placed in the inspection list in this way is called an inspection target variable.
And the reference of the inspection target variable, the assignment to the inspection target variable (the inspection target variable is the left side in the assignment statement), the assignment to the other variable via the inspection target element (the other variable is the left side in the assignment statement), , Check whether at least one of the assignment of the variable to be examined to another variable (in the assignment statement, the other variable is on the left side and the variable to be examined is on the right side) is included in the analysis source code. I do.
The source code analysis device is a variable that stores an address when the variable to be checked is assigned to another variable (in the assignment statement, the other variable is the left side and the variable to be checked is the right side). If the other variable is a variable for storing an address, the other variable is put in the inspection list and is set as the inspection target variable.

  Then, the source code analysis apparatus, for each of the extracted <A> to <I>, variable name, source file name of the extraction source, line number, call hierarchy, operation type (separate reference / substitution), setting List the values and present them to the user of the source code analyzer.

  Next, FIG. 1 shows functional blocks of an analysis system including the source code analysis device 1 according to the present embodiment.

The analysis system includes a source code analysis device 1 (information processing device) and a storage device 2.
The source code analysis device 1 is a device that can provide a detailed analysis result for reference / substitution of a global variable, and details of the operation will be described later.
The storage device 2 is a non-volatile storage device such as an HDD (Hard Disk Drive).
The storage device 2 stores data to be input to the source code analysis device 1 and an output from the source code analysis device 1.

  The source code analysis device 1 includes an input unit 10, a source file identification unit 11, a source code development unit 12, an argument related information setting unit 13, an analysis unit 14, a display unit 15, and a temporary storage unit 16.

  The input unit 10 is a function that receives an input from a user of the analysis system. Based on the input, the input unit 10 determines a function to be analyzed using the source code analysis device 1 and determines a display format of the analysis result. .

The source file specifying unit 11 determines a source code 21 to be used for analysis based on the analysis target function passed from the input unit 10 or the analysis unit 14 and the function definition file list 20.
The source file specifying unit 11 is an example of a code specifying unit. The process performed by the source file specifying unit 11 is a code specifying step.

The source code development unit 12 creates a syntax tree 160 and a symbol table 161 from the source code 21 determined by the source file specifying unit 11 and stores the syntax tree 160 and the symbol table 161 in the temporary storage unit 16.
Based on the syntax tree 160 stored in the temporary storage unit 16 by the source code development unit 12 and the symbol table 161, the argument related information setting unit 13 indicates the correspondence between the formal argument and the actual argument of the function to be analyzed, and the argument related information 162. Is stored in the temporary storage unit 16.
Based on the syntax tree 160 and the symbol table 161 stored in the temporary storage unit 16 by the source code development unit 12, the analysis unit 14 receives a global variable, a local variable in which the address of the global variable is stored, and a function argument. References and substitutions for the used global variables are output to the analysis result 22, and operations such as references and substitutions for global variables using the dummy arguments in the argument related information 162 are recorded in the argument related information 162. If there is a description of a function call, the analysis for the described function is executed first and output to the analysis result 22.
The source code development unit 12, the argument related information setting unit 13, and the analysis unit 14 are examples of a code analysis extraction unit. In the source code development unit 12, the argument related information setting unit 13, and the analysis unit 14, the processing performed by the code analysis extraction unit is the code analysis extraction step.

The display unit 15 displays the analysis result 22 in the format specified by the input unit 10.
The temporary storage unit 16 is a volatile storage device such as a RAM (Random Access Memory), for example, and temporarily stores the syntax tree 160, the symbol table 161, the argument related information 162, the hierarchy value 163, and the analysis result 164.
The analysis result 164 is an analysis result at an intermediate stage in which the source code analysis device 1 is analyzing the source code.
Each time the analysis unit 14 extracts the above-described <A> to <I> to be reflected in the analysis result 22, the analysis result is sequentially accumulated in the analysis result 164, and the analysis result 164 is transferred to the storage device 2 and the analysis result 22. However, in order to avoid complicated description, the analysis unit 14 will be described below as storing the extraction result in the analysis result 22.
The temporary storage unit 16 is an example of an extraction result storage unit. The storage process of the analysis result 164 by the temporary storage unit 16 is an extraction result storage step.

In the above description, the source code analysis device 1 and the storage device 2 are separate devices, but they may be configured as one device.
In the above description, the display unit 15 is included in the source code analysis device 1, but may be a device different from the source code analysis device 1 (for example, “display device”).

Next, the syntax tree 160 will be described.
FIG. 2 is a diagram showing the structure of the node 1600 that constitutes the syntax tree 160.
The node 1600 includes a node type 1601, a syntax rule number 1602, a line number 1603, a value type 1604, and a node value 1605.
The node type 1601 is a terminal symbol (identifier, operator, special symbol, etc. appearing in the source code) or non-terminal symbol (which does not appear in the source code and represents a set of specific terminal symbols) constituting the syntax rule. It is information for identifying.
The syntax rule number 1602 is a number for uniquely specifying a syntax rule regarding a non-terminal symbol. For example, when there are two syntax rules corresponding to a tree structure in which a certain non-terminal symbol is a parent node, the corresponding syntax rule can be specified by putting either 0 or 1 in the syntax rule number 1602.
A line number 1603 is a number indicating an appearance position on the source code for each terminal symbol.
The value type 1604 is information for identifying the type of the node value 1605.
The node value 1605 is the number of child nodes and connection information to the child nodes when the node type 1601 belongs to a non-terminal symbol. When the node type 1601 is an identifier stored in the symbol table 161, the node value 1605 is connection information to corresponding information in the symbol table. When the node type 1601 is a terminal symbol other than an identifier, the node value 1605 is a character string such as a reserved word or special character that appears in the source code.

The symbol table 161 will be described.
FIG. 3 is a diagram showing the structure of the symbol table 161.
The symbol table 161 includes as many identifier names 1610, identifier types 1611, type specifier information 1612, declarator information 1613, and initializer information 1614 as the number of identifiers. That is, the symbol table 161 includes a set including one or more identifier names 1610, identifier types 1611, type specifier information 1612, declarator information 1613, and initializer information 1614.
The identifier name 1610 is a name of an identifier that appears in the source code.
The identifier type 1611 is information indicating the type of identifier. The values stored in the identifier type 1611 are values that mean, for example, global variables, static variables, arguments, local variables, and the like.
The type specifier information 1612 is information related to the type specifier of the identifier name 1610. Specifically, it is a description of a terminal symbol that appears in a subtree of the syntax tree 160 whose root is a node corresponding to a nonterminal symbol named type specifier, that is, a type name.
The declarator information 1613 is information related to the declarator of the identifier name 1610. Specifically, a terminal symbol that appears in a subtree of the syntax tree 160 rooted at a node corresponding to a nonterminal symbol named declarator, that is, a variable name in the case of a variable declaration, a function name and an argument in the case of a function declaration A description such as a list.
The initializer information 1614 is information regarding the initializer of the identifier name 1610. Specifically, it is a description of a terminal symbol that appears in a subtree of the syntax tree 160 whose root is a node corresponding to a nonterminal symbol named initializer, that is, a value to be substituted. In FIG. 3, “20” is described only for the global variable gVal, which means that the global variable gVal is initialized with a value of 20 at the same time as the declaration.
For the sake of explanation, in FIG. 3, the type name or initialization value is directly described in the type specifier information 1612, declarator information 1613, and initializer information 1614 fields of the symbol table 161. Connection information to the corresponding node 1600 may be stored.

The argument related information 162 will be described.
FIG. 4 is a diagram showing the structure of the argument related information 162.
The argument related information 162 includes as many actual arguments 1620, temporary arguments 1621, initial settings 1622, and operation types 1623 as the number of arguments.
That is, the argument related information 162 includes a set including zero or more actual arguments 1620, temporary arguments 1621, initial settings 1622, and operation types 1623. In the case of calling a function without an argument, the number of sets composed of an actual argument 1620, a dummy argument 1621, an initial setting 1622, and an operation type 1623 is zero.
The actual argument 1620 is an argument in the function call described in the source code 21.
The formal argument 1621 is an argument described in a function definition or function prototype declaration described in the source code 21.
The initial setting 1622 is a value assigned to the actual argument 1620. In FIG. 4, since the address of a variable named gVal is stored, “& gVal” and “&” are added to the initial setting 1622.
The operation type 1623 is information indicating the type of processing using the dummy argument 1621.

The hierarchy value 163 will be described.
The layer value 163 is a value indicating the number of function calls from the function that starts the analysis until the function currently being analyzed is reached in the analysis by the source code analysis device 1.

The function definition file list 20 will be described.
FIG. 5 shows the structure of the function definition file list 20. In the function definition file list 20, there are as many function names 200 and source file names 201 as there are functions defined in one or more source codes 21 used for analysis by the source code analysis device 1.
That is, the function definition file list 20 includes a set composed of one or more function names 200 and source file names 201.
The function name 200 is a function name in the function definition described in the source code 21.
The source file name 201 is the name of a file in which the function definition of the function name 200 is described.

The source code 21 will be described.
FIG. 6 is a diagram showing the source code 21 used for explaining this embodiment.
The source code 21 is a program written in C language.
FIG. 6 shows three source codes 21a, 21b, and 21c, and the file names are / src / funcA. c, / src / funcB. c, / src / func C.I. c.
The source code 21a describes the declaration of the global variable gVal and the definition of the function f1.
The source code 21b describes the definition of the function f2.
The source code 21c describes the definition of the function f3.
Although not shown in FIG. 6, it is assumed that a function prototype declaration is described in each source code so that the function f2 can be called in the function f1 and the function f3 can be called in the function f2. .
In this embodiment, source code written in C language will be described as an example, but other languages can also be targeted.

The analysis result 22 will be described.
FIG. 7 is a diagram showing the structure of the analysis result 22.
The analysis result 22 includes the variable name 220, the source file name 221, the line number 222, the call hierarchy 223, the operation type 224, and the setting value 225 as many times as the number of operations on the variable to be analyzed. That is, the analysis result 22 includes a set including one or more variable names 220, source file names 221, line numbers 222, a call hierarchy 223, operation types 224, and setting values 225.
The variable name 220 is the name of the manipulated variable.
The source file name 221 is a name of a file in which an operation on the variable specified by the variable name 220 is described.
The line number 222 is information indicating the description position of the operation for the variable specified by the variable name 220 in the file of the source file name 221.
The call hierarchy 223 is information indicating the depth of function calls.
The operation type 224 is information indicating the type of operation for the variable specified by the variable name 220, and the type of information to be stored is the same as the operation type 1623. In the operation type 224 of FIG. 7, “Set”, “Read”, and “Write” are stored one by one in each column, but a plurality of pieces of information can be held simultaneously.
The set value 225 is a value set for the variable itself specified by the variable name 220, or when the variable has an address, the variable indicated by the address. For an operation that does not set a value for the variable, the set value 225 is empty.

  The operation of the source code analyzing apparatus 1 in this embodiment will be described in detail based on FIGS. 1 to 7 described above and FIGS. 8 to 19 below.

First, an initialization process that is an operation of the input unit 10 in this embodiment will be described with reference to FIGS. 1, 4, and 8.
FIG. 8 is a flowchart showing the operation of the input unit 10 that receives an input from the user of the analysis system in this embodiment.

(S100): The input unit 10 starts an initialization process when a function for starting analysis is passed from the user of the analysis system.
(S101): The input unit 10 sets 0 to the layer value 163. This operation corresponds to initialization of the hierarchy value 163.
(S102): The input unit 10 opens the analysis result 22.
(S103): The input unit 10 passes the function name acquired in S100 and empty argument-related information to the source file specifying unit 11. The empty argument related information means that the argument related information 162 does not have any combination of the actual argument 1620, the dummy argument 1621, the initial setting 1622, and the operation type 1623.
(S104): The input unit 10 completes the initialization process.

Next, the operation of the source file specifying unit 11 will be described with reference to FIG. 1, FIG. 5, and FIG.
FIG. 9 is a flowchart showing the operation of the source file specifying unit 11 in this embodiment.

(S110): When the function name and the argument related information 162 are passed from the input unit 10 or the analysis unit 14, the source file specifying unit 11 starts processing.
(S111): The source file specifying unit 11 reads the function definition file list 20. In this embodiment, it is assumed that the function definition file list 20 is prepared in advance before execution of analysis by the analysis system, and the contents shown in FIG. 5 are recorded.
(S112): The source file specifying unit 11 determines whether the function name passed from the input unit 10 or the analysis unit 14 exists in the function name 200 of the function definition file list 20. If it is determined that it exists (Yes in S112), the process proceeds to S113. On the other hand, if it is determined that it does not exist (No in S112), the process proceeds to S114.
(S113): The source file specifying unit 11 takes out the corresponding function name 200 and source file name 201 from the function definition file list and passes them to the source code development unit 12.
(S114): The source file specifying unit 11 completes the process.

Next, the operation of the source code development unit 12 will be described with reference to FIGS. 1, 2, 3, 5, and 10.
FIG. 10 is a flowchart showing the operation of the source code development unit 12 in this embodiment.
In the following description, it is assumed that the source code 21 corresponding to the source file name 201 exists in the storage device 2.

(S120): The source code development unit 12 starts processing upon receiving the function name 200 and the source file name 201 to be analyzed from the source file specifying unit.
(S121): The source code development unit 12 reads the source code 21 and creates a syntax tree 160. The method of creating the syntax tree 160 will not be described in detail, but only an overview will be described. First, lexical analysis is performed on the source code 21 to extract it as a terminal symbol, and a node 1600 is created and accumulated in the stack. Next, when the sequence of nodes matches the syntax rule, one or more matched nodes are taken out of the stack, and a node representing a non-terminal symbol having them as child nodes is created, and the created node is stacked. To accumulate. By repeating this process until the end of the source code 21, a syntax tree 160 is created.
(S122): The source code development unit 12 reads the source code 21 and creates the symbol table 161. The method of creating the symbol table 161 will not be described in detail, but only an overview will be described. A variable declaration, function definition, and the like are read from the source code 21, and five pieces of information from the identifier name 1610 to the initializer information 1614 are extracted based on the syntax rules and stored in the symbol table 161. The identifier type 1611 for the variable declaration is determined by the position in the source code 21 where the variable declaration is made, specifically, outside the function definition (global variable), argument list (argument) of the function definition, inside the function definition. (Local variable).
(S123): The source code development unit 12 completes the process.

Next, the operation of the argument related information setting unit 13 will be described with reference to FIGS. 1, 3, 4, 5, 7, and 11.
FIG. 11 is a flowchart showing the operation of the argument related information setting unit 13 in this embodiment.

(S130): The argument-related information setting unit 13 starts processing when the source code development unit 12 completes the creation of the syntax tree 160 and the symbol table 161.
(S131): The argument related information setting unit 13 is a set including an actual argument 1620, a temporary argument 1621, an initial setting 1622, and an operation type 1623 stored in the argument related information 162 passed to the source file specifying unit 11. Determine the number of If there are more than zero (Yes in S131), the process proceeds to S132. On the other hand, if the number is zero (No in S131), the process proceeds to S136.
(S132): The argument related information setting unit 13 searches the symbol table 161 for the identifier name 1610 corresponding to the dummy argument 1621, and extracts the type of the identifier name 1610, the type specifier information 1612, and the declarator information 1613. . If it is determined from the type specifier information 1612 and the declarator information 1613 that the dummy argument 1621 stores an address (Yes in S132), the process proceeds to S133. On the other hand, if it is determined that the dummy argument 1621 does not store an address (No in S132), the process proceeds to S134.
(S133): The argument-related information setting unit 13 searches the declarator information 1613 corresponding to the dummy argument 1621 from the symbol table 161. Subsequently, the variable name 220 is the formal argument 1621, the source file name 221 is the source file name 201 passed to the source code development unit 12, and the line number 222 is the line of the node 1600 of the syntax tree 160 corresponding to the declarator information 1613. Recorded in the analysis result 22 is a set storing the number 1603, the hierarchy value 163 in the call hierarchy 223, the value indicating address setting (described as “Set” in FIG. 7) in the operation type 224, and the actual argument 1620 in the setting value 225. To do.
(S134): The argument related information setting unit 13 advances the execution target of S132 next in the argument related information 162.
(S135): The argument-related information setting unit 13 determines whether S132 has been executed for the entire argument-related information 162 (supplement: in FIG. Is determined). When it is determined that the process has been executed (Yes in S135), the process proceeds to S136. On the other hand, when it determines with not having performed (No in S135), it progresses to S132.
(S136): The argument related information setting unit 13 completes the process.

Next, operation | movement of the analysis part 14 is demonstrated based on FIG.1, FIG.2, FIG.4 and FIG.
FIG. 12 is a flowchart showing the operation of the analysis unit 14 in this embodiment.

(S140): The analysis unit 14 starts processing when the recording of the analysis result 22 using the argument related information 162 by the argument related information setting unit 13 is completed.
(S141): The analysis unit 14 creates a test list including link information for a specific identifier in the symbol table (the test list is not shown). The variables stored in the inspection list are all the global variables of the source code 21 and the temporary argument 1621 of the argument related information 162 recorded in the analysis result 22 by the argument related information setting unit 13. In this embodiment, static global variables, that is, variables whose scope is limited within the source file are not stored in the inspection list.
(S142): The analysis unit 14 moves to the node corresponding to the function definition of the function to be analyzed in the syntax tree 160. Thereafter, analysis is performed using child nodes of the node.
(S143) to (S147): The analysis unit 14 performs analysis in units of declarations within function definitions or assignment statements. First, a subtree of the syntax tree 160 corresponding to the unit is determined using a node type 1601, a syntax rule number 1602, a value type 1604, and a node value 1605, and whether the determined subtree corresponds to a declaration. It is determined whether it corresponds to an assignment statement (S143). If it is determined to be a declaration (declared in S143), the process proceeds to S144, and the declaration is analyzed (S144). On the other hand, if it is determined that the statement is an assignment statement (assignment statement in S143), the process proceeds to S145 to analyze the statement (S145). Detailed operations of S144 and S145 will be described later. When the analysis of the declaration or assignment statement is completed, the process proceeds to the next declaration or assignment statement. At this time, local variables that are out of the effective range (scope) are deleted from the examination list (S146). Subsequently, it is determined whether the end of the function definition has been reached (S147). If it is determined that it has arrived (Yes in S147), the process proceeds to S148. On the other hand, when it has not reached yet (No in S147), the process proceeds to S143. In S143 and S146, parts that are neither declarations nor assignment statements are skipped.
(S148): The analysis unit 14 discards the inspection list. Also, the syntax tree 160 and the symbol table 161 are discarded.
(S149): The analysis unit 14 completes the process.

Next, analysis of the declaration in the analysis unit 14 will be described with reference to FIGS. 1, 2, 3, 7, and 13.
FIG. 13 is a flowchart showing the analysis operation (S144 in FIG. 12) for the declaration in the analysis unit 14.

(S150): When the analysis unit 14 determines to analyze the declaration, it starts processing.
(S151): The analysis unit 14 determines whether the declared variable is initialized using the subtree of the syntax tree 160 corresponding to the declaration. If it is determined that it has been initialized (Yes in S151), an assignment statement analysis for the initialization expression is executed (S152), and then the process proceeds to S153. On the other hand, if it is determined that it has not been initialized (No in S151), the process proceeds to S157.
(S152): The analysis unit 14 performs an assignment statement analysis on the initialization expression. The detailed operation of S152 will be described later.
(S153): The analysis unit 14 specifies the type of the declared variable using the subtree of the syntax tree 160 corresponding to the declaration, and determines whether the type is for storing an address. If it is determined that the address is stored (Yes in S153), the process proceeds to S154. On the other hand, if it is determined that the address is not stored (No in S153), the process proceeds to S157.
(S154): The analysis unit 14 determines whether the variable stored in the check list appears in the initialization expression analyzed in S152, using the subtree of the syntax tree 160 corresponding to the declaration. When it determines with having appeared (it is Yes at S154), it progresses to S155. On the other hand, when it determines with not having appeared (it is No at S154), it progresses to S157.
(S155): The analysis unit 14 adds the declared variable to the inspection list.
(S156): The analysis unit 14 searches for declarator information 1613 corresponding to the variable declared from the symbol table 161. Subsequently, the name of the variable declared in the variable name 220, the source file name 201 passed to the source code development unit 12 in the source file name 221, and the node of the syntax tree 160 corresponding to the declarator information 1613 in the line number 222 1600 is a line number 1603, a hierarchy value 163 in the call hierarchy 223, a value meaning address setting in the operation type 224 (indicated as “Set” in FIG. 7), and a set value 225 for storing the entire expression used for initialization Is recorded in the analysis result 22.
(S157): The analysis unit 14 ends the analysis on the declaration.

Next, analysis of the assignment statement in the analysis unit 14 will be described with reference to FIGS. 1, 2, 4, 5, 7, and 14.
FIG. 14 is a flowchart showing the analysis operation (S145 in FIG. 12 and S152 in FIG. 13) for the assignment statement in the analysis unit 14.

(S160): When the analysis unit 14 determines to analyze the assignment statement, the analysis unit 14 starts processing.
(S161): The analysis unit 14 determines whether there is a function call using the subtree of the syntax tree 160 corresponding to the assignment statement. If it is determined that there is a function call (Yes in S161), the process proceeds to S180. On the other hand, when it is determined that there is no function call (No in S161), the process proceeds to S162.
(S162): Using the subtree of the syntax tree 160 corresponding to the assignment statement and the check list, the analysis unit 14 determines whether the assignment statement refers to a variable stored in the check list. However, the part corresponding to the function call referred to in S161 is not used for the determination. If it is determined that the assignment statement refers to a variable stored in the examination list (Yes in S162), the process proceeds to S167. On the other hand, if it is determined that the assignment statement does not refer to a variable stored in the examination list (No in S162), the process proceeds to S163.
(S163): The analysis unit 14 uses the subtree of the syntax tree 160 corresponding to the assignment statement and the check list to perform assignment to another variable via the variable stored in the check list using the assignment statement. Judgment is made. If it is determined by the assignment statement that assignment to another variable has been performed via a variable stored in the check list (Yes in S163), the process proceeds to S168. On the other hand, if it is determined that the assignment statement is not assigned to another variable via the variable stored in the check list (No in S163), the process proceeds to S164.
(S164): The analysis unit 14 uses the subtree of the syntax tree 160 corresponding to the assignment statement and the check list to assign to the variable stored in the check list in the assignment statement (stored in the check list in the assignment statement). Determine whether the variable is on the left side. If it is determined by the assignment statement that assignment to the variable stored in the check list has been performed (Yes in S164), the process proceeds to S168. On the other hand, if it is determined that the assignment statement is not assigned to the variable stored in the examination list (No in S164), the process proceeds to S165.
(S165): Using the subtree of the syntax tree 160 corresponding to the assignment statement and the check list, the analysis unit 14 assigns the variables stored in the check list by the assignment statement (stored in the check list in the assignment statement). Determine whether the variable is on the right side. If it is determined that the variable stored in the examination list is substituted by the assignment statement (Yes in S165), the process proceeds to S170. On the other hand, if it is determined that the variable stored in the examination list is not substituted by the assignment statement (No in S165), the process proceeds to S174.

(S180): The analysis unit 14 proceeds to function call analysis. Details of the function call analysis will be described later with reference to FIG.
(S166): The analysis unit 14 searches for the next function call using the subtree of the syntax tree 160 corresponding to the assignment statement.

  (S167): The analysis unit 14 uses the name of the variable referenced by the variable name 220, the source file name 221 passed to the source code development unit 12 as the source file name 221, and the syntax tree representing the assignment statement at the line number 222. A row number 1603 of a node 1600 representing a variable referred to in a subtree of 160, a hierarchy value 163 in the call hierarchy 223, a value meaning reference to the operation type 224 (indicated as “Read” in FIG. 7), a set value 225 Is stored in the analysis result 22 as a set for storing a value indicating no set value. In addition, if the variable name 220 is a variable stored in the dummy argument 1621 of the argument related information 162 or a variable to which the variable stored in the dummy argument 1621 of the argument related information 162 is assigned, A value meaning reference is recorded in the operation type 1623 of the set.

(S168): The analysis unit 14 specifies the type of the left side using the subtree of the syntax tree 160 corresponding to the left side of the assignment statement and the symbol table 161.
(S169): The analysis unit 14 uses the name of the variable assigned to the variable name 220, the source file name 201 passed to the source code development unit 12 as the source file name 221, and the syntax tree 160 representing the assignment statement at the line number 222. The row number 1603 of the node 1600 representing the substituted variable in the sub-tree of, the hierarchy value 163 in the call hierarchy 223, the value meaning address setting in the operation type 224 or the value meaning substitution (in FIG. 7, “Set” or “ The group storing the entire expression substituted for the set value 225 is recorded in the analysis result 22. At this time, the analysis unit 14 refers to the type of the left side specified in S168, and in the case of the type storing the address, the value indicating the address setting is stored in the operation type 224 and is not the type storing the address. Stores a value that means substitution. In addition, if the variable name 220 is a variable stored in the dummy argument 1621 of the argument related information 162 or a variable to which the variable stored in the dummy argument 1621 of the argument related information 162 is substituted, A value meaning address setting or substitution is recorded in the operation type 1623 of the set.

(S170): The analysis unit 14 determines whether the type of the left side is a type for storing an address, using the subtree of the syntax tree 160 corresponding to the left side of the assignment statement and the symbol table 161. If it is determined that the type on the left side is a type for storing an address (Yes in S170), the process proceeds to S171. On the other hand, if it is determined that the type on the left side is not a type for storing an address (No in S170), the process proceeds to S174.
(S171): Using the subtree of the syntax tree 160 corresponding to the assignment statement and the check list, the analysis unit 14 determines whether the assigned variable (the variable on the left side of the assignment statement) is stored in the check list. . If it is determined that the substituted variable is stored in the examination list (Yes in S171), the process proceeds to S172. On the other hand, when it is determined that the assigned variable is not stored in the examination list (No in S171), the process proceeds to S173.
(S172): The analysis unit 14 adds the substituted variable to the check list using the subtree of the syntax tree 160 corresponding to the assignment statement and the check list.
(S173): The analysis unit 14 uses the name of the variable assigned to the variable name 220, the source file name 221 passed to the source code development unit 12 as the source file name 221, and the syntax tree 160 representing the assignment statement at the line number 222. The row number 1603 of the node 1600 representing the substituted variable in the sub-tree of, the hierarchy value 163 in the call hierarchy 223, the value meaning address setting in the operation type 224 (indicated as “Set” in FIG. 7), and the setting value 225 A set storing the entire assigned expression is recorded in the analysis result 22. In addition, if the variable name 220 is a variable stored in the dummy argument 1621 of the argument related information 162 or a variable to which the variable stored in the dummy argument 1621 of the argument related information 162 is substituted, A value meaning reference is recorded in the operation type 1623 of the set.
(S174): The analysis unit 14 ends the analysis for the assignment statement.

Next, the analysis of the function call in the analysis unit 14 (S180 in FIG. 13 and FIG. 14: function call analysis) will be described based on FIG. 1, FIG. 2, FIG. 4, FIG.
FIG. 15 is a flowchart showing an analysis operation for a function call in the analysis unit 14.

(S181): When the analysis unit 14 determines to analyze the function call, the analysis unit 14 starts processing.
(S182): The analysis unit 14 counts the number of arguments using the subtree of the syntax tree 160 corresponding to the function call.
(S183): The analysis unit 14 determines whether information has been added to the argument related information 162 by the number of arguments counted in S182. If it is determined that information is added to the argument related information 162 by the number of arguments (Yes in S183), the process proceeds to S190. On the other hand, if it is determined that information is not added to the argument related information 162 for the number of arguments (No in S183), the process proceeds to S184.
(S184): The analysis unit 14 determines whether the argument is a function call using the subtree of the syntax tree 160 corresponding to the function call. If it is determined that the argument is a function call (Yes in S184), the process proceeds to S185. On the other hand, if it is determined that the argument is not a function call (No in S184), the process proceeds to S186.
(S185): The analysis unit 14 performs a function call analysis for the function in the argument. That is, S180 is recursively executed.
(S186): The analysis unit 14 uses the check list and the subtree of the syntax tree 160 corresponding to the function call, and (a) the type of the actual argument is a type for storing an address. Two conditions stored in the examination list are determined. When (a) is true and (b) is false (Yes in S186), the process proceeds to S187. On the other hand, if (a) is true and (b) does not satisfy false (No in S186), the process proceeds to S188.
(S187): The analysis unit 14 adds the variable described in the argument to the inspection list.
(S188): Using the analysis result 22, the analysis unit 14 first identifies the value assigned to the actual argument. However, if the actual argument is expressed by multiple variables, it is not specified. Next, the analysis unit 14 performs the expression described in the function call in the actual argument 1620, the dummy argument described in the prototype declaration or definition of the function called in the dummy argument 1621, and the initial setting 1622 by the above operation. Argument related information 162New is stored that stores the value assigned to the specified actual argument 1620 (if nothing is specified, nothing is set) and the operation type 1623 indicates a value that means no setting (source file) (In order to distinguish it from the argument related information passed to the specific part, it is set to 162 New). If there are multiple arguments, they are created by processing the first argument, and the remaining arguments are added.
(S189): The analysis unit 14 proceeds to processing for the next argument.

(S190): The analysis unit 14 increases the layer value 163 by one.
(S191): The analysis unit 14 executes the source file specifying unit 11. At this time, the function name is the name of the function described in the function call, and the argument related information 162New is created by the processing from S184 to S189, or is empty.
(S192): The analysis unit 14 decreases the hierarchy value 163 by one.
(S193): When there is argument-related information 162New, that is, when the number of arguments is 1 or more, the analysis unit 14 refers to the argument-related information 162New, and a value indicating reference or substitution is stored in the operation type 1623 If it is, the actual argument 1620 is assigned to the variable name 220, the source file name 201 is passed to the source code development unit 12 as the source file name 221, and the subtree of the syntax tree 160 representing the assignment statement is assigned to the line number 222. The line number 1603 of the node 1600 representing the variable, the hierarchy value 163 in the call hierarchy 223, the value stored in the operation type 1623 (either reference or substitution), and the value that means no set value in the set value 225 , Are stored in the analysis result 22. Further, the actual argument stored in the argument related information 162New is a variable stored in the dummy argument 1621 of the argument related information 162, or the variable stored in the temporary argument 1621 of the argument related information 162 is substituted. In the case of a variable, the operation type 1623 of the corresponding argument related information 162 is also updated. When a value indicating that both reference and substitution have occurred is stored in the operation type 1623 of the argument related information 162New, each is separately recorded in the analysis result. On the other hand, the analysis unit 14 does nothing if there is no argument related information 162New.
(S194): When there is the argument related information 162New, the analysis unit 14 discards the argument related information 162New created in S184 to S189. On the other hand, the analysis unit 14 does nothing if there is no argument related information 162New.
(S195): The analysis unit 14 completes the function call analysis.

  Finally, when the analysis by the analysis unit 14 is completed for the function passed to the input unit 10, the analysis unit 14 closes the analysis result 22 (not shown).

  The flow of analysis for the function f1 in this embodiment is shown in FIGS. 1, 4, 5, 7, 8, 9, 10, 10, 11, 12, 13, 14, and 15. This will be explained based on this.

(Input unit 10): The function name “f1” and empty argument related information 162a are passed to the source file specifying unit 11 (S103).
(Source file specifying unit 11 [f1]): The function definition file list 120 is read (S111), the existence of the function f1 is determined (S112), the function name 200, that is, “f1”, and the source file name (/ src / funcA) .C) is passed to the source code development unit 12 (S113).
(Source code development unit 12 [f1]): / src / funcA. c is read and a syntax tree 160a and a symbol table 161a are created (S121, S122).
(Argument-related information setting unit 13 [f1]): Since the argument-related information 162a is empty, the process branches in S131 and reaches S136.

(Analysis unit 14 [f1]): A test list is created, and the global variable gVal is stored in the test list (S141).
(Analysis unit 14 [f1: line number 5]): Declaration analysis for “int y = gVal” is executed (S144). Since this declaration has been initialized (Yes in S151), an initialization expression, that is, an assignment statement analysis for gVal is executed (S152). The flow of assignment statement analysis for gVal is No in S161, Yes in S162, No in S163, No in S164, No in S165, and the reference of gVal is recorded in the analysis result 22 (S167). The process ends (S174). Subsequently, since the local variable y is not a type for storing an address (No in S153), the declaration analysis is terminated (S157).
(Analysis unit 14 [f1: line number 7]): An assignment statement analysis for “gVal = 0” is executed (S145). Since gVal is stored in the examination list, the assignment statement analysis flow is No in S161, No in S162, No in S163, Yes in S164, No in S165, and the type on the left side stores the address. Therefore, the value assignment for gVal is recorded in the analysis result 22 (S168, S169), and the assignment statement analysis is terminated (S174).
(Analysis unit 14 [f1: line number 8]): An assignment statement analysis for “x = &gVal;” is executed (S145). The flow of assignment statement analysis is first No in S161. Next, since gVal is stored in the examination list, S162 becomes Yes, and the reference of gVal is recorded in the analysis result 22 (S167). Since x is not stored in the examination list, S163 and S164 are No. Since there is gVal on the right side, S165 is Yes, and since x is a type for storing an address, S170 is Yes. Since x is not stored in the inspection list, S171 is No, x is added to the inspection list (S172), and the address setting for x is recorded in the analysis result 22 (S173). Thereafter, the assignment statement analysis is terminated (S174).
(Analyzer 14 [f1: Line number 9]): Performs an assignment statement analysis for “y = f2 (x)”. The flow of assignment statement analysis first becomes Yes in S161, and executes a function call (S180). The argument related information 162b is created (S184 to S189), and the function name f2 and the argument related information 162b are passed to the source file specifying unit 11 (S191).

(Source file specifying unit 11 [f2]): The function definition file list 120 is read (S111), the existence of the function f2 is determined (S112), the function name 200, that is, “f2”, and the source file name 201 (/ src) /FuncB.c) is passed to the source code development unit 12 (S113).
(Source code development unit 12 [f2]): / src / funcB. c is read and a syntax tree 160b and a symbol table 161b are created (S121, S122).
(Argument-related information setting unit 13 [f2]): Since the argument-related information 162b is not empty (Yes in S131) and the dummy argument p is a type for storing an address (Yes in S132), the address setting for p is analyzed. Record in the result 22 (S133).

(Analyzing unit 14 [f2]): An inspection list is created (S141). / Src / funcB. Since c has no global variables, it is an empty checklist.
(Analyzing unit 14 [f2: line number 3]): Declaration analysis for “int * q = p” is executed (S144). Since this declaration is initialized (Yes in S151), an initialization expression, that is, an assignment statement analysis for p is executed (S152). The flow of assignment statement analysis for p is No in S161, Yes in S162, No in S163, No in S164, No in S165, so p reference is recorded in the analysis result 22 (S167), and assignment statement analysis is performed. Is finished (S174). Subsequently, since the local variable q is a type for storing an address (Yes in S153) and p on the right side is stored in the inspection list (Yes in S154), q is stored in the inspection list (S155). The address setting for q is recorded in the analysis result 22 (S156). Thereafter, the declaration analysis ends (S157).
(Analysis unit 14 [f2: line number 4]): Declaration analysis for “int * r = q” is executed (S144). Since this declaration is initialized (Yes in S151), an initialization expression, that is, an assignment statement analysis for q is executed (S152). The flow of assignment statement analysis for q is No in S161, Yes in S162, No in S163, No in S164, No in S165, so the reference to q is recorded in the analysis result 22 (S167), and the assignment statement analysis is performed. Is finished (S174). Subsequently, since the local variable r is a type for storing an address (Yes in S153) and q on the right side is stored in the inspection list (Yes in S154), r is stored in the inspection list (S155), The address setting for r is recorded in the analysis result 22 (S156). Thereafter, the declaration analysis ends (S157).
(Analysis unit 14 [f2: line number 5]): Declaration analysis is performed for “int * s = r” (S144). Since this declaration is initialized (Yes in S151), an initialization expression, that is, an assignment statement analysis for r is executed (S152). Since the flow of assignment statement analysis for r is No in S161, Yes in S162, No in S163, No in S164, Yes in S165, the reference of r is recorded in the analysis result 22 (S167), and the assignment statement analysis Is finished (S174). Subsequently, since the local variable s is a type for storing an address (Yes in S153) and r on the right side is stored in the inspection list (Yes in S154), s is stored in the inspection list (S155). The address setting for s is recorded in the analysis result 22 (S156). Thereafter, the declaration analysis ends (S157).
(Analysis unit 14 [f2: line number 6]): Declaration analysis for “int b = * r” is executed (S144). Since this declaration has been initialized (Yes in S151), an initialization expression, that is, an assignment statement analysis for * r is executed (S152). * Since the assignment statement analysis flow for r is No in S161, Yes in S162, No in S163, No in S164, No in S165, a reference to r is recorded in the analysis result 22 (S167). The analysis is terminated (S174). Subsequently, since the local variable s is not a type for storing an address (No in S153), the declaration analysis is terminated (S157).
(Analyzing unit 14 [f2: line number 8]): The assignment statement analysis for “* s = 0” is executed. The flow of assignment statement analysis is No in S161, No in S162, Yes in S163, and since the type on the left side is not a type for storing an address, assignment of a value for s is recorded in the analysis result 22 (S168, S168). S169). Subsequently, since the answer is No in S165, the assignment statement analysis is terminated (S174).
(Analysis unit 14 [f2: line number 9]): The assignment statement analysis for “b = f3 (q)” is executed. The flow of assignment statement analysis first becomes Yes in S161, and executes a function call (S180). The argument related information 162c is created (S184 to S189), and the function name f3 and the argument related information 162c are passed to the source file specifying unit 11 (S191).

(Source file specifying unit 11 [f3]): The function definition file list 120 is read (S111), the existence of the function f3 is determined (S112), the function name 200, that is, “f3”, and the source file name 201 (/ src) /FuncC.c) is passed to the source code development unit 12 (S113).
(Source code development unit 12 [f3]): / src / funcC. c is read and a syntax tree 160c and a symbol table 161c are created (S121, S122).
(Argument-related information setting unit 13 [f3]): Since the argument-related information 162c is not empty (Yes in S131) and the dummy argument t is a type for storing an address (Yes in S132), the address setting for t is analyzed. The result 22 is recorded (S133).

(Analyzing unit 14 [f3]): An inspection list is created (S141). / Src / funcC. Since c has no global variables, it is an empty checklist.
(Analysis unit 14 [f3: line number 3]): Declaration analysis for “int z = * t” is executed (S144). Since this declaration has been initialized (Yes in S151), an initialization expression, that is, an assignment statement analysis for * t is executed (S152). Since the assignment statement analysis flow for t is No in S161, Yes in S162, No in S163, No in S164, No in S165, a reference to t is recorded in the analysis result 22 (S167), The analysis is terminated (S174). Subsequently, since the local variable z is not a type for storing an address (No in S153), the declaration analysis is terminated (S157).
(Analysis unit 14 [f3: line number 4]): Performs an assignment statement analysis for “* t = 100”. The flow of assignment statement analysis is No in S161, No in S162, Yes in S163, and since the type on the left side is not a type for storing an address, the value assignment for t is recorded in the analysis result 22 (S168, S169). Then, since it becomes No at S165, the assignment statement analysis is terminated (S174).
(Analysis section 14 [f3: line number 5] executes an assignment sentence analysis for “z”. The flow of assignment sentence analysis is No in S161, No in S162, No in S163, No in S164, No in S165. Therefore, the assignment statement analysis is terminated (S174).
(Analysis unit 14 [f3]): When the analysis is performed up to the end of the function f3 (Yes in S147), the processing of the analysis unit 14 is completed (S149), and the process returns to the analysis of the function f2.

(Analysis unit 14 [f2: line number 9]): Using the operation type recorded in the argument related information 162c in S193, the reference and substitution for the argument q are recorded in the analysis result 22 (S193). When the function analysis is completed (S195), the process returns to S162 in FIG. Since the flow of assignment statement analysis after S162 is No in S162, No in S163, No in S164, No in S165, the assignment statement analysis ends (S174). (Analysis unit 14 [f2: line number 10]): Performs an assignment statement analysis for “b”. Since the flow of assignment statement analysis is No in S161, No in S162, No in S163, No in S164, No in S165, the assignment statement analysis is terminated (S174).
(Analysis unit 14 [f2]): When the analysis is performed up to the end of the function f2 (Yes in S147), the processing of the analysis unit 14 is completed (S149), and the process returns to the analysis of the function f1.

(Analysis unit 14 [f1: line number 9]): Using the operation type recorded in the argument related information 162b in S193, the reference and substitution for the argument x are recorded in the analysis result 22 (S193). When the function analysis is completed (S195), the process returns to S162 in FIG. Since the flow of assignment statement analysis after S162 is No in S162, No in S163, No in S164, No in S165, the assignment statement analysis ends (S174).
(Analyzing unit 14 [f1: line number 10]): The assignment statement analysis for “y” is executed. Since the flow of assignment statement analysis is No in S161, No in S162, No in S163, No in S164, No in S165, the assignment statement analysis is terminated (S174).
(Analyzing unit 14 [f1]): When the analysis is performed up to the end of the function f1 (Yes in S147), the processing of the analyzing unit 14 is completed (S149). That is, the analysis process by the source code analysis apparatus is completed.

Next, the operation of the display unit 15 after the creation of the analysis result 22 is completed will be described with reference to FIGS.
FIG. 16 is a flowchart showing the operation of the display unit 15.

(S200): The display unit 15 starts processing when the creation of the analysis result 22 from the input unit 10 to the analysis unit 14 is completed.
(S201): The display unit 15 acquires the display format from the input unit 10.
(S202): The display unit 15 reads the analysis result 22.
(S203): The display unit 15 displays the analysis result 22 in accordance with the display format acquired in S201.
(S204): The display unit 15 completes the process.
For example, when the display format is “table”, the display is as shown in FIG.

As described above, according to the present embodiment, by assigning the address of the global variable and performing analysis using the related information of the argument of the function, the analysis for the global variable is performed rather than the analysis based only on the name of the global variable. There is an advantage that reference and substitution can be extracted in detail.
Specifically, when analyzing the source code of FIG. 6, in the analysis based only on the name of the global variable, / src / funcC. It cannot be seen that the assignment to the global variable gVal occurs in the assignment statement “* r = 100;” of c.
However, according to the present embodiment, / src / funcA. c, “x = &gVal;”, address substitution via “y = f2 (x);”, address propagation via function argument, / src / funcB. substitution of the address by “int * q = p;” of c, propagation of the address through the function argument by “b = f3 (q);”, / src / funcC. By substituting c into the global variable via the pointer type variable by “* r = 100;” and extracting it from the source code and outputting it to the analysis result 22, the user can use the analysis result 22 to specify / src / funcC. It can be determined that the assignment to the global variable gVal has occurred in the assignment statement “* r = 100;” of c.

  Further, in the present embodiment, all local variables that store addresses are not stored in the check list, but are added to the check list when variables in the check list are assigned or specified as function arguments. As a result, the number of items stored in the inspection list is reduced, the load of search processing on the inspection list is reduced, and as a result, the analysis speed is increased.

In the above description, the static global variable (static variable) is not stored in the inspection list in S141. However, the static global variable may be stored in the inspection list.
By doing this, there is an advantage that it is possible to analyze references and assignments to static global variables.

Further, the operation on the static global variable in the analysis unit 14 may be changed based on an instruction from the input unit 10.
By doing so, when a large number of function definitions are described in one file, it is possible to give flexibility to the analysis range, such as putting a static global variable in a check list, etc., and If static global variables are not stored in the test list, the analysis can be speeded up.

In the above description, the function that performs recursive calls was not described in particular. However, the function name being analyzed can be saved in the stack, and the analysis can be skipped for functions already stored in the stack. I do not care.
By doing so, it is possible to analyze a function that performs a recursive call.

In the above description, the syntax tree 160 and the symbol table 161 are created by analyzing each function. However, the syntax tree 160 and the symbol table 161 that have already been created may be reused.
In this way, the number of executions of the source code expansion unit 12 can be reduced, and as a result, the storage area for expanding the syntax tree 160 and the symbol table 161 can be expected, and the analysis speed can be increased.
At this time, the syntax tree 160 and the symbol table 161 are discarded when there is no more analysis processing to be referred to.

In the above description, only int type variables are used, but the present embodiment can be applied to other types.
Furthermore, the structure and union members can be analyzed in the same manner as variables because the type can be specified by using the syntax tree 160 and the symbol table 161.
At this time, the variable name 220 of the analysis result 22 may be stored including the member name. A user-defined type name (in the case of C language, typedef is used) can be similarly analyzed.

In the above description, the argument-related information 162 is created for the number of arguments. However, what is actually required is only an argument of a type for storing an address.
Therefore, only the necessary arguments may be stored in the argument related information.
At this time, an ordinal number for specifying the number of each group is added to a group including an actual argument 1620, a dummy argument 1621, an initial setting 1622, and an operation type 1623 (not shown).

Further, in the above description, the display unit 15 displays the analysis result 22 generated by the input unit 10 to the analysis unit 14, but displays the already created analysis result 22 designated from the input unit 10. It doesn't matter.
That is, analysis and display can operate independently.

In the above description, the display unit 15 displays the analysis result 22 shown in FIG. 7 as it is. However, the analysis result 22 and the source code 21 may be used to display in another format.
Another display format will be described with reference to FIG.
FIG. 17 is a diagram showing the analysis result 22 in a tree structure. When the function name is extracted from the source code 21 and the call hierarchy 223 of the analysis result 22 is used, the display as shown in FIG. 17 can be realized. In the block indicating each function, the function name and the operation type 224 appearing in the analysis result 22 are displayed.

In the above description, when a variable in the inspection list is assigned in S165, it is determined whether the assigned variable has been stored in the inspection list. The same determination may be made when a numerical value is substituted.
However, it is assumed that the storage device 2 knows in advance the correspondence between the memory address and the variable stored in the address.

Further, when the input unit 10 detects selection of the function f3 in the state where FIG. 17 is displayed, the display unit 15 displays the processing actually performed by the function f3 as shown in FIG. It doesn't matter.
Similarly, regarding the function calling relationship, the display unit 15 may first display only the analysis start function f1, and then display the function f2 in accordance with an instruction from the input unit 10.
Further, when there are a plurality of function calls, a function call for expanding information as shown in FIGS. 17 to 18 may be selected.
By doing so, there is an advantage that even a function having a complicated calling relationship can focus on a specific execution path.

An example of a display format different from FIGS. 17 and 18 will be described with reference to FIG.
In FIG. 19, one variable to be focused on on the vertical axis is selected (gVal is selected in FIG. 19), functions called from the analysis start function are arranged on the horizontal axis, and assignment of addresses and substitution to the variables of interest are performed according to the execution order. FIG.
The display format as shown in FIG. 19, for example, has an advantage that the readability of the analysis result 22 is improved because only necessary information is displayed when attention is paid only to the timing of substitution and reference.

Further, the display unit 15 may display the analysis result 22 shown in FIGS. 7, 17, and 18 and the corresponding source code 21 side by side.
By doing in this way, there exists an advantage that the correspondence of the analysis result 22 and the source code 21 becomes easy to understand.

Further, when there are a plurality of global variables in the analysis result 22, the display unit 15 may select a global variable to be displayed based on an instruction from the input unit 10.
Moreover, you may make it select a local variable instead of a global variable.
By doing in this way, there exists an advantage that the readability of the analysis result 22 improves.

The display unit 15 may simultaneously display a plurality of analysis results 22 stored in the storage device 2 based on an instruction from the input unit 10.
By doing in this way, there exists an advantage that the reference and substitution to a specific global variable in a plurality of tasks can be grasped easily, for example.

As described above, in the present embodiment, the source code analyzing apparatus analyzes the source code described in the programming language.
An input part for inputting a function to be analyzed or a display format;
A source file specifying unit for specifying a file in which the analysis target function is described;
A source code expansion unit that reads the source code identified by the source file identification unit and creates a syntax tree and a symbol table;
A temporary storage unit for temporarily storing a syntax tree and a symbol table;
Using a syntax tree and a symbol table, an analysis unit that outputs a reference and assignment to the analysis result as a global variable, a local variable storing the address of the global variable, and a global variable using a function argument,
A source code analyzing apparatus including a display unit that displays an analysis result based on the display format specified from the input unit has been described.

Further, when a function call appears in the syntax tree, the analysis unit executes the processing of the source file specifying unit using the correspondence between the dummy argument and the actual argument and the name of the function that has appeared,
The source code analysis device further includes:
Using the correspondence between the dummy argument and the actual argument received by the source file identification part, it has an argument related information setting part that outputs to the analysis result that the address of the variable is stored in the actual argument,
further,
The analysis unit uses the correspondence between the dummy argument and the actual argument received by the source file identification unit to refer to and assign the dummy argument or the local variable to which the value of the dummy argument is assigned. Explained to record in correspondence.

  In addition, it has been described that the source file specifying unit stores the name of the analysis target function, and skips the analysis process when the analysis unit is instructed to analyze the stored function.

  The source code expansion unit stores the file name of the source code used to create the syntax tree and symbol table, and instructs the source code expansion process for the source code stored from the source file specifying unit. Explained that the source code expansion process is skipped when it is done.

The input unit receives an input as to whether or not to include a static global variable in the analysis target,
It has been described that the analysis unit determines whether to include a static global variable in the analysis target based on the input received by the input unit.

  In addition, it has been described that the display unit displays the source code corresponding to the analysis result side by side.

  Moreover, the said display part demonstrated only displaying the part relevant to the variable designated from the said input part using the said analysis result.

  Further, it has been described that the display unit uses a plurality of the analysis results and displays the analysis results side by side.

Embodiment 2. FIG.
In the first embodiment, all the source code 21 necessary for creating the analysis result 22 is analyzed on the spot, and the function definition file list 20 needs to be prepared in advance.
On the other hand, in the second embodiment, the syntax tree 160 and the symbol table 161 created by the source code development unit 12 for each source code 21 that seems to be necessary for analysis are stored in the storage device 2 in advance. The correspondence between the function and the source code is recorded in the function definition file list 20 to speed up the analysis.

FIG. 20 is a functional block diagram of an analysis system including the source code analysis device 1 according to the second embodiment.
The difference from the first embodiment is that expanded data 23 is added to the storage device 2 and an arrow from the input unit 10 to the source code expansion unit 12 is added.

  The expanded data 23 has a syntax tree 160 and a symbol table 161 in the temporary storage unit 16 (not shown).

  In the second embodiment, the operation of the source code analyzing apparatus 1 is divided into two. The first operation is the creation of the expanded data 23, and the second operation is an analysis using the expanded data 23.

A first operation of the source code analyzing apparatus 1 in the second embodiment, that is, a process for creating the expanded data 23 will be described.
When receiving the file name of the source code 21 as input from the user of the analysis system, the input unit 10 passes the received file name to the source code development unit 12.

The function definition file list 20 in the second embodiment will be described.
FIG. 21 is a diagram showing the structure of the function definition file list 20 in the second embodiment.
The function definition file list 20 includes function names 200, source file names 201, and expanded data names 202 corresponding to the number of functions defined in one or more source codes 21 used for analysis by the source code analysis apparatus 1. To do.
That is, the function definition file list 20 includes a set composed of one or more function names 200, source file names 201, and expanded data names 202.

Creation of the developed data 23 by the source code developing unit 12 will be described with reference to FIGS. 20, 21, and 22. FIG.
FIG. 22 is a flowchart showing the operation of creating the developed data 23 by the source code developing unit 12 according to the second embodiment.

(S120)-(S122): Since it is the same as that of FIG. 10, description is abbreviate | omitted.
(S124): The source code expansion unit 12 creates the expanded data 23 using the syntax tree 160 and the symbol table 161. The expanded data 23 is stored in the same directory as the source code 21, and the file name is assumed to have the extension of the source code changed to “.dat”.
(S125): The source code development unit 12 records the function definition file list 20 using the syntax tree 160 and the symbol table 161. At this time, the function name 200 is a function name of the function definition extracted from the syntax tree 160 and the symbol table 161, and is changed for each function definition. The source file name 201 uses the file name given from the input unit 10. The expanded data name 202 uses the one described in S124.
(S126): The source code development unit 12 completes the process. At the same time, the first operation of the source code analyzing apparatus 1 is also completed.

A second operation of the source code analyzing apparatus 1 in the second embodiment, that is, an analysis process using the expanded data 23 will be described.
When receiving the file name of the source code 21 as input from the user of the analysis system, the input unit 10 passes the received file name to the source code development unit 12.

Reading of the expanded data 23 by the source code expansion unit 12 will be described with reference to FIGS. 20, 21, and 23.
FIG. 23 is a flowchart showing an operation of reading the developed data 23 by the source code developing unit 12 according to the second embodiment.

(S120), (S123): The description is omitted because it is the same as FIG.
(S127): The source code expansion unit 12 acquires the expanded data name 202 corresponding to the file name of the source code 21 from the function definition file list 20, reads the corresponding expanded data 23, The symbol table 161 is stored in the temporary storage unit 16.

  Since the operations of the argument related information setting unit 13, the analysis unit 14, and the display unit 15 in the second embodiment are the same as those in the first embodiment, description thereof is omitted.

As described above, according to the present embodiment, the syntax tree 160 and the symbol table 161 are stored in the storage device 2 as the expanded data 23, and the syntax tree 160 and the symbol table 161 are used by using the expanded data 23 in the analysis. By expanding the syntax tree 160 and the symbol table 161, and the analysis can be performed faster than in the first embodiment.
For example, when only a few files are changed and the analysis is performed again in a program composed of a plurality of files, the expanded data 23 can be reused in the second embodiment, so that the analysis can be performed at high speed.

  Furthermore, according to the present embodiment, there is an advantage that the trouble of preparing the function definition file list 20 in advance can be omitted.

In the above description, the file name of the expanded data 23 is stored in the expanded data name 202. However, if the expanded data name 202 can be uniquely identified from the source file name 201 as in the second embodiment, The expanded data name 202 may not be present.
On the contrary, if the expanded data name 202 exists, the expanded data 23 may be stored in a directory different from the source code 21.

In the above description, only the syntax tree 160 and the symbol table 161 are stored in the expanded data 23, but the contents output to the analysis result 22 by the analysis unit 14 are closed inside the function, that is, other The contents that are not affected by the function may be stored in the expanded data 23 and reused in the second operation of the analysis system according to the second embodiment.
In this way, the second operation of the analysis system according to the second embodiment has an advantage that only the part related to the function call needs to be analyzed, and the analysis can be performed at high speed.

In the above description, the expanded data 23 is always used. However, when the generation time of the source code 21 and the expanded data 23 is checked and the expanded data 23 is older than the source code 21, the expanded data 23 is used. You can make it again.
By doing in this way, after the change to the source code 21, it is possible to reflect the change to the source code 21 in the analysis result 22 simply by performing the analysis using the source code analyzing apparatus 1. is there.

  As described above, in the present embodiment, the source code development unit accumulates the created syntax tree and symbol table, and the correspondence relationship between the source code, syntax tree and symbol table in the nonvolatile storage device, and performs this operation. The analysis explained that the syntax tree and the symbol table stored in the non-volatile storage device are read.

  In addition to the correspondence relationship between the syntax tree and symbol table stored in the nonvolatile storage device by the source code development unit and the source code and syntax tree and symbol table, the analysis unit also includes analysis results other than function calls. In the analysis after accumulating and performing this operation, it was explained that the analysis result accumulated in the non-volatile storage device is read and used to create another analysis result.

  In addition, the source code expansion unit and the analysis unit have a syntax tree and a symbol table stored in the nonvolatile storage device, a correspondence relationship between the source code and the syntax tree and the symbol table, and a generation time of an analysis result other than the function call. In the case where it is older than the code, it has been described that the syntax tree and symbol table stored in the nonvolatile storage device and the correspondence between the source code and the syntax tree and symbol table are created again from the source code.

Finally, a hardware configuration example of the source code analysis apparatus 1 shown in the first and second embodiments will be described.
FIG. 25 is a diagram showing an example of hardware resources of the source code analysis apparatus 1 shown in the first and second embodiments.
Note that the configuration in FIG. 25 is merely an example of the hardware configuration of the source code analysis device 1, and the hardware configuration of the source code analysis device 1 is not limited to the configuration described in FIG. There may be.

In FIG. 25, the source code analysis apparatus 1 includes a CPU 911 (also referred to as a central processing unit, a central processing unit, a processing unit, an arithmetic unit, a microprocessor, a microcomputer, and a processor) that executes a program.
The CPU 911 is connected to, for example, a ROM (Read Only Memory) 913, a RAM (Random Access Memory) 914, a communication board 915, a display device 901, a keyboard 902, a mouse 903, and a magnetic disk device 920 via a bus 912. Control hardware devices.
Further, the CPU 911 may be connected to an FDD 904 (Flexible Disk Drive), a compact disk device 905 (CDD), a printer device 906, and a scanner device 907. Further, instead of the magnetic disk device 920, a storage device such as an optical disk device or a memory card (registered trademark) read / write device may be used.
The RAM 914 is an example of a volatile memory. The storage media of the ROM 913, the FDD 904, the CDD 905, and the magnetic disk device 920 are an example of a nonvolatile memory. These are examples of the storage device.
A communication board 915, a keyboard 902, a mouse 903, a scanner device 907, an FDD 904, and the like are examples of input devices.
The communication board 915, the display device 901, the printer device 906, and the like are examples of output devices.

  The communication board 915 is connected to the network. For example, the communication board 915 may be connected to a LAN (local area network), the Internet, a WAN (wide area network), a SAN (storage area network), or the like.

The magnetic disk device 920 stores an operating system 921 (OS), a window system 922, a program group 923, and a file group 924.
The programs in the program group 923 are executed by the CPU 911 using the operating system 921 and the window system 922.

The RAM 914 temporarily stores at least part of the operating system 921 program and application programs to be executed by the CPU 911.
The RAM 914 stores various data necessary for processing by the CPU 911.

The ROM 913 stores a BIOS (Basic Input Output System) program, and the magnetic disk device 920 stores a boot program.
When the source code analysis device 1 is activated, the BIOS program in the ROM 913 and the boot program in the magnetic disk device 920 are executed, and the operating system 921 is activated by the BIOS program and the boot program.

  The program group 923 stores programs that execute the functions described as “˜units” in the description of the first and second embodiments. The program is read and executed by the CPU 911.

In the file group 924, in the description of the first and second embodiments, “determination of”, “analysis of”, “calculation of”, “comparison of”, “update of”, and “setting of” are set. ”,“ Registration of ”,“ Selection of ”, etc. Information, data, signal values, variable values, and parameters indicating the results of the processing are indicated as“ ˜file ”and“ ˜database ”items. It is remembered.
The “˜file” and “˜database” are stored in a recording medium such as a disk or a memory. Information, data, signal values, variable values, and parameters stored in a storage medium such as a disk or memory are read out to the main memory or cache memory by the CPU 911 via a read / write circuit, and extracted, searched, referenced, compared, and calculated. Used for CPU operations such as calculation, processing, editing, output, printing, and display.
Information, data, signal values, variable values, and parameters are stored in the main memory, registers, cache memory, and buffers during the CPU operations of extraction, search, reference, comparison, calculation, processing, editing, output, printing, and display. It is temporarily stored in a memory or the like.
In addition, the arrows in the flowcharts described in the first and second embodiments mainly indicate input / output of data and signals, and the data and signal values are the RAM 914 memory, the FDD 904 flexible disk, the CDD 905 compact disk, and the magnetic field. Recording is performed on a recording medium such as a magnetic disk of the disk device 920, other optical disks, mini disks, DVDs, and the like. Data and signals are transmitted online via a bus 912, signal lines, cables, or other transmission media.

  In addition, what is described as “˜unit” in the description of the first and second embodiments may be “˜circuit”, “˜device”, “˜device”, and “˜step”, It may be “to procedure” or “to process”. That is, what is described as “˜unit” may be realized by firmware stored in the ROM 913. Alternatively, it may be implemented only by software, or only by hardware such as elements, devices, substrates, and wirings, by a combination of software and hardware, or by a combination of firmware. Firmware and software are stored as programs in a recording medium such as a magnetic disk, a flexible disk, an optical disk, a compact disk, a mini disk, and a DVD. The program is read by the CPU 911 and executed by the CPU 911. That is, the program causes the computer to function as “to part” in the first and second embodiments. Alternatively, the computer executes the procedure and method of “to unit” in the first and second embodiments.

  As described above, the source code analysis device 1 shown in the first and second embodiments includes a CPU as a processing device, a memory as a storage device, a magnetic disk, a keyboard as an input device, a mouse, a communication board, and a display device as an output device, A computer including a communication board or the like, and implements the functions indicated as “˜units” as described above using these processing devices, storage devices, input devices, and output devices.

  1 source code analysis device, 2 storage device, 10 input unit, 11 source file specifying unit, 12 source code development unit, 13 argument related information setting unit, 14 analysis unit, 15 display unit, 16 temporary storage unit, 20 function definition file List, 21 source code, 22 analysis result, 23 expanded data, 160 syntax tree, 161 symbol table, 162 argument related information, 163 hierarchy value, 164 analysis result.

Claims (20)

Since a program code including a global variable and a local variable is specified as a program code to be analyzed, a code specifying part,
Analyzes the analysis target program code specified by the code specification unit, assigns the address of the global variable to a local variable, assigns an argument that stores one of the addresses to the local variable, and sets the address of the global variable Code analysis for extracting from the analysis target program code at least one of assignment of a local variable to be stored to another local variable and assignment of a local variable to store an argument for storing any address to another local variable An extractor;
An information processing apparatus comprising: an extraction result storage unit that stores an extraction result of the code analysis extraction unit. The code analysis extraction unit
The information processing apparatus according to claim 1, wherein a reference to a local variable that stores a global variable and a reference to a local variable that stores an argument that stores any address are extracted from the analysis target program code. The code analysis extraction unit
A reference to a global variable or local variable via a local variable assigned the address of the global variable, and
A reference to a global variable or local variable via a local variable assigned an argument that stores one of the addresses,
A global variable or local variable reference via a local variable assigned a local variable that stores the address of the global variable,
The global variable or local variable reference via a local variable assigned with a local variable storing an argument for storing any address is extracted from the analysis target program code. 2. The information processing apparatus according to 2. The code analysis extraction unit
Assignment to a global variable or local variable via a local variable assigned the address of a global variable;
Assignment to a global variable or local variable via a local variable assigned an argument that stores one of the addresses,
Assignment to a global variable or local variable via a local variable assigned a local variable that stores the address of the global variable;
2. At least one of a global variable or a substitution to a local variable via a local variable substituted with a local variable for storing an argument for storing any address is extracted from the analysis target program code. The information processing apparatus according to any one of? The code analysis extraction unit
The information processing apparatus according to claim 1, wherein a reference to an argument storing any one of the addresses is extracted from the analysis target program code. The code analysis extraction unit
It is characterized in that at least one of a global variable reference via an argument storing any address and a local variable reference via an argument storing any address is extracted from the analysis target program code. The information processing apparatus according to claim 1. The code analysis extraction unit
At least one of assignment to a global variable via an argument storing any address and assignment to a local variable via an argument storing any address is extracted from the analysis target program code The information processing apparatus according to claim 1. The code analysis extraction unit
The information processing apparatus according to claim 1, wherein at least one of reference to a global variable and assignment to a global variable is extracted from the analysis target program code. The code analysis extraction unit
When a function call is included in the analysis target program code,
Extract the dummy argument and actual argument related to the function call, associate the extracted extracted argument with the extracted actual argument, analyze the program code of the function to be called, refer to the extracted dummy argument, and extract the dummy argument And at least one of assignment to the local variable to which the value of the extracted dummy argument is assigned and assignment of the local variable to which the value of the extracted dummy argument is assigned to another local variable are extracted. The information processing apparatus according to claim 1, wherein the information processing apparatus associates the extracted dummy argument with the extracted actual argument. The code designating part is
When a function call is included in the analysis target program code, the program code including the call target function is identified, the program code is designated as a new analysis target program code,
The code analysis extraction unit
When a new analysis target program code is specified by the code specifying unit, the analysis for the analysis target program code that has been analyzed until then is stopped, the analysis for the new analysis target program code is started, and the new analysis target program code is started. When the analysis with respect to the analysis target program code is completed, the analysis with respect to the analysis target program code that has been analyzed before the new analysis target program code is resumed. The information processing apparatus described in 1. The code analysis extraction unit
Global variables, variables described in actual arguments that store addresses, variables described in dummy arguments corresponding to actual arguments that store addresses, and variables included in declaration statements ,
The analysis target program code includes at least one of reference to the inspection target variable, assignment to the inspection target variable, assignment to another variable via the inspection target element, and assignment of the inspection target variable to another variable. The information processing apparatus according to claim 1, wherein an extraction process is performed by checking whether or not the data is included in the information processing apparatus. The code analysis extraction unit
If the variable to be examined is assigned to another variable, determine whether the other variable is a variable that stores an address. If the other variable is a variable that stores an address, the other variable The information processing apparatus according to claim 11, wherein a variable to be inspected is used.
The code analysis extraction unit
The information processing apparatus according to claim 11, wherein when the analysis target program includes a static variable, the static variable is included in the inspection target variable. The code analysis extraction unit
14. The analysis target program code is analyzed, a syntax tree and a symbol table of the analysis target program code are generated, and extraction processing is performed using the generated syntax tree and symbol table. The information processing apparatus according to any one of the above. The code analysis extraction unit
Analyzing a plurality of program codes before specifying the analysis target program code by the code specifying unit, generating a syntax tree and a symbol table for each program code,
15. The information according to claim 1, wherein when an analysis target program code is specified by the code specifying unit, an extraction process is performed using a syntax tree and a symbol table of the analysis target program code. Processing equipment. The code analysis extraction unit
The information processing apparatus according to claim 1, wherein an extraction process for the analysis target program code is performed using a previous extraction result for another program code. The code analysis extraction unit
Generate extraction result information indicating the extraction result,
The information processing apparatus further includes:
The information processing apparatus according to claim 1, further comprising: a display unit that displays the extraction result information and the analysis target program code together. The display unit
The at least one of a program statement in which a specific variable included in the analysis target program code is described and a propagation status of the specific variable are displayed using the extraction result information. The information processing apparatus described. Since the computer designates a program code including a global variable and a local variable as a program code to be analyzed, a code designation step;
The computer analyzes the analysis target program code specified in the code specifying step, assigns a global variable address to a local variable, assigns an argument storing any address to a local variable, and global At least one of assignment of a local variable that stores the address of a variable to another local variable and assignment of a local variable that stores an argument that stores one of the addresses to another local variable from the analysis target program code A code analysis extraction step to extract;
An information processing method comprising: an extraction result storage step in which the computer stores an extraction result of the code analysis extraction step. Since the program code including the global variable and the local variable is specified as the analysis target program code, the code specifying process,
Analyzes the analysis target program code specified by the code specifying process, assigns the address of the global variable to the local variable, assigns the argument storing one of the addresses to the local variable, and sets the address of the global variable. Code analysis for extracting from the analysis target program code at least one of assignment of a local variable to be stored to another local variable and assignment of a local variable to store an argument for storing any address to another local variable Extraction process,
A program causing a computer to execute an extraction result storage process for storing an extraction result of the code analysis extraction process.

Images