WO2017067175A1

WO2017067175A1 - Method, apparatus and device for loading elf file, and computer storage medium

Info

Publication number: WO2017067175A1
Application number: PCT/CN2016/084304
Authority: WO
Inventors: 秦松; 陈鑫; 位广军; 马家智; 桂敬文; 王博通; 王晓卿; 张洪卫; 常磊; 张治�; 李新开
Original assignee: 百度在线网络技术（北京）有限公司
Priority date: 2015-10-21
Filing date: 2016-06-01
Publication date: 2017-04-27
Also published as: CN105224370B; CN105224370A

Abstract

A method, apparatus and device for dynamically loading an executable and linking format (ELF) file, and a computer storage medium. The method comprises: parsing a static library file in an ELF file to obtain an object file (101); extracting an effective segment from the object file, and recording effective segment information (102); and loading the effective segment, and separately establishing an object mapping table and a function mapping table for objects and functions in the object file to re-position the objects and the functions in the loaded effective segment (103). By means of the method and device for dynamically loading an ELF file provided in the solution, the troubles of an embedded system needing to depend on a specific instruction set when the embedded system parses and loads an ELF file and the embedded system is not be suitable for all embedded processor architectures in the prior art can be eliminated, applications of multiple ELF files can be simultaneously operated under a specific processor system structure, and dynamic linking can be realized, thereby greatly reducing a file volume generated by using static linking before, and reducing power consumption.

Description

Method, device, device and computer storage medium for loading ELF file

The present application claims priority to Chinese Patent Application No. 201510688388.3, entitled "A Method and Apparatus for Loading ELF Files", filed on October 21, 2015.

Technical field

The present invention relates to the field of computers, and in particular, to a method, an apparatus, a device, and a computer storage medium for loading an ELF file.

Background technique

ELF (Executable and Linking Format) with executable and link format is a format of an object file for defining content and its format in different types of object files. Since the existing embedded operating system uses the static link method to generate the executable file for the ELF file loading, and burns the executable file directly into the memory (Flash) by using the burning method, these processes must be performed. It is done under the ARM instruction set, and some processors do not use the ARM instruction set, and do not support the instruction set to the ARM instruction set. Therefore, the prior art cannot provide ELF file loading for such processors. .

Summary of the invention

The invention provides a method, a device, a device and a computer storage medium for loading an ELF file, so as to solve the problem that the prior art cannot record an ELF file in some embedded systems.

The specific technical solutions are as follows:

A method of loading an ELF file having an executable and link format, the method comprising:

Parsing a static library file in the ELF file to obtain an object file;

Extracting a valid segment from the object file;

Loading a valid segment, and establishing an object mapping table and a function mapping table for the objects and functions in the object file, respectively, for relocating the objects and functions in the loaded valid segment.

According to a preferred embodiment of the invention, the extracted valid segment comprises: an executable code segment, an application data segment or a relocation segment.

According to a preferred embodiment of the invention, the valid segment is extracted according to the ELF file header and the segment file header table of the object file.

According to a preferred embodiment of the present invention, the loading the valid segment comprises: loading different types of valid segments into different regions respectively.

According to a preferred embodiment of the present invention, the loading different types of valid segments into different regions separately includes:

Relocating the executable code segment according to the executable code segment and the segment information of the corresponding relocation segment, and writing the re-executed executable code segment to Flash; or

The application data segment is directly loaded into the RAM according to the application data segment and the segment information of the corresponding relocation segment.

According to a preferred embodiment of the invention, the segment information comprises a segment number, a segment offset or a segment size.

According to a preferred embodiment of the present invention, the executable code segment includes a .text segment, and the application data segment includes a .data segment, a .bss segment, or a .rodata segment, and the relocation segment includes a .rel.data segment. .rel.bss section, or .rel.rodata section.

According to a preferred embodiment of the present invention, after the valid segment is loaded, the valid segment of the object file is marked with at least one of the following: a starting address of the segment, a segment offset, and a segment size.

According to a preferred embodiment of the present invention, the mapping table entry of the object mapping table includes an object name And an object address, the object address is obtained by searching an export object in the valid segment according to the address of the export object; the mapping table entry of the function mapping table includes a function name and a function address, and the function address is passed Find the export function in the valid segment, based on the address where the exported function is located.

According to a preferred embodiment of the present invention, when the object in the valid segment is relocated, the address of the object in the object pool is searched for by the address of the current object in the object mapping table, and the text is The address of the jump object in the pool is modified to the address of the current object.

According to a preferred embodiment of the present invention, when the function in the valid segment is relocated, the address of the current function runtime and the address of the function that needs to be jumped from the function mapping table are used, and the jump instruction is obtained through calculation. The previous jump instruction is updated with the calculated jump instruction to jump to the function address to be executed according to the updated jump instruction.

An apparatus for loading an ELF file, the apparatus comprising:

a parsing device, configured to parse the static library file in the ELF file to obtain an object file;

An extracting device, configured to extract a valid segment from the object file;

The loading device is configured to load a valid segment, and respectively establish an object mapping table and a function mapping table for the objects and functions in the object file, and are used for relocating the objects and functions in the loaded valid segment.

According to a preferred embodiment of the present invention, the valid segment extracted in the extracting device comprises: an executable code segment, an application data segment or a relocation segment.

According to a preferred embodiment of the present invention, the extracting means is configured to extract a valid segment according to an ELF file header and a segment file header table of the object file.

According to a preferred embodiment of the present invention, the loading device loading the valid segment comprises: loading different types of valid segments into different regions respectively.

According to a preferred embodiment of the present invention, when loading the different types of valid segments into different regions, the loading device performs:

According to a preferred embodiment of the present invention, after the loading valid segment is executed, the loading device is further configured to mark at least one of the following valid segments of the object file: a starting address of the segment, a segment offset, Segment size.

According to a preferred embodiment of the present invention, the mapping table entry of the object mapping table includes an object name and an object address, and the object address is obtained by searching for an export object in the valid segment according to the address of the export object; The mapping table entry of the mapping table includes a function name and a function address, and the function address is obtained by searching for an export function in the valid segment according to the address where the derived function is located.

According to a preferred embodiment of the present invention, when the loading device relocates an object in the effective segment, the loading device specifically executes:

The address of the jump object of the object in the text pool is searched for by the address of the current object in the object mapping table, and the address of the jump object in the text pool is modified to the address of the current object.

According to a preferred embodiment of the present invention, when the loading device relocates the function in the valid segment, the loading device performs: using the address of the current function runtime and the function address that needs to be jumped from the function mapping table. After the calculation, the jump instruction is obtained, and the jump instruction obtained by the calculation is used to update the previous jump instruction, so as to jump to the function address to be executed according to the updated jump instruction.

It can be seen from the above technical solution that the present invention adopts parsing a static library (.a) file and extracts a valid segment, loads the valid segment, and establishes an object and function mapping table for respectively respectively for objects and functions in the relocatable segment. In the way of relocation, these processing methods are not limited to a specific instruction set, thus solving the problem that the prior art cannot load ELF files in some embedded systems.

DRAWINGS

FIG. 1 is a schematic flowchart of a method for dynamically loading an ELF file according to an embodiment of the present invention;

2 is a schematic diagram of a format of an ELF header according to an embodiment of the present invention;

FIG. 3 is a schematic structural diagram of an apparatus for loading an ELF file according to an embodiment of the present invention.

detailed description

The present invention will be described in detail below with reference to the drawings and specific embodiments.

Please refer to FIG. 1. FIG. 1 is a schematic flowchart diagram of an embodiment of a method for loading an ELF file having an executable and a link format according to the present invention. As shown in Figure 1, the process includes:

101: Parse the static library (.a) file in the ELF file to obtain an object file (.o).

The object file (.o) of the present invention is a re-directable file saved in ELF format, and the contents of the object file may contain entry marks and descriptions of the respective functions to form machine-executable instructions. When the program is to be executed, a link is also required. The link is to link multiple .o files into one executable file.

In addition to the relocatable object file, the ELF file can also contain an executable object file and an object file that can be shared. The above three object files can be represented in the form of an object file .o, and multiple. o The object file can be archived into a .a static library file, thereby finally forming an ELF file. Therefore, the purpose of parsing the static library (.a) file in the present invention is to obtain an object file (.o) constituting the ELF file.

Specifically, the process of parsing the static library file is similar to the decompression (restore) process of a compressed package rar in the Windows operating system, that is, analyzing the static library (.a) generated by the object file (.o) package, and parsing each of them. Object files (.o).

102: Extract a valid section from the obtained object file.

After the object file (.o) is acquired, a valid segment can be extracted from each object file and segment information can be recorded.

The valid sections are in the ELF file and are used to load the smallest container of content data.

Preferably, for each acquired object file, a valid segment is extracted according to an ELF header and a SHT (Section Header Table) of the object file, and each piece of information is recorded.

The specific type of the valid segment may include: an executable code segment, an application data segment, or a relocation segment. The executable code segment may specifically include a .text segment, etc., and the application data segment may include a .data segment, a .bss segment, or a .rodata segment, and the relocation segment may include .rel.data. Segment, .rel.bss section, or rel.rodata section.

The valid segment information of the record includes but is not limited to: each segment number, segment offset, or segment size, and the like.

among them

1) The executable file is loaded in the .text section;

2) The .data section is loaded with the initialized data;

3) The .bss section is loaded with uninitialized data;

4) The .rodata section is loaded with the corresponding string and the defined constant

5) The relocation segment starting with .rel, the rel.text segment, the .rel.data segment, the .rel.bss segment, and the .rel.rodata segment, are loaded with relocation entries, which are used to help the executable code. Segments and segments in which the application data segment is relocated;

For example: .rel.text shows where in the .text section you need to do relocation.

The following is a specific example to illustrate the specific way to extract valid segments and pieces of information from the ELF Header and SHT of the object file:

The ELF Header in this embodiment can be represented in the format shown in FIG. 2.

As shown in Figure 2, the ELF Header represents the format of the relocatable object file (.o). The corresponding sections and serial numbers can be known from the ELF Header, and what specific sections are in an ELF file are reflected in the SHT in the ELF file.

The structure definition of an entry in an SHT table can be:

Typedef struct{

Elf32_Word sh_name;

Elf32_Word sh_type;

Elf32_Word sh_flags;

Elf32_Addr sh_addr;

Elf32_Off sh_offset;

Elf32_Word sh_size;

Elf32_Word sh_link;

Elf32_Word sh_info;

Elf32_Word sh_addralign;

Elf32_Word sh_entsize;

}Elf32_Shdr;

In SHT, for each section, an entry is set to describe the corresponding section, the content of which mainly includes the name, type, size of the section, and the byte offset position in the entire ELF file.

The field Off(sh_offset) in the structure of the entry in the above SHT table indicates the distance of the section from the head position of the file, that is, the offset; Size (sh_size) indicates the segment size of the section.

Thereby, the information of each valid segment can be extracted based on the relevant sections indicated by the ELF Header and SHT.

The above 101 and 102 are preparatory processes for loading before dynamically loading the ELF file, and the steps may be performed simultaneously or sequentially. The present invention does not strictly define the order of execution thereof. When the above preparation process is performed, the process further proceeds through 103. Implements loading of valid segments of the object file.

103: Load a valid segment, and establish an object mapping table and a function mapping table for the objects and functions in the object file, respectively, for relocating the objects and functions in the valid segment loaded.

For 103, it can be further divided into loading valid segments, establishing mapping tables, and The three steps are re-positioned, wherein the first two steps can be performed simultaneously or sequentially. The order of the execution of the present invention is not rigidly specified, and the corresponding functions are all within the scope of the present invention.

The three steps are described in detail below:

Step 1: Load a valid segment.

For the valid segment extracted at 102, the executable code segment, the application data segment, and the relocation segment are three types, wherein the executable code segment and the application data segment belong to a valid segment to be loaded, and the relocation segment does not need to be loaded. For the valid segment to be loaded, it can be loaded into different regions in two ways according to its type.

The first way is to load the executable code segment (.text segment):

Since the flash reading and writing are inconsistent for different products, in order to facilitate relocation and modify the content of the .text segment, the .text segment can be relocated first, and then written to Flash.

Since the extracted relocation segment (.rel.text segment) corresponding to the .text segment contains the information that the .text segment needs to be relocated, the relocation method before writing to the flash may be: the identified .rel. The .text segment recorded in the text segment needs to be relocated to create relocation information, relocate .text, and then copy and write the .text segment to Flash.

The second way is to load the application data segments (.data, .bss, and .rodata):

The loading methods for .data, .bss, and .rodata are slightly different from the loading method for .text segments. Compared to the loading of .text segments, the relocation process for .text segments is included before writing to Flash. In other words, the loading of .data, .bss, and .rodata does not require relocation before loading the segments into random access memory (RAM), but in accordance with .data, .bss, and .rodata. The valid segment information of the corresponding relocation segments (..rel.data, .rel.bss, and .rel.rodata) loads the .data, .bss, and .rodata segments directly into RAM.

After the valid segment is loaded by the first and second methods, each segment of each object file (.o) can be marked accordingly, and the tag can include but is not limited to the segment start address and the segment offset. , segment size and other information.

The starting address of the segment is obtained according to the initialization of the valid segment after loading, and the segment offset and the segment size are obtained based on the extracted valid segment when the valid segment is extracted.

In the first step, a memory map is generated by separating the .text segment loaded with executable code from the application data of other application data segments and by creating relocation information for the target file of the executable code and loading the memory. The process avoids the process of copying the code data multiple times when loading the ELF file, which improves the running efficiency.

The second step is to establish an object mapping table and a function mapping table for the objects and functions in the object file.

In this step, the object mapping table (obj_map) and the function mapping table (func_map) are respectively established according to the difference between the object and the function, and the created mapping table is used for subsequent relocation and external calling.

The mapping table entry of the object mapping table includes an object name and an object address, and the object address in the mapping table is obtained by searching an export object in a valid segment of the object file, according to an address of the export object; a mapping table of the function mapping table The item includes the function name and the function address, which is obtained by looking up the export function in the valid section of the object file, according to the address where the function is derived.

For objects and functions, for example, most of the .text segments are functions, and .text segments, .data segments, .bss segments, .rodata segments, file variables, function variables, and other global variables, function elements, etc. Can be represented by an object. Since the division of objects and functions is prior art, it will not be described here.

The third step is to relocate the objects and functions in the valid segment loaded.

In this step, the object in the valid segment is relocated using the object mapping table, or the function in the valid segment is relocated using the function mapping table.

Specifically, when linking, it is necessary to relocate relocatable segments of all target files, establish symbol reference rules, and assign addresses to objects, functions, and the like. When the program is executed, the code is loaded into the address space specified by the link to ensure that the program correctly references the objects, functions and other symbols during the execution process, so that the program runs normally.

Two different relocation methods can be used based on the objects and function types extracted from the object file.

The first way is to relocate the object (obj):

The object is used in the .o file by writing the object's real address directly into the literal pool. When the object is dynamically loaded, the address of the object in the object pool is searched for by the address of the current object in the object mapping table, and the address of the jump object in the text pool is modified to the current object. the address of.

Specifically, the compiler puts the address of the object into the Literal Pool area. The Literal Pool only stores absolute addresses or constants. When relocation is required, the text pool is obtained from the current address of the object recorded in the object mapping table according to the object relocation information contained in .rel.text, .rel.data, .rel.bss, and .rel.rodata. The absolute address of the jump object recorded in the file, find the absolute address from the Literal Pool, in the dynamic loading, the absolute address in the text pool where the object is located is modified to the address where the current object is located, thus .text, .data, The objects contained in the .bss and .rodata sections are relocated.

The second way is to relocate the function (func):

For function relocation, you can use the address of the current function runtime and the function map The function address found in the shot table needs to jump to, the jump instruction is obtained through calculation, and the jump instruction obtained by the calculation is used to update the previous jump instruction, so as to jump to the jump instruction according to the update The address of the function to be executed.

Specifically, the function call jump uses a corresponding jump instruction, such as B/BL, etc., when the function is relocated, the function is relocated based on the function included in .rel.text, etc., and the function mapping table needs to jump. The real address of the function, according to the current address where the function is running, combined with the real address of the function that needs to be jumped from the function mapping table, after a series of calculations, the jump instruction is obtained, and the correct jump instruction is obtained. The jump instruction is updated to load the relocated function according to the updated jump instruction.

Of course, it is not only based on the object mapping table and the function mapping table to find the address. Since the object may refer to an external object or the function uses a dynamic library function when dynamically loaded, the corresponding information cannot be found in the object or function mapping table. When the address information indicates that the object or function refers to an external object or a dynamic library function, it is possible to dynamically find the address of the object or function for relocation, thereby implementing dynamic loading.

Please refer to FIG. 3. FIG. 3 is a schematic structural diagram of an apparatus for loading an ELF file according to the present invention. As shown in FIG. 3, the device includes: a parsing device 301, an extracting device 302, and a loading device 303. The following describes each device in detail:

The parsing device 301 is configured to parse a static library (.a) file in the ELF file to obtain an object file (.o).

The object file (.o) of the present invention is a re-directable file saved in ELF format, and the contents of the object file may contain entry marks and descriptions of the respective functions to form machine-executable instructions. When the program is to be executed, a link is also required. The link is to link multiple .o files into one executable file. Multiple .o object files can be archived into .a static Library files, and static library file lines become ELF files.

The purpose of the parsing device to parse the static library (.a) file is to obtain the object file (.o) therein.

The extracting device 302 is configured to extract a valid section from the acquired object file.

The valid sections are in the ELF file and are used to load the smallest container of content data. In the ELF file, each section is loaded with the same properties. ,

The specific type of the valid segment may include: an executable code segment, an application data segment, or a relocation segment. The executable code segment may specifically include a .text segment, etc., and the application data segment may include a .data segment, a .bss segment, or a .rodata segment, and the relocation segment may include a .rel.data segment and a .rel. Bss segment, or rel.rodata segment, etc.

among them

1) The executable file is loaded in the .text section;

2) The .data section is loaded with the initialized data;

3) The .bss section is loaded with uninitialized data;

The specific way to extract valid segments and pieces of information from the ELF Header and SHT of the object file can be:

The corresponding sections and serial numbers are known from the ELF Header. From the contents of the SHT, information such as the segment offset and the segment size are obtained according to the fields Off(sh_offset) and Size(sh_size) in the SHT.

The

devices

301 and 302 are configured to perform pre-loading preparation on the pre-loaded ELF file before the ELF file is dynamically loaded, and the preparation process may be performed simultaneously or sequentially, and the present invention does not strictly define the order of execution thereof. After execution, the loading of the valid segment of the object file is further implemented by the device 303.

The loading device 303 is configured to load a valid segment, establish an object mapping table and a function mapping table for the objects and functions in the object file, and re-locate the objects and functions in the valid segment loaded.

The loading device 303 can be further divided into three units: a valid segment loading unit 3031, a mapping table establishing unit 3032, and a relocating unit 3033. The first two units can perform corresponding operations simultaneously or in sequence, and the order in which the present invention is executed. Without stipulations, as long as the corresponding functions can be completed, they are all within the scope of the present invention.

The three units are described in detail below:

The valid segment unit 3031 is loaded.

For the valid segment extracted by the extracting unit 302, there are three types of executable code segments, application data segments, and relocation segments, wherein the executable code segment and the application data segment belong to a valid segment that needs to be loaded, and the relocation segment does not need to be Loading, for the valid segment to be loaded, it can be loaded into different regions in two ways according to its type.

The first way is to load the executable code segment (.text segment):

The loading methods for .data, .bss, and .rodata are slightly different from the loading method for .text segments. Compared to the loading of .text segments, the relocation process for .text segments is included before writing to Flash. In other words, the loading of .data, .bss, and .rodata does not require relocation before loading the segments into random access memory (RAM), but in accordance with .data, .bss, and .rodata. The valid segment information of the corresponding relocation segments (.rel.data, .rel.bss, and .rel.rodata) loads the .data, .bss, and .rodata segments directly into RAM.

The starting address of the segment is obtained based on the initialization of the valid segment after loading. The quantity and segment size are obtained based on the extracted valid segment when the valid segment is extracted.

In this embodiment, by loading an effective segment unit, the .text segment loaded with the executable code is separated from the application data of other application data segments, and the relocation information is created and loaded into the memory by the target file of the executable code. Thereby generating a memory mapping process, avoiding the process of copying the code data multiple times when loading the ELF file, and improving the running efficiency.

The mapping table establishing unit 3032 is configured to separately establish an object mapping table and a function mapping table for objects and functions in the object file.

This unit is used to establish an object mapping table (obj_map) and a function mapping table (func_map) according to the difference between the object and the function. The created mapping table is used for subsequent relocation and external calling.

The relocating unit 3033 is configured to relocate the objects and functions in the valid segment loaded.

This unit is used to relocate an object in a valid segment using an object mapping table, or to relocate a function in a valid segment using the function mapping table.

The first way is to relocate the object (obj):

The second way is to relocate the function (func):

For the relocation of the function, you can use the address of the current function runtime and the function address that needs to be jumped from the function mapping table. After the calculation, the jump instruction is obtained, and the jump instruction obtained by the calculation is used to jump to the previous jump. The instruction is updated to jump to the address of the function to be executed in accordance with the updated jump instruction.

Of course, it is not only based on the object mapping table and the function mapping table to find the address. Since the object may refer to an external object or the function uses a dynamic library function when dynamically loaded, the corresponding information cannot be found in the object or function mapping table. When the address information indicates that the object or function refers to an external object or a dynamic library function, the address of the object or function can be searched for relocation, thereby implementing dynamic loading.

The method and device for dynamically recording the ELF file of the present invention can be applied to various scenarios such as a set top box, a smart wearable device, and a smart home cloud. Take a set-top box as an example, when the user makes When the ELF file is started or installed by the set top box, the method and apparatus provided by the present invention can be used to implement dynamic loading of the ELF file by parsing and loading and relocating the static library file (.a).

The method and apparatus provided by the present invention can have the following advantages:

1) The present invention adopts a method of parsing a static library (.a) file and extracting a valid segment, loading a valid segment, and establishing an object and a function mapping table for relocating objects and functions in the relocatable segment respectively. These processing methods are not limited to a specific instruction set, thus solving the problem that the prior art cannot load ELF files in some embedded systems.

As an example, the present invention is particularly useful for supporting Cortex-M series processor embedded systems employing the Thumb-2 instruction set. Because the embedded Mbed OS is an operating system based on the ARM Cortex-M processor, Mbed os has a unique advantage as a system specifically tailored for embedded development. Currently, the Cortex-M series processors are already capable of supporting Mbed os, but currently Mbed os cannot provide ELF file loaders for the Cortex-M processors, thus limiting the Mbed os on the Cortex-M series processors. use. This is because the existing embedded operating system generates a executable file by static linking for the loading of ELF files, and burns the executable file to Flash. These operations must be completed under the ARM instruction set, but due to Cortex- The M-series processor instruction set uses the Thumb-2 instruction set, which does not support switching to the state of the ARM instruction set, so the prior art cannot provide a loader that dynamically parses the loaded ELF file for such processors.

The method and apparatus provided by the present invention converts an idea not to generate an executable file by static linking and directly load the memory, nor to parse and load the ELF file through a specific ARM instruction set. Instead, parse the static library file of the ELF file. To obtain a valid segment of the ELF relocatable object file and relocate it so that objects and functions in the ELF file can be dynamically loaded in a relocatable manner. The processes of the present invention are not limited to a particular ARM instruction set and are therefore particularly well-suited for supporting Cortex-M series processor embedded systems employing the Thumb-2 instruction set.

2) In the prior art, an executable file is generated by static linking, and the executable file is burned to Flash, so the number of applications running is limited by the number of executable files burned in Flash. The present invention adopts a dynamic loading mode, based on which dynamic linking can be implemented, and the number of running applications is no longer limited by the number of executable files in the Flash.

3) The way of static linking requires generating an executable file and loading it into Flash, which results in a larger file size and higher power consumption. The dynamic loading method of the present application greatly reduces file size and power consumption compared to the prior art.

In the several embodiments provided by the present invention, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. For example, the device embodiments described above are merely illustrative. For example, the division of the unit is only a logical function division, and the actual implementation may have another division manner.

The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above integrated unit can be implemented in the form of hardware or in the form of hardware plus software functional units.

The above are only the preferred embodiments of the present invention, and are not intended to limit the present invention. Any modifications, equivalents, improvements, etc., which are made within the spirit and principles of the present invention, should be included in the present invention. Within the scope of protection.

Claims

A method of loading an ELF file having an executable and link format, the method comprising:

Parsing a static library file in the ELF file to obtain an object file;

Extracting a valid segment from the object file;

Loading a valid segment, and establishing an object mapping table and a function mapping table for the objects and functions in the object file, respectively, for relocating the objects and functions in the loaded valid segment.
The method of claim 1 wherein the extracted valid segment comprises: an executable code segment, an application data segment, or a relocation segment.
The method according to claim 1 or 2, wherein the valid segment is extracted according to the ELF file header and the segment file header table of the object file.
The method according to claim 1 or 2, wherein the loading the valid segment comprises: loading different types of valid segments into different regions respectively.
The method according to claim 4, wherein the loading different types of valid segments into different regions separately comprises:

Relocating the executable code segment according to the executable code segment and the segment information of the corresponding relocation segment, and writing the re-executed executable code segment to Flash; or

The application data segment is directly loaded into the RAM according to the application data segment and the segment information of the corresponding relocation segment.
The method according to claim 5, wherein the segment information comprises a segment number, a segment offset or a segment size.
The method according to claim 5, wherein said executable code segment comprises a .text segment, and said application data segment comprises a .data segment, a .bss segment, or a .rodata segment, said weight The positioning segment includes a .rel.data segment, a .rel.bss segment, or a .rel.rodata segment.
The method according to claim 1 or 2, wherein after the loading of the valid segment, the valid segment of the object file is marked with at least one of the following: a starting address of the segment, a segment offset, a segment size.
The method of claim 1 wherein:

The mapping table entry of the object mapping table includes an object name and an object address, and the object address is obtained by searching for an export object in the valid segment according to the address of the export object;

The mapping table entry of the function mapping table includes a function name and a function address, and the function address is obtained by searching for an export function in the valid segment according to an address where the derived function is located.
The method according to claim 1, wherein when the object in the valid segment is relocated, the address of the current object in the object mapping table is used to find the jump object of the object in the text pool. Address and modify the address of the jump object in the literal pool to the address of the current object.
The method according to claim 1, wherein when the function in the valid segment is relocated, the address of the current function runtime and the address of the function to be jumped from the function mapping table are used. The jump instruction is calculated, and the jump instruction obtained by the calculation is used to update the previous jump instruction, so as to jump to the function address to be executed according to the updated jump instruction.
An apparatus for loading an ELF file, the apparatus comprising:

a parsing device, configured to parse the static library file in the ELF file to obtain an object file;

An extracting device, configured to extract a valid segment from the object file;

a loading device for loading a valid segment, respectively for objects and functions in the object file An object mapping table and a function mapping table are created and used to relocate objects and functions in the loaded valid segment.
The apparatus for loading an ELF file according to claim 12, wherein the valid segment extracted in the extracting device comprises: an executable code segment, an application data segment or a relocation segment.
The apparatus for loading an ELF file according to claim 12 or 13, wherein said extracting means is configured to extract a valid segment based on an ELF file header and a segment header table of said object file.
The apparatus for loading an ELF file according to claim 12 or 13, wherein the loading device loading the valid segment comprises: loading different types of valid segments into different regions respectively.
The apparatus for loading an ELF file according to claim 15, wherein the loading device performs: when loading different types of valid segments into different regions, respectively:

Relocating the executable code segment according to the executable code segment and the segment information of the corresponding relocation segment, and writing the re-executed executable code segment to Flash; or

The application data segment is directly loaded into the RAM according to the application data segment and the segment information of the corresponding relocation segment.
The apparatus for loading an ELF file according to claim 16, wherein the segment information comprises a segment number, a segment offset or a segment size.
The apparatus for loading an ELF file according to claim 16, wherein the executable code segment comprises a .text segment, and the application data segment comprises a .data segment, a .bss segment, or a .rodata segment, the weight The positioning segment includes a .rel.data segment, a .rel.bss segment, or a .rel.rodata segment.
The apparatus for loading an ELF file according to claim 12 or 13, wherein After performing the loading valid segment, the loading device is further configured to perform at least one of the following markings on the valid segment of the object file: a starting address of the segment, a segment offset, and a segment size.
The apparatus for loading an ELF file according to claim 12, wherein:

The mapping table entry of the object mapping table includes an object name and an object address, and the object address is obtained by searching for an export object in the valid segment according to the address of the export object;

The mapping table entry of the function mapping table includes a function name and a function address, and the function address is obtained by searching for an export function in the valid segment according to an address where the derived function is located.
The apparatus for loading an ELF file according to claim 12, wherein the loading device performs: when relocating an object in the valid segment, specifically:

The address of the jump object of the object in the text pool is searched for by the address of the current object in the object mapping table, and the address of the jump object in the text pool is modified to the address of the current object.
The apparatus for loading an ELF file according to claim 12, wherein the loading device performs: when relocating a function in the valid segment, using the address of the current function runtime and searching from the function mapping table. The address of the function to be jumped to, the jump instruction is calculated, and the jump instruction obtained by the calculation is used to update the previous jump instruction, so as to jump to the upcoming execution according to the updated jump instruction. Function address.
a device, including

One or more processors;

Memory

One or more programs, the one or more programs being stored in the memory, when executed by the one or more processors:

Parsing a static library file in the ELF file to obtain an object file;

Extracting a valid segment from the object file;

Loading a valid segment, and establishing an object mapping table and a function mapping table for the objects and functions in the object file, respectively, for relocating the objects and functions in the loaded valid segment.
A computer storage medium encoded with a computer program, when executed by one or more computers, causes the one or more computers to perform the following operations:

Parsing a static library file in the ELF file to obtain an object file;

Extracting a valid segment from the object file;

Loading a valid segment, and establishing an object mapping table and a function mapping table for the objects and functions in the object file, respectively, for relocating the objects and functions in the loaded valid segment.