JP2014182711A - Build tool - Google Patents

Abstract

PROBLEM TO BE SOLVED: To generate a load module having a reduced size, which does not include any redundant instruction code by sharing instruction codes to be used in common while ensuring normal operations when independently developed software is integrated into one multi-core processor.SOLUTION: In a library provided in a build tool, reentrant attributes are preliminarily given to respective functions included in the library. When a plurality of programs are integrated, function names of reentrant functions called from object code groups of respective programs are integrated to output an entire reentrant function name file including all reentrant function names without duplication. Link processing is performed on the object code groups of the plurality of programs to generate load modules corresponding to them respectively. Further, a load module of reentrant functions is generated on the basis of the entire reentrant function name file.

Description

  The present invention relates to a software development environment for a multi-core processor, and can be suitably used for a build tool for sharing a library in which reentrant attributes are mixed among a plurality of load modules.

  In a software development environment for a processor, a build process is performed to convert a source program developed in a high-level language into a hex file that can be executed by the processor. A build tool that performs a build process includes a library and includes steps such as a compile unit and a link unit. The source program is converted into an object module (object code group) by the compiling unit. The link unit refers to the library and generates a load module from the object module (object code group). The load module is an instruction code in an executable format that is loaded into a memory accessed from the processor. The instruction code in the execution format is called a hex file because of the format, and is often stored in a ROM (Read Only Memory) of the processor. The load module includes a hex file converted from an object module (object code group) and a hex file of a function called from the object module. In the link step, the section that is the address area where the object code is to be stored is specified, and the hex file converted from the object module and the hex file of the function are generated on the premise that each is stored in the specified section. Is done. Allocating a stored address is called address resolution, and converting a load module into a hex file which is an instruction code in an execution format stored in a specified section is called ROMization.

  In some cases, software independently developed by a plurality of independent processor systems is integrated into one multi-core processor having a plurality of CPU (Central Processing Unit) cores. Such integration is performed for the purpose of chip cost reduction and miniaturization by integration. At this time, build processing is independently performed on a plurality of independently developed software, and independent load modules are generated. In the build process, sections are specified so that memory areas for storing load modules do not overlap.

  Patent Document 1 discloses a program editing apparatus in which when a plurality of execution files are connected to create one hex file, modules that are duplicated in the plurality of execution files are integrated into a shared module. Has been.

JP-A-4-117523

  When integrating independently developed software in multiple independent processor systems into one multi-core processor, the instruction code of the same function that is called and used by multiple software is the load module of each software As a result, the Hexafile becomes redundant and cannot fully enjoy the benefits of integration. On the other hand, by applying the technique described in Patent Document 1 and unifying redundant function code contained in a plurality of executable files, the redundant part is removed from the hex file. It seems that means can be adopted.

  However, as a result of examination of Patent Document 1 by the present inventors, it has been found that there are the following new problems.

  When integrating a plurality of pieces of software developed independently from each other into one multi-core processor, even if the same function is called from a plurality of pieces of software, the functions are called asynchronously. As a result, while a function is called and used from one of a plurality of software, the same function may be called and used by another software operating on another CPU core. In general, when one function is called and the same function is called while the operation is being executed, the function does not always operate normally. For example, the general-purpose register for storing the intermediate data of the operation of the function is not considered so that it is not duplicated every time the function is called, so one function read overwrites the other intermediate data. This is because normal operation cannot be guaranteed.

  The technique described in Patent Document 1 is merely an effective technique for creating one hex file by concatenating execution files of a plurality of programs, which are sequentially operated by a single CPU. It cannot be applied to a case where a plurality of developed software is integrated into one multi-core processor. This is because when an execution code of a function that is duplicated in a plurality of execution files is unified, normal operation cannot be guaranteed if the functions are called simultaneously.

  Means for solving such problems will be described below, but other problems and novel features will become apparent from the description of the present specification and the accompanying drawings.

  According to one embodiment, it is as follows.

  That is, in the library provided in the build tool, a reentrant attribute is assigned in advance to each function included in the library. Here, the reentrant attribute is an attribute that allows normal processing to be executed even when called in parallel and asynchronously from a plurality of programs. When integrating a plurality of programs, the function name of a reentrant function called (referenced) from the object code group of each program is output to a file (reentrant function name file). At this time, the function name of the function having no reentrant attribute is not output. The reentrant function name files of all programs to be integrated are integrated, and all reentrant function name files including all reentrant function names without duplication are output. The function names of functions that are commonly used in a plurality of programs are unified at this point. Each load module is created by linking each object code group of a plurality of programs. However, the load module at this time includes the instruction code of the function having the non-reentrant attribute, but does not include the instruction code of the function having the reentrant attribute. The load module for the reentrant attribute function is created based on the entire reentrant function name file.

  The effects obtained by the one embodiment will be briefly described as follows.

  That is, when multiple independently developed software is integrated into a single multi-core processor, redundant instructions can be obtained by sharing the instruction code of a commonly used reentrant attribute function while guaranteeing normal operation. A reduced-size load module can be created that does not contain code.

FIG. 1 is a block diagram showing an entire program development system for a microcomputer chip, which is a multi-core processor, including the build tool of the first embodiment. FIG. 2 is a block diagram showing an entire program development system for a microcomputer chip, which is a multi-core processor, including the build tool of the second embodiment. FIG. 3 is a block diagram showing the entire program development system for a microcomputer chip that is a multi-core processor, including the build tool of the third embodiment. FIG. 4 is an explanatory diagram illustrating the operation of the build tool according to the first embodiment. FIG. 5 is an explanatory diagram illustrating the operation of the build tool according to the second embodiment. FIG. 6 is an explanatory diagram illustrating the operation of the build tool according to the third embodiment. FIG. 7 is an explanatory diagram showing a load module created by applying a conventional build tool. FIG. 8 is an explanatory diagram illustrating a load module created by the build tool according to the first embodiment. FIG. 9 is an explanatory diagram showing an example of a dummy function for creating a reentrant function load module. FIG. 10 is an explanatory diagram showing an example of a reentrant function address information file.

1. First, an outline of a typical embodiment disclosed in the present application will be described. Reference numerals in the drawings referred to in parentheses in the outline description of the representative embodiments merely exemplify what are included in the concept of the components to which the reference numerals are attached.

[1] <Build that generates a load module that shares a reentrant function>
By being read and executed by the computer (12), the library (10) including the reentrant function is referred to based on the plurality of input object code groups (30), and the plurality of object code groups are supported. A build tool (1) that outputs a load module (34) that is configured as follows.

  The build tool (1) includes a reentrant function name output unit (2), an all reentrant function name output unit (3), a reentrant function load module output unit (4), and a code link unit (5).

  The reentrant function name output unit (2) is inputted with the first object code group (30_1) and the second object code group (30_2), refers to the library, is a reentrant function in the library, and A first reentrant function name file (31_1) that holds the function names of all reentrant functions referenced from the first object code group is output. The reentrant function name output unit is a reentrant function name file (31_2) that holds the function names of all reentrant functions that are reentrant functions in the library and are referenced from the second object code group. Is output.

  The all reentrant function name output unit (3) receives the first and second reentrant function name files and includes all reentrant function names included in the first and second reentrant function name files without duplication. The function name file (32) is output.

  The reentrant function load module output unit (4) receives all the reentrant function name files, and refers to the library to refer to the reentrant function load module (load module R: 34_R) and the reentrant function address information file (33). Is output. The reentrant function load module includes execution codes of all reentrant functions included in the all reentrant function name files, and does not include reentrant function codes not included in the all reentrant function name files. The reentrant function address information file holds address information of a reentrant function in the reentrant function load module.

  The code link unit (5) receives the first and second object code groups and the reentrant function address information file, and refers to the library to correspond to the first and second object code groups, respectively. The first and second load modules (34_1, 34_2) are output. At this time, the code link unit replaces the function name symbol that refers to the reentrant function in the first and second object code groups with the function address in the reentrant function address information file, and the address of the function that calls other than the reentrant function. Link the unresolved function name symbol with the above library to resolve the address.

  As a result, by sharing the execution code of the reentrant function used in common among a plurality of load modules, it is possible to output a load module in which the entire code size is minimized. In addition, the above is enabled for a library in which reentrant attributes (whether reentrant or not) are mixed.

[2] <Rebuild with the addition of object code group>
In Item 1, the build tool (1) further includes an entrant function load module update determination unit (6) and a reentrant function name addition output unit (7).

  The reentrant function name output unit (2) receives the third object code group (30_3), refers to the library, is a reentrant function in the library, and is referenced from the third object code group. A third reentrant function name file (31_3) that holds the function names of all the reentrant functions is output.

  The reentrant function load module update determination unit (load module R update determination unit: 6) receives the third reentrant function name file (31_3) and the all reentrant function name file (32_1), and receives reentrant function load module update information. A file (load module R update information file: 36) is output. The reentrant function load module update information file is included in the third reentrant function name file, and based on the presence / absence of a function name not included in the all reentrant function name file, the update necessity information of the all reentrant function name file Is stored.

  The reentrant function name addition output unit (7) includes the third reentrant function name file (31_3), the all reentrant function name file (32), and the reentrant function load module update information file (load module R update information). File: 36) is input. The reentrant function name addition output unit is included in the third reentrant function name file based on the update necessity information in the reentrant function load module update information file, and is included in the all reentrant function name file. No reentrant function name is added to all the reentrant function name files (32_1).

  The reentrant function load module output unit (4) includes all the reentrant function name files (32_1) added by the reentrant function name additional output unit, and the reentrant function load module update information file (load module R update information file). : 36) is input. The reentrant function load module output unit refers to the library and updates the reentrant function load module and the reentrant function address information file (33) according to the update necessity information of the reentrant function load module update information file. .

  The code link unit (5) receives the third object code group (30_3) and the updated function address information file (33). A third load module (34_3) corresponding to the third object code group is output. The code link unit refers to the library, replaces the function name symbol that refers to the reentrant function in the third object code group with the function address in the function address information file, and calls a function that calls other than the reentrant function. Address unresolved function name symbols are linked with the above library to resolve addresses.

  As a result, common functions can be shared even when there is additional object code, and the build time can be shortened.

[3] <Rebuild due to object code change>
In claim 1, the build tool (1) includes a relink information determination unit (8), a reentrant function load module update determination unit (load module R update determination unit: 6), and a reentrant function name edit output unit (9). ).

  The reentrant function name output unit (2) receives a fourth object code group (30_4) changed from the first object code group, refers to the library, and is a reentrant function in the library, A fourth reentrant function name file (31_4) that holds the function names of all the reentrant functions referenced from the fourth object code group is output.

  The all reentrant function name output unit (3) receives the fourth reentrant function name file and the second reentrant function name file and inputs all the reentrant function names included in the fourth and second reentrant function name files. A second all reentrant function name file (32_2) including no duplication is output.

  The relink information determination unit (8) receives the all reentrant function name file (32), the third all reentrant function name file (32_2), and the second reentrant function name file (31_2). Information on whether or not to relink the second reentrant function name file is output to a relink information file (37).

  The reentrant function load module update determination unit (load module R update determination unit: 6) receives the all reentrant function name file (32) and the second all reentrant function name file (32_2). The reentrant function load module update determination unit outputs a reentrant function load module update information file (load module R update information file: 36) that stores update information as to whether or not to update the reentrant function load module.

  The reentrant function name editing output unit (9) receives the all reentrant function name file (32), the second all reentrant function name file (32_2), and the reentrant function load module update information file. The reentrant function name edit output unit overwrites the all reentrant function name file with the second all reentrant function name file according to the information of the reentrant function load module update information file.

  The reentrant function load module output unit (4) receives the all reentrant function name file edited by the reentrant function name editing output unit and the reentrant function load module update information file. The previous reentrant function load module output unit refers to the library, and according to the information in the reentrant function load module update information file, the reentrant function load module (load module R: 34_R) and the function address information file (33). And update.

  The code link unit (5) receives the fourth object code group (30_4), the relink information file (37), and the function address information file (33). The code link unit (5) refers to the library and replaces a function name symbol that refers to a reentrant function in the fourth object code group with a function address in the function address information file. Further, the function name symbol of the function that calls a function other than the reentrant function is linked to the library to resolve the address, and the load module corresponding to the fourth object code group is output to overwrite the first load module. To do. The code link unit (5) refers to the library, and if there is information for relinking the second object code group in the relink information file, a function that refers to a reentrant function in the second object code group. Replace the name symbol with the function address in the function address information file. Further, other unresolved symbols are linked with the library and a load module which is a result of resolving the address is output to overwrite the second load module.

  Thereby, for example, by the method shown in the first embodiment, a common reentrant function can be shared even when a modification has occurred in an object code group in which a load module has already been created, and the build time can be shortened.

[4] <Omit re-creation when load module R does not require updating>
In the item 2 or 3, the reentrant function load module output unit (4) includes the reentrant function included in the all reentrant function name file only when the reentrant function load module update information file includes information other than update unnecessary. Overwrite the reentrant function load module consisting only of the code. The reentrant function load module output unit outputs a function address information file holding address information of all the reentrant functions in the reentrant function load module and overwrites the function address information file.

  Thus, if the reentrant function load module (load module R: 34_R) does not need to be changed, the reentrant function load module is not recreated, thereby shortening the time required for the build.

[5] <Necessity determination of re-linking>
In item 3, the relink information determination unit (8) determines whether a different function name first appears from the beginning of the files of the all reentrant function name file (32) and the second all reentrant function name file (32_2). Create a matching function name file consisting of function names. The relink information determination unit performs control so that relinking is performed when a function name not included in the matching function name file is included in the second reentrant function name file (31_2), and relinking is not performed when the function name is not included. The information is output to the relink information file (37).

  Thus, for example, in the method shown in the first embodiment, when a modification has occurred in an object code group that has already created a load module, it is determined whether relinking of object code groups other than the object code group in which the modification has occurred is necessary. By determining and processing, the time required for the build can be shortened.

[6] <Determining whether to change the reentrant function load module and whether to relink>
In item 3, the reentrant function load module update determination unit (load module R update determination unit: 6) starts from the beginning of the files of the all reentrant function name file (32_1) and the second all reentrant function name file (32_2). Create a matching function name file consisting of function names until different function names appear. If the all reentrant function name file (32_1) and the matching function name file match, updating is necessary. If not, rewriting is necessary. The second all reentrant function name file (32_2) and the matching function name file are If they match, a reentrant function load module update information file (load module R update information file: 36) that stores control information that does not require updating is output.

  As a result, for example, in the method shown in the first embodiment, when a modification has occurred in an object code group in which a load module has already been created, it is necessary to change the reentrant function load module. Since it is determined whether or not the object code group needs to be relinked, the time required for the build can be shortened.

[7] <Determination of necessity of editing all reentrant function name files>
In item 3, the reentrant function name editing output unit (9) is included in the fourth reentrant function name file (31_4) when the reentrant function load module update information file includes information that needs to be updated. The reentrant function name not included in the all reentrant function name file (32_1) is additionally written in the all reentrant function name file (32_1). If the reentrant function load module update information file contains information that needs to be rewritten, the second all-reentrant function name file (32_2) is overwritten on the all-reentrant function name file (32_1).

  Thus, for example, when the object code group that has already created the load module is modified by the method shown in the first embodiment, the reentrant function load module needs to be changed, rewritten, or rewritten according to whether it is necessary. By preparing to build the function load module, the time required for the build can be shortened as a result.

[8] <Builds that share reentrant functions>
By being read and executed by the computer (12), the library (10) including the reentrant function is referred to based on the plurality of input object code groups (30), and the plurality of object code groups are supported. A build tool (1) that outputs a load module (34) that is configured as follows.

  A first object code group (30_1) and a second object code group (30_2) are input to the build tool. The build tool refers to the library to obtain the function names of all reentrant functions referenced from the first object code group and the function names of all reentrant functions referenced from the second object code group. An all reentrant function name list (32) including all the reentrant function names included without duplication is created.

  The build tool outputs a reentrant function load module (load module R: 34_R) and first and second load modules (34_1, 34_2) corresponding to the first and second object code groups, respectively. The reentrant function load module includes execution codes of all reentrant functions included in the all reentrant function name list, and does not include reentrant function codes not included in the all reentrant function name file.

  As a result, by sharing the execution code of the reentrant function used in common among a plurality of load modules, it is possible to output a load module in which the entire code size is minimized. In addition, the above is enabled for a library in which reentrant attributes (whether reentrant or not) are mixed.

[9] <Rebuild with the addition of object code group>
In item 8, the third object code group (30_3) is further input, and among all the reentrant function names referenced from the third object code group, all the reentrant functions not included in the all reentrant function name list Add the function name of the function to the list of all reentrant functions.

  A third load module (34_3) corresponding to each of the third object code groups is further output. Further, when a new reentrant function name is added to the all reentrant function name list, the reentrant function load module is recreated and updated.

  As a result, common functions can be shared even when there is additional object code, and the build time can be shortened.

[10] <Rebuild associated with object code group change>
In item 8, the fourth object code group (30_4) changed from the first object code group is input, and the function names of all the reentrant functions referenced from the fourth object code group with reference to the library Based on the above, the list of all reentrant function names is updated.

  A fourth load module corresponding to the fourth object code group is created to overwrite the first load module, and when the all reentrant function name list is updated, the reentrant function load module is recreated and updated. .

  Thereby, for example, by the method shown in the first embodiment, a common reentrant function can be shared even when a modification has occurred in an object code group in which a load module has already been created, and the build time can be shortened.

2. Details of Embodiments Embodiments will be further described in detail.

Embodiment 1
FIG. 1 is a block diagram showing an entire program development system for a microcomputer chip, which is a multi-core processor, including the build tool of the first embodiment.

  In the microcomputer chip program development system, a display 14 and a keyboard 13 are connected to a PC main body 12 which is an example of a computer on which the build tool of the first embodiment is executed, and can be connected to the microcomputer chip 20 via a ROM writer 15. It has become a structure. The PC main body 12 includes a CPU 16, a hard disk drive (HDD: Hard Disk Drive) 17, and a RAM 18 that are connected to each other via a bus 19. The microcomputer chip 20 is a multi-core processor including a plurality of CPU cores. The illustrated microcomputer chip 20 includes a CPU core 1 (21_1), a CPU core 2 (21_2), a ROM 25, and a RAM 24 connected to each other via a bus 26. It may be configured to include more than two CPU cores as illustrated, and may be configured to include other functional modules. The CPU core 1 (21_1) includes a CPU 1 (21_1) and a local memory LM1 (23_1), and the CPU core 2 (21_2) includes a CPU 2 (21_2) and a local memory LM2 (23_2). It is not always necessary to include local memory, but providing local memory increases the independence of operations for each CPU compared to sharing the memory on the bus, and speeds up the operation individually and as a whole. Is done. The load module 35 written via the ROM writer 15 is stored in the ROM 25.

  The build tool 1 having the library 10 is stored in the HDD 17 of the PC main body 12 and transferred to the RAM 18 to execute the build program. In the RAM 18, the input object code groups 1 and 2 (30_1 and 2), reentrant function name files 1 and 2 (31_1 and 2) as intermediate data, all reentrant function name files 32, and reentrant function address information file 33 are stored. , Load modules 1 and 2 and R (34_1 to 2 and 34_R) are held. The generated load modules 1 and 2 and R (34_1 to 2 and 34_R) are written to the ROM 25 of the microcomputer chip 20 by the ROM writer 15. The ROM 25 is preferably an electrically erasable / rewritable ROM such as a flash memory (registered trademark). The ROM 25 may be an external ROM without being integrated in the microcomputer chip 20. In that case, the load module 35 may be transferred from the stored ROM 25 to the RAM 24 or the local memories 23_1 and 2 on the microcomputer chip 20 in the execution stage, or may be sequentially accessed from the CPU core.

  The build tool 1 includes a reentrant function name output unit 2, an all reentrant function name output unit 3, a reentrant function load module output unit 4, and a code link unit 5. Based on the input object code group 30, the library 10 including the reentrant function is referred to, and the load module 34 corresponding to each of the object code group 30 and the object code group 30 are used. The load module 34_R for the reentrant function is output.

  FIG. 4 is an explanatory diagram illustrating the operation of the build tool according to the first embodiment. The object code group 1 (30_1) input to the build tool 1 includes calls to functions f1 and f2 whose addresses are unresolved. If the addresses of these functions can be resolved, the load module 1 (34_1) is obtained. . The object code group 2 (30_2) includes calls of functions f2 and f3 whose addresses are unresolved. If the addresses of these functions can be resolved, the load module 2 (34_2) is obtained. The library 10 includes function definitions of functions f1, f2, f3, f4, and f5, and the functions f1, f2, f3, f4, and f5 all have reentrant attributes.

  The reentrant function name output unit 2 refers to the input object code groups 1 and 2 (30_1 and 2) and the library 10, and outputs reentrant function name files (31_1 and 2) corresponding to the respective object code groups. To do. The reentrant function name files 31_1 and 2 hold function names of all the reentrant functions referred to from the object code groups 1 and 2 (30_1 and 2), respectively.

  The reentrant function name output unit 2 performs the same processing as that of a normal linker, searches for an unresolved symbol in the object code group 1 (30_1), and if it exists in the library, the symbol name is reentrant. Output to information file 1 (31_1). Since the object code group (30_1) includes function symbols f1 and f2 whose addresses are unresolved and these are included in the library as functions having reentrant attributes, the function names f1 and f2 are included in the reentrant information file 1 (31_1). Is output.

  Similarly, the reentrant function name output unit 2 performs the same processing as that of a normal linker for the object code group 2 (30_2), and selects an unresolved symbol in the object code group 2 (30_2). If it is found and exists in the library, the symbol name is output to the reentrant information file 2 (31_2). Since the object code group 2 (30_2) includes function symbols f2 and f3 whose addresses are unresolved and these are included in the library, the function names f2 and f3 are output to the reentrant information file 2 (31_2).

  The all reentrant function name output unit 3 outputs an all reentrant function name file 32 including all the reentrant function names included in the reentrant function name files 31_1 and 2 without duplication. The reentrant information file 1 (31_1) includes function names f1 and f2, and the reentrant information file 2 (31_2) is a file including function names f2 and f3. The all reentrant information file 32 is a file including function names f1, f2, and f3. The function name f2 is included in both the reentrant information file 1 (31_1) and the reentrant information file 2 (31_2), but is unified at this time.

  The reentrant function load module output unit 4 outputs a load module R (34_R) including execution codes of all the reentrant functions included in the all reentrant function name file 32. The load module R (34_R) does not include reentrant functions that are not included in the entire reentrant function name file 32 and execution codes of non-reentrant functions. The reentrant function load module output unit 4 further outputs a reentrant function address information file 33 that holds address information of the reentrant function in the load module R (34_R). The reentrant function address information file 33 is an object code composed of a function name symbol and an address pointed to by the symbol. This will be described in detail with reference to FIG.

  FIG. 10 is an explanatory diagram showing an example of the reentrant function address information file 33.

  The function symbols f1, f2, and f3 indicate that the addresses they point to are 0x1a, 0x24, and 0x38, respectively. FIG. 10 shows this more specifically in the form of an assembler source program. “.Public _f1” is an assembler language pseudo-instruction that declares the symbol “_f1” so that it can be referenced from other files. However, “_f1” is prefixed with “_” to indicate that the symbol “f1” in the C language has been converted into the assembler language. In FIG. 4, the symbol name “_” at the beginning is omitted to simplify the description. The same applies to “.public _f2” and “.public _f3”. “_F1: .equ 0x1a” is an assembler language pseudo instruction indicating that the symbol “_f1” has the value 0x1a. The same applies to “_f2: .equ 0x24” and “_f3: .equ 0x38”.

  Returning to the description of FIG.

  The load module R (34_R) output from the reentrant function load module output unit 4 is a load module including only the reentrant functions f1, f2, and f3. The function definitions of the functions f1, f2, and f3 are assigned to the addresses indicated in the reentrant function address information file 33, respectively.

  The reentrant function load module output unit 4 first inputs all the reentrant function name files 32 and creates dummy functions that call those functions.

FIG. 9 is an explanatory diagram showing an example of a dummy function for creating the load module R. It is an assembler source file of a dummy function created internally by the reentrant function load module output unit 4.
“.Extern _f1” is an assembler language pseudo-instruction indicating that a symbol _f defined outside the file is referred to. The same applies to “.extern_f2” and “.extern_f3”. “Dumsec .cseg TEXT” is an assembler language pseudo-instruction that declares the start of a text section named dumsec. “_Dummy” represents the definition of the symbol _dummy. “Call_f1” is an assembler instruction for calling the function symbol _f1. “Return” is an instruction to return from the function to the calling function. In this case, it represents returning to the function that called the _dummy function.

  By linking this file with the library, a load module consisting of the dummy functions and the definitions of the functions f1, f2, and f3 is created. The address of the dumsec section to which the dummy function is allocated can be specified by the function of the linker, and the address range of the load module to be output can be specified by another function of the linker. Therefore, in this embodiment, this function is used so that the output load module R (34_R) includes only the functions f1, f2, and f3, and the code for the dummy function itself is not output.

  FIG. 4 shows the load module R (34_R) output in this way. The load module R (34_R) is composed only of function definitions of the functions f1, f2, and f3, and each function is assigned to addresses 0x1a, 0x24, and 0x38. At the same time, the reentrant function load module output unit 4 outputs the symbol names of the functions f1, f2, and f3 and the addresses assigned to them as assembler codes. The reentrant function address information file 33 is a file output in this way. This is more specifically expressed in the form of an assembler source program.

  The code link unit 5 outputs load modules 1 and 2 (34_1 and 34_2) corresponding to the input object code groups 1 and 2 (30_1 and 2), respectively. At this time, the code link unit 5 replaces the function name symbol that refers to the reentrant function in the object code groups 1 and 2 (30_1 and 2) with the function addresses in the reentrant function address information file 33, and loads modules 1 and 2 (34_1, 34_2) is output. At this time, the function name symbol whose function is unresolved that calls a function other than the reentrant function is linked to the library 10 to be resolved. The load module 1 (34_1) is a result of replacing the calls of the functions f1 and f2 in the object code group 1 (30_1) with the addresses of the respective functions in the load module R (34_R). The load module 2 (34_2) is a result of replacing the calls of the functions f2 and f3 in the object code group 2 (30_2) with the addresses of the respective functions in the load module R (34_R).

  As described above, the load modules 1 and 2 (34_1) which are load modules for the object code groups 1 and 2 (30_1 and 2) with respect to the function f2 shared by the object code groups 1 and 2 (30_1 and 2). , 34_2) do not have a copy of the function f2, but share one code for the function f2, so that the total code size of the entire load module group can be reduced.

  FIG. 7 is an explanatory diagram showing a load module created by applying a conventional build tool.

  (A) is a figure showing a mode that two load modules 1 and 2 are arrange | positioned on RAM at the time of program development and test. The load module 1 is composed of an object module prog1.obj and an object module composed of library functions sin and cos, and calls the functions sin and cos from prog1.obj. The load module 2 is composed of an object module prog2.obj and an object module composed of library functions sin and tan, and calls the functions sin and tan from within prog2.obj.

  (B) shows the hex files 1 and 2 obtained by converting the load modules 1 and 2 shown in (a) into ROM without applying the prior art disclosed in Patent Document 1, and each hex file is in the address space. It is a figure showing a mode that it arrange | positioned so that it may become a continuous address. prog1-hex and prog2-hex are the parts obtained by hexating prog1.obj and prog2.obj, respectively, and sin, cos, and tan are the functions sin, cos, and tan in the object module in (a), respectively. It is the part which became. The total size of the hex files 1 and 2 at this time is the sum of the sizes of prog1-hex, sin, cos, and prog2-hex, sin, and tan.

  On the other hand, (c) shows an integrated hex file as a result of applying ROM to the load modules 1 and 2 shown in FIG. It is a figure showing a mode that it arrange | positioned so that it may become a continuous address. In the prior art disclosed in Patent Document 1, duplicate functions can be deleted when the ROM is implemented. In the example of (a), the function sin is duplicated in the two load modules, so this is set to one in the integrated hex file. As a result, the total size of the integrated hex files 1 and 2 is the sum of the sizes of prog1-hex, sin, cos, prog2-hex, and tan, and is reduced by the size of the function sin compared to (b). The

  However, as already mentioned, there is a problem with the above prior art. This will be described in more detail below.

  When creating a load module for the purpose of debugging two load modules at the same time on a multi-core, a copy of the library function is included in each load module, so the overall size can be larger than the actual size. The address range may be exceeded and the load module may not be created. This is the state shown in (b).

  Also, if there is a user function in prog1.obj that has the same name as the library function tan that is called from prog2.obj but is different in processing, both will be deleted when creating the integrated hex file. Then, since the remaining functions are called from the two hex files, there is a possibility that an illegal code is created without the programmer being aware.

  In addition, the program cannot be debugged with the same code at the time of program development / test and actual use before ROMization, so that the reliability of the program test is inferior.

  If it is guaranteed that the function sin common to prog1 and prog2 is not called from prog1 and prog2 at the same time, the method (c) can be adopted. However, when prog1 and prog2 operate on different CPU cores operating in parallel, there is no guarantee that the other does not call the sin function during one sin operation. Therefore, according to the prior art, the method (b) must be taken. However, since prog1 and prog2 are independently developed programs, adopting (b) requires new work for integrating programs, such as adjusting conflicts between variable names and function names.

  FIG. 8 is an explanatory diagram illustrating a load module created by the build tool according to the first embodiment.

  (A) is a diagram showing a function load information file including the library load module and address information of each function created in the first half of the build process. The library load module (34_R) is composed of codes for the reentrant functions sin, cos, and tan. This library load module (34_R) is created by linking a dummy library call function that calls all the functions included therein and a library including the functions sin, cos, and tan. At that time, the section allocated to the dummy library call function is deleted by a certain link option. As a result, a load module including only the functions sin, cos, and tan is created. Further, a reentrant function address information file 33, which is an assembly source program including information on absolute addresses assigned by the functions sin, cos, and tan, is output by another link option.

(B) is a diagram showing two load modules created in the second half of the build process.
In the second half of the build, first, the object code prog1.obj that calls the functions sin and cos is linked to the function address information file of (a). As a result, the addresses for sin and cos in prog1.obj are resolved, and prog1.obj resulting from the address resolution becomes load module 1 (34_1). The object code prog2.obj that calls the functions sin and tan is linked to the function address information file of (a). As a result, the addresses for sin and tan in prog2.obj are resolved, and prog2.obj as a result of the address resolution becomes load module 2 (34_2). As a result, the total size of the load modules 1 and 2 (34_1 to 2) and the library load module (34_R) is the sum of the sizes of prog1.obj, prog2.obj, sin, cos, and tan, and (b) Compared with, the size of the function sin is reduced. At this time, since the library load module (34_R) is composed only of the reentrant function, it is guaranteed that the function that is being executed from prog1 and being executed from prog2 operates normally.

  As described above, the following effects are obtained.

  When trying to create a load module for the purpose of debugging two load modules at the same time on a multi-core, the library function is shared among multiple load modules and the overall size is the same as the actual size. A load module can always be created if the size fits within an available address.

  Also, if there is a user function in prog1.obj that has the same name as the library function tan that is called from prog2.obj but is different in processing, define the function tan when creating a load module using prog1.obj and the function address information file. Is in two places in prog1.obj and in the function address information file, resulting in a link error. As a result, programmers can be aware of program fraud.

  In addition, since debugging can be performed with the same code during program development / test and actual use before ROMization, the reliability of program testing is improved.

[Embodiment 2]
In the second embodiment, it is assumed that the build process shown in the first embodiment is executed and the created file remains on the RAM 18, and the build tool for the case of adding a new object code group is added. Describe the function.

  FIG. 2 is a block diagram showing an entire program development system for a microcomputer chip, which is a multi-core processor, including the build tool of the second embodiment.

  The program development system for a microcomputer chip has a configuration in which a display 14 and a keyboard 13 are connected and can be connected to a microcomputer chip 20 via a ROM writer 15, and is the same as the PC main body 12 shown in FIG. . The configuration of the microcomputer chip 20 is the same as that of the microcomputer chip 20 shown in FIG. The description of the same part is omitted.

  The build tool 1 having the library 10 is stored in the HDD 17 of the PC main body 12 and transferred to the RAM 18 to execute the build program. In the RAM 18, an object code group 3 (30_3) to be added, a library 10, a reentrant function name file 3 (31_3), an all reentrant function name file 32_1, a load module R update information file 36, a load module R (34_R), and The function address information file 33 and the load module 3 (34_3) are held.

  The build tool 1 includes a reentrant function name output unit 2, a load module R update determination unit 6, a reentrant function name addition output unit 7, a reentrant function load module output unit 4, and a code link unit 5. Based on the additionally input object code group 3 (30_3), the library 10 including the reentrant function is referred to, and the load module 3 (34_3) corresponding to the object code group 3 (30_3) is output, and the reentrant function is output. The load module R (34_R) is updated. The generated load module 3 (34_3) and the updated load module R (34_R) are written into the ROM 25 of the microcomputer chip 20 by the ROM writer 15.

  FIG. 5 is an explanatory diagram illustrating the operation of the build tool according to the second embodiment.

  The object code group 3 (30_3) to be added includes a call to the function f4 whose addresses are unresolved, and if the addresses of these functions can be resolved, the load module 3 (34_3) is obtained.

  The reentrant function name output unit 2 receives the object code group 3 (30_3), is referred to the library 10 and is called from the object code group 3 (30_3), and the reentrant function name file that holds the reentrant function name of the library 10 3 (31_3) is output. The reentrant function name file 3 (31_3) includes the function name f4.

  The load module R update determination unit 6 receives the reentrant function name file 3 (31_3) and the all reentrant function name file 32_1 and needs to update the all reentrant function name file 32 output from the build program shown in the first embodiment. The load module R update information file 36 that stores the reject information is output. Whether all the reentrant function name files 32 need to be updated is determined based on the presence or absence of a function name that is included in the reentrant function name file 3 (31_3) and not included in the all reentrant function name file 32. The load module R update information file 36 includes information “update required” indicating that the load module needs to be updated. Since the reentrant function name file 3 (31_3) illustrated in FIG. 5 includes the function name f4 that is not included in all the reentrant function name files 32 before the update, the load module includes information indicating that “update is necessary”. An R update information file 36 is output.

  The reentrant function name addition output unit 7 generates the reentrant function name file 3 (31_3), all reentrant function name files 32 before update, and all the information after update based on the update necessity information of the load module R update information file 36. The reentrant function name file 32_1 is output. The reentrant function name addition output unit 7 appends reentrant function names that are included in the reentrant function name file 3 (31_3) and are not included in the entire reentrant function name file 32 before update, and all reentrants after update. The function name file 32_1 is output. The all-reentrant function name file 32 is a file including the function names f1, f2, and f3 immediately after being output from the build program shown in the first embodiment. However, after the update process is performed in this embodiment, the function name f4 is used. Is added and becomes the updated all reentrant function name file 32_1.

  The reentrant function load module output unit 4 receives all reentrant function name files 32_1 added by the reentrant function name output unit 2 and refers to the library 10 according to the update necessity information of the load module R update information file 36. The load module R (34_R) and the reentrant function address information file 33 are updated. Since the information in the load module R update information file 36 is “update required”, the reentrant function load module output unit 4 does not change the address of the function in the load module R (34_R) so far, The address is resolved, the load module R (34_R) and the function address information file 33 are output, and the existing file is overwritten. That is, the definition of the function f4 is added to the load module R (34_R), and the address 0x44 to which the function f4 is assigned is added to the reentrant function address information file 33.

  The code link unit 5 receives the object code group 3 (30_3) and the updated reentrant function address information file 33, and refers to the library 10 to load module 3 (34_3) corresponding to the object code group 3 (30_3). Is output. In the object code group 3 (30_3), the function name symbol that refers to the reentrant function is replaced with the function address in the reentrant function address information file 33, and the function name symbol whose address is unresolved that calls a function other than the reentrant function is To resolve the address. In the object code group 3 (30_3), the function name symbol referring to the reentrant function f4 is replaced with the function address 0x44 in the reentrant function address information file 33, and the load module 3 (34_3) is output.

  As described above, even when an object code is added and a new reentrant function is added, the function is shared among the load modules, and the total code size of the entire load module group can be kept small. In addition, since the allocation addresses of functions registered in the load module R are not changed, it is not necessary to relink the object code groups 1 and 2 referring to these functions. That is, the build can be performed at high speed. As a result, common functions can be shared even when there is additional object code, and the build time can be shortened.

[Embodiment 3]
In the third embodiment, assuming that the build process shown in the first embodiment is executed and the created file remains on the RAM 18, the object code group that has already created the load module has been modified. The function of the build tool is described.

  FIG. 3 is a block diagram showing the entire program development system for a microcomputer chip that is a multi-core processor, including the build tool of the third embodiment.

  The program development system for a microcomputer chip has a configuration in which a display 14 and a keyboard 13 are connected and can be connected to a microcomputer chip 20 via a ROM writer 15, and is the same as the PC main body 12 shown in FIG. . The configuration of the microcomputer chip 20 is the same as that of the microcomputer chip 20 shown in FIG. The description of the same part is omitted.

  The build tool 1 having the library 10 is stored in the HDD 17 of the PC main body 12 and transferred to the RAM 18 to execute the build program. The RAM 18 includes an object code group 1A (30_4) and an object code group 2 (30_2) changed by modification from the object code group 1 (30_1), the library 10, the reentrant function name file 2 (31_2), and the first embodiment. All the reentrant function name files 32 output from the build program shown in FIG. Further, the load module R update information file 36, the load module R (34_R), the function address information file 33, and the load module 3 (34_3) are held as intermediate data and output.

  The build tool 1 includes a reentrant function name output unit 2, an all reentrant function name output unit 3, a relink information determination unit 8, a load module R update determination unit 6, a reentrant function name edit output unit 9, and a reentrant function load. A module output unit 4 and a code link unit 5 are provided. Based on the changed object code group 1A (30_4), the load module 34_1 corresponding to the object code group 1 (30_1) and the reentrant function load module R34_R are updated with reference to the library 10 including the reentrant function. To do. The updated load module 1 (34_1) and load module R (34_R) are written into the ROM 25 of the microcomputer chip 20 by the ROM writer 15.

  FIG. 6 is an explanatory diagram illustrating the operation of the build tool according to the third embodiment.

  The reentrant function name output unit 2 receives the object code group 1A (30_4) changed from the object code group 1 (30_1), and refers to the library 10 to output the reentrant function name file 1A (31_4). The reentrant function name file 1A (31_4) holds function names of reentrant functions in the library 10 that are referenced from the object code group 1A (30_4). In FIG. 6, in the first embodiment, the object code group 1 (30_1) is a file including calls of functions f1, f2, and f3 whose addresses are unresolved. However, the function f2 whose address is unresolved is changed by the programmer. , f3 is called, the example becomes the object code group 1A (30_4).

  A reentrant function name file 1A (31_4) and a reentrant function name file 2 (31_2) are input to the all reentrant function name output unit 3, and all reentrant function name files (including all reentrant function names included in them) ( 32_2) is output. All reentrant function name files are files including function names f1, f2, and f3 before update by the build process of the present embodiment, that is, immediately after executing the build program shown in the first embodiment. The all reentrant function name file 32_2 after the update by the build process of this embodiment is a file including the function names f2 and f3.

  The relink information determination unit 8 receives an all reentrant function name file 32 before update, an all reentrant function name file 32_2 after update, and a reentrant function name file 2 (31_2), and the reentrant function name file 2 ( Information on whether or not to relink 31_2) is output to the relink information file 37. The relink information file 37 is information indicating whether or not the object code group in which the load module has already been created is linked again with the load module R (34_R). In FIG. 6, the example is “relink”. Show.

  First, the relink information determination unit 8 compares the contents “f1, f2, f3” of all the reentrant function name files 32 before the update with the contents “f2, f3” of all the reentrant function name files 32_2 after the update, Create a matching function name file consisting of function names from the beginning of the file until the first different function name appears. In the example shown in FIG. 6, the matching function name file is an empty file. Next, if the reentrant function name file 2 (31_2) includes a function name that is not included in the matching function name file, the relink information file 37 is output to the relink information file 37. In the example shown in FIG. 6, since the reentrant function name file 2 (31_2) includes function names f2 and f3 that are not in the matching function name file, “relink” is performed.

  The load module R update determination unit 6 receives the all reentrant function name file 32 before update and the all reentrant function name file 32_2 after update, and stores update information as to whether or not to update the load module R (34_R). The load module R update information file 36 to be output is output. The load module R update information file 36 is a file including information “rewrite required” indicating that the existing part included in the load module R (34_R) also needs to be updated.

  The load module R update determination unit 8 is also composed of function names from the beginning of all reentrant function name files 32 before update and all reentrant function name files 32_2 after update until a different function name first appears. Create a matching function name file. In the example shown in FIG. 6, the matching function name file is an empty file. Next, since all the reentrant function name files do not match the matching function name file, information indicating “rewrite required” is output to the load module R update information file 36.

  The reentrant function name editing output unit 9 receives all reentrant function name files 32 before update and all reentrant function name files 32_2 after update, and all reentrants before update according to the information in the load module R update information file 36. The function name file 32 is overwritten with the updated all reentrant function name file 32_2. In the example shown in FIG. 6, since the reentrant function name editing output unit 9 includes information that the load module R update information file 36 indicates “rewrite required”, the reentrant function name file 1A (31_4) is changed to the all reentrant function name file 32_2. Overwrite and output. As a result, the reentrant function name file 32_2 changes from f1, f2, f3 before update to f2, f3 after update.

  The reentrant function load module output unit 4 receives all the reentrant function name file files 32_2 edited by the reentrant function name editing output unit 9 and the load module R update information file 36. The load module R is referenced with reference to the library 10. In accordance with the information in the update information file 36, the load module R (34_R) and the reentrant function address information file 33 are updated. The reentrant function address information file 33 is an object code composed of a function name symbol and an address pointed to by the function name, and functions f1, f2, f3 before updating, that is, immediately after executing the build program shown in the first embodiment. However, after updating, that is, after performing update processing in this embodiment, the file includes the allocation addresses of the functions f2 and f3. Since the function f1 is deleted, the addresses of the functions f2 and f3 are changed to 0x1a and 0x38 to 0x2e, respectively. The load module R (34_R) is a load module composed of the functions f1, f2, and f3 before updating, that is, immediately after executing the build program shown in the first embodiment. After performing the update process in the embodiment, the load module is composed of the functions f2 and f3. The reentrant function load module output unit 4 eliminates all previous function addresses in accordance with the information “rewrite required” in the load module R update information file 36, newly performs link processing, and loads the module R (34_R) and reentrant function address information. The file 33 is output and the existing file is overwritten. As a result, in the load module R, the addresses assigned to the functions f2 and f3 are changed to new addresses 0x1a and 0x2e.

  The changed object code group 1A (30_4), the relink information file 37, and the reentrant function address information file 33 are input to the code link unit 5. The code link unit 5 refers to the library 10 and replaces the function name symbol that refers to the reentrant function in the changed object code group 1A (30_4) with the function address in the reentrant function address information file 33. Further, a function name symbol of a function that calls a function other than the reentrant function is linked to the library to resolve the address, and a load module corresponding to the changed object code group 1A (30_4) is output to output the load module 1. (34_1) is overwritten. The code link unit 5 refers to the library 10, and if the relink information file 37 has information for relinking the object code group 2 (30_2), the function that refers to the reentrant function in the object code group 2 (30_2). The name symbol is replaced with the function address in the reentrant function address information file 33. Further, other unresolved symbols are linked with the library and the load module which is the result of resolving the address is output to overwrite the load module 2 (34_2).

  In the example shown in FIG. 6, since the code link unit 5 has the information “relink” in the relink information file, the object code group 2 (30_2) is relinked together with the object code group 1A (30_4), As a result, the load modules 1 and 2 (34_1 and 2) are output. The load module 1 (34_1) changes the call of the functions f1, f2, and f3 in the object code group 1 (30_1) to the call of the functions f2 and f3 in the object code group 1A (30_4). Each symbol is changed by replacing the addresses 0x1a and 0x2e of the functions f2 and f3 in the load module R (34_R). The load module 2 (34_2) replaces the calls of the functions f2 and f3 in the object code group 2 (30_2) with the addresses 0x1a and 0x2e of the functions f2 and f3 in the load module R (34_R).

  According to the third embodiment, for example, even when a modification occurs in the object code group in which the load module has already been created by the method shown in the first embodiment, a common reentrant function is shared among the load modules, It can be seen that the total code size of the entire load module group is kept small. In addition, since it is determined whether or not the load module R needs to be changed and whether or not the object code group other than the object code group that has been corrected needs to be relinked, the time required for the build can be shortened. it can.

  Thereby, for example, by the method shown in the first embodiment, a common reentrant function can be shared even when a modification has occurred in an object code group in which a load module has already been created, and the build time can be shortened.

  Although the invention made by the present inventor has been specifically described based on the embodiments, it is needless to say that the present invention is not limited thereto and can be variously modified without departing from the gist thereof.

  For example, each functional block constituting the build tool does not need to be divided as shown in the embodiment, and the build tool may be configured to include a part that realizes the function as a whole. The build tool itself may further include other tools, and may be realized as part of a larger development system.

DESCRIPTION OF SYMBOLS 1 Build tool 2 Reentrant function name output part 3 All reentrant function name output part 4 Reentrant function load module (load module R) output part 5 Code link part 6 Reentrant function load module (load module R) update determination part 7 Reentrant function name addition Output unit 8 Relink information determination unit 9 Reentrant function name edit output unit 10 Library 12 Computer (PC)
13 Keyboard 14 Display 15 ROM Writer 16 (Computer Side) CPU
17 Hard disk 18 (Computer side) RAM
19 (computer side) bus 20 microcomputer chip 21 (in microcomputer chip) CPU core 22 (in microcomputer chip) CPU
23 (within microcomputer chip) Local memory 24 (within microcomputer chip) RAM
25 (in microcomputer chip) ROM
26 (in microcomputer chip) bus 30 object code group 31 reentrant function name file 32 all reentrant function name file 33 reentrant function address information file 34 load module 35 (in microcomputer chip) load module 36 reentrant function load module (load module R) update Information file 37 Relink information file

Claims (10)

A build tool that outputs a load module corresponding to a plurality of object code groups by referring to a library including a reentrant function based on a plurality of input object code groups by being read and executed by a computer Because
Reentrant function name output unit, all reentrant function name output unit, reentrant function load module output unit, and code link unit,
The reentrant function name output unit receives a first object code group and a second object code group, refers to the library, is a reentrant function in the library, and is referenced from the first object code group. A first reentrant function name file that holds function names of all reentrant functions, and reentrant functions in the library that hold function names of all reentrant functions referenced from the second object code group; Output the second reentrant function name file,
The all reentrant function name output unit receives the first and second reentrant function name files, and includes all the reentrant function name files included in the first and second reentrant function name files without duplication. Output
The reentrant function load module output unit receives the all reentrant function name file, includes the execution codes of all the reentrant functions included in the all reentrant function name file with reference to the library, and all the reentrant function names A reentrant function load module that does not include code of a reentrant function that is not included in the file, and a reentrant function address information file that holds address information of the reentrant function in the reentrant function load module are output.
The code link unit receives the first and second object code groups and the reentrant function address information file, refers to the library, and refers to the reentrant function in the first and second object code groups. The name symbol is replaced with the function address in the reentrant function address information file, the function name symbol of the function that calls a function other than the reentrant function is linked to the library to resolve the address, and the first and second object codes A build tool for outputting first and second load modules respectively corresponding to a group. The reentrant function load module update determination unit and a reentrant function name addition output unit according to claim 1, further comprising:
The reentrant function name output unit receives a third object code group, refers to the library, is a reentrant function in the library, and functions of all reentrant functions referenced from the third object code group Output the third reentrant function name file that holds the name,
The reentrant function load module update determination unit receives the third reentrant function name file and the all reentrant function name file, is included in the third reentrant function name file, and is not included in the all reentrant function name file. Based on the presence or absence of the name, output the reentrant function load module update information file that stores the update necessity information of all the reentrant function name files,
The reentrant function name addition output unit receives the third reentrant function name file, the reentrant function load module update information file, and the all reentrant function load module name information file, and the update request of the reentrant function load module update information file is input. Based on the rejection information, the reentrant function name that is included in the third reentrant function name file and not included in the all reentrant function name file is added to the all reentrant function name file,
The reentrant function load module output unit receives all the reentrant function name files added by the reentrant function name additional output unit and the reentrant function load module update information file. Update the reentrant function load module and the reentrant function address information file according to the update necessity information of the function load module update information file,
The code link unit receives the third object code group and the function address information file updated by the reentrant function load module output unit, refers to the library, and reentrant functions in the third object code group. The function name symbol that references the function address in the function address information file is replaced, the address of the function name symbol that is not resolved by the function that calls a function other than the reentrant function is linked to the library, and the address is resolved. A build tool that outputs a third load module corresponding to a code group. In claim 1, further comprising a relink information determination unit, a reentrant function load module update determination unit, and a reentrant function name edit output unit,
The reentrant function name output unit receives a fourth object code group changed from the first object code group, refers to the library, is a reentrant function in the library, and is the fourth object code group. Output the 4th reentrant function name file that holds the function names of all reentrant functions referenced from
The all reentrant function name output unit receives the fourth reentrant function name file and the second reentrant function name file, and includes all the reentrant function names included in the fourth and second reentrant function name files without duplication. Output the second all reentrant function name file,
The relink information determination unit receives the all reentrant function name file, the second all reentrant function name file, and the second reentrant function name file, and relinks the second reentrant function name file. Information on whether or not to relink information file,
The reentrant function load module update determination unit receives the all reentrant function name file and the second all reentrant function name file, and stores renewal function load module update that stores update information as to whether or not to update the reentrant function load module. Output information file,
The reentrant function name editing / outputting unit receives the all reentrant function name file, the second all reentrant function name file, and the reentrant function load module update information file, and executes the above according to the information of the reentrant function load module update information file. Overwrite all reentrant function name files with the above second all reentrant function name file,
The reentrant function load module output unit receives all the reentrant function name files edited by the reentrant function name editing output unit and the reentrant function load module update information file, and refers to the library to load the reentrant function load module. Update the reentrant function load module and the function address information file according to the information in the module update information file.
The code link unit receives the fourth object code group, the relink information file, and the function address information file, refers to the library, and refers to the reentrant function in the fourth object code group. The function name symbol to be replaced is replaced with the function address in the function address information file, and the function name symbol of the function that calls other than the reentrant function is linked to the library to resolve the address, and the fourth object code group The corresponding load module is output to overwrite the first load module, and if there is information to relink the second object code group in the relink information file, the reentrant function is referred to in the second object code group. Function name symbol The function address in the function address information file is replaced, and other unresolved symbols are linked with the above library and the load module that is the result of resolving the address is output to overwrite the second load module. tool.   3. The reentrant function load module output unit according to claim 2, wherein the reentrant function load module output unit includes only the reentrant function code included in the all reentrant function name file only when the reentrant function load module update information file includes information other than update unnecessary. A build tool that overwrites the function address information file by overwriting the reentrant function load module to be output, outputting a function address information file holding the address information of all the reentrant functions in the reentrant function load module.   4. The relink information determination unit according to claim 3, wherein the relink information determination unit includes a function name including function names from the beginning of files of the all reentrant function name file and the second all reentrant function name file until a first different function name appears. Relink information that creates a name file and relinks if the second reentrant function name file contains a function name that is not in the matching function name file, and does not relink if it does not. Build tool that outputs to a file.   4. The reentrant function load module update determination unit according to claim 3, wherein the reentrant function load module update determination unit includes function names from the beginning of files of the all reentrant function name file and the second all reentrant function name file until a first different function name appears. A match function name file is created. If all the reentrant function name files and the match function name file match, update is required. If they do not match, rewrite is required. The second all reentrant function name file and the match function name Build tool that outputs a reentrant function load module update information file that stores control information that does not need to be updated if the files match.   The reentrant function name edit output unit according to claim 3, wherein the reentrant function load module update information file is included in the fourth reentrant function name file when the reentrant function load module update information file includes information that needs to be updated. If a reentrant function name not included in the reentrant function name file is additionally written to the above all reentrant function name file and the reentrant function load module update information file contains information that needs to be rewritten, the above second all reentrant function name file Is a build tool that overwrites all the reentrant function name files above. A build tool that outputs a load module corresponding to a plurality of object code groups by referring to a library including a reentrant function based on a plurality of input object code groups by being read and executed by a computer Because
The first object code group and the second object code group are input, and by referring to the library, the function names of all the reentrant functions referenced from the first object code group and the second object code group are referred to. Create a list of all reentrant function names including all reentrant function names included in the function names of all reentrant functions.
A reentrant function load module including execution codes of all reentrant functions included in the all reentrant function name list and not including reentrant function codes not included in the all reentrant function name file; and the first and second objects. A build tool that outputs first and second load modules respectively corresponding to a code group. 9. The reentrant function according to claim 8, wherein a third object code group is further input, and all of the reentrant function names not included in the all reentrant function name list among the function names of all reentrant functions referenced from the third object code group. Add the function name to the above list of all reentrant functions,
The third load module corresponding to each of the third object code groups is further output. When a new reentrant function name is added to the all reentrant function name list, the reentrant function load module is recreated and updated. Build tool. 9. The fourth object code group changed from the first object code group is input according to claim 8, and based on the function names of all reentrant functions referenced from the fourth object code group with reference to the library. Update the above list of all reentrant functions,
A fourth load module corresponding to the fourth object code group is created to overwrite the first load module, and when the all reentrant function name list is updated, the reentrant function load module is recreated and updated. , Build tools.

Images