Redundant symbol searching method and apparatus, terminal and medium

Abstract

The embodiment of the application discloses a kind of redundant symbol search method, device, terminal and medium, belong to binary file field, the method includes: obtaining the ELF file of compilation completion, extract the reference relationship of function from the symbol table, relocation table, code section and debugging information of ELF file;From program entry and dynamic call point, recursively, according to the reference relationship, build symbol reference graph;From the preset function use starting point, traverse the symbol reference graph, obtain the use function set;All function symbols that appear in the code section of ELF file are compared with the use function set, and redundant function is obtained according to the comparison result.Can quickly and accurately find the redundant function in ELF file, provide accurate cleaning target for later on ELF file slimming.

Description

Technical Field

[0001] This invention relates to the field of software optimization technology, and in particular to a method, apparatus, terminal, and medium for finding redundant symbols. Background Technology

[0002] As production processes become more complex and delivery more agile, an increasing number of users are choosing to build application binaries using static compilation techniques. This approach, by compiling and packaging all dependent library code along with business logic code into a single executable file, offers advantages such as easy deployment, fewer runtime dependencies, and rapid startup. Therefore, it is widely used in scenarios such as microservices, container images, and embedded systems.

[0003] Binary files are generated using static compilation, which refers to the process of directly converting program code into machine instructions during the compilation phase. All external dependencies (such as library functions) are also fully embedded in the final executable file. Staticly compiled programs do not depend on external libraries in the runtime environment, exhibiting greater independence and portability. For example, when using static linking libraries in C, the compiler directly merges the code of standard library functions into the output file, generating a binary program that is ready to use out of the box without requiring additional dependencies. Because static compilation completely copies all dependent libraries (including standard and third-party libraries) into the final binary, the size of the compiled executable file continues to increase with the growth of software size, often containing a large number of function symbols that are not actually called. Existing technologies mainly rely on the compiler's LTO (LinkTime Optimization) mechanism or manual source code trimming to reduce redundant functions. However, this approach requires comprehensive analysis of the binary file to identify redundant symbols. Due to the complex relationships between symbols, this results in time-consuming processes and low accuracy in the checks. Summary of the Invention

[0004] This invention provides a method, apparatus, terminal, and medium for finding redundant symbols, in order to solve the technical problem that the redundancy symbol checking is time-consuming and has low accuracy in the process of slimming down statically compiled binary files in the prior art.

[0005] In a first aspect, embodiments of the present invention provide a method for finding redundant symbols, including:

[0006] Obtain the compiled ELF file and extract function references from the symbol table, relocation table, code sections, and debugging information of the ELF file;

[0007] Recursively traverse downwards from the program entry point and dynamic call point, constructing a symbolic reference graph based on the aforementioned reference relationships;

[0008] Starting from the preset function usage starting point, traverse the symbol reference graph to obtain the set of used functions;

[0009] Compare all function symbols appearing in the ELF file code segment with the set of functions to be used, and obtain redundant functions based on the comparison results;

[0010] The extraction of function references from the symbol table, relocation table, code sections, and debugging information of the ELF file includes:

[0011] Parse the ELF header and section header table to obtain the section list;

[0012] The function is extracted from the symbol table section;

[0013] The relocation table identifies the reference location of the function;

[0014] The function reference relationships are obtained in the relocation table based on the reference positions;

[0015] Obtain supplementary reference relationships from the debugging information, and use these supplementary reference relationships to improve the reference relationships, thus obtaining a complete reference relationship.

[0016] Secondly, embodiments of the present invention also provide a redundant symbol lookup device, comprising:

[0017] The acquisition module is used to acquire the compiled ELF file and extract function references from the symbol table, relocation table, code sections, and debugging information of the ELF file.

[0018] The building module is used to recursively construct a symbolic reference graph based on the reference relationships, starting from the program entry point and dynamic call point;

[0019] The traversal module is used to traverse the symbol reference graph starting from a preset function usage starting point to obtain the set of used functions;

[0020] The comparison module is used to compare all function symbols appearing in the code segment of the ELF file with the set of functions to be used, and to obtain redundant functions based on the comparison results;

[0021] The acquisition module includes:

[0022] The parsing unit is used to parse the ELF header and section header table to obtain the section list;

[0023] The function extraction unit is used to extract functions from the symbol table section;

[0024] An identifier unit is used to identify the reference position of the function in the relocation table;

[0025] The reference relationship obtaining unit is used to obtain the function reference relationship in the relocation table based on the reference position;

[0026] The reference relationship acquisition unit is used to obtain supplementary reference relationships from debugging information, and to improve the reference relationships using the supplementary reference relationships to obtain complete reference relationships.

[0027] Thirdly, embodiments of the present invention also provide a terminal, including:

[0028] One or more processors;

[0029] Storage device for storing one or more programs.

[0030] When the one or more programs are executed by the one or more processors, the one or more processors implement the redundant symbol lookup method as described in any of the above embodiments.

[0031] Fourthly, embodiments of the present invention also provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the redundant symbol lookup method provided in the above embodiments.

[0032] The redundant symbol lookup method, apparatus, terminal, and medium provided in this invention obtain a compiled ELF file and extract function reference relationships from the ELF file's symbol table, relocation table, code sections, and debugging information. It recursively constructs a symbol reference graph based on these reference relationships, starting from the program entry point and dynamic call point. From a preset function usage starting point, it traverses the symbol reference graph to obtain a set of used functions. All function symbols appearing in the ELF file's code segment are compared with the set of used functions, and redundant functions are obtained based on the comparison results. This method can extract all functions corresponding to symbols in the ELF file, along with their corresponding reference relationships, and create a symbol reference graph using the symbols and reference relationships. By traversing the symbol reference graph according to preset nodes, the set of functions used in the ELF file is determined, and by comparing all functions corresponding to symbols in the ELF file with the set of used functions, a set of unused functions is obtained as redundant functions. Using this method, redundant functions in the ELF file can be quickly and accurately found, providing accurate targets for subsequent ELF file slimming. It can directly perform redundant function identification based on ELF binary files, and is suitable for closed-source scenarios or scenarios where only the target file is provided. It achieves a complete expression of the call relationship by recursively constructing a function reference graph, which further improves the accuracy of the inspection. It can distinguish the usage of different functions in the same section, and the detection granularity is finer. It adopts a static traversal algorithm, and the identification process does not depend on runtime information, so the analysis efficiency is higher. Attached Figure Description

[0033] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0034] Figure 1 This is a flowchart illustrating the redundant symbol lookup method provided in Embodiment 1 of the present invention;

[0035] Figure 2 This is a flowchart illustrating the redundant symbol lookup method provided in Embodiment 2 of the present invention;

[0036] Figure 3 This is a schematic diagram of the redundant symbol lookup device provided in Embodiment 3 of the present invention;

[0037] Figure 4 This is a schematic diagram of the terminal provided in Embodiment 4 of the present invention. Detailed Implementation

[0038] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0039] Example 1

[0040] Figure 1 This is a flowchart of a redundant symbol lookup method provided in Embodiment 1 of the present invention. This embodiment is applicable to scenarios involving the rapid lookup of redundant symbols in ELF files. The method can be executed by a redundant symbol lookup device and specifically includes the following steps:

[0041] Step 110: Obtain the compiled ELF file and extract the function reference relationships from the symbol table, relocation table, code section, and debugging information of the ELF file.

[0042] A binary file is a machine code file that a computer can execute directly. It is usually generated by a compiler from a high-level language (such as C, Rust) or assembly language. It is stored in binary (0 and 1) form and contains instructions and data that the processor can directly execute, such as executable programs (such as .exe in Windows or / bin / ls in Linux), static libraries (.a) or dynamic libraries (.so / .dll).

[0043] Unlike text files, binary files cannot be read directly, but they are highly efficient and are typically optimized by compilers to improve execution speed or reduce storage space. ELF (Executable and Linkable Format) is a common binary file format standard in Unix / Linux systems. As ELF file sizes continue to increase, delivery efficiency and deployment resource consumption rise accordingly. This expansion is mainly reflected in: during static linking, entire sections of the object file are completely packaged, even if only some symbols are used; unused functions or variables are also linked because they are in the same section as the code that uses them; and as the project scales up, the generated executable file often contains a large amount of redundant code and data that is not actually used.

[0044] Furthermore, many binary artifacts originate from upstream build pipelines, and users typically only possess the final ELF file, without the complete source code or build scripts. In some scenarios, recompiling static libraries or executables is not permitted for delivery stability reasons. This makes traditional compiler-dependent source code optimization methods (such as -ffunction-sections and -gc-sections) unsuitable for these types of ELF files.

[0045] In view of this, this embodiment provides a method for finding redundant symbols in compiled ELF files without requiring source code.

[0046] This method extracts the symbol table, relocation table, code section, and debugging information by parsing the ELF header and section header table, and establishes reference relationships between functions.

[0047] In this embodiment, function references can be extracted from the symbol table, relocation table, code sections, and debugging information of an existing compiled ELF file. This can include: parsing the ELF header and section header table to obtain a section list; extracting functions from the symbol table sections; identifying the reference positions of the functions in the relocation table; obtaining the function reference relationships based on the reference positions in the relocation table; obtaining supplementary reference relationships from the debugging information; and using these supplementary reference relationships to complete the reference relationships, resulting in a complete set of reference relationships.

[0048] The sections in an ELF file are interconnected: the symbol table records symbol names, types (functions / variables), binding attributes (global / local), and addresses; the relocation table marks the locations of instructions in the code that need relocation; the code section stores machine instructions; and debugging information provides the mapping relationship between functions and source code. For example, this may include: parsing the ELF header and section header table to determine the section layout; extracting function definitions and reference information from the symbol table section (.symtab); identifying function call locations from the relocation table (.rela.text, etc.); establishing reference relationships between functions based on the relocation information; and supplementing source-level call relationships from debugging information (such as .debug_info, .debug_line). Using these supplementary reference relationships, the reference relationships can be improved. For example, different reference relationships can be found and added to the set of function reference relationships obtained based on the reference locations to obtain a complete reference relationship.

[0049] By combining the above information, the function reference network inside the ELF file can be completely reconstructed, providing a foundation for subsequent redundant function detection.

[0050] Step 120: Recursively build a symbolic reference graph from the program entry point and dynamic call point downwards based on the reference relationships.

[0051] For example, a symbolic reference graph can be constructed by recursively traversing downwards from the program entry point, using functions extracted from `.symtab` as nodes and the obtained reference relationships as edges. If unconnected nodes are encountered, the recursion can continue downwards from the dynamic call point. Alternatively, a symbolic reference graph can be constructed by recursively traversing downwards from the ELF file's program entry point, using functions extracted from `.symtab` as graph nodes and the reference relationships between functions as directed edges. If nodes not directly connected are encountered during the recursion, the recursion can be further extended downwards from the dynamic call point to capture dynamically bound paths such as function pointers and virtual function tables.

[0052] Step 130: Starting from the preset function usage starting point, traverse the symbol reference graph to obtain the set of usage functions.

[0053] For example, the preset function usage starting point may include: the main function or the entry point marked in the dynamic link table; the initialization function registered through _attribute_((constructor)); externally referenced symbols in the dynamic symbol table (.dynsym); and call relationship information in the debug sections .eh_frame and .debug_info. The main function or the entry point marked in the dynamic link table can be regarded as the logical starting point from the perspective of C / C++ source code, and can be used to cover most user code paths. The initialization function registered through _attribute_((constructor)) can be regarded as all function pointers automatically executed by the dynamic linker before main. It can be used to cover hidden entry points such as static initialization, global object construction, framework self-checking, and hook injection. The externally referenced symbols in the dynamic symbol table .dynsym can be all symbols exported by the dynamic linker (STB_GLOBAL / STB_WEAK) and of type STT_FUNC, and can enumerate functions that may be called externally at once. It can serve as a supplement to the usage functions obtained dynamically and statically as described above. The call relationship information in the debug section `.eh_frame` and `.debug_info` can include the CFI used for runtime stack rollback, providing basic block boundaries and return address information; `debug_info` is DWARF debugging information, containing the function table and call points for each compilation unit. Using this information, it's possible to deduce which function addresses appeared at the call points, thus completing the call relationships missing from the previous three static tables. Implicit calls via function pointer tables, virtual tables, `boost::function`, and TLS callbacks can be retrieved. In existing technologies, only functions involved in the user code path are typically considered as used functions. However, this embodiment fully considers all factors, thus perfecting the function usage starting point and enabling the acquisition of complete used functions. Starting from the four types of entry nodes, a reachability traversal is performed along the edges of the call relationship, finally obtaining the set of used functions, i.e., the list of functions that will actually be executed on the entire call tree.

[0054] Step 140: Compare all function symbols appearing in the ELF file code segment with the set of functions to be used, and obtain redundant functions based on the comparison results.

[0055] For example, the set of function symbols in the ELF file extracted in the above steps can be compared with the set of functions obtained in the above steps to obtain a set of functions that are not actually used, which are redundant functions.

[0056] This embodiment obtains the compiled ELF file and extracts function reference relationships from the ELF file's symbol table, relocation table, code sections, and debugging information. It recursively constructs a symbol reference graph based on these reference relationships, starting from the program entry point and dynamic call point. From a preset function usage starting point, it traverses the symbol reference graph to obtain the set of used functions. All function symbols appearing in the ELF file's code segment are compared with the set of used functions, and redundant functions are obtained based on the comparison results. This method can extract the functions corresponding to all symbols in the ELF file, along with their corresponding reference relationships, and create a symbol reference graph using these symbols and reference relationships. By traversing the symbol reference graph according to preset nodes, the set of functions used in the ELF file is determined, and by comparing the functions corresponding to all symbols in the ELF file with the set of used functions, a set of unused functions is obtained as redundant functions. Using this method, redundant functions in the ELF file can be quickly and accurately located, providing accurate targets for subsequent ELF file slimming. It can directly perform redundant function identification based on ELF binary files, and is suitable for closed-source scenarios or scenarios where only the target file is provided. It achieves a complete expression of the call relationship by recursively constructing a function reference graph, which further improves the accuracy of the inspection. It can distinguish the usage of different functions in the same section, and the detection granularity is finer. It adopts a static traversal algorithm, and the identification process does not depend on runtime information, so the analysis efficiency is higher.

[0057] Example 2

[0058] Figure 2 This is a flowchart illustrating the redundant symbol lookup method provided in Embodiment 2 of the present invention. This embodiment is an optimization based on the above embodiment, and the method may further include the following steps: constructing an address mapping table from symbols to offsets within sections; using the address mapping table to locate the position of redundant functions; setting the machine code region of the redundant function in the code section to NOP or INT3 instructions according to the position of the redundant function; updating the size and address mapping of redundant functions in the .symtab and .debug_* sections; determining whether there are address misalignments or mismatches according to the address mapping table and performing corresponding processing; and rewriting the section where the redundant function exists based on the content of the deleted redundant function.

[0059] See Figure 2 The redundant symbol lookup method includes:

[0060] Step 210: Obtain the compiled ELF file and extract the function reference relationships from the symbol table, relocation table, code section, and debugging information of the ELF file.

[0061] Step 220: Recursively traverse downwards from the program entry point and dynamic call point, construct a symbolic reference graph based on the reference relationships, and traverse the symbolic reference graph from the preset function usage starting point to obtain the set of used functions.

[0062] Step 230: Compare all function symbols appearing in the ELF file code segment with the set of functions to be used, and obtain redundant functions based on the comparison results.

[0063] Step 240: Construct an address mapping table from symbols to section offsets, and use the address mapping table to locate the position of redundant functions.

[0064] This embodiment can be applied to technical scenarios where unused functions are removed (or logically deleted) from ELF binary files of x86_64 or aarch64 architectures without destroying debugging information, so as to achieve both file size optimization and debugging usability.

[0065] After identifying redundant functions, they can be processed to reduce the size of the statically compiled binary file. Current technologies typically consider stripping the symbol table or debugging information to reduce file size. However, in real-world production environments, especially when anomalies occur at customer sites, R&D or operations personnel often need to use the symbol table (.symtab) and debugging information in the binary file for symbol resolution, call stack tracing, variable location, and other debugging tasks. Separating debugging information into a separate file adds complexity to the delivery and management process. Therefore, simply stripping the symbol table and separating debug files severely impacts problem localization efficiency and does not meet the operational and support needs of business scenarios.

[0066] Furthermore, ELF organizes code and data with sections as the smallest processing unit, and the linker does not strip at the function level; even if some functions are not called, the linker will retain the entire section in which they are located; current mainstream slimming methods (such as strip, objcopy-remove-section, etc.) often destroy the symbol table, delete debugging information, or affect symbol address mapping, making them unusable in production debugging environments.

[0067] Therefore, in this embodiment, a non-destructive approach is adopted. In order to accurately modify the target ELF file, an address mapping table needs to be established in advance. For example, the correspondence between symbols and sections and offsets within the file needs to be established so as to process redundant functions in a targeted manner.

[0068] For example, constructing the address mapping table from symbols to section offsets may include: parsing the section header table to find the names, offsets, and sizes of all sections, and determining the section indices of the symbol table and string table; parsing the symbol table to record the offsets and sizes of symbols within sections; parsing the program header table to record the virtual address range of each segment; matching the virtual address (sh_addr) of the section with the virtual address range of the segment to determine the segment where the symbol resides; calculating the absolute offset of the symbol in the file; and writing the absolute offset and size of the symbol using a pre-established mapping table structure. By parsing the symbol table, a mapping from symbol names to section offsets and sizes is constructed. Combined with the program header table, the segment where each symbol resides is determined, and its offset and size in the file are calculated. Optionally, this can be implemented in the following way:

[0069] Parse the section header table:

[0070] Using readelf-S<elf_file> View the name, offset, and size of all sections.

[0071] Records the section indexes for the symbol table (.symtab or .dynsym) and the string table (.strtab or .dynstr).

[0072] Symbol table for parsing:

[0073] Each symbol entry contains: st_name: the offset of the symbol name in the string table.

[0074] st_value: The address of the symbol (offset or virtual address in the section).

[0075] st_size: The size of the symbol.

[0076] st_shndx: The index of the section to which the symbol belongs.

[0077] Symbols are associated with sections via st_shndx, which records the symbol's offset (st_value) and size (st_size) within the section.

[0078] step:

[0079] Parse the program header table:

[0080] Use readelf-l<elf_file> View segment information.

[0081] Record the virtual address range (p_vaddr to p_vaddr+p_memsz) for each segment.

[0082] Related sections and segments:

[0083] The section's virtual address (sh_addr) is matched with the segment's virtual address range to determine the segment in which the symbol resides.

[0084] For example, if a symbol's st_value (offset) is within the range of a segment's p_offset, then the symbol belongs to that segment.

[0085] Calculate the absolute offset of the symbol in the file:

[0086] The offset of a symbol in the file = the p_offset of the segment + the offset of the symbol within the section (st_value - sh_addr of the section).

[0087] Build the mapping table:

[0088] Example mapping table structure:

[0089] {

[0090] "symbol_name":{

[0091] "section":"section_name",

[0092] "offset_in_section":0x1234,

[0093] "size":0x56,

[0094] "virtual_address":0x8048000

[0095] }, ...

[0096] }

[0097] This mapping table allows you to directly locate the precise byte range of each redundant function within the file.

[0098] Step 250: Based on the location of the redundancy function, set the machine code region of the redundancy function in the code section to NOP or INT3 instruction.

[0099] Setting the machine code region of the corresponding function in the .text file to NOP or INT3 instructions can be used as a placeholder without affecting the layout. It maintains the address space, preventing address drift for subsequent functions. It transforms the instruction semantics into a no-operation, eliminating the need to recalculate any references and significantly simplifying the pipeline. In cases of missed jumps, resulting in a deleted function's address being jumped to, NOP can be used to sequentially slide to the next valid instruction. This ensures program correctness while also providing debuggability, alignment, auditability, and optimization potential.

[0100] For redundant functions, their corresponding machine code can be removed from the .text section, thus reducing the actual size of the .text section. After deletion, the offsets and virtual addresses of subsequent functions will be shifted forward as a whole. The data in the .text section can be directly modified using ELF operation libraries (such as libelf, pyelftools) or tools such as objcopy.

[0101] Step 260: Update the size and address mapping of redundant functions in the .symtab and .debug_* sections.

[0102] After redundant functions are removed, the relevant information in the ELF file needs to be updated synchronously. This may include: deleting redundant function symbol entries; adjusting the st_value (inter-section offset / virtual address) of subsequent function symbols;

[0103] Preserve symbol names and section indexes (optional) to ensure the debugger recognizes symbols, supports stack backtracking, and updates debugging information (.debug_info, .debug_line, .debug_ranges, etc.). Delete or compress DWARFDIE entries corresponding to redundant functions; adjust the start and end addresses and line number mappings of subsequent functions to maintain the correct correspondence between source code and instructions; ensure the debugger is unaffected during stack backtracking, variable location, breakpoint setting, and other operations. For example, based on all functions set to NOP / INT3 in the above steps, sort them by address from smallest to largest, and calculate the modified shortcut position. In the .symtab section, modify the length and type of symbols for redundant functions, and modify the symbols for non-redundant functions. Determine if the address is affected by functions set to NOP / INT3. If affected, modify the address accordingly. In the `.debug_*` section, remove the influence of functions set to NOP / INT3, and find the DIE corresponding to the address of the function set to NOP / INT3 at its starting address. Change its start and end addresses to the same empty interval so that the debugger will not be affected when unrolling the stack and backtracking. Also, modify the addresses of symbols for non-redundant functions to ensure that source code line numbers, variable addresses, and inline points correspond one-to-one. Finally, delete the segment corresponding to the address of the function set to NOP / INT3 in the address range table.

[0104] Step 270: Determine whether there are address misalignments or mismatches based on the address mapping table, and perform corresponding processing; rewrite the sections containing redundant functions based on the content of the deleted redundant functions.

[0105] For example, the address and size of redundant functions can be determined based on the address mapping table. The starting address and length of subsequent sections, symbols, relocations, and debug items can be adjusted based on the address and size of the redundant functions. It is necessary to determine if any new addresses in the remaining functions fall within the addresses of redundant functions, or if the removal of redundant functions has resulted in new function addresses not being aligned to the originally required byte boundaries. In such cases, the function addresses need to be processed to meet the modified requirements. After overwriting redundant functions, the legality of the section layout should be further verified. For example, this may include: address alignment detection and correction; section content rewriting; and verification of the ELF structure. According to ELFABI requirements, function addresses should be aligned (e.g., 16 or 32 bytes); insufficient alignment can be filled with NOP instructions; the .text section content can be directly modified without moving the section order; if the redundant debug section is deleted, the section header offset (e_shoff) needs to be updated; the offsets and sizes of ELFHeader, ProgramHeader, and SectionHeader must be confirmed to ensure the loader can load correctly.

[0106] This embodiment adds the following steps: Constructing an address mapping table from symbols to section offsets; using this table to locate redundant functions; setting the machine code region of the redundant function in the code section to NOP or INT3 instructions based on its location; updating the size and address mapping of redundant functions in the .symtab and .debug_* sections; determining whether there are address misalignments or mismatches based on the address mapping table and performing corresponding processing; rewriting the section containing the redundant function based on the content of the deleted redundant function. This allows for targeted deletion of redundant functions without affecting normal use, ensuring that addresses are not used to delete redundant functions and without affecting function address alignment. It achieves a streamlined ELF binary file that is functionally intact, smaller in size, debuggable, and loads legally. It overcomes the limitation of traditional linkers retaining code on a section-by-section basis, achieving true binary slimming. DWARF information can still be used for symbol resolution and stack backtracking, and the size of the .text section and symbol table is reduced, resulting in a lower overall ELF file size. NOP padding maintains loader-acceptable alignment boundaries without requiring relinking; the section header table, program header table, and relocation table remain valid.

[0107] In a preferred embodiment of this example, the method may further include the following steps: In the debug segment, retain the debug information entity of the redundant function symbol, and add an optimized deletion mark to the redundant function, or set the debug information entity of the redundant function to an empty segment; clear or remove the .eh_frame entry of the redundant function. Using the above method, redundant functions can be marked with an optimized deletion mark instead of being directly erased in the debug segment, while the corresponding .eh_frame stack rollback table is completely cleared. This method allows developers to clearly identify the corresponding deletion mark, while also allowing the exception handling mechanism to skip the dead zone generated by deletion.

[0108] In another preferred embodiment of the present invention, the method may further include the following steps: verifying the consistency of the section headers and checking whether the reserved section headers have changed; verifying that the index relationship of the debug section is free of broken links and that no dynamically loaded symbols are lost. Using the above method, it can be ensured that the slimmed-down ELF file structure is valid and can be loaded and debugged normally.

[0109] Example 3

[0110] Figure 3 This is a schematic diagram of the redundant symbol lookup device provided in Embodiment 3 of the present invention. See also: Figure 3 The redundant symbol lookup device includes:

[0111] The module 310 is used to obtain the compiled ELF file and extract the function reference relationships from the symbol table, relocation table, code section and debugging information of the ELF file;

[0112] Module 320 is used to recursively construct a symbolic reference graph based on the reference relationships, starting from the program entry point and dynamic call point.

[0113] Traversal module 330 is used to traverse the symbol reference graph starting from a preset function usage starting point to obtain the set of used functions;

[0114] The comparison module 340 is used to compare all function symbols appearing in the code segment of the ELF file with the set of functions used, and obtain redundant functions based on the comparison results;

[0115] The acquisition module includes:

[0116] The parsing unit is used to parse the ELF header and section header table to obtain the section list;

[0117] The function extraction unit is used to extract functions from the symbol table section;

[0118] An identifier unit is used to identify the reference position of the function in the relocation table;

[0119] The reference relationship obtaining unit is used to obtain the function reference relationship in the relocation table based on the reference position;

[0120] The reference relationship acquisition unit is used to obtain supplementary reference relationships from debugging information, and to improve the reference relationships using the supplementary reference relationships to obtain complete reference relationships.

[0121] The redundant symbol lookup device provided in this embodiment obtains the compiled ELF file and extracts function reference relationships from the ELF file's symbol table, relocation table, code sections, and debugging information. It recursively constructs a symbol reference graph based on these reference relationships, starting from the program entry point and dynamic call point. From a preset function usage starting point, it traverses the symbol reference graph to obtain the set of used functions. It compares all function symbols appearing in the ELF file's code segment with the set of used functions and obtains redundant functions based on the comparison results. This device can extract all functions corresponding to symbols in the ELF file, along with their corresponding reference relationships, and create a symbol reference graph using the symbols and reference relationships. By traversing the symbol reference graph according to preset nodes, it determines the set of functions used in the ELF file and compares all functions corresponding to symbols in the ELF file with the set of used functions to obtain a set of unused functions as redundant functions. Using this method, redundant functions in the ELF file can be quickly and accurately found, providing accurate targets for subsequent ELF file slimming. It can directly perform redundant function identification based on ELF binary files, and is suitable for closed-source scenarios or scenarios where only the target file is provided. It achieves a complete expression of the call relationship by recursively constructing a function reference graph, which further improves the accuracy of the inspection. It can distinguish the usage of different functions in the same section, and the detection granularity is finer. It adopts a static traversal algorithm, and the identification process does not depend on runtime information, so the analysis efficiency is higher.

[0122] Based on the above embodiments, the preset function start point includes:

[0123] The entry point marked in the main function or in the dynamic link table;

[0124] Initialization functions registered via _attribute_((constructor));

[0125] Symbols referenced externally in dynamic symbols (.dynsym);

[0126] And the call relationship information in the debug section .eh_frame, .debug_info.

[0127] Based on the above embodiments, the device further includes:

[0128] The building module is used to construct an address mapping table from symbols to section offsets, and the address mapping table is used to locate the location of redundant functions;

[0129] The module is set to a NOP or INT3 instruction in the machine code region of the code section based on the location of the redundant function.

[0130] The update module is used to update the size and address mapping of redundant functions in the .symtab and .debug_* sections;

[0131] The judgment module is used to determine whether there is an address misalignment or mismatch based on the address mapping table, and to perform corresponding processing.

[0132] The rewrite module is used to rewrite sections where redundant functions exist, based on the content of the deleted redundant functions.

[0133] Based on the above embodiments, the building module includes:

[0134] The first parsing unit is used to parse the section header table, find the name, offset and size of all sections, and determine the section indices of the symbol table and string table;

[0135] The second parsing unit is used to parse the symbol table and record the offset and size of the symbol within the section;

[0136] The third parsing unit is used to parse the program header table and record the virtual address range of each segment;

[0137] The matching unit is used to match the virtual address of a section with the virtual address range of a segment to determine the segment in which the symbol is located;

[0138] A calculation unit used to calculate the absolute offset of a symbol within a file;

[0139] The write unit is used to write the absolute offset and size of a symbol using a pre-established mapping table structure.

[0140] Based on the above embodiments, the device further includes:

[0141] The retention module is used to retain the debugging information entity of redundant function symbols in the debugging section, and add an optimized deletion mark to the redundant function, or set the debugging information entity of the redundant function to an empty section;

[0142] The clear module is used to clear or remove the .eh_frame entries of the redundant functions.

[0143] Based on the above embodiments, the device further includes:

[0144] The verification module is used to verify the consistency of the section header and check whether the reserved section header has changed;

[0145] The verification module is used to verify that the index relationship of the debug section is not broken and that no dynamically loaded symbols are lost.

[0146] The redundant symbol lookup device provided in this embodiment of the invention can execute the redundant symbol lookup method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0147] Example 4

[0148] Figure 4 This is a schematic diagram of the structure of a terminal provided in Embodiment 4 of the present invention. Figure 4 A block diagram is shown of an exemplary terminal 12 suitable for implementing embodiments of the present invention. Figure 4 The terminal 12 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0149] like Figure 4 As shown, terminal 12 is presented in the form of a general-purpose computing device. The components of terminal 12 may include, but are not limited to: one or more processors or processing units 16, memory 28, and a bus 18 connecting different system components (including memory 28 and processing unit 16).

[0150] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0151] Terminal 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by terminal 12, including volatile and non-volatile media, removable and non-removable media.

[0152] Memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Terminal 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 4 Not shown; usually referred to as a "hard drive"). Although Figure 4Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. Memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0153] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in memory. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0154] Terminal 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with terminal 12, and / or with any device that enables terminal 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 22. Furthermore, terminal 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. As shown, network adapter 20 communicates with other modules of terminal 12 via bus 18. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with terminal 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0155] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory, such as implementing the redundant symbol lookup method provided in the embodiments of the present invention.

[0156] Example 5

[0157] Embodiment 5 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform any of the redundant symbol lookup methods provided in the above embodiments.

[0158] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0159] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0160] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0161] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or device. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0162] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A method for finding redundant symbols, characterized in that, include: Obtain the compiled ELF file and extract function references from the symbol table, relocation table, code sections, and debugging information of the ELF file; Recursively traverse downwards from the program entry point and dynamic call point, constructing a symbolic reference graph based on the aforementioned reference relationships; Starting from the preset function usage starting point, traverse the symbol reference graph to obtain the set of used functions; Compare all function symbols appearing in the ELF file code segment with the set of functions to be used, and obtain redundant functions based on the comparison results; The extraction of function references from the symbol table, relocation table, code sections, and debugging information of the ELF file includes: Parse the ELF header and section header table to obtain the section list; The function is extracted from the symbol table section; The relocation table identifies the reference location of the function; The function reference relationships are obtained in the relocation table based on the reference positions; Obtain supplementary reference relationships from the debugging information, and use these supplementary reference relationships to improve the reference relationships, thus obtaining a complete reference relationship; The preset function usage starting point includes: The entry point marked in the main function or in the dynamic link table; Initialization functions registered via attribute((constructor)); Symbols referenced externally in dynamic symbols (.dynsym); And the call relationship information in the debug section .eh_frame, .debug_info; The construction of the address mapping table from symbols to section offsets includes: Parse the section header table to find the name, offset, and size of all sections, and determine the section indices for the symbol table and string table; Parse the symbol table to record the offset and size of symbols within a section; Parse the program header table and record the virtual address range of each segment; Match the virtual address of the section with the virtual address range of the segment to determine the segment where the symbol is located; Calculate the absolute offset of the symbol in the file; The absolute offset and size of the symbol are written using a pre-established mapping table structure.

2. The method according to claim 1, characterized in that, The method further includes: Construct an address mapping table from symbols to section offsets, and use the address mapping table to locate the position of redundant functions; Based on the location of the redundancy function, set the machine code region of the redundancy function in the code section to NOP or INT3 instruction; Update the size and address mapping of redundant functions in the .symtab and .debug_* sections; The address mapping table is used to determine whether there are address misalignments or mismatches, and corresponding processing is performed accordingly. The sections containing redundant functions are rewritten based on the content of the deleted redundant functions.

3. The method according to claim 2, characterized in that, The method further includes: In the debugging section, the debugging information entity of the redundant function symbol is retained, and the redundant function is marked as optimized and deleted, or the debugging information entity of the redundant function is set to an empty segment; Clear or remove the .eh_frame entry for the redundant function.

4. The method according to claim 2, characterized in that, The method further includes: Verify the consistency of the section header and check if the reserved section header has changed; Verify that the index relationships in the debug section are not broken and that no dynamically loaded symbols are missing.

5. A redundant symbol lookup device, characterized in that, include: The acquisition module is used to acquire the compiled ELF file and extract function references from the symbol table, relocation table, code sections, and debugging information of the ELF file. The building module is used to recursively construct a symbolic reference graph based on the reference relationships, starting from the program entry point and dynamic call point; The traversal module is used to traverse the symbol reference graph starting from a preset function usage starting point to obtain the set of used functions; The comparison module is used to compare all function symbols appearing in the code segment of the ELF file with the set of functions to be used, and to obtain redundant functions based on the comparison results; The acquisition module includes: The parsing unit is used to parse the ELF header and section header table to obtain the section list; The function extraction unit is used to extract functions from the symbol table section; An identifier unit is used to identify the reference position of the function in the relocation table; The reference relationship obtaining unit is used to obtain the function reference relationship in the relocation table based on the reference position; The reference relationship acquisition unit is used to obtain supplementary reference relationships from debugging information, and to improve the reference relationships using the supplementary reference relationships to obtain complete reference relationships; The preset function usage starting point includes: The entry point marked in the main function or in the dynamic link table; Initialization functions registered via _attribute_((constructor)); Symbols referenced externally in dynamic symbols (.dynsym); And the call relationship information in the debug section .eh_frame, .debug_info; The preset function usage starting point includes: The entry point marked in the main function or in the dynamic link table; Initialization functions registered via _attribute_((constructor)); Symbols referenced externally in dynamic symbols (.dynsym); And the call relationship information in the debug section .eh_frame, .debug_info.

6. A terminal, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the redundant symbol lookup method as described in any one of claims 1-4.

7. A storage medium containing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to perform the redundant symbol lookup method as described in any one of claims 1-4.

Images