JP2006048431A - Dynamic link library processor - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a dynamic link library processor capable of increasing the efficiency of execution. <P>SOLUTION: A virtual address layout plan indicating positions on a virtual address where respective dynamic link libraries are positioned is created, and the dynamic link libraries are relocated in accordance with the virtual address layout plan. When the dynamic link libraries are loaded, the dynamic link libraries are loaded to the positions indicated on the virtual address layout plan. This enables the use of position dependent codes with high efficiency of execution to be used as the codes of the dynamic link libraries and enables dynamic codes to be shared among a plurality of processes. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a dynamic link library processing apparatus that links and loads an executable program and a dynamic link library.

  There are many processes common to a plurality of programs in a computer system. Developing processes common to multiple programs for each program is redundant and inefficient. Therefore, processes common to a plurality of programs are developed together as a library.

  Development is progressed in such a way that a library is developed once, and main parts of a plurality of programs using the library are developed, and common processing is not duplicated.

  Generally, a library is constructed by being encapsulated separately from the main part of the program. The main part of the program and the library are constructed separately, and finally, these are linked to generate an executable program.

  Linking is a process of connecting one part and another part in a program. Link processing is performed by the linker. In the link process, for example, a function call is performed to connect the caller and the callee.

  For example, consider a case where a function in a library is called from the main part of a program. In general, in a function call, a machine language instruction for jumping from a caller to a callee is used. Therefore, the address where the callee function is written is written in the caller code. The linker first obtains the address of a function (call destination) in the library. Next, this address is written in the program body (caller). As a result, the caller and the callee are appropriately linked, and the function in the library can be called from the main part of the program. In addition, the work of resolving the address and rewriting the code or the like in this way is called relocation (relocation).

  There are two main methods for linking libraries. One is a static link method and the other is a dynamic link method.

  The static link method is a method of making a copy of a library code and linking it to the main part of the program when an executable program is constructed. The library development itself does not overlap, but the code of the constructed library is copied to multiple programs. In the static linking method, the executable program can be executed alone because the program body and the library are linked when the executable program is constructed.

  In the static linking method, the code of the same library is copied to a plurality of programs, so there is a possibility that many copies of one code are made in the computer system. In the case of a computer system that uses a virtual memory mechanism, the same code may be duplicated on the memory. For this reason, in recent computer systems, the dynamic link method described below is often adopted.

  In the dynamic linking method, the library code is not included in the main part of the executable program, and the library is read and linked when the program is executed. Since the executable program that is the main part of the program contains no library code, the main part of the program initially contains an unresolved address reference. Therefore, an executable program may not be executed alone. When the executable program is started or when information in the library is required, the program body and the library are linked.

  Patent Document 1 discloses a method using an application binary interface such as GOT (Global Offset Table) as a dynamic link method using ELF which is an industry standard format. The GOT is a table of addresses used when the main part of the program and the library refer to addresses of different libraries.

  For example, consider a case where a program using a certain library X and another library Y is executed. At this time, there is a function f in the library Y, and this function is used from the library X. When the program is executed, the library used by the program is loaded, and the GOT of each library is initialized. An entry for f is prepared in the GOT of the library X. In the entry for f, the address of the function f is stored. That is, the address of the function f in the library Y is stored in the GOT of the library X. When the function f is called from the library X, the GOT is examined to obtain the address of the function f, and the jump is made to the obtained address.

  When a library refers to an address outside the library, it does not refer to the address directly, but refers to it via GOT. The library code itself does not change wherever the address is outside the library. Therefore, when GOT is used, a position independent code can be generated. The position-independent code is a code in which the code of the program may be arranged at any position in the address space, that is, a position-independent code. The position-dependent information is collected in the GOT, and the GOT is initialized when the library is loaded.

  When the code of a library is position-independent, this library may be placed at any position in the address space. Therefore, the library code need not be rewritten when this library is loaded.

  Since the library code cannot be rewritten, the contents of the code are unchanged. Therefore, in a multi-process environment using a virtual memory mechanism, when a plurality of programs use the same library, it is possible to share the code of this library. For example, assume that there are a plurality of different programs each operating in an independent virtual address space. Suppose these programs load the same library at different locations. The library code is position-independent, and the code is unchanged regardless of where it is loaded. Therefore, these different programs refer to the exact same code. Therefore, these programs can share the library code.

If the code of the library is shared, it is not necessary to load the same library more than once, and it is not necessary to duplicate the code of the library in the memory. For this reason, the memory use efficiency is good.
JP-A-8-179947

  In the method using GOT, the library code can be position-independent. As a result, the library code can be shared even between programs operating in different virtual address spaces.

  However, the method using GOT has a problem in that when referring to an address outside the library, the address of the reference destination is not directly accessed, but indirect reference is made via GOT. For example, consider the case of a function call. In the case of direct address reference, a function call can be realized simply by jumping directly to a reference destination address written in advance in the code. On the other hand, in the case of indirect address reference, it is necessary to obtain a reference destination address from the GOT, store it in a register, and jump to the address indicated by the register. Indirect referencing has the problem that the number of processing instructions increases compared to direct referencing, leading to a decrease in execution efficiency.

  The present invention has been made to solve the above-described problems, and an object of the present invention is to provide a dynamic link library processing apparatus capable of improving execution efficiency.

  In the present invention, in order to solve the above-mentioned problem, a virtual address arrangement plan indicating which dynamic link library is loaded at which position in the virtual address space is created, and the dynamic address arrangement plan is dynamically generated based on the virtual address arrangement plan. Relocate the link library so that it is loaded at the location indicated in the virtual address placement plan when the dynamic link library is loaded.

  The location of each dynamic link library in the virtual address space is determined by the placement plan of the virtual address. The address where each dynamic link library is arranged is determined so as not to overlap.

  Furthermore, according to this virtual address allocation plan, each dynamic link library is relocated before program execution. For example, consider a case where a certain dynamic link library X calls a function f in another dynamic link library Y. Since the position where the dynamic link library Y is arranged in the virtual address is decided by the virtual address arrangement plan, the address where the function f in the dynamic link library Y is arranged is also decided. The code that calls the function f from the dynamic link library X is relocated so as to jump directly to the address of the function f.

  When a dynamic link library or executable program is loaded into memory by the loader, if the dynamic link library or executable program to be loaded is already loaded in a different virtual address space, the code is shared. Otherwise, the dynamic link library or executable program is placed at the location determined by the virtual address placement plan.

  When the dynamic link library processing apparatus according to the present invention is used, a library code can be shared by a plurality of virtual address spaces in a multi-process environment using a virtual memory mechanism, and the code depends on the position of the virtual address. Can be used. Since the library code is shared, memory use efficiency is good. In addition, since the code depends on the address position, direct reference can be used for address reference, and execution efficiency is improved.

  For example, even if there is location-dependent code that directly references the data of another dynamic link library in one dynamic link library, the address where each dynamic link library is allocated depends on the virtual address allocation plan. It has been decided. For this reason, the address of the reference destination is known before executing the program, and address resolution is performed in advance. Since the code of each dynamic link library has already been relocated, there is no need to rewrite the code at runtime. For this reason, the code of the dynamic link library can be shared in different virtual address spaces.

  Embodiments of the present invention will be described with reference to the drawings.

(Embodiment 1)
FIG. 1 is a diagram showing a configuration of a dynamic link library processing apparatus according to Embodiment 1 of the present invention.

  The secondary storage device 101 is a device that stores programs and data, and stores a dynamic link library 102, an executable program 103, and a virtual address arrangement plan 104. The secondary storage device may store other information such as user data in addition to these.

  The dynamic link library 102 is a library that includes code and data used when a program is executed, and one or more dynamic link libraries 102 exist. A detailed description of the dynamic link library will be described later with reference to FIG.

  The executable program 103 is a main body part of each program excluding the library, and there is one or more executable programs 103. A detailed description of the executable program will be described later with reference to FIG.

  The virtual address arrangement plan 104 is a plan indicating where each dynamic link library 102 or executable program 103 is arranged on a virtual address when the program is executed. A detailed description of the virtual address arrangement plan 104 will be described later with reference to FIG.

  The virtual address arrangement plan generation unit 105 receives one or a plurality of executable programs 103 and the dynamic link library 102 and generates a virtual address arrangement plan 104. A detailed description of the process of generating the virtual address arrangement plan will be described later with reference to FIG.

  The arrangement plan corresponding relocator 106 receives one or a plurality of executable programs 103 and dynamic link libraries 102, and each of the executable programs and dynamic link libraries is generated by the virtual address arrangement plan generation unit 105. Relocate based on the placement plan 104. A detailed description of the relocation process using the virtual address arrangement plan will be described later with reference to FIG.

  The placement plan support loader 107 receives the executable program 103 and the dynamic link library 102 relocated by the placement plan support relocator 106, and the same executable program or dynamic link library as the load target executable program or dynamic link library is received. If it is already loaded, the code is shared. Otherwise, the executable program or the dynamic link library to be loaded is loaded at a position on the virtual address according to the virtual address arrangement plan 104. A detailed description of the load process according to the virtual address arrangement plan will be described later with reference to FIG.

  FIG. 2 is a diagram showing information included in one executable program or dynamic link library. Hereinafter, the executable program and the dynamic link library are collectively referred to as a program binary.

  The header information 201 includes information on the entire program binary. The information included includes a flag indicating whether the program binary is an executable program or a dynamic link library, file format version information, endian information to be used, supported architecture, included sections and their locations, Dynamic link library to be used.

  Text section 202 contains the text of the program binary. A text is a sequence of machine language instructions executed by the CPU. The CPU reads and executes the written instructions one by one according to the text arranged on the memory at the time of execution. In the present embodiment, a description will be given of a case of position-dependent code text with high execution efficiency. The text may be a position independent code.

  The data section 203 includes data used by the program binary. For example, suppose that there is a global variable in the source code that is the source of the program binary. Also assume that an initial value is set for this global variable. The initial value of this global variable is stored in the data section. When the program binary is loaded, the initial value of the global variable is read from the data section and the global variable is initialized.

  The bss section 204 includes initialization-free data used by the program binary. The data section 203 includes data for a global variable that requires an initial value. When the data section 203 is loaded, the initial value is read from the data section 203 and the global variable is initialized. However, some global variables do not require explicit initialization. Global variables that do not require initialization are included in the bss section, and processing such as zero initialization is performed by the loader.

  The relocate information 205 includes unresolved reference information, which is information necessary for relocating the text section 202 and the data section 203 of the program binary. The unresolved reference information is composed of a set of address reference positions that remain unresolved and information of reference destination symbols. In the relocate information 205, there are as many unresolved reference information as the number of address references that remain unresolved.

  The symbol table 206 includes information on symbols that the program binary has. The symbol information is information indicating where the function or variable included in the source code that is the source of the program binary is located in the program binary. One symbol information consists of a set of a symbol character string and a position where a function or data corresponding to the symbol is arranged on a virtual address. The symbol table 206 includes as many symbols as the number included in the program binary. The symbol information may be expressed by a hash key representing a symbol instead of a symbol character string, or may be a pointer to a character string table including the symbol. Further, the symbol table 206 may hold not only all symbol information of the program binary but only symbol information necessary for processing.

  FIG. 3 is a diagram illustrating information on the relocate information 205 and the symbol table 206 using a specific example. 301 and 302 are separate dynamic link libraries. 303 and 304 are text sections of the dynamic link libraries 301 and 302, respectively. Reference numeral 305 denotes an unresolved address reference to the function f. Reference numeral 306 denotes the text of the function f. Reference numeral 307 denotes relocation information of the dynamic link library 301. Reference numeral 308 denotes one item of the relocate information 307, which is a set of the position 305 and the symbol f. Reference numeral 309 denotes a symbol table of the dynamic link library 302. 310 is one item of 309, and is a set consisting of the addresses of symbols f and 306.

  The dynamic link library 301 includes a reference to the function f, and the function f is included in the dynamic link library 302. When the dynamic link library 301 is constructed, it is not known where in the virtual address space the function f is placed, so that the reference to the function f is left unresolved. This is an unresolved reference 305. This unresolved information needs to be stored for later relocation processing, and this is one relocate information 308.

  The dynamic link library 302 includes a function f. In order for another library (for example, the dynamic link library 301) to refer to the function f, it is necessary to store f and its position, and this is the symbol information 310.

  FIG. 4 is an example showing the contents of the virtual address arrangement plan 104. 401 is a table showing the contents of the virtual address arrangement plan 104. In this example, there are a total of six program binaries. There are three executable programs P # 1, P # 2, and P # 3, and three dynamic link libraries L # 1, L # 2, and L # 3.

  Here, the executable program P # 1 uses the dynamic link library L # 1 and the dynamic link library L # 2, and the executable program P # 2 is the dynamic link library L # 1 and the dynamic link library L. Assume that # 3 is used and the executable program P # 3 uses the dynamic link library L # 1, the dynamic link library L # 2, and the dynamic link library L # 3.

  In the virtual address arrangement plan, the start address and end address of each program binary are determined. The start address and end address of the executable program P # 1 are a # 1 and a # 2, respectively. The start address and end address of the executable program P # 2 are a # 1 and a # 3, respectively. The start address and end address of the executable program P # 3 are a # 1 and a # 4, respectively. The start address and end address of the dynamic link library L # 1 are a # 4 and a # 5, respectively. The start address and end address of the dynamic link library L # 2 are a # 5 and a # 6, respectively. The start address and end address of the dynamic link library L # 3 are a # 6 and a # 7, respectively.

  In the virtual address arrangement plan, a plurality of executable programs may be arranged in duplicate at the same virtual address position. Since a plurality of executable programs are not loaded on the same virtual address space, there is no problem even if a plurality of executable programs are arranged at the same virtual address position on the virtual address arrangement plan. If all the executable programs are arranged at the same virtual address position on the virtual address arrangement plan, the virtual address space area is not consumed more than necessary even if there are a large number of executable programs. Note that virtual address areas of a plurality of executable programs may be arranged so as not to overlap.

  The virtual link area of the dynamic link library is set not to overlap. In other words, other program binaries are not arranged in the virtual address area where one dynamic link library is arranged. Since a plurality of dynamic link libraries may be used from one program, a plurality of dynamic link libraries may be loaded on the same virtual address space. When multiple dynamic link libraries are loaded on the same virtual address space, contention occurs if they are placed at the same virtual address location.

  FIG. 5 shows the arrangement of program binaries on virtual addresses when each executable program is executed according to the virtual address arrangement plan 401.

  Reference numeral 501 denotes a virtual address space when the executable program P # 1 is executed, and shows the arrangement of program binaries on the virtual address. The executable program P # 1 uses a dynamic link library L # 1 and a dynamic link library L # 2. According to the virtual address arrangement plan 401, the arrangement of the executable program P # 1 on the virtual address is from the address a # 1 to the address a # 2, and the start address and the end address of the dynamic link library L # 1 are respectively a # 4 and a # 5, and the start address and end address of the dynamic link library L # 2 are a # 5 and a # 6, respectively.

  Reference numeral 502 denotes a virtual address space when the executable program P # 2 is executed, and shows an arrangement of program binaries on the virtual address. The executable program P # 2 uses a dynamic link library L # 1 and a dynamic link library L # 3. According to the virtual address arrangement plan 401, the arrangement of the executable program P # 2 on the virtual address is from the address a # 1 to the address a # 3, and the start address and the end address of the dynamic link library L # 1 are respectively a # 4 and a # 5, and the start address and end address of the dynamic link library L # 3 are a # 6 and a # 7, respectively.

  Reference numeral 503 denotes a virtual address space when the executable program P # 3 is executed, and shows an arrangement of program binaries on the virtual address. The executable program P # 3 uses a dynamic link library L # 1, a dynamic link library L # 2, and a dynamic link library L # 3. According to the virtual address arrangement plan 401, the arrangement of the executable program P # 3 on the virtual address is from the address a # 1 to the address a # 4, and the start address and the end address of the dynamic link library L # 1 are respectively a # 4 and a # 5, the start address and end address of the dynamic link library L # 2 are a # 5 and a # 6, respectively, and the start address and end address of the dynamic link library L # 3 are respectively a # 6 and a # 7.

  The virtual address areas of the executable programs P # 1, P # 2, and P # 3 overlap. For example, an area from address a # 1 to address a # 4 is allocated to the executable program P # 3, and this area is allocated from address a # 1 to address a # 2 to which the executable program P # 1 is allocated. It overlaps with the area. This is because a plurality of executable programs are not loaded into one virtual address space when the program is executed. Since a plurality of executable programs are not executed when the program is executed, no conflict occurs in the virtual address space even if the virtual address areas of the executable programs overlap.

  In addition, regardless of which executable program is used, the virtual address area of the dynamic link library L # 1 is address a # 4 to address a # 5. (The same applies to the dynamic link libraries L # 2 and L # 3.)

  Since the executable program P # 2 does not use the dynamic link library L # 2, the addresses a # 5 to a # 6 in the virtual address space 502 are not used. Similarly, the area from the address a # 2 to the address a # 4 in the virtual address space 501 is not used. However, since this area is a virtual address area and the corresponding physical memory area is not allocated, even if there is memory that is not used in this way, the memory usage is unnecessarily increased. There is nothing to do.

  FIG. 6 is a flowchart showing steps up to the program binary relocation process by the virtual address arrangement plan generation unit 105 and the arrangement plan corresponding relocator 106 according to the present embodiment.

  In step S <b> 601, the virtual address arrangement plan generation unit 105 generates an empty virtual address arrangement plan 104. An empty virtual address arrangement plan 104 means that no virtual address area is reserved.

  In step S <b> 602, the virtual address arrangement plan generation unit 105 reads one program binary (dynamic link library 102 or executable program 103) from the secondary storage device 101.

  In S603, the virtual address arrangement plan generation unit 105 adds virtual address information for the read program binary to the virtual address arrangement plan 104 generated in S601. Details of step S603 will be described later with reference to FIG.

  In step S <b> 604, the virtual address arrangement plan generation unit 105 determines whether it is the last program binary acquired from the secondary storage device 101. If it is the last program binary, the process proceeds to S605. If it is not the last program binary, the next program binary is read and the process returns to S602.

  In step S605, the virtual address arrangement plan generation unit 105 stores the virtual address arrangement plan 104 generated in step S601 and added with the arrangement information in step S603 in the secondary storage device 101.

  In S <b> 606, the arrangement plan corresponding relocator 106 reads one program binary from the secondary storage device 101. Here, this program binary is B.

  In S <b> 607, the arrangement plan corresponding relocator 106 relocates the program binary (dynamic link library 102 or executable program 103) read from the secondary storage device 101. Details of step S607 will be described later with reference to FIG.

  In step S <b> 608, it is determined whether the arrangement plan corresponding relocator 106 is the last program binary acquired from the secondary storage device 101. If it is the last program binary, the process ends. If it is not the last program binary, the next program binary is read and the process returns to S606.

  FIG. 7 is a flowchart showing the contents of step S603 in FIG.

  In step S701, the virtual address arrangement plan generation unit 105 acquires the program binary information acquired in step S602. The information to be acquired is the size of the virtual address area required by the program binary.

  In step S702, the virtual address arrangement plan generation unit 105 determines whether the program binary acquired in step S602 is an executable program. If the acquired program binary is an executable program, the process proceeds to step S703. If the acquired program binary is a dynamic link library, the process proceeds to step S704.

  In step S703, the virtual address arrangement plan generation unit 105 determines an area in which the executable program acquired in step S602 is to be arranged. The size of the area to be allocated is the size of the virtual address area required in step S701. The start address of the area to be allocated is a predetermined start address for an executable program.

  In step S704, the virtual address arrangement plan generation unit 105 determines an area in which the dynamic link library acquired in step S602 is to be arranged. An area to which the dynamic link library is allocated is an unused area in the virtual address arrangement plan 104.

  In step S705, the virtual address arrangement plan generation unit 105 writes the virtual address area to which the program binary is allocated, determined in step S703 or step S704, in the virtual address arrangement plan 104 generated in step S601.

  FIG. 8 is a flowchart showing the contents of step S607 in FIG.

  In S801, the arrangement plan corresponding relocator 106 acquires all the dynamic link libraries on which the program binary B acquired in S606 depends. In particular, here, not only the dynamic link library directly dependent on the program binary acquired in S606 but also the dynamic link library on which the dynamic link library acquired in this step depends is acquired recursively.

  In S802, the arrangement plan corresponding relocator 106 acquires the relocate information of the program binary B.

  In S803, the arrangement plan corresponding relocator 106 acquires one unresolved reference item from the relocate information acquired in S802.

  In S804, the arrangement plan corresponding relocator 106 performs relocate processing for resolving the unresolved reference item acquired in S803. A detailed description of S804 will be described later with reference to FIG.

  In step S805, the arrangement plan corresponding relocator 106 determines whether it is the last unresolved reference item acquired from the program binary. If it is the last unresolved reference item, the process ends. If not, the process returns to step S803 for the next unresolved reference item.

  FIG. 9 is a flowchart showing the contents of step S804 in FIG.

  In S901, the arrangement plan corresponding relocator 106 acquires the position of the unresolved reference and the reference destination symbol from the unresolved reference item acquired in Step S803. Here, it is assumed that the position of the acquired unresolved reference is P, and the reference destination symbol is S.

  In S902, the arrangement plan corresponding relocator 106 acquires one dynamic link library among the dynamic link libraries on which the program binary B acquired in step S801 depends. Here, let this dynamic link library be L.

  In S903, the relocation locator 106 acquires the symbol table of the dynamic link library L. Here, this symbol table is T.

  In S904, the arrangement plan corresponding relocator 106 determines whether the symbol S acquired in S901 is included in the symbol table T. If it is included, the process proceeds to S904. If it is not included, the next dynamic link library is examined, and the process returns to step S902.

  In S905, the arrangement plan corresponding relocator 106 acquires the address corresponding to the symbol S from the symbol table T, and writes it in the unresolved reference position P acquired in step S901.

  FIG. 10 is a flowchart showing processing steps of the arrangement plan corresponding loader 107.

  The arrangement plan corresponding loader 107 is activated in response to a request to load a specific executable program or dynamic link library from a program being executed.

  The placement plan loader 107 reads the program binary (executable program 103 or dynamic link library 102) relocated by the placement plan support relocator 106 from the secondary storage device 101, and the same program binary as the program binary to be loaded is already loaded. If it is, the code is shared. If not, the program binary is loaded at a position on the virtual address according to the virtual address arrangement plan 104 generated by the virtual address arrangement plan generation unit 105. Detailed steps are described below.

  The arrangement plan corresponding loader 107 receives the program binary and is activated. Here, this program binary is B.

  In step S1001, the arrangement plan corresponding loader 107 determines whether or not the program binary B has already been loaded. If already loaded, the process proceeds to step S1003. If it has not been loaded yet, the process proceeds to step S1002.

  In step S1002, the arrangement plan corresponding loader 107 loads the text section of the program binary B. At this time, the address to be loaded follows the virtual address arrangement plan 104. Thereafter, the process proceeds to step S1004.

  In step S1003, the arrangement plan corresponding loader 107 shares the text section of the program binary B that has already been loaded by another process or the like. In a computer system provided with a virtual memory mechanism, a virtual address area can be associated with a specific physical address area, and when the virtual address area is accessed, actual access is performed to the physical address area. When a certain memory area is shared, each virtual address area is associated with the same physical address area. Thereafter, the process proceeds to step S1004.

  In step S1004, the arrangement plan corresponding loader 107 loads the data section of the program binary. At this time, the address for loading the dynamic link library follows the virtual address arrangement plan.

  Unlike the text area, each process can write unique information in the data area and the bss area. Therefore, generally, the data area and the bss area cannot be shared between processes. Note that even the data area can be shared until writing is performed, so the data area may be shared among a plurality of processes until writing is performed.

  In step S1005, the arrangement plan corresponding loader 107 loads the bss section of the program binary B. At this time, the address for loading the bss section follows the virtual address arrangement plan 104.

  In step S1006, the arrangement plan corresponding loader 107 recursively loads all the dynamic link libraries on which the program binary B depends.

  When the dynamic link library processing apparatus according to the present embodiment is used, the virtual address at which each dynamic link library is loaded is always fixed. Therefore, when referring to information of another dynamic link library from a certain dynamic link library, the position on the virtual address where the reference destination information is placed is determined. From this, unresolved references in each dynamic link library can be resolved in advance.

  For example, in any of the virtual address spaces 501, 502, and 503 in FIG. 5, the dynamic link library L # 1 is arranged from the address a # 4 to the address a # 5. Therefore, the addresses where the functions and data in the dynamic link library L # 1 are placed are always constant. Therefore, when there is an address reference to a function or data in the dynamic link library L # 1 from another program binary, the address of the function or data can be determined in advance. Therefore, even if the address is referenced between program binaries, it can be relocated in advance.

  Also, since the virtual address at which each dynamic link library is loaded is always constant, code that depends on the location that accesses different dynamic link libraries without going through a binary interface such as GOT can be used. Can be used. Position-dependent code is more efficient than position-independent code using GOT.

  As described above, when the dynamically linked library processing apparatus according to the present embodiment is used, the library code can be shared by a plurality of virtual address spaces in a multi-process environment using a virtual memory mechanism, and the virtual address You can use position-dependent code. Since the library code is shared, memory use efficiency is good. In addition, since the code depends on the address position, direct reference can be used for address reference, and execution efficiency is improved.

  In either the conventional static link method or the conventional dynamic link method using GOT, an arrangement plan for each program binary is generated in order to execute the program.

  In the conventional static link method, when program binaries are assigned to a certain address area, other program binaries cannot be assigned to that area. In the static linking method, the library code is copied to the executable program and cannot be shared between different programs. In the dynamic link library processing apparatus according to the present embodiment, virtual address areas to which executable programs are assigned can be overlapped. A library can be shared between different programs as a dynamic link library. For example, consider the virtual address spaces 501 and 502 of FIG. Executable programs P # 1 and P # 2 are assigned to the same virtual address area. The dynamic link library L # 1 is shared by the executable programs P # 1 and P # 2.

  In the conventional dynamic link method using GOT or the like, the virtual address area in which the dynamic link library is arranged is different for each program. If the dynamic link library includes position-dependent code when the dynamic link library is arranged in different virtual address areas, the code of the dynamic link library cannot be shared between programs. In the method using the dynamic link library apparatus of the present embodiment, a virtual address area loaded with a dynamic link library is common to all programs by using a virtual address allocation plan common to all programs. It becomes. Therefore, since the position where each dynamic link library is loaded is always determined, the code of the dynamic link library can be shared between programs even if position dependent code is used.

(Embodiment 2)
FIG. 11 is a diagram showing a configuration of the dynamic link library processing apparatus according to the second embodiment of the present invention. In FIG. 11, the same components as those in FIG.

  The stripper 1101 is a stripper that deletes symbol information and relocate information necessary for relocation from the dynamic link library 102 or the executable program 103 relocated by the arrangement plan corresponding relocator 106.

  The relocate information 205 and the symbol table 206 in FIG. 2 are information necessary for relocation. This information may become unnecessary once the relocation is complete. The stripper 1101 deletes these unnecessary ones, reduces the size of the program binary, and improves efficiency.

  FIG. 12 is a flowchart showing processing steps in which the stripper 1101 deletes the program binary relocate information 205 and the symbol table 206.

  In step S <b> 1201, the stripper 1101 acquires one program binary (the executable program 103 or the dynamic link library 102) from the secondary storage device 101. Here, it is assumed that the acquired program binary is B.

  In S1202, the stripper 1101 acquires the relocate information 205 in the program binary B and deletes it.

  In step S1203, the stripper 1101 acquires the symbol table 206 in the program binary B and deletes it.

  In step S <b> 1204, the stripper 1101 stores the program binary from which the relocate information 205 and the symbol table 206 are deleted in the secondary storage device 101.

  In step S1205, the stripper 1101 determines whether the program binary B is the last program binary that can be acquired. For the last program binary, the process ends. If it is not the last program binary, the next program binary is targeted for processing, and the flow returns to S1201.

  In the case of the dynamic link library technology using the conventional GOT, it is necessary to leave the symbol table and relocate information in the dynamic link library in order to generate the GOT when the dynamic link library is loaded. When the dynamic link library processing apparatus according to the present embodiment is used, the relocate process of the executable program and the dynamic link library is completed, and the program can be loaded properly without the relocate information. Therefore, in the dynamic link library processing apparatus according to the present embodiment, unnecessary relocate information and symbol tables can be deleted, the size of the program binary can be reduced, and efficiency can be improved.

(Embodiment 3)
FIG. 13 is a diagram showing a configuration of the dynamic link library processing apparatus according to the third embodiment of the present invention. In FIG. 13, the same components as those in FIG.

  A memory manager 1301 secures and releases a virtual address area, and starts processing upon receiving a request to secure a virtual address area from a running program.

  The reserved memory area table 1302 is a table used by the memory manager 1301 to store the reserved area. The reserved memory area table 1302 is empty in the initial state.

  When the memory manager 1301 receives a request for securing a virtual address area from a running program, the memory manager 1301 refers to the virtual address allocation plan 104 and secures the memory so as not to use a virtual address area not allocated in the virtual address allocation plan 104. To do.

  FIG. 14 is a flowchart showing processing steps when the memory manager 1301 secures memory.

  In step S1401, the memory manager 1301 starts processing upon receiving a request to secure a virtual address area from the program being executed. In the securing request, the memory capacity to be secured is specified.

  In step S1402, the memory manager 1301 reads the virtual address allocation plan 104 from the secondary storage device 101, and acquires the virtual address area allocated for the program binary in the virtual address allocation plan 104.

  In step S1403, the memory manager 1301 checks the reserved memory area table 1302 and acquires the allocated virtual address area.

  In step S1404, the memory manager 1301 secures a virtual address area that is not allocated in both step S1402 and step S1403, and writes it as an allocated area in the reserved memory area table 1302.

  In step S1405, the memory manager 1301 notifies the program of the virtual address area secured in step S1404 and ends.

  In general, when a program is executed, not all dynamic link libraries are used, but only some dynamic link libraries are used. Even a dynamic link library used by a program can be loaded on the spot as needed during execution without being loaded when the program is started. Therefore, when a program is executed, not all virtual address areas included in the virtual address allocation plan are used, but a virtual address area for a dynamic link library that is not used by the program being executed. Will remain unused.

  Since the dynamic link library can be linked at the time of execution, the dynamic link library may be used after the processing of the program proceeds. When the dynamic link library is used, if the virtual address area for the dynamic link library is used for other purposes, the dynamic link library is dynamically moved to the location indicated in the virtual address allocation plan. The link library cannot be placed. Therefore, the memory manager according to the present embodiment secures and allocates a virtual address area not shown in the virtual address arrangement plan when receiving a memory reservation request. As a result, the virtual address area allocated in the virtual address arrangement plan is not used for other purposes, and it can be guaranteed that the dynamic link library is loaded at an appropriate position.

  The dynamic link library processing apparatus according to the present invention enables sharing of the code of the dynamic link library in a computer system using a virtual memory mechanism even if position dependent code is used. Since the code of the dynamic link library is shared by a plurality of processes, the memory consumption is small and the position-dependent code with high execution efficiency can be used. Therefore, the execution efficiency of the program is improved and useful.

It is a figure which shows the structure of the dynamic link library processing apparatus in Embodiment 1 of this invention. It is a figure which shows the information contained in one executable program or a dynamic link library. It is the figure explaining the information of the relocate information 205 and the symbol table 206 using a specific example. It is an example which showed the content of the virtual address arrangement plan 104. FIG. It is a figure of arrangement | positioning of the program binary on a virtual address when each executable program is executed according to the said virtual address arrangement plan 401. FIG. 2 is a flowchart showing steps up to a program binary relocation process by a virtual address arrangement plan generation unit 105 and an arrangement plan corresponding relocator 106 in FIG. 1. It is a flowchart which shows the content of step S603 of FIG. It is a flowchart which shows the content of step S607 of FIG. It is a flowchart which shows the content of step S804 of FIG. It is the flowchart which showed the processing step of the arrangement plan corresponding loader. It is a figure which shows the structure of the dynamic link library processing apparatus in Embodiment 2 of this invention. It is the flowchart which showed the process step which the stripper 1101 deletes the relocate information 205 and the symbol table 206 of a program binary. It is a figure which shows the structure of the dynamic link library processing apparatus in Embodiment 3 of this invention. It is the flowchart which showed the processing step when the memory manager 1301 reserves a memory.

Explanation of symbols

DESCRIPTION OF SYMBOLS 101 Secondary storage device 102 Dynamic link library 103 Executable program 104 Virtual address arrangement plan 105 Virtual address arrangement plan production | generation part 106 Placement plan corresponding relocator 107 Placement plan corresponding loader 108 Memory 201 Header information 202 Text section 203 Data section 204 BSS section 205 Relocate Information 206 Symbol Table 301 Dynamic Link Library 302 Dynamic Link Library 303 Text Section 304 Text Section 305 Unresolved Reference 306 Function Text 307 Relocate Information 308 Relocate Information 309 Symbol Table 310 Symbol Information 401 Virtual Address Placement Plan 501 Virtual Address space 502 Virtual address space 503 Virtual address Space 1101 Stripper 1301 Memory manager 1302 Reserved memory area table

Claims (3)

In a computer system using a virtual memory mechanism,
One or more executable programs and one or more dynamic link libraries are received, and the one or more dynamic link libraries and the one or more executable programs are virtual so that the dynamic link libraries do not overlap. A virtual address arrangement plan for generating a virtual address arrangement plan indicating an arrangement position on a virtual address of the one or more dynamic link libraries and the one or more executable programs by determining an arrangement on the address A generator,
The one or more executable programs and the one or more dynamic link libraries are received, and the respective executable programs and dynamic link libraries are relocated based on the virtual address allocation plan before the execution of the programs. A relocation locator
When the program is executed, the relocation locator corresponding to the arrangement plan receives the relocated executable program and dynamic link library, and is already loaded in a different virtual address space from the program being executed by the loadable executable program or dynamic link library. A placement plan compatible loader that loads an executable program or a dynamic link library at a location on a virtual address according to the virtual address placement plan otherwise.
A dynamic link library processing apparatus characterized by comprising: A stripper for receiving the executable program or the dynamic link library relocated by the arrangement plan corresponding relocator and deleting the symbol information and the relocate information in each executable program or the dynamic link library;
The dynamic link library processing apparatus according to claim 1, further comprising: A memory manager that receives the virtual address arrangement plan and secures a memory area other than the virtual address area indicated by the virtual address arrangement plan when securing a memory area on the virtual address;
The dynamic link library processing apparatus according to claim 1, further comprising:

Images