JP2006113935A - Dynamic link library calling code generation method, program, and apparatus - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To create a loading image of a dynamic link library for each application program in an execution environment where one process can execute a plurality of applications. <P>SOLUTION: A wrapper library generation apparatus 1 performs: a first reading step for reading a dynamic link library 31 stored in a storage part 30, a generation step for generating a wrapper library 34 based on functions described in the read dynamic link library 31, a second reading step for reading an application program 35 stored in the storage part 30, and a converting step for specifying a code calling the dynamic link library 31 in the application program 35 to convert the calling code into a code for calling the wrapper library 34. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a technique for calling a dynamic link library.

  An operating system (hereinafter referred to as “OS”) such as Windows (registered trademark) allocates one process (unit of job) for each execution of an application program running on the OS. When the application program uses a function of a dynamic link library (hereinafter referred to as “DLL”), the OS dynamically loads the DLL into the process. In other words, the OS secures, initializes, and rearranges a DLL memory area. Then, the application program calls a DLL function by using the relocated address. The DLL is a library that is dynamically linked when the program is executed. Non-Patent Document 1 describes such a DLL.

  In recent years, the use of program execution environments by virtual machines has become widespread. Typical examples include Java (registered trademark) virtual machines by Sun Microsystems, and CLR (Common Language Runtime) by Microsoft. A virtual machine is often implemented as one application program that runs on an OS. In this case, the OS allocates one process for each execution environment of the virtual machine. In a virtual machine, a plurality of application programs may be executed in the execution environment (one process) of one virtual machine.

John R. Levin, "linkers & loaders", Morgan Kaufmann Pub, 2000.

  When a DLL is taken into a process, a DLL load image (a load module loaded in a memory) is created for each process. Therefore, a global variable area included in the DLL is also created for each process. When one application program is executed in one process, a global variable is created for each application program. Therefore, even if a certain application program changes the value of the global variable, it can be used for processing other application programs. Has no effect.

  On the other hand, in an environment where a plurality of application programs are executed in one process such as a virtual machine, one DLL is read for each process, and one global variable area is created. That is, the global variable area is shared among a plurality of application programs executed in the process. In such an execution environment, when a DLL holds state information (status) in a global variable or the like, a change in the state information of a DLL by a certain application program affects the processing of another application program being executed in the same process. Will be given. That is, processing differs between when one application program is executed by one process and when a plurality of application programs are executed by one process.

  The present invention has been made in view of the above circumstances, and an object of the present invention is to execute processing of a predetermined application program when calling a DLL in an environment in which a plurality of application programs are executed in one process. It is to prevent the application program processing from being affected.

  In order to solve the above-described problem, in the present invention, a wrapper library for creating a load image of a dynamic link library that differs for each application program is generated. Also, the calling code of the dynamic link library in the application program is changed so as to call the wrapper library.

  For example, in the dynamic link library call code generation method for calling the dynamic link library, the information processing apparatus includes an arithmetic processing unit and a storage unit. Then, the arithmetic processing unit creates a load image of the dynamic link library for each application program based on the first read step of reading the dynamic link library stored in the storage unit and the function described in the read dynamic link library. A generation step for generating a wrapper library to be created, a second reading step for reading an application program stored in the storage unit, and a code for calling the dynamic link library in the application program is specified, and the calling code for the dynamic link library is And a change step for changing the code to call the generated wrapper library.

  In the present invention, when a DLL is called in an environment where a plurality of application programs are executed in one process, it is possible to prevent the processing of a predetermined application program from affecting the processing of other application programs.

  Embodiments of the present invention will be described below.

  FIG. 1 is a schematic diagram of a wrapper library generation apparatus 1 to which an embodiment of the present invention is applied. The wrapper library generation device 1 of this embodiment generates a dummy DLL (that is, a wrapper library) that secures a DLL area and performs initialization and rearrangement for each program operating on a virtual machine.

  The wrapper library generation device 1 includes a wrapper code generation unit 10, a call code generation unit 20, and a storage unit 30, as illustrated. The wrapper code generation unit 10 reads the DLL 31 stored in the storage unit 30 and generates a wrapper library 34. The wrapper code generation unit 10 includes a DLL input unit 11, a code generation unit 12, and an output unit 13.

  The DLL input unit 11 reads the DLL 31 from the storage unit 30 and analyzes it to obtain a list of external function symbols. Then, the DLL input unit 11 records each acquired external function symbol in the symbol management table 32. The external function symbol is a function of the DLL 31 that can be used (callable) by the calling program 35. The symbol management table 32 will be described later.

  The code generator 12 creates a wrapper code (not shown) for each external function symbol registered in the symbol management table 33. The wrapper code will be described later.

  The output unit 13 generates a wrapper library 34 based on the symbol management table 32 and the wrapper code generated by the code generation unit 12 and stores it in the storage unit 30. In addition, the output unit 13 stores the name of the DLL 31 and the name of the wrapper library 34 generated from the DLL 31 in the name correspondence table 33. The wrapper library 34 and the name correspondence table 33 will be described later.

  The call code generation unit 20 reads the call program 35 from the storage unit 30 and analyzes it. Then, the calling code generation unit 20 specifies a part of the code (source code) calling the DLL 31 in the calling program 35. Then, the calling code generation unit 20 changes the specified code portion so as to call the wrapper library 34 instead of the DLL 31. Then, the calling code generation unit 20 stores the changed calling program 36 in the storage unit 30. The call code generation unit 20 refers to the name correspondence table 33 and acquires the name of the wrapper library 34 to be called.

  The storage unit 30 stores a DLL 31, a symbol management table 32, a name correspondence table 33, a wrapper library 34, a calling program 35, and a changed calling program 36.

  The DLL 31 is a library that is dynamically linked (called) when the program is executed. When the calling program 35 is executed, the OS loads the DLL into the address space (process) of the program.

  FIG. 2 is a diagram illustrating an example of the DLL 31. The DLL 31 includes a header section 21, a text section 22, a data section 23, and an export symbol section 24. In the header section 21, the sizes and start addresses of the other sections 22, 23, and 24 are set.

  In the text section 22, at least one function is defined. The illustrated text section 22 includes a function “func_A” 221, a function “func_B” 222, and a function “func_C” 223. In the data section 23, a data area such as a global variable used by each function defined in the text section 22 is defined. In the export symbol section 24, the name of at least one external function symbol disclosed to the outside and the virtual relative address of the symbol are set.

  The symbol management table 32 is a table for managing external function symbols defined in the DLL 31.

  FIG. 3 is a diagram showing an example of the symbol management table 32. The symbol management table 32 includes a symbol number 321, a symbol name 322, an address 323, and a wrapper code area pointer 324 for each external function symbol.

  The symbol number 321 is identification information for identifying the external function symbol. The symbol name 332 is a name of the external function symbol. In the illustrated example, the names of external function symbols (“func_A”, “func_B”) set in the export symbol section 24 of the DLL 31 shown in FIG. 2 are set. The DLL input unit 11 sets a symbol number 321 and a symbol name 322.

  In the address 323, the position (address) in the text section of the wrapper code generated for each external function symbol in the generated wrapper library 34 is set.

  In the wrapper code area pointer 324, pointer information (storage location information) indicating where the wrapper code generated for each external function symbol is stored in the storage unit 30 is set. The code generation unit 12 sets the address 323 and the wrapper code area pointer 324.

  The name correspondence table 33 is a table in which the DLL 31 is associated with the wrapper library 34 generated from the DLL.

  FIG. 4 is a diagram showing an example of the name correspondence table 33. The name correspondence table 33 includes a DLL name 331 that is the name of the DLL 31 and a name 332 of the wrapper library 34 corresponding to the DLL 31. In the present embodiment, the wrapper library name 332 is a name in which “W” is added to the head of the DLL name 331.

  The calling program 35 is an application program that operates on the virtual machine, and is a program that calls the DLL 31 when the program is executed. The software configuration of the virtual machine on which the calling program operates will be described later.

  The post-change call program 36 is a program after the call code generation unit 20 changes the call program 35. The wrapper library 34 is a dummy DLL that secures an area for the DLL 31, and performs initialization and rearrangement for each calling program 35 (the calling program 36 after the change). The calling program 35, the changed calling program 36, and the wrapper library 34 will be described later.

  The wrapper library generation device 1 described above includes, for example, a CPU 901, a memory 902, an external storage device 903 such as an HDD, an input device 904 such as a keyboard and a mouse, an output such as a monitor and a printer, as shown in FIG. A general-purpose computer system including a device 905, a communication control device 906 for connecting to a network, and a bus 907 for connecting these devices can be used. In this computer system, when the CPU 901 executes a predetermined program loaded on the memory 902, each function of the wrapper library generation device 1 is realized. That is, each function of the wrapper library generation device 1 is realized by the CPU 901 of the wrapper library generation device 1 executing a program for the wrapper library generation device 1. In this case, the memory 902 of the wrapper library generation device 1 or the external storage device 903 is used for the storage unit 30 of the wrapper library generation device 1.

  Next, the software configuration of the virtual machine will be described. The virtual machine is one process (unit of job) of the OS. The virtual machine can execute a plurality of application programs in the process. The application program is the calling program 35 (or the changed calling program 36) in the present embodiment.

  FIG. 13 is a diagram illustrating an example of a software configuration of a virtual machine. As illustrated, the virtual machine 62 operates on the OS 61. In addition, at least one calling program 35 is executed on the virtual machine 62. The virtual machine 62 includes a memory management unit 621, a type management unit 622, and an execution management unit 623. The memory management unit 621 manages the memory used on the virtual machine. The type management unit 622 manages classes in object-oriented programming. The execution management unit 623 manages the execution of each program operating on the virtual machine.

  Next, processing of the wrapper code generation unit 10 of the wrapper library generation device 1 will be described.

  FIG. 6 shows a processing flow of the DLL input unit 11 and the code generation unit 12 of the wrapper code generation unit 10. First, the DLL input unit 11 reads the DLL 31 stored in advance in the storage unit 30, and obtains a list of external function symbols described in the export symbol section 24 (see FIG. 2) of the DLL 31 (S61). Then, the DLL input unit 11 sequentially registers the acquired name of the external function symbol in the symbol name 322 of the symbol management table 32 (S62). The DLL input unit 11 sets serial numbers in order from “1” to each symbol number 321 when setting the external function symbol name to the symbol name 322.

  Then, the code generation unit 12 reads each record of the symbol management table 32 in which the symbol number 321 and the symbol name 322 are set, in ascending order of the symbol number 321 (S63). The code generation unit 12 generates a wrapper code that is a component of the wrapper library 34 according to a predetermined algorithm (or a predetermined template) for each read record (that is, for each external function symbol). Hereinafter, the wrapper code generation processing will be described.

  The code generation unit 12 creates a DLL load image selection code (S64). Then, the code generation unit 12 creates an address calculation code for the calling function (S65). Then, the code generation unit 12 generates a function call code that calls a function using the address calculated by the address calculation code (S66). From S64 to S66, the code generation unit 12 generates a wrapper code and stores it in the storage unit 30. The processing of the wrapper code will be described later.

  Then, the code generation unit 12 sets the start address (storage location) of the wrapper code stored in the storage unit 30 in the wrapper code area pointer 324 of the record in the symbol management table 32 (S67).

  Then, the code generation unit 12 sets the address 323 of the symbol management table 32. That is, the code generation unit 12 determines whether or not the record read in S63 is the first record (the record whose symbol number 321 is “1”) (S68). In the case of the first record (S68: YES), the code generation unit 12 sets “00000000” to the address 323 of the first record (S69).

  On the other hand, if it is not the first record (S68: NO), the code generation unit 12 reads the value set in the address 323 of the record immediately before the record. Then, the code generation unit 12 adds the size of the parallax code of the immediately preceding record generated in S64 to S66 to the value of the address 323 of the immediately preceding record. Then, the code generation unit 12 sets the added value to the address 323 of the record (S70). In the present embodiment, the immediately preceding record is a record having a record number 321 obtained by subtracting “1” from the record number 321 of the record.

  Then, the code generation unit 12 reads the symbol management table 32 and determines whether or not there is an unprocessed record (a record for which no wrapper code is generated) (S71). If there is an unprocessed record (S71: YES), the code generation unit 12 returns to S63 and processes the next record in the symbol management table 32. On the other hand, when there is no unprocessed record (S71: NO), processing of the output unit 13 described later is performed.

  The processing of FIG. 6 described above will be specifically described by taking the DLL 31 shown in FIG. 2 as an example.

  First, the DLL input unit 11 acquires a list of external function symbols of the DLL 31 and creates the symbol management table 32 shown in FIG. 3 (S61, S62). At this time, the address 323 and the wrapper code area pointer 324 are blank.

  Then, the code generation unit 12 generates a wrapper code of the function func_A of the first record in the symbol management table 32 and stores it in the storage unit 30 (S63 to S66). Then, the code generation unit 12 sets the wrapper code storage location start address) in the wrapper code area pointer 324 of the function func_A (S67). Since “function func_A” currently being processed is the first record (S68: YES), the code generation unit 12 sets “00000000” in the address 323 of the symbol management table 32 (S69).

  Next, the code generation unit 12 reads the symbol management table 32 and performs processing of the function func_B which is an unprocessed record (S71: YES). Similar to the processing of the function func_A, the code generation unit 12 generates a wrapper code and sets a storage location in the wrapper code area pointer (S63 to S67). Since the record of the function func_B is not the first record (S68: NO), the code generator 12 sets the wrapper “of the function func_A generated to the value“ 00000000 ”of the address 323 of the record (function func_A) one level higher. A value “00000100” obtained by adding the code size (here, “00000100” (hexadecimal)) is set in the address 323. Then, the code generation unit 12 reads the symbol management table 32 and terminates the process illustrated in FIG. 6 because there is no next (unprocessed) record.

  Next, processing of the output unit 13 of the wrapper code generation unit 10 will be described.

  FIG. 7 shows a processing flow of the output unit 13 of the wrapper code generation unit 10. The output unit 13 outputs the name correspondence table 33 and the wrapper library 34 based on the symbol management table 32 after the processing of FIG.

  First, the output unit 13 outputs the name correspondence table 33 (see FIG. 4) (S71). That is, the output unit 13 sets the name of the DLL 31 read in S61 of FIG. 6 and the wrapper library name generated from the DLL 31 in the name correspondence table 33. In the present embodiment, as shown in FIG. 4, the name (Wsub.dll) with “W” added to the head of the DLL 31 name (sub.dll) is used as the name of the wrapper library.

  Then, the output unit 13 calculates the size of each section of the wrapper library prior to the output of the wrapper library (S72). That is, the output unit 13 calculates the sizes of the text section, data section, and export symbol section. The size of the text section is the sum of the sizes of the wrapper codes of all the external function symbols registered in the symbol management table 32.

  The size of the data section is the total data size of the global variable area used by each wrapper code. In the present embodiment, it is assumed that 36 (20 in hexadecimal) bytes are required for managing the load image of the DLL 31. The load image is a load module loaded in the memory.

  The size of the export symbol section is a size necessary for writing the external function symbol name and the address of the external function symbol. In this embodiment, it is assumed that 64 (hexadecimal 40) bytes are required.

  And the output part 13 outputs the wrapper library 34 as shown in FIG. 8, for example by the following processes.

  First, the output unit 13 outputs a header section (FIG. 8: 81) (S73). That is, the output unit 13 outputs a header section describing the size of each section calculated in S72.

  Then, the output unit 13 outputs the text section (FIG. 8: 82) (S74). That is, the output unit 13 sequentially reads each wrapper code pointed by the wrapper code area pointer 324 of the symbol management table 32 from the storage unit 30 and outputs it as a text section. In the illustrated example, two wrapper codes 821 and 822 of a function func_A and a function func_B are described in the text section.

  Then, the output unit 13 outputs the data section (FIG. 8: 83) (S75). The size of the data section is a value unique to the wrapper code, and is 36 (hexadecimal 20) bytes described above in the illustrated example.

  Then, the output unit 13 outputs the export symbol section (FIG. 8: 84) (S76). That is, the output unit 13 sequentially outputs the data set in the symbol name 322 and the address 323 of the symbol management table 32 to the export symbol section. Then, the output unit 13 generates a wrapper library 34 as shown in FIG. 8 by outputting each section, and stores it in the storage unit 30 (S77).

  Next, processing of the calling code generation unit 20 of the wrapper library generation device 1 will be described.

  FIG. 9 is a processing flow of the calling code generation unit 20. First, the calling code generation unit 20 reads and analyzes the calling program 35 stored in the storage unit 30 (S91). Then, the call code generation unit 20 identifies and corrects the external declaration for the call of the DLL function in the call program 35 (S92). That is, the call code generation unit 20 changes the code (description) that calls the DLL 31 so as to call the wrapper library 34. Then, the code generation unit 20 adds one argument that is an identifier of the calling program 35. The call code generation unit 20 refers to the name correspondence table 33 and acquires the name of the wrapper library whose call destination is to be changed.

  Then, the call code generation unit 20 generates a definition of the identifier acquisition function and adds it to a predetermined part of the call program 35 (S93). The identifier acquisition function is a function that returns an identifier (identification information) for identifying the calling program 35. For example, when the execution environment in which the calling program 35 operates provides an identifier, the identifier can be used.

  Further, for example, the identifier can occupy a different memory area if the calling program is different, and an address of a variable indicating the same memory area can be used whenever the calling program is the same.

  Then, the call code generation unit 20 specifies a call code (for example, a call statement) of the function of the DLL 31 from the call program 35. Then, the call code generation unit 20 adds the call code (for example, call statement) of the identifier acquisition function generated in S93 immediately before the identified call code (S94). Then, the calling code generation unit 20 outputs the changed calling program 36 changed from S92 to S94, and stores it in the storage unit 30 (S95).

  Next, the calling program 35 and the calling program 36 after the change in which the processing shown in FIG.

  FIG. 10 shows an example of the calling program 35. The call program 35 shown in the figure has a function call method 10a for calling a function func_A included in a DLL and an external declaration 10b for the function func_A.

  FIG. 11 shows an example of the calling program 36 after the change. The call program 35 shown in the figure has a function call method 11a for calling the function func_A, an external declaration 11b for func_A, and an identifier acquisition function 11c.

  The call code generation unit 20 changes the function func_A to call the wrapper library 111 in the external declaration (FIG. 11: 11b). In addition, the call code generation unit 20 adds one argument 112 that is an identifier of the call program 35 in the external declaration of the function func_A. In the illustrated example, the argument to be added is a 32-bit integer type.

  In addition, the call code generation unit 20 generates an identifier acquisition function 11c. In addition, in the function call method 11a, the call code generation unit 20 adds a Call statement 113 that calls the identifier acquisition function 11c immediately before the call code of the function func_A. As a result, the changed calling program 36 uses the identifier of the program acquired by calling the identifier acquisition function 11c as the value of the argument added to the function func_A.

  The wrapper library 34 and the changed calling program 36 are generated by the processing of the wrapper code generation unit 10 and the calling code generation unit 20 described above. The changed calling program 36 is executed on the virtual machine as shown in FIG. 13 and calls the generated wrapper library 34. The processing of the wrapper library 34 called when the changed calling program 36 is executed will be described below.

  FIG. 12 is a processing flow of the load image selection code. The load image selection code is a code generated in S64 of FIG. 6 in the wrapper code created for each external function symbol. The wrapper code has an interface in which an identifier for identifying the read program 36 after the change is added as an argument to the external function symbol to be wrapped.

  First, the load image selection code acquires the identifier of the read program 36 after the change that has been called, and determines whether a load image of the DLL 31 corresponding to the identifier has been created in the process (S121). Note that the identifier that created the load image of the DLL 31 is registered by the process of S124 described later.

  When the load image of the DLL 31 is not created (S121: NO), the load image selection code develops the DLL 31 in the memory (S122) and rearranges it (S123), thereby creating the load image. The load image selection code registers (stores) the created load image and the identifier in association with each other (S124).

  On the other hand, when the load image of the DLL 31 has already been created (121: YES), the load image selection code acquires the load image (S125). Note that the deployment of the DLL 31 to the memory (S122) and the rearrangement (S123) are described in detail in Non-Patent Document 1.

  Next, the address calculation code of the calling function generated in S65 of FIG. 6 refers to the export symbol section (see FIG. 2) of DLL 31, and acquires the virtual relative address of the external function symbol of the wrapper code. Then, an actual function address is calculated from the acquired virtual relative address and the head address of the load image.

  The function call code generated in S66 of FIG. 6 calls a function in the load image of the DLL 31 using the actual function address calculated by the address calculation code.

  The embodiment of the present invention has been described above.

  In the present embodiment, the wrapper library generation device 1 analyzes an existing DLL 31 and generates a wrapper library 34 for the DLL 31. Further, the wrapper library generating apparatus 1 generates a changed calling program 36 that calls the wrapper library 34 from the existing calling program 35. By executing the call program 36 after the change, the wrapper library 34 is called and a load image of the DLL 31 can be created for each call program 36 after the change.

  The wrapper library 34 creates a load image of the DLL 31 for each application program (calling program). Thereby, even in an execution environment in which a plurality of allocation programs operate in one process, it is possible to prevent the processing of a predetermined application program from affecting the processing of other application programs.

  In addition, the wrapper library generation device 1 automatically generates the wrapper library 34 and the changed calling program 36, so that even in an execution environment in which a plurality of application programs operate in one process, the resources (DLL 31,. The calling program 35) can be used effectively.

  In addition, this invention is not limited to said embodiment, Many deformation | transformation are possible within the range of the summary.

  For example, in the above embodiment, the wrapper library generation device 1 generates the wrapper library 34 and the changed calling program 36 in advance. However, the present invention may dynamically generate the wrapper library 34 and the changed calling program 36 when the calling program 35 is executed. In this case, each function of the wrapper library generation device 1 shown in FIG. 1 is implemented in the execution management unit 623 of the virtual machine shown in FIG. Below, the process of the execution management part 623 is demonstrated.

  FIG. 14 shows a processing flow of the execution management unit 623. First, the execution management unit 623 determines whether the current instruction to be processed is a function call defined in the DLL 31 (S141). If it is not a call to the DLL 31 (S141: NO), the execution management unit 623 executes a general code generation process (S145).

  On the other hand, when the DLL 31 is called (S141: YES), the execution management unit 623 receives a user instruction input by the input unit 904, a runtime option, a file, or the like, and generates a wrapper code. Is determined (S142). When a wrapper code generation instruction is received (S142: YES), the execution management unit 623 generates an identifier acquisition function call code (S143). Note that the process of S143 is the same as the process in which the call code generation unit 20 generates the identifier acquisition function code in S93 of FIG. Then, the execution management unit 623 generates a wrapper code (S144). Note that the processing in S144 is the same as the processing in which the code generation unit 12 generates the wrapper code in S64 to S66 in FIG. On the other hand, when a wrapper code generation instruction is not accepted (S142: NO), the execution management unit 623 performs a general code generation process (S145).

  Note that it is possible to omit all of the DLL 31 as a wrap target by omitting the process of whether or not to generate the wrapper code in S142. Further, before the execution of the calling program 35, the wrapper code generation unit 10 can create the wrapper library 34 in advance, and the wrapper code generation process of S144 can be omitted.

  In the above embodiment, a load image of the entire DLL is created for each program that calls the DLL. However, the present invention may create a part of the load image for each program that calls the DLL.

  That is, when a part of the DLL area is configured to be sharable among a plurality of programs operating in one process, the wrapper library creates a load image of only the area that cannot be shared between programs for each program. It is good as well.

  FIG. 15 is a processing flow of the load image selection code. This process corresponds to the process flow (see FIG. 12) of the load image selection code in the above embodiment. Here, the text section 22 of the DLL 31 is an area that can be shared between programs (hereinafter, “shared part”), and the data section 23 is an area that cannot be shared between programs (hereinafter, “unshared part”). ).

  First, the load image selection code determines whether or not a load image of the text section 22 (shared part) has been created (S151). When the load image of the text section 22 has been created (S151: YES), the load image selection code acquires the load image (S152). On the other hand, when the load image of the text section 22 has not been created (S151: NO), the load image selection code develops the text section in the memory to create a load image, and records the load image (S153).

  Then, the load image selection code obtains the identifier of the read program 36 after the change, and determines whether or not the load image of the non-shared part corresponding to the identifier has been created in the process (S154). If it has been created (S154: YES), the load image selection code acquires the load image (S155). On the other hand, when the load image of the non-shared part has not been created (S154: NO), the load image selection code expands the non-shared part into the memory (S156) and rearranges it (S157). The load image selection code registers (stores) the created load image and the identifier in association with each other (S158). Then, the load image selection code loads the head table of the address table into the base register for indirect reference (S159).

  Next, the processing of the load image selection code when the text section 22 of the DLL 31 is a non-shared part will be described.

  FIG. 16 is a processing flow of the load image selection code when the text section is a non-shared part. The processing flow shown in FIG. 16 differs from the processing flow shown in FIG. 15 in the following points. That is, the point that the creation of the data address table (S163) is added is different from the processing flow shown in FIG. Further, in the process of S164 corresponding to S153 in FIG. 15, not only the text section is expanded in the memory, but also the reference portion of the data in the text section is modified to indirect reference using the data address table. As a result, the text section can be corrected to position independent code, and the code can be shared among a plurality of programs operating in the process. The address table created in S163 is a non-shared part. Therefore, in S168, the data address table is expanded in the memory, and the address table is rearranged.

FIG. 1 is a schematic configuration diagram of a wrapper library generation apparatus to which an embodiment of the present invention is applied. FIG. 2 is a diagram illustrating an example of a dynamic link library. FIG. 3 is a diagram illustrating an example of the symbol management table. FIG. 4 is a diagram illustrating an example of the name correspondence table. FIG. 5 is a diagram illustrating a hardware configuration of the wrapper library generation device. FIG. 6 is a diagram illustrating a processing flow of the DLL input unit and the code generation unit. FIG. 7 is a diagram illustrating a processing flow of the output unit. FIG. 8 is a diagram illustrating an example of a wrapper library. FIG. 9 is a diagram illustrating a processing flow of the calling code generation unit. FIG. 10 is a diagram illustrating an example of a calling program. FIG. 11 is a diagram illustrating an example of the calling program after the change. FIG. 12 is a diagram illustrating a processing flow of the load image selection code. FIG. 13 is a diagram illustrating an example of a software configuration of a virtual machine. FIG. 14 is a diagram showing a processing flow when a wrapper code is generated during program execution. FIG. 15 is a diagram showing a processing flow of the first load image selection code when a part of the load image is created. FIG. 16 is a diagram showing a processing flow of the second load image selection code when a part of the load image is created.

Explanation of symbols

  1: wrapper library generation device, 10: wrapper code generation unit, 11: DLL input unit, 12: code generation unit, 13: output unit, 20: call code generation unit, 30: storage unit, 31: dynamic link library, 32 : Symbol management table, 33: Name correspondence table, 34: Wrapper library, 35: Call program, 36: Call program after change

Claims (8)

A dynamic link library call code generation method for calling a dynamic link library,
The information processing apparatus includes an arithmetic processing unit and a storage unit,
The arithmetic processing unit includes:
A first reading step of reading the dynamic link library stored in the storage unit;
A generation step of generating a wrapper library for creating a load image of the dynamic link library for each application program based on the function described in the read dynamic link library;
A second reading step of reading the application program stored in the storage unit;
In the application program, the dynamic link library is characterized in that: a code for calling the dynamic link library is specified, and a change step for changing the call code of the dynamic link library to a code for calling the generated wrapper library is performed. Call code generation method. The dynamic link library call code generation method according to claim 1,
The wrapper library generated in the generating step is
A dynamic link library that identifies an area that cannot be shared among the application programs from each area of the dynamic link library and creates a load image of only the non-shareable area for each application program Call code generation method. The dynamic link library call code generation method according to claim 1,
The wrapper library generated in the generating step is
If the text description part of the dynamic link library is not sharable between the applications, the code of the text description part is modified to a code that can be shared between the applications, and is shared between the applications other than the text description part. A dynamic link library call code generation method, wherein a load image of only an impossible area is created for each application program. The dynamic link library call code generation method according to claim 1,
The wrapper library generated in the generating step is
A dynamic link library call code generation method, wherein the load image is created for each address of a memory area used by the application program. The dynamic link library call code generation method according to claim 1,
The arithmetic processing unit includes:
The execution step of reading and executing the application program from the storage unit is further performed,
A dynamic link library call code generation method comprising: performing the first read step, the generation step, and the change step when executing the execution step. The dynamic link library call code generation method according to claim 5,
The arithmetic processing unit includes:
Further performing a receiving step of receiving an instruction to execute the generating step;
Performing the generation step when the execution instruction is received in the execution step;
A dynamic link library call code generation method characterized by the above. An information processing device is a call code generation program for generating a call code of a dynamic link library,
The information processing apparatus includes an arithmetic processing unit and a storage unit,
In the arithmetic processing unit,
A first reading step of reading the dynamic link library stored in the storage unit;
A generation step of generating a wrapper library for creating a load image of the dynamic link library for each application program based on the function described in the read dynamic link library;
A second reading step of reading the application program stored in the storage unit; and
In the application program, a code for calling the dynamic link library is specified, and a change step for changing the call code of the dynamic link library to a code for calling the generated wrapper library is executed. program. A dynamic link library call code generation device for calling a dynamic link library,
Storage means for storing the dynamic link library and an allocation program for calling the dynamic link library;
A generation step of generating a wrapper library for creating a load image of the dynamic link library for each application program based on a function described in the dynamic link library;
A change unit that reads the application program from the storage unit, identifies a code that calls the dynamic link library in the application program, and changes the call code of the identified dynamic link library to a code that calls the generated wrapper library; And a dynamic link library call code generation device.

Images