Compiler driver

Abstract

To prevent quality defects from occurring in deliverables.SOLUTION: A compiler driver 21 includes a function of executing embedding processing to embed test information corresponding to child source code when performing compilation processing on post-change child source code in which a predetermined change has been made to pre-change parent source code obtained from a configuration management database 4 via a configuration management tool, a function of executing acquisition processing to acquire compilation information related to the compilation processing for the parent source code, and a function of executing comparison processing to compare the compilation information of the parent source code with the compilation information of the child source code. The compiler driver 21 executes the comparison processing when executing link processing, continues the execution of the link processing if there is no difference between the two pieces of compilation information, and determines whether or not to continue the execution of the link processing based on the test information if there is a difference between the two pieces of compilation information.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a compiler driver that functions as both a compiler and a linker. [Background technology]

[0002] In recent years, with growing demands for compliance with various regulations, including exhaust gas regulations, and for improved convenience in the market, the number of control devices installed in automobiles is increasing, including the electronic devices that make up EVs and HVs and the computers that handle driving safety functions (EV is an abbreviation for Electric Vehicle, and HV is an abbreviation for Hybrid Vehicle).In addition, there has been an increase in the development of applications that run on microcomputers equipped with PosixOS for in-vehicle embedded software, which has led to software becoming more complex and larger in scale, and an increase in the number of engineers working on a single project.

[0003] When developing large-scale software, multiple engineers need to share, edit, and manage files within the project. In such cases, as disclosed in Patent Document 1, a configuration management tool is generally used to manage the items that make up the software, as well as manage versions and changes. Well-known representative configuration management tools include Git and Apache Subversion.

[0004] Specifically, as shown in Figure 7, an engineer 6 uses a configuration management tool 1 that manages the change history of source code to copy items necessary for creating software, such as source files 2, from a configuration management database 4, which is a database provided on a management server 3, such as a Git server, to his or her own development PC 5. The engineer then makes the necessary changes to the source code to create an executable file, which is an executable program, and tests the executable file to confirm its quality. Note that Figure 7 shows the detailed configuration of only one development PC 5; the detailed configurations of the other development PCs 5 are omitted, but they are assumed to have similar configurations. Also, in Figure 7, the database is abbreviated as DB.

[0005] In this case, an engineer 6 can perform the above-mentioned tests using a test tool 7 to which source files and executable files are input. In this case, a build tool 8 is used to create the executable file, and a compiler driver 9 is used to translate each source file into machine language. The build tool 8 is a program that creates an executable file based on a configuration file that indicates what processing should be applied to the given source file. Well-known examples of build tools include make and bazel. In this case, the compiler driver 9 refers to the program required to create an executable program from the source file.

[0006] As shown in FIG. 8, the following process is generally required when creating an executable program file from a program source file. (a) Preprocessing Preprocessing is performed by the preprocessor 11, and is a process that performs preprocessing necessary for compiling source code. Examples of preprocessing in the C language include include processing and macro processing.

[0007] (b) Compilation process Compilation is performed by the compiler 12, which interprets the semantics of preprocessed source code, i.e., source code that has undergone preprocessing, and translates it into code called assembly language, which has a one-to-one correspondence with machine language.

[0008] (c) Assembly processing The assembly process is performed by the assembler 13, and is a process of converting assembler code, which is code written in assembly language, into relocatable machine language.

[0009] (d) Link processing Linking is performed by the linker / loader 14, and involves aggregating object files, which are machine language code files required for execution, and library files, to generate an executable file, which is an executable program file.

[0010] (e) Loading process The load process is performed by the linker / loader 14, and involves reading an executable file into the main storage device and embedding a program that initializes registers and the like.

[0011] Each of the above processes is carried out by the preprocessor 11, compiler 12, assembler 13, and linker / loader 14, respectively. However, in consideration of portability and extensibility, a program generally called a compiler driver 9 calls the appropriate compiler 12, assembler 13, linker / loader 14, etc. so that it can run on the target platform, and outputs object code and executable program files directly from the source code.

[0012] The compiler driver 9 can create an executable program, i.e., output an executable file 15, and can also output a preprocessed source file that is the output result of the preprocessor 11, an assembler file that is the output result of the compiler 12, or an object file 16 that is the output result of the assembler 13. Generally, when people say "compiler," they are often referring to a compiler driver, but in this specification, the terms "compiler" and "compiler driver" will be used in their original meaning.

[0013] In this way, if the target executable program is created correctly using the compiler driver 9 via the build tool 8 and the test is deemed to be satisfactory, the engineer will register the details of his work in the configuration management database via the configuration management tool in order to share the changes he has made. This allows the engineer to share the changes he has made with all members working on the project. [Prior art documents] [Patent documents]

[0014] [Patent Document 1] Japanese Patent Publication No. 2022-108452 Summary of the Invention [Problem to be solved by the invention]

[0015] As the number of software engineers involved increases, it becomes difficult to thoroughly enforce software update rules during development, resulting in the release of executable programs in a state where quality checks have not been adequately carried out, resulting in sporadic problems with quality defects.In addition, in such cases, because update rules were not followed, the source code used to generate the executable programs often no longer remains, and it can take a great deal of time to investigate the cause of the quality defect.

[0016] One possible solution to these problems is to use configuration management tools such as Git and automated testing technologies such as CI / CD. However, configuration management tools such as Git only manage the existence of files and differences in changes, making it difficult to guarantee that source files are of guaranteed quality. Furthermore, automated testing technologies such as CI / CD are limited to simulation testing that can be done on a desk, and also involve manual testing and reviews on actual devices, so they cannot be said to be a sufficient solution. CI is an abbreviation for Continuous Integration, and CD is an abbreviation for Continuous Delivery.

[0017] The present invention has been made in view of the above circumstances, and an object of the present invention is to provide a compiler driver that can prevent the occurrence of quality defects in the deliverables. [Means for solving the problem]

[0018] The compiler driver described in claim 1 has a function as a compiler (12) that executes a compilation process to translate source code into machine language and convert it into an object file, and a function as a linker (14) that executes a link process to link multiple object files together and generate an executable file.

[0019] The compiler driver has a function (22) for executing an embedding process to embed test information, which is information related to a test for verifying the quality of the executable file corresponding to the child source code, when performing the compilation process on the child source code, which is the source code after a predetermined change has been made to the parent source code, which is the source code before the change, obtained from a database (4) via a configuration management tool (1) that manages the change history of the source code; a function (22) for executing an acquisition process to acquire compilation information, which is information related to the compilation process for the parent source code; and a function (23) for executing a comparison process to compare the compilation information of the parent source code with the compilation information of the child source code.

[0020] The compiler driver performs the comparison process when executing the linking process, and if there is no difference between the two sets of compilation information, continues the execution of the linking process, and if there is a difference between the two sets of compilation information, determines whether to continue the execution of the linking process based on the test information. With this configuration, the build is successful only if the quality of the changes is correctly evaluated, preventing the release of an executable program in the development stage. Therefore, with the above configuration, it is possible to prevent quality defects from occurring in the deliverables. [Brief explanation of the drawings]

[0021] [Figure 1] FIG. 1 is a diagram schematically illustrating a configuration of a compiler driver according to a first embodiment. [Figure 2] FIG. 10 is a diagram showing an example of a processing flow when an execution program is created in a child node according to the first embodiment; [Figure 3] FIG. 1 is a diagram showing an example of versions managed by a configuration management tool according to the first embodiment; [Figure 4] FIG. 10 is a diagram schematically illustrating a configuration of a compiler driver according to a modification of the first embodiment. [Figure 5] FIG. 10 is a diagram for explaining the function of a compiler driver in normal operation according to the second embodiment; [Figure 6] FIG. 10 is a diagram for explaining the functions of a compiler driver at the time of product release according to the second embodiment. [Figure 7] FIG. 1 is a diagram showing a schematic configuration for multiple engineers to share, edit, and manage files in a project when carrying out large-scale software development according to the prior art. [Figure 8] FIG. 1 is a diagram schematically illustrating a configuration of a compiler driver according to a conventional technique. DETAILED DESCRIPTION OF THE INVENTION

[0022] Hereinafter, several embodiments will be described with reference to the drawings. Note that substantially the same components in the respective embodiments will be denoted by the same reference numerals, and the description thereof will be omitted. (First embodiment) The first embodiment will be described below with reference to FIGS.

[0023] As shown in FIG. 1, the compiler driver 21 of this embodiment has functions as a preprocessor 11, a compiler 12 that executes a compilation process to translate source code into machine language and convert it into an object file, an assembler 13, and a linker / loader 14 that executes a linking process to link multiple object files together to generate an executable file and also executes a loading process.

[0024] That is, compiler driver 21 has the same functions as the conventional compiler driver 9 shown in Fig. 8. Like the conventional compiler driver 9 shown in Fig. 8, compiler driver 21 of this embodiment is used in a configuration in which multiple engineers share, edit, and manage files in a project when developing large-scale software, that is, in a configuration such as that shown in Fig. 7. Therefore, in the following description, Fig. 7 will also be referred to as necessary, but in such cases, it is assumed that compiler driver 9 in Fig. 7 has been replaced with compiler driver 21 of this embodiment.

[0025] Unlike the conventional compiler driver 9, the compiler driver 21 also has the following four functions. The first function is to execute an embedding process to embed test information corresponding to child source code, which is source code after a predetermined change has been made to parent source code, which is source code before the change, obtained from the configuration management database 4 via the configuration management tool 1 that manages the change history of the source code, when performing a compilation process on the child source code. The test information is information related to a test that checks the quality of the executable file. The test information includes the test results and the date and time when the test was performed.

[0026] The second function is a function to execute an acquisition process to acquire compilation information, which is information related to the compilation process for the parent source code. The compilation information includes at least one of the following: the compiler version, which is the version of the compiler 12; compiler options, which are options for the compiler 12; and whether or not there is a difference between the parent source code and the child source code. In this embodiment, the compilation information includes all of these. Such compilation information is build information obtained from a reliable parent node. The first and second functions are realized by the information generation unit 22.

[0027] The third function is to execute a comparison process that compares the compilation information of the parent source code with the compilation information of the child source code. The third function is realized by the information comparison unit 23 included in the linker / loader 14. The compiler driver 21, which has the first to third functions, executes the comparison process when executing the link process, and continues the execution of the link process if there is no difference between the two pieces of compilation information, and determines whether to continue the execution of the link process based on the test information if there is a difference between the two pieces of compilation information. In this case, the compiler driver 21 can output a warning to the user, i.e., the engineer 6, based on the test information, if there is a difference between the two pieces of compilation information.

[0028] The fourth function is to encrypt the test information to be embedded by the embedding process. The second function can be realized by the information generating unit 22. For encryption, a general encryption method such as CRC or a common key method can be used. CRC is an abbreviation for Cyclic Redundancy Check.

[0029] An example of the process flow when an execution program is created using the above configuration in a child node, which is a node currently being worked on locally, will be described with reference to Figure 2. First, in step S101, various processes are performed to generate an object file from source code. At this time, an embedding process is also performed to embed test information acquired from the test tool 7. In step S102, various processes are performed to link the object file and library file. At this time, an acquisition process is also performed to acquire build information, i.e., compilation information, of the parent node.

[0030] In step S103, a comparison process is executed. That is, in step S103, it is determined whether or not there is a difference between the compilation information of the parent source code and the compilation information of the child source code. In other words, in step S103, it is determined whether or not there is a difference between the build information of the parent node and the build information of the child node. If there is no difference between the two pieces of compilation information, the answer is "NO" in step S103, and the process proceeds to step S104. In step S104, each process is executed to generate an executable file, which is the result. After step S104 is executed, this series of processes ends. That is, in this case, the build ends after the executable file is generated.

[0031] On the other hand, if there is a difference between the two compilation information, step S103 returns "YES" and the process proceeds to step S105. In step S105, the test result indicated by the test information is referenced to determine whether the test result is true. In this case, a true test result means that a test has been conducted on the difference and the test result indicates that there is no problem with the quality of the executable file. In addition, a false test result means that a test has not been conducted on the difference, or that a test has been conducted on the difference and the test result indicates that there is a problem with the quality of the executable file.

[0032] If the test result is true, step S105 becomes "YES", the process proceeds to step S104 where an executable file is generated, and then this series of processes ends. In other words, in this case, the build ends after the executable file is generated. On the other hand, if the test result is false, step S105 becomes "NO", and the process proceeds to step S106. In step S106, a warning is output to the user. After step S106 is executed, this series of processes ends. In other words, in this case, the build ends without generating an executable file.

[0033] Next, we will explain an example of a specific procedure for building child source code derived from parent source code using the above configuration. Here, we consider the case where Git is used as the configuration management tool 1 and a child node project derived from a parent node is built using a project written in C language. As shown in Figure 3, in this case, there are four versions: "ver 1.0.0," "ver 1.0.1," "ver 1.1.0," and "ver 1.1.1." "ver 1.1.0" is the officially released node and corresponds to the parent node mentioned above. "ver 1.1.1" is a node branched off for functional expansion and corresponds to the child node mentioned above.

[0034] A child node, which is a derived node for which functional expansion is planned, is created from a parent node, which is a node that was previously released, and necessary changes are made. Generally, various quality confirmation tests applied in the project are performed on the source file after the changes have been made. In this case, test information indicating the results of such tests is output from the test tool 7. In this embodiment, the test information output from the test tool 7 is saved in an arbitrary location that can be referenced by the compiler driver 21.

[0035] When the modified source code is translated into machine language, a process is executed to embed test information output from the test tool 7. Examples of the embedded test information include the "test source file name," "test date and time," and "test name." This information can be stored in a location that does not affect the execution of the resulting product, and can be a dedicated section or debug information such as Dwarf. Furthermore, if a malicious user manually embeds this embedded information into an object file, it could potentially allow for the fabrication of test results, so it is desirable to embed it in an encrypted state. Note that various encryption methods can be used.

[0036] When linking an entire project, a process is executed to obtain the build information of the parent node. The information obtained includes the "compiler version," "compiler options," and "whether there are differences in the source code." The "compiler version" and "compiler options" can be obtained from the debug information of the executable file, and the "whether there are differences in the source code" can be obtained from the configuration management tool 1.

[0037] When linking machine-translated object files, the two build information corresponding to the parent node and child node are compared, and a process is executed to extract differences on a file-by-file basis. Differences are extracted by comparing the three pieces of information mentioned above - compiler version, compiler options, and whether there are differences in the source code - on a source file-by-source file basis. If there are differences in the compiler version, it is possible that the compiler 12 is completely different, and so retesting is required.

[0038] If there are differences in compiler options, there is a possibility that the final product will differ significantly, especially if optimization is performed or not, so retesting is required. If there are changes, the embedded test information described above is checked for files that are determined to have changes, and a process is executed to determine whether testing has been performed. If there are no changes, or if there are changes and it is determined that all changes have been tested, a process is executed to output a linked executable file.

[0039] In other cases, that is, when there are change differences and at least a part of the change differences has not been tested, either (A) or (B) below will be implemented. (A) An error message is output, and the executable file is not output, but the process is treated as an error and terminated. The error message includes the files that have been determined to be untested and include the files that have been found to be different.

[0040] (B) A warning message is output, an executable file is output, and the process is terminated after handling it as a warning. The warning message includes the output of files that have been determined to have differences and have not been tested.

[0041] When building an executable file for product release, it is desirable to perform (A). On the other hand, when testing is still in progress during project development, performing (A) will prevent the creation of the executable file to be tested, so it is desirable to perform (B). In this embodiment, when running the compiler driver 21, the user can select whether to perform (A) or (B).

[0042] According to the present embodiment described above, cooperation between the configuration management tool 1 and the compiler driver 21 prevents the creation of an executable program from untested source code. In other words, according to this embodiment, a build is successful only when the quality of the changes has been properly evaluated, preventing the release of an executable program in the development stage. Therefore, this embodiment has the excellent effect of preventing quality defects in the deliverables.

[0043] <Modifications regarding comparison processing> The information comparison unit 23 that realizes the function of executing the comparison process is included in the linker / loader 14, but this is not limiting. For example, as in the modified example shown in Fig. 4, the information comparison unit 23 may be provided independently from the linker / loader 14. According to this modified example, the comparison process can be executed after linking.

[0044] (Second embodiment) The second embodiment will be described below with reference to FIGS. As shown in FIGS. 5 and 6, the compiler driver 31 of this embodiment can normally generate and output an object file 16 and an executable file 15 from source code, similar to the compiler driver 21 of the first embodiment.

[0045] Compiler driver 31 has the following functions: Compiler driver 31 also has a function of registering the used child source code and the generated object file 16 and executable file 15 in configuration management database 4 via configuration management tool 1 when generating executable file 15 for release as a product, that is, at the time of product release.

[0046] 6, when creating an object to be released as a product, compiler driver 31 performs the steps of registering the source files used in the build in configuration management database 4 and registering the object files and other files created in the build in configuration management database 4. In this way, object files and other files are managed one-to-one with the source files used to create them, ensuring their identity.

[0047] According to the present embodiment described above, when compiling at the time of product release, the source code used by the compiler 12 for compilation and the object file 16 output by the compiler 12 are registered in the configuration management database 4, making it possible to manage information at the time of release. According to this embodiment, the information at the time of release is automatically stored, so that the released executable program and source file can be managed as a pair, thereby improving traceability when a defect occurs.

[0048] (Other embodiments) The present invention is not limited to the embodiments described above and illustrated in the drawings, but can be modified, combined, or expanded as desired without departing from the spirit of the invention. The numerical values ​​and the like shown in the above embodiments are examples and are not limited to these.

[0049] The present invention is not limited to the compiler drivers 21 and 31 described in the above embodiments, but can be applied to all compiler drivers that have the function of a compiler that executes a compilation process to translate source code into machine language and convert it into an object file, and the function of a linker that executes a link process to link multiple object files together and generate an executable file.

[0050] Although the present disclosure has been described with reference to the embodiments, it is understood that the present disclosure is not limited to the embodiments or structures. The present disclosure also encompasses various modifications and equivalent modifications. In addition, various combinations and forms, including only one element, more than one element, or less than one element, are also within the scope and spirit of the present disclosure.

[0051] The control unit and the method described herein may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to perform one or more functions embodied in a computer program. Alternatively, the control unit and the method described herein may be implemented by a special-purpose computer configured by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the control unit and the method described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to perform one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible storage medium. [Explanation of symbols]

[0052] 1...configuration management tool, 4...configuration management database, 12...compiler, 14...linker / loader, 21, 31...compiler driver, 22...information generation unit, 23...information comparison unit.

Claims

1. A compiler driver having a function as a compiler (12) that executes a compilation process of translating source code into machine language and converting it into an object file, and a function as a linker (14) that executes a link process of linking a plurality of the object files together to generate an executable file, a function (22) for executing an embedding process for embedding test information, which is information on a test for verifying the quality of the executable file corresponding to the child source code, when performing the compilation process on the child source code, which is the source code after a predetermined change has been made to the parent source code, which is the source code before the change, obtained from a database (4) via a configuration management tool (1) that manages the change history of the source code; a function (22) for executing an acquisition process for acquiring compilation information, which is information regarding the compilation process of the parent source code; a function (23) of executing a comparison process to compare the compilation information of the parent source code with the compilation information of the child source code; Equipped with A compiler driver that performs the comparison process when executing the linking process, and continues the execution of the linking process if there is no difference between the two pieces of compilation information, and determines whether to continue the execution of the linking process based on the test information if there is a difference between the two pieces of compilation information.

2. 2. The compiler driver according to claim 1, wherein if there is a difference between the two pieces of compilation information, a warning is output to a user based on the test information.

3. 2. The compiler driver according to claim 1, wherein the compilation information includes at least one of a compiler version, which is the version of the compiler, a compiler option, which is an option of the compiler, and whether or not there is a difference between the parent source code and the child source code.

4. 2. The compiler driver according to claim 1, wherein the test information includes the results of the test and the date and time when the test was performed.

5. 2. The compiler driver according to claim 1, further comprising a function (22) for encrypting the test information embedded by the embedding process.

6. 2. The compiler driver according to claim 1, further comprising a function of registering the child source code used when generating the executable file to be released as a product, and the generated object file and executable file in the database via the configuration management tool.

Images