KR100478463B1 - Dynamic Linking Method for Application Program - Google Patents

Abstract

The present invention relates to a dynamic linking method of an application program that enables a dynamic loading mechanism of an application program using delay binding for an embedded system having limited resources. According to the dynamic linking method of the application of the present invention, it is possible to support the dynamic loading mechanism of the application for an embedded system having no limited memory management unit and having limited storage space, thereby performing an operating system operating in a single address space. The advantage is that applications can be added and removed dynamically.

Description

Dynamic Linking Method for Application Program

The present invention relates to a dynamic linking method of an application program that enables a dynamic loading mechanism of an application program using delay binding for an embedded system having limited resources.

Conventionally, an operating system running on a CPU without a memory management unit (MMU) configures a so-called library kernel to be suitable for execution in a single address space. In the library kernel, an application program and various libraries are configured as a kernel ( kernel, which links together to form a single image and loads that single image into the target system's memory. When constructing such a library kernel, it is common for a designer to construct a library kernel of a single image optimized for a target system by selecting various subsystems required for an application program during the linking process.

These library kernels are optimized for the system to configure the kernel, after which it is suitable for so-called closed embedded systems that do not need to expand the kernel on the fly. However, among the widely used information and communication devices, PDAs and the like have different characteristics from the above-described closed-type embedded system. When these are listed, (1) users need different applications, and (2) many third-party applications are used. It is provided by a third party, and (3) upgrading the application occurs more often than upgrading the kernel.

The so-called open system having such characteristics is difficult to operate with only statically configured images as library kernels as described above. In other words, when using a statically configured kernel image for such an open system, various inconveniences occur. For example, each user must provide a different kernel image. Also, every time an application is upgraded, the entire kernel image is regenerated. Inconvenience such as downloading occurs. Therefore, in order to use the library kernel in an open system such as a PDA, a function that dynamically downloads and executes an application program during execution must be added.

Accordingly, an object of the present invention is to provide a dynamic linking method of an application that enables a dynamic loading mechanism of an application by using delay binding for an embedded system having limited resources.

1 is a diagram showing the structure of the entire system for applying the dynamic link method of the application of the present invention. The ability to dynamically load applications is built into general-purpose operating systems such as Unix or Windows. To provide dynamic loading, applications are stored on the hard disk and then shelled by the user when needed. In this case, the general operating system allocates an independent address space for each application program using a virtual memory system. On the other hand, in an embedded system such as a PDA, there is a problem that a memory management unit for supporting a virtual memory system is not provided and storage space for an application program is also very limited.

Therefore, the dynamic link method of the application program proposed in the present invention is designed to satisfy the following requirements in supporting the dynamic loading function of the application program in the embedded system, and enumerating them (1) program module to be downloaded dynamically Must be able to compile independently of the kernel, (2) be able to use modules that have already been downloaded even if the kernel is updated, (3) be available on systems without a virtual memory system, and (4) It should not be dependent on the compiler.

In FIG. 1, the entire system for applying the dynamic link method of the present invention comprises a host 110 for developing an application and a target 150 for executing an application. In order to be able to link to the host 110 and the target 150 is provided with a component builder 130 and a dynamic loader 160, respectively.

First, the component builder 130 is executed on the host 110. The component builder 130 generates a component 140 by compiling and linking an application source written by a user, that is, the component source 120, and generates the generated component ( The file information is modified in consideration of the dynamic link, and preferably, a part of the address relocation operation is performed to improve the performance of the dynamic link. Component 140 typically follows a known ELF format.

On the other hand, the dynamic loader (Incremental Loader: 160) is performed on the operating system of the target 150, the component 140 by relocating the address of the component 140 of the newly added application downloaded from the host 110, the component 140 Is dynamically linked to the currently executing kernel image 170 to be performed within the operating system of the target 150. In the present invention, the component 140 thus downloaded and newly added is late bound to the kernel image 170, which will be described in detail later.

FIG. 2 illustrates a method of generating a component 140 of an application program that can be dynamically loaded in the component builder 130 of the host 110 according to the method of dynamically linking an application of the present invention, and dynamically loading it into the target 150 to kernel. It is a figure which shows the process of linking to 170. FIG.

In the present invention, in order to perform dynamic linking by delay binding, the target 150 defines an interface provided by the kernel 270 to the application program component 140, and refers to the stub file 220 to be used in the application. And a vector table 280 provided by the kernel 270. The kernel 270 and the application component 140 are then linked with the vector table 280 and the stub file 220 to generate an image, and the components of the application from the host 110 during the execution of the kernel 270. Once 140 is downloaded, dynamic loader 160 relocates the address reference of application program 140 according to vector table 280. In this process, the application component 140 dynamically linked to the kernel 270 by relocating the address of the kernel service routine provided by the kernel 270 and used by the application component 140 to the location of the vector table 280. To call the kernel service routine on the target 150.

First, a description will be given of defining an interface of a kernel service routine provided by the kernel 270 for lazy binding. In order to dynamically load the component 140 of the application and dynamically link it during kernel execution, the present invention includes a library description file 230, an application stub 220, and a library vector table. table: 280), among which the application stub 220 and the library vector table 280 can be automatically generated from the library description file 230.

First, the library description file 230 may be configured by describing a list of functions exported by the kernel 270 in a simple text form. FIG. 3 illustrates an embodiment of the library description file 230. . The illustrated library description file 230 simply shows the function name in text form, and global variables cannot be exported. More preferably, the application stub 220 and the library vector table 280 described below are automatically generated from the library description file 230 by using a specific development tool.

Next, the application program stub 220 will be described. The application program is compiled from the source file 210 independently of the kernel 270 and is generated as a memory relocatable form, that is, a relocatable object file 240. At this time, the application program should have a reference to the location of the function being exported from the kernel 270, and the actual functions are mostly arranged arbitrarily by the linker. Therefore, in the present invention, the indirect call table for the function exported by the kernel 270, that is, the library vector table 280 is set in the kernel, and the application program uses the function from the base address vec_base of the vector table 280. Allow the application to store an offset (0x150) up to the call routine for. The function position is obtained by summing the offset and the base address upon relocation.

The application stub 220 is given as a linker script file, where the creator of the application sets the stub file 220 when linking the application to locate the kernel service routine used by the application. Can be specified. 3 illustrates an embodiment of the application program stub file 220, the entry order of the stub file 220 preferably matches the entry order of the library description file 230, as shown. The relative address assigned to each symbol in the stub file 220 corresponds to the position of an entry for jumping to a function corresponding to the symbol in the library vector table 280.

Next, the library vector table 280 is described. The library vector table 280 is linked with the kernel 270 and contains entry point information for each kernel service routine, which is relative to each entry point from the base address vec_base of the vector table 280. The address is stored in the application stub file 220 and used by the host 110 to link the application. 3 shows a library vector table 280 for an ARM architecture as an example. Advantages of using the library vector table 280 in the present invention are that, without having to directly search the library function routine, the desired library function routine can be executed by jumping to the corresponding entry according to the index of the library vector table 280. In addition, even if the kernel 270 is reconfigured to change the actual position of the function, the application does not need to recompile the application since only the indexes on the vector table 280 are maintained.

A process of generating an application program in a manner suitable for the dynamic link method of the present invention in the host 110 will be described. The dynamically loadable application program used in the present invention, that is, the application program components 140 and 240 are compiled and linked independently of the kernels 170 and 270. The compiling process of the application program is the same as the general compiling process, compiling the source file 210 of the application program to generate the object file 240, and linking it again to generate an image that can be dynamically loaded according to the present invention. In order to generate an image that can be dynamically loaded, information about symbol and relocation information must be included in the image, and information for dynamic linking with the kernel service routine provided by the kernel 270 must also be included. An embodiment of a link command usable in the present invention is as follows.

ld -e entry -r -d -o output * .o libos.lnk

In the link command, option "-e" specifies a start function with the following argument, option "-r" specifies that the final output is generated in a relocatable form, and option "-d" is relocatable. This forces the BSS section to be allocated for the output of. If the option "-d" is not set, the BSS section will not be allocated to the final output image, resulting in the loss of information about the uninitialized data area. have. The option "-o" specifies the output file with the following arguments, after which it lists the object files (.o) created during the compilation process above. In the link command, the application program stub file 220 is specified at the end, so that the offset information of the vector table 280 is stored in the final image so that it can be dynamically linked with the kernel service routine provided by the kernel 270.

4 is a diagram illustrating a result of compiling and linking a relocatable application program used in the dynamic link method of an application program according to the present invention. The test.c program uses a printf () function provided by the kernel. The printf () function is called by a so-called indirect method at the 0x150 position of the library vector table 280. In the lower left of FIG. 4, it can be seen that the relative position of the printf () function is indicated by offset 0x150 in the .os.lib.libc section on the symbol table of the generated image.

On the other hand, it is preferable that the application program generated as described above is optimized for its size, and as an embodiment thereof, a method of removing unnecessary symbols is provided. That is, the size of the application is reduced by removing information that is not actually used for delay binding among information existing in the application image after the final link. Through this optimization process, the size and load time of the storage space can be reduced.

Information about the relocation table is shown in the lower right of FIG. 4. The relocation table is information necessary for the relocation process according to the present invention, and includes (1) the position of an instruction to be modified at the time of relocation, (2) the type of instruction to be modified at the time of relocation, and (3) a symbol referred to by the instruction. Contains information. The relocation table is included in the relocatable type object file and is used suitably as described later in the relocation process. In the relocation process, the absolute address of the referenced symbol is calculated and the address within the instruction is modified according to the type of the instruction at the position of the instruction to which the referenced symbol is located. This address relocation problem will be described in detail with reference to FIGS. 5 and 6.

In addition, the relocation information includes an entry of a relative address as information about a function performed in a section. Since a section is allocated to a contiguous address space, such a relocation is performed before a link even if the memory location is not determined. Relocation can be performed, which makes it possible to delete the associated entry from the relocation information. Through this, it is possible to reduce the size of the application program to obtain the effects as described above. The optimization process of these applications can be performed automatically in software.

FIG. 5 is a diagram illustrating rearrangement of each section of an object file 510 on a memory 520 in the dynamic link method of an application program of the present invention, and FIG. 6 is a dynamic link method of the application program of the present invention. Is a diagram illustrating a process of rearranging the actual instructions for each entry of the relocation table. The delay binding scheme of the present invention will be described with reference to FIGS. 5 and 6.

According to the present invention, the relocatable object file image 240 may be dynamically loaded into the memory 250 and linked with the kernel 270 during the kernel execution of the target 150. Dynamically linking the image to the kernel 270 is called late binding. In the present invention, the delay binding process includes: (1) a first step of allocating a section address for each section in the object file 510 to be dynamically linked and placing the section data in the memory 520; And (2) a second step of performing memory relocation corresponding to each entry of the relocation table in the object file 510. The first step includes setting a section for the vector table 280 provided by the kernel 270, and each step may be implemented using header information of the ELF binary.

First, a first step of allocating a section address for each section of the object file 510 will be described. As shown in FIG. 4, the address of each section after the final linking process is undefined and is preferably set to "0". In order to load and execute an application program on the target 150, an object file ( The address at which each section of 510 will be located on memory 520 must be determined. 5 shows a process of allocating section addresses for each section of the object file 510. The address allocated to each section, sh_addr, is used to load the object file 510 into the memory 520. It is allocated from the memory allocator. The assigned section address is stored in the section header 530 of the application residing on the memory 520, and then used in performing memory relocation for each instruction. In the above process, the section address for the library vector table 280 of the kernel 270 is also read from the kernel 270 and stored.

Next, a second step of performing memory relocation corresponding to each entry of the relocation table in the object file 510 will be described. As described above with reference to FIG. 5, when a section address is determined for each section of the object file 510, the contents of each section are copied to the memory 520 to be actually executed and for each entry of the relocation table in the program header. The actual instruction relocation takes place. The address relocation process according to the present invention includes (1) calculating an absolute address for a reference symbol, (2) converting an absolute address into an address form required by an instruction to perform relocation, and (3) modifying an actual instruction. It consists of steps.

6 illustrates a process of relocating an actual instruction for each entry of the relocation table. As an embodiment, relocation address calculations for entries and branch instructions of the relocation table in the ARM architecture, and applying the same to the actual instructions, are illustrated in FIG. Shows the process.

In the relocatable object file 510, the branch instruction for the library function is generated in a form in which the address of the branch target is undetermined. In FIG. 6, the branch instruction for the printf () function has the target address where the actual printf () function is located. You can see that it is set to its own address (0x1C). On the other hand, the relocation table stores the position (0x1C) of the instruction to be relocated and the position (0x150) in which the symbol (that is, printf) referenced by the instruction exists in the vector table. As described with reference to FIG. 5, when the section address assignment process is completed, the address of each section and the location of the library vector table 280 can be known. In FIG. 6, the text of the object file 510 is shown. Assume that the section is assigned to 0x100 and the library vector table 280 containing printf is assigned to a location of 0x400 in the kernel.

After the section is addressed, the address in the vector table can be calculated for the actual symbols. As an example, the branching instructions of the ARM architecture perform branching operations using relative addresses to PCs (program counters), thereby calculating the difference between the absolute address in the vector table for the target symbol (ie, printf) and the current PC. Instructions can be modified. That is, the symbol printf's address in the vector table is 0x150 and the vector table's address is 0x400 by assumption, so the absolute address of printf is 0x400 + 0x150, that is, 0x550, and the absolute position of the current instruction is the address of the text section. Is 0x100, so 0x100 + 0x1C, that is, 0x11C. Therefore, the relative position of the symbol printf is 0x550-0x11C, that is, 0x434.

Now, using these values to change the target address of the branch instruction, the branch instruction can correctly branch to the printf location in the library vector table 280 in executing the application. Through this process, other relocatable instructions may also perform relocation by determining an address of a reference symbol. The relocation process shown in FIG. 6 may be different depending on the instruction encoding scheme of a particular architecture, since it may vary depending on the location of the address within the instruction and the number of bits in the address.

According to the dynamic link method of the application of the present invention, there is an advantage in that the dynamic loading mechanism of the application can be supported for an embedded system having a limited storage space without a memory management unit.

In addition, according to the dynamic link method of the application program of the present invention, there is an advantage that the application program can be added and removed dynamically while the operating system is executed in a single address space.

1 is a diagram showing the structure of an entire system for applying a dynamic link method of an application program of the present invention.

2 is a diagram illustrating a process of generating and loading an application program capable of dynamically loading according to the dynamic link method of an application program of the present invention.

3 is a diagram illustrating an embodiment of a library description file, an application stub file, and a library vector table used in a dynamic link method of an application program of the present invention.

4 is a view showing a result of compiling and linking a relocatable application program used in the dynamic link method of the application program of the present invention.

FIG. 5 is a diagram illustrating a process of rearranging each section of an object file on a memory in the dynamic link method of an application program of the present invention. FIG.

6 is a diagram illustrating a process of relocating actual instructions for each entry of a relocation table in the dynamic link method of an application program of the present invention.

<Explanation of symbols for the main parts of the drawings>

110: host

120: component source

130: Component builder

140: component

150: target

160: dynamic loader

170: kernel

Claims (5)

A dynamic link method of an application program, the dynamic link method comprising: a first step of generating an object file by compiling and linking a component source of the application program; A second step of generating a component file by performing a predetermined first address relocation operation on the object file; Providing the component file to a target system; And a fourth step of performing a predetermined second address relocation operation on the component file and linking the component file to a kernel image of the target system to change the kernel image. The first address relocation operation is performed by resetting location reference information of a kernel service routine with respect to the object file to indirect location reference information of a kernel service routine provided by a kernel of the target system. Placing each section of the component file in memory of the target system and relocating instructions corresponding to each entry of the relocation table included in the component file. 2. The method of claim 1, wherein the indirect georeference information for the kernel service routine used in the first address relocation operation is based on the base address of the vector table for the kernel service routine of the kernel and the kernel service routine in the vector table. Dynamic link method of an application program comprising an offset value up to the call routine for the. The method of claim 2, wherein the first address relocation operation is based on function name information on the kernel service routine provided by the kernel of the target system and offset information on which a call routine for the kernel service routine exists in the vector table. Dynamic link method of the application, characterized in that performed by. The method of claim 1, wherein the BSS section is allocated to the object file when generating the object file from the component source in the first step. A computer-readable information recording medium having recorded thereon a program for implementing the dynamic link method of an application program according to any one of claims 1 to 4.