Static resource processing method, access method, device and system

Abstract

The application discloses a static resource processing method, an access method, equipment and a system, and relates to the technical field of computer program processing. The static resource processing method comprises the following steps: acquiring an ELF file generated by source code, wherein a to-be-stripped static resource containing a nested structure body and / or a pointer member is marked by a segment attribute indicator, and a corresponding descriptor is defined; scanning and positioning each resource and the descriptor; recursively traversing a member structure, copying values of members which are neither structure bodies nor pointers in sequence, and continuously storing the values to form a flattened data packet, while changing a pointer value from an absolute address to a logical offset relative to a parent variable; updating offset and size information in the descriptor; and stripping all data packets to obtain data packets which can be independently burned into a nonvolatile storage medium. Thus, the tree-shaped nested static resource is converted into the flattened data packet, the separation of the static resource and the ELF file is realized, and the physical access characteristics of a specific nonvolatile storage medium are not relied on.

Description

Technical Field

[0001] This application relates to the field of computer program processing technology, specifically to a static resource processing method, access method, device, and system. Background Technology

[0002] In environments with limited computing resources, such as embedded systems and IoT devices, programs typically run on Static Random-Access Memory (SRAM) with limited capacity. These programs often contain a large amount of read-only data that remains unchanged throughout the entire runtime, such as configuration parameters, string constants, lookup tables, and version information—collectively referred to as "static resources" in this paper. Static resources are characterized by low usage frequency but are indispensable: they are idle most of the time, yet must be accessible when the program needs them.

[0003] Currently, the industry mainly handles the aforementioned static resources in the following ways:

[0004] A common approach is to write static resources directly into the source code as constant structures or arrays. During compilation, the compiler allocates this data to read-only data segments (such as the .rodata segment), and the linker embeds it in the program image. At system startup, static resources are loaded into SRAM along with the code segment and reside there, allowing the program to access them at any time during runtime.

[0005] Another approach is to separate program code from static resources: only the code segment is loaded into SRAM for execution, while the static resources are kept in NOR Flash. During runtime, the static resources are accessed directly from NOR Flash through Execute In Place (XIP), thus avoiding the static resources occupying SRAM space.

[0006] However, all the aforementioned existing technical solutions have drawbacks. The first method keeps all static resources resident in SRAM. As the amount of static resource data increases, SRAM shortages become increasingly prominent, becoming a key bottleneck restricting system performance and functional expansion. Simultaneously, this infrequently used data occupies valuable SRAM space for extended periods, resulting in severe resource waste. The second method, while saving SRAM, is only applicable to NOR Flash that supports XIP technology and cannot be adapted to storage media such as NAND Flash and EEPROM that lack XIP capabilities. Furthermore, when using the XIP method, application write operations to NOR Flash (such as log recording) must be strictly avoided; otherwise, bus conflicts or NOR Flash state corruption can easily occur, increasing the complexity of system design and operational risks. Summary of the Invention

[0007] This application provides a static resource processing method, access method, device, and system to solve the problem of how to reduce the memory footprint of static resources while ensuring that the storage and access of static resources are not limited by the physical characteristics of specific non-volatile storage media.

[0008] According to a first aspect, one embodiment provides a static resource processing method, comprising:

[0009] Obtain executable and linkable format files generated from source code, wherein at least one static resource to be stripped is marked by a segment attribute indicator and contains nested structures and / or pointer members, and a corresponding descriptor is defined for each static resource to be stripped in the source code;

[0010] Scan the executable and linker format files to locate each static resource to be stripped and its corresponding descriptor;

[0011] For each static resource to be stripped, recursively traverse its member structure, copy and store the values ​​of all members that are neither structures nor pointers in the traversal order to form a flattened data packet; during the traversal, if a pointer member is encountered, the pointer value of the pointer member is rewritten from an absolute address to a logical offset, where the logical offset is the offset of the starting address of the target object originally pointed to by the pointer value in the flattened data packet relative to the starting address of the parent variable to which the pointer member belongs in the flattened data packet;

[0012] After traversing all the static resources to be stripped, based on the size of each flattened data packet and the position of each flattened data packet in the overall data block composed of all flattened data packets, update the offset and size information recorded in the descriptor corresponding to the static resource to be stripped that forms each flattened data packet.

[0013] All flattened data packets are stripped from the executable and linker format files to obtain at least one flattened data packet that can be independently burned to a non-volatile external storage medium.

[0014] In one embodiment, the recursive traversal process includes:

[0015] Based on the debugging information containing attribute record format in the executable and link format files, determine the type of the currently traversed member;

[0016] If the currently traversed member is a structure, then enter the structure and perform the recursive traversal on its member structure;

[0017] If the currently traversed member is a pointer, then locate the target object pointed to by the pointer, and perform the recursive traversal on the member structure of the target object;

[0018] If the currently traversed member is neither a structure nor a pointer, then stop the recursive traversal of the currently traversed member.

[0019] In one embodiment, the segment attribute indicator is configured to link the static resource to be stripped to a preset segment, which is mapped to an invalid virtual address during the compilation phase, so that the preset segment does not occupy physical read-only memory or random access memory space.

[0020] In one embodiment, the non-volatile external storage medium is any one of NOR Flash, NAND Flash, or EEPROM.

[0021] According to a second aspect, one embodiment provides a static resource access method, including:

[0022] In response to an access request for a static resource, for each requested static resource, a descriptor corresponding to each static resource is obtained. The descriptor records the offset and size information of the flattened data packet of each static resource in the overall data block composed of all flattened data packets. The overall data block is stored in a non-volatile external storage medium. All flattened data packets are generated by the method described in any embodiment of the first aspect of this application. The pointer value of the pointer member in each static resource is rewritten from an absolute address to a logical offset in the flattened data packet of each static resource. The logical offset is the offset of the starting address of the target object originally pointed to by the pointer value in the flattened data packet relative to the starting address of the parent variable to which the pointer member belongs in the flattened data packet.

[0023] Based on the offset and size information recorded in the descriptor, random access memory space is requested, and the flattened data packet of each static resource is copied from the non-volatile external storage medium to the requested random access memory space.

[0024] In response to the need to access the target object pointed to by the pointer member, the logical offset of the pointer member is read, the base address of the parent variable to which the pointer member belongs in the allocated random access memory space is added to the logical offset of the pointer member to obtain the actual physical address of the target object and then access it.

[0025] In one embodiment, the static resource access method further includes:

[0026] In response to a need to access a member in a flattened data packet that is neither a structure nor a pointer, the value of the member that is neither a structure nor a pointer is accessed via a structure member operator or a structure pointer access operator.

[0027] In one embodiment, the static resource access method further includes:

[0028] After completing access to the flattened data packet, release the requested random access memory space.

[0029] According to a third aspect, one embodiment provides a computer device, comprising:

[0030] The first memory is used to store the first program;

[0031] A first processor is configured to execute the first program to implement the method as described in any embodiment of the first aspect of this application.

[0032] According to a fourth aspect, one embodiment provides an embedded device, comprising:

[0033] The second memory is used to store the second program;

[0034] A second processor is configured to execute the second program to implement the method as described in any embodiment of the second aspect of this application.

[0035] According to a fifth aspect, one embodiment provides a static resource management system, including: a computer device, a non-volatile external storage medium, and an embedded device;

[0036] The computer device is configured to perform the method as described in any embodiment of the first aspect of this application, to extract at least one flat data packet formed from static resources from an executable and linkable format file; and to write the extracted flat data packet to the non-volatile external storage medium.

[0037] The embedded device is configured to perform the method described in any embodiment of the second aspect of this application to load and access a corresponding flattened data packet from the non-volatile external storage medium in response to an access request for a static resource.

[0038] According to the static resource processing method of the above embodiments, the marked static resources to be stripped in the executable and linker format files are recursively traversed. The values ​​of all members in the tree-forming member structure that are neither structures nor pointers are copied sequentially and stored continuously in traversal order, forming flattened data packets. Simultaneously, the absolute address values ​​of pointer members encountered during traversal are rewritten as logical offsets. This reorganizes the originally discretely stored tree-shaped nested data, referenced by absolute addresses, into flattened data that is continuous and uses relative offset addressing internally. The target object referenced by the pointer no longer depends on its original absolute address in the executable and linker format files. After traversal, the offset and size information of the corresponding descriptors are automatically updated based on the actual size of each flattened data packet and its position in the overall data block composed of all flattened data packets. This establishes an accurate index for each stripped static resource. Then, all flattened data packets are stripped from the executable and linker format files, resulting in at least one flattened data packet that can be independently burned to a non-volatile external storage medium. Therefore, static resource data is completely separated from executable and linker format files, no longer occupying their storage space. Simultaneously, the independently stored flattened data package does not rely on the physical access characteristics of specific non-volatile storage media (such as the XIP capability of NOR Flash), and can adapt to any non-volatile external storage media, fundamentally solving the key problems of static resources being bound to program code and limited by the physical characteristics of specific non-volatile storage media. Furthermore, because it uses recursive traversal of member structures and automatically completes the continuous rearrangement of member data that is neither a structure nor a pointer, and the rewriting of pointer values ​​for pointer members, the entire flattening process requires no manual intervention. After flattening, the descriptor corresponding to each static resource is automatically updated to record the actual offset and size of the resource in the overall data block, providing accurate positioning information for subsequent on-demand loading and ensuring that the descriptor and the flattened data package remain synchronized. Attached Figure Description

[0039] Figure 1 This is a flowchart illustrating a static resource processing method according to one embodiment.

[0040] Figure 2 This is an example diagram of a tree-structured static resource discrete storage in one embodiment;

[0041] Figure 3 This is an example diagram of the flattening process of a static resource static_res1 in one embodiment;

[0042] Figure 4 This is an example diagram illustrating the flattening process of a static resource static_res2 according to one embodiment;

[0043] Figure 5 This is an example diagram comparing static resources static_res1 and static_res2 before and after flattening processing in one embodiment.

[0044] Figure 6 This is a schematic diagram of a recursive traversal process of a static resource to be stripped, according to one embodiment.

[0045] Figure 7 This is a flowchart illustrating a static resource access method according to one embodiment.

[0046] Figure 8 This is an example diagram illustrating an on-demand loading and access process for a static resource, as described in one embodiment.

[0047] Figure 9 This is a schematic diagram illustrating the dynamic loading process of a static resource in one embodiment.

[0048] Figure 10 This is a schematic diagram of the structure of a computer device according to one embodiment;

[0049] Figure 11 This is a schematic diagram of the structure of an embedded device according to one embodiment;

[0050] Figure 12 This is a schematic diagram of the structure of a static resource management system according to one embodiment. Detailed Implementation

[0051] The present application will now be described in further detail with reference to the accompanying drawings and specific embodiments. Similar elements in different embodiments are referred to by related similar element reference numerals. In the following embodiments, many details are described to facilitate a better understanding of the present application. However, those skilled in the art will readily recognize that some features may be omitted in different situations, or may be replaced by other elements, materials, or methods. In some cases, certain operations related to the present application are not shown or described in the specification. This is to avoid obscuring the core parts of the present application with excessive description. For those skilled in the art, detailed description of these related operations is not necessary; they can fully understand the related operations based on the description in the specification and general technical knowledge in the art.

[0052] Furthermore, the features, operations, or characteristics described in the specification can be combined in any suitable manner to form various embodiments. At the same time, the order of the steps or actions in the method description can be changed or adjusted in a manner obvious to those skilled in the art. Therefore, the various orders in the specification and drawings are only for clearly describing a particular embodiment and do not imply a necessary order, unless otherwise stated that a particular order must be followed.

[0053] The serial numbers assigned to components in this document, such as "first" and "second," are used only to distinguish the described objects and have no sequential or technical meaning. The terms "connection" and "linkage" used in this application, unless otherwise specified, include both direct and indirect connections (linkages).

[0054] Understandably, in traditional embedded program development, there are two common approaches to handling read-only static resources that remain unchanged during runtime, such as configuration parameters, string constants, and lookup tables: One approach is to directly write the static resources as constant structures into the source code, and after compilation and linking, load them into SRAM along with the generated Executable and Linkable Format (ELF) image file for long-term residency; the other approach is to store the static resources in NOR Flash and access them locally via XIP, avoiding SRAM occupation. However, the first approach leads to a large amount of infrequently used data occupying valuable SRAM space for extended periods, and the SRAM shortage problem becomes increasingly prominent as the size of static resources grows. While the second approach saves SRAM, it relies on the XIP hardware capabilities of NOR Flash, making it incompatible with other storage media such as NAND Flash and EEPROM. Furthermore, write operation conflicts to Flash under the XIP method increase the complexity of system design and operational risks.

[0055] The reason for this is that neither of the above two methods truly decouples static resource data from the ELF file generated after compiling and linking the source code. The first method completely embeds it within the ELF file, while the second method, although leaving the data externally, binds it to specific hardware access capabilities. Based on this, this application proposes a static resource processing method that creatively automates the post-processing of the ELF file generated from the source code conversion. It recursively traverses the tree-like nested member structure of the marked static resources, continuously rearranging the values ​​of discrete members (neither structures nor pointers) into flattened data packets. Simultaneously, it uniformly rewrites the absolute address references of pointer members into relative references based on logical offsets, making the static resource a continuous, flattened data packet internally using relative offset addressing. This allows it to be completely extracted from the ELF file and stored independently on a non-volatile external storage medium. This fundamentally decouples the static resource from the physical characteristics of the ELF file and the specific non-volatile external storage medium, achieving complete separation of the static resource from the ELF file's runtime environment.

[0056] Please refer to Figure 1Some embodiments disclose a static resource processing method 100, which is applicable to solving the problem of how to reduce the system memory footprint of static resources while ensuring that the storage and access of static resources are not limited by the physical characteristics of specific non-volatile storage media. This method can be executed by a computer device on the program development side. Figure 1 As shown, the method includes the following steps:

[0057] Step 110: Obtain the executable and linkable format files generated by the source code conversion, wherein at least one static resource to be stripped is marked by a segment attribute indicator, which contains nested structures and / or pointer members, and a corresponding descriptor is defined for each static resource to be stripped in the source code.

[0058] The source code can be understood as high-level language (such as C) program text written by developers, containing specific segment attribute tags and descriptor definitions before compilation. The executable and linker format ELF file is a standard executable file generated by compiling and linking the source code, and its format follows executable and linker format specifications. The segment attribute indicator can be understood as a syntax mechanism provided by the compilation toolchain that allows variables or functions to be specified and linked to specific program segments.

[0059] For example, in the GCC compiler, the `__attribute__((section("section_name")))` syntax can be used to mark a variable as a section with a specified name. It should be noted that in other compiler toolchains, there may be functionally equivalent section indicator syntaxes. Regardless of the specific syntax form, as long as the target variable can be assigned to a specific section that can be uniquely identified in subsequent scanning phases, it falls within the scope of the section attribute indicator described in this application.

[0060] In one embodiment, the segment attribute marking operation described above is manually performed by the developer during the source code coding stage—that is, when writing the source code, the developer determines which static resources need to be extracted from the ELF file based on actual needs and manually adds segment attribute indicators to these static resource variables. The purpose of marking is to: clearly identify the static resources that need to be extracted, facilitating subsequent automated script identification and processing; and to uniformly group the marked static resources into a specific segment, providing a unified symbol lookup entry point for subsequent scanning and location.

[0061] It is understood that in this application, the source code is not only the original code that implements the program's functionality, but also the carrier for implementing the "definition of static resource tags and descriptors to be stripped" in the static resource processing method described in this application. When writing the source code, developers must first complete the two preparatory tasks of tagging the static resources to be stripped and defining the descriptors before they can start the processing flow of the static resource processing method of this application.

[0062] The static resources to be stripped can be understood as static resources in the source code that are marked as needing to be separated from the ELF file, which are defined in the source code as data structures containing nested structures and / or pointer members.

[0063] The nested structure and / or pointer members can be understood as data structures of static resources where the member variables themselves may also be structure types (forming nested structures), or they may be pointer types (pointing to data located at other memory addresses), or both.

[0064] To facilitate understanding, a specific application example is given below.

[0065] Please refer to Figure 2 Suppose that two static resource variables are defined in the program of the embedded system, named static_res1 and static_res2 respectively.

[0066] The `static_res1` data structure is relatively simple: it contains a pointer member `name`, which points to a string constant (such as a device name or version string). In a typical C language definition, `static_res1` is a structure containing only a `char*` pointer member. After compilation, the `static_res1` structure itself and the string content pointed to by `name` are stored at different memory addresses in the ELF file.

[0067] The `static_res2` data structure is relatively complex: it contains a scalar member `version` (of type `int`) and two pointer members—`config` and `strtable`. `config` points to a structure of type `config`, which contains a scalar member `config_val` (of type `int`) and a pointer member `sub_config`. `sub_config` in turn points to a structure of type `sub_config`, which contains a scalar member `sub_config_val` (of type `int`). `strtable` points to a structure of type `stringtable`, which contains two pointer members `stringtable1` and `stringtable2`, each pointing to a different string constant. Therefore, `static_res2` is a typical multi-level nested tree structure resource—containing scalar leaf nodes, multi-level nested structures, and multi-level pointer indirection.

[0068] It should be noted that in this application, a "structure" can be understood as a composite data type that combines multiple data members into a whole. Its variable is allocated a contiguous storage area in the logical storage space to directly hold the data of all its members. A "pointer" can be understood as a variable used to store an address value, whose value represents the location of another data entity in the logical storage space. The essential difference between the two is that a structure variable itself is a container for data, while a pointer variable is a carrier of addresses. It is particularly important to note that in this application, a "pointer to a structure" (such as `config *config` in the `static_res2` example above) belongs to the pointer type, not the structure type. In the processing logic of this application, such members are processed according to the rules of pointer types.

[0069] like Figure 2 As shown, after normal compilation, these static resources are stored discretely in the ELF file: the `static_res1` structure and the string pointed to by `name` are scattered at different addresses; the `static_res2` structure, `config` structure, `sub_config` structure, `strtable` structure, and various string constants occupy different address spaces in the ELF file. Meanwhile, the regular data segment (such as the `.sdata` segment) also stores descriptors corresponding to each static resource—`static_res1_desc` and `static_res2_desc`, each containing two fields: `offset` and `total_size`, which are filled with initial values ​​during compilation (e.g., offset filled with 0xFFFFFFFF and size filled with 0x0).

[0070] The descriptors mentioned above can be understood as variables used to record the position and size information of their corresponding static resources after flattening. Descriptor variables are defined in the source code in the conventional way and are not marked by segment attribute indicators. Therefore, after compilation, they are retained in the regular data segment of the ELF file and can be read throughout the entire runtime of the final executable program.

[0071] Step 120: Scan the executable and linker files to locate each static resource to be stripped and its corresponding descriptor.

[0072] Understandably, after obtaining the ELF file, scanning its various program segments can locate each static resource to be stripped and its corresponding descriptor.

[0073] In one embodiment, during the scanning process, a set of symbol pairs is simultaneously located based on the following identification conditions: a variable X is found whose segment is a preset segment marked by a segment attribute indicator; simultaneously, a variable X_desc (or a descriptor variable that satisfies other preset correspondence rules) is found, which has a one-to-one correspondence with X. Each time such a set of symbol pairs is found, a static resource to be stripped and its associated descriptor are determined.

[0074] For example, naming conventions can be used to establish the correspondence—for instance, if a static resource variable is named "static_res1", its descriptor is named "static_res1_desc"; if a static resource variable is named "static_res2", its descriptor is named "static_res2_desc". After scanning the ELF file, the symbol pair "static_res1" and "static_res1_desc", and the symbol pair "static_res2" and "static_res2_desc" are located, thus identifying the two sets of static resources to be stripped. Other association methods that can establish unique mappings can also be used, and this application does not limit this approach.

[0075] Step 130: For each static resource to be stripped, recursively traverse its member structure, copy and store the values ​​of all members that are neither structures nor pointers in the traversal order to form a flattened data packet; during the traversal, if a pointer member is encountered, rewrite the pointer value of the pointer member from an absolute address to a logical offset, where the logical offset is the offset of the starting address of the target object originally pointed to by the pointer value in the flattened data packet relative to the starting address of the parent variable to which the pointer member belongs in the flattened data packet.

[0076] The member structure can be understood as a hierarchical organization consisting of all members within the static resource to be extracted and their nesting relationships. It is understood that for static resources containing nested structures and pointers, their member data is not stored flatly, but rather forms a multi-level tree structure through structure nesting and pointer references.

[0077] Members that are neither structs nor pointers can be understood as final data members in the tree-forming member structure of static resources whose type is neither a struct nor a pointer. These members are the terminating nodes (leaf nodes) of recursive traversal, and their values ​​are basic data that can be directly copied, such as basic data types (int, char, float, etc.) and their arrays.

[0078] The recursive traversal can be understood as a traversal method that enters nested structures or traces data pointed to by pointers in a depth-first manner on a tree-forming member structure until a leaf member that is neither a structure nor a pointer is encountered.

[0079] The flattened data packet can be understood as a contiguous block of binary data formed by recursively copying and storing the values ​​of all members that are neither structures nor pointers in the order of traversal of the static resources to be stripped. The flattened data packet eliminates the fragmentation and nesting relationships of the original tree structure, and arranges the data at each level that were originally scattered in memory in a compact manner.

[0080] The pointer member can be understood as a member variable of type pointer within a member structure to be stripped of static resources. The pointer value can be understood as the value stored in the pointer member variable itself. In C, the value of a pointer variable is a memory address. After compilation and linking, this value is an absolute virtual or physical address. That is, the pointer member stores an absolute address value in the compiled ELF file, pointing to the data it references.

[0081] The absolute address can be understood as the address value stored in the pointer member, determined in the original compilation environment, pointing to a specific memory location.

[0082] The logical offset can be understood as the byte offset of the starting address of the target object originally pointed to by the pointer member in the flattened data packet, relative to the starting address of the parent variable to which the pointer member belongs in the flattened data packet.

[0083] The parent variable can be understood as the upper-level structure variable that directly contains a pointer member within the tree-form member structure. The "parent variable" is relative to the pointer member. The structure to which a pointer member belongs is its parent variable. In multi-level nesting, each pointer has its direct parent variable.

[0084] Understandably, in the original ELF file, pointer values ​​store absolute addresses in memory space. These absolute addresses are only valid when the ELF file is loaded into a specific memory layout. Once static resource data is stripped from the ELF file and becomes an independent flat data packet, the original absolute addresses become meaningless. The above embodiment rewrites absolute addresses into logical offsets (i.e., logical offsets of the data pointers relative to their parent variables), so that the stripped flat data packet no longer depends on any external address context. Consequently, regardless of the location of the flat data packet on any non-volatile external storage medium, the internal reference relationships can be re-established during subsequent loading using the "base address plus logical offset" method.

[0085] In one embodiment, during the recursive traversal in step 130, the member structure is recursively traversed starting from the static resource variable to be stripped as the root node. The processing rule during traversal is as follows: for each member currently traversed, if the member is neither a structure type nor a pointer type (for example, it belongs to a basic data type in the C language, such as int, char, float, etc.), then the value of the member is copied out and stored consecutively in the output buffer in the order of traversal, and further recursion on that member stops. Such members are usually "leaf nodes" of a tree data structure, and their values ​​are the data that needs to be retained in the end, without further expansion.

[0086] If a pointer member is encountered during traversal, it indicates that the actual data content of that member is not stored within the few bytes occupied by the pointer variable itself, but rather at a different memory address pointed to by the pointer value. In this case, two operations need to be performed on the pointer member: First, rewrite the current pointer value of the pointer member (which is the absolute virtual address of the target object in the original ELF file) into a logical offset. This logical offset can be calculated as follows: the difference between the starting address of the data originally pointed to by the pointer value in the final flattened data packet and the starting address of the parent variable to which the pointer member belongs in the flattened data packet. That is, the logical offset represents the distance of the target object relative to the starting position of its parent variable. Second, based on the original absolute address value stored in the pointer member, locate the target object it points to in the ELF file, and recursively perform the same traversal process as in this step on the members of the target object—that is, determine whether the member of the target object is a structure, a pointer, or neither a structure nor a pointer, and process them according to the corresponding rules.

[0087] If a member of a structure type is encountered during the traversal, the process enters the structure and recursively performs the same processing as in this step on each of its members.

[0088] Through the recursive traversal and processing described above, regardless of the complexity of the original static resource's tree-like nested structure (how many levels of nested structures or how many levels of indirect pointer references), all leaf node data will eventually be extracted sequentially and arranged continuously in traversal order. The pointer values ​​of all pointer members are rewritten as logical offsets relative to their parent variables, and absolute addresses are no longer stored. Thus, data originally referenced by absolute addresses and discretely distributed across multiple locations in the ELF file is reorganized into a single, continuous, flattened data packet that uses relative offset addressing internally. This flattened data packet no longer contains any absolute addresses pointing to the outside; regardless of its physical location in memory, the internal data can be located using logical offsets.

[0089] For example, the following uses the aforementioned static_res1 and static_res2 as examples to specifically demonstrate the complete process of recursive traversal and flattening.

[0090] For an illustration of the effects before and after flattening of static_res1, please refer to [link / reference]. Figure 3 The processing procedure is as follows:

[0091] When traversing its members, the `name` member is found, confirming that it is a pointer variable pointing to a constant string. The actual data content of `name` is stored at the address pointed to by this pointer (i.e., `name_val`). The ELF file is then scanned to find the string content pointed to by `name`. The string data is copied and stored contiguously after the `name` variable. The value of the `name` member variable is modified to a logical offset relative to the starting address of `static_res1`—that is, the value obtained by subtracting the starting address of `static_res1` from the starting address of `name_val` in the flattened data packet, denoted as `name_offset`. Please refer to [reference needed]. Figure 3 Before flattening, name in static_res1 stores the absolute address of name_val; after flattening, name in static_res1 stores name_offset, and the actual string data of name_val is stored immediately after name.

[0092] For an illustration of the effects before and after flattening of static_res2, please refer to [link / reference]. Figure 4 The processing procedure is as follows:

[0093] First, iterate through the version member, which is a non-pointer scalar (int type). No special processing is needed; simply save the value of version into the flattened data packet.

[0094] The process iterates to the `config` member, confirming it's a pointer to a `config` structure. Locate the address pointed to by `config`, enter the `config` structure, and continue iterating through its members. Within the `config` structure: `config_val`, a scalar, is iterated through and its value is stored directly; `sub_config`, a pointer, is located at the address pointed to by `sub_config`, enter the `sub_config` structure, and iterate through `sub_config_val`, also a scalar, storing its value directly. This completes the traversal of the `config` branch. In the flattened data packet, the pointer value of `config` is rewritten as `config_offset` (the logical offset of the starting address of the `config` structure data in the flattened data packet relative to the starting address of `static_res2`); the pointer value of `sub_config` is rewritten as `sub_config_offset` (the logical offset of the starting address of the `sub_config` structure data in the flattened data packet relative to the starting address of the `config` structure in the flattened data packet). The values ​​of `config_val` and `sub_config_val` are arranged consecutively in the order of traversal.

[0095] The process iterates through the `strtable` member, which is a pointer to a `stringtable` structure. Entering the `stringtable` structure, it iterates through `stringtable1` and `stringtable2`, both pointers pointing to different string constants. The contents of these two strings are located and their data is flattened and stored. Within the flattened data structure, the pointer value of `strtable` is rewritten as `stringtable_offset` (the logical offset of the starting address of the `stringtable` structure data within the flattened data structure relative to the starting address of `static_res2`). The pointer values ​​of `stringtable1` and `stringtable2` within `stringtable` are respectively rewritten as the logical offsets of the string data they point to relative to the starting address of `stringtable` within the flattened data structure.

[0096] After the traversal is complete, all data inside the flattened data packet formed by static_res2 is arranged continuously in the traversal order, and all pointer values ​​are rewritten as logical offsets.

[0097] Please refer to Figure 5 In comparison: Before flattening, the data of each node in static_res1 and static_res2 is stored discretely, and the pointer value is an absolute address; after flattening, all the data in static_res1 and static_res2 is arranged compactly and continuously, and the pointer value is unified as a logical offset.

[0098] Step 140: After traversing all the static resources to be stripped, update the offset and size information recorded in the descriptor corresponding to the static resource to be stripped that forms each flat data packet, based on the size of each flat data packet and the position of each flat data packet in the overall data block composed of all flat data packets.

[0099] The overall data block can be understood as a complete data set formed by splicing all flattened data packets of all static resources to be stripped into a predetermined order after flattening; wherein the predetermined order may be the order in which each static resource to be stripped appears in the ELF file, the linking order of each corresponding descriptor, or any other pre-specified order.

[0100] It should be noted that in step 140, the overall data block can be understood as a conceptual overall data block that exists only logically, generated by splicing all the flattened data packets in a predetermined order after traversing all the static resources to be stripped and obtaining all the flattened data packets; its purpose is only to provide a unified reference system for calculating the actual offset of the "offset recorded in the update descriptor".

[0101] In one embodiment, after traversing all static resources to be stripped and obtaining each flattened data packet, all flattened data packets can be first assembled into a continuous logically existing whole data block in a predetermined order, and then the offset and size information in each descriptor can be updated according to the logically existing whole data block.

[0102] In one embodiment, the operation of updating the descriptor includes: calculating the actual size (e.g., total length in bytes) of the flattened data packet formed by each static resource, and the starting offset position of the flattened data packet in the overall data block formed by the flattened data packets of all static resources to be stripped in sequence; writing the calculated actual offset and actual size into the descriptor of the static resource, replacing the initial value filled in the descriptor during the encoding stage.

[0103] It is important to note that the "offset" in the updated descriptor refers to the external offset of the corresponding flattened data packet within the overall data block, which is a different concept from the "logical offset" (internal offset) stored in the internal pointer member of the flattened data packet.

[0104] For example, let's continue with the aforementioned `static_res1` and `static_res2` as examples: For `static_res1`, calculate its flattened data packet size as `sizeof(static_res1) + sizeof(name_val)`, and record its starting offset within the overall data block as `static_res1_offset`, updating it in `static_res1_desc`. For `static_res2`, calculate its flattened data packet size as `sizeof(static_res2) + sizeof(config) + sizeof(strtable)`, and record its starting offset within the overall data block as `static_res2_offset`, updating it in `static_res2_desc`.

[0105] Please refer to Figure 5 Comparing the ELF file layout before and after flattening: Before processing, the offset and total_size fields in each descriptor are initially invalid values ​​(such as 0xFFFFFFFF and 0x0), and the static resource data is distributed in a tree-like discrete structure in the marked static resource segments; after processing, each descriptor has been updated with the actual offset and actual size, and the tree-like discrete data in the marked segments has been reorganized into continuously arranged flattened data packets.

[0106] Understandably, the initial value of the descriptor can be any value during the encoding phase, such as a flag indicating "uninitialized" (e.g., 0xFFFFFFFF), because it will be automatically updated to the accurate value after the flattening process. By using a "placeholder first, update later" approach, the descriptor has legal variable status and storage space during the compilation phase, without affecting the normal compilation process, and can then be located and corrected (i.e., updated) during the post-processing phase. This process is executed one by one for all located static resources to be stripped until all are processed.

[0107] Step 150: Extract all flattened data packets from the executable and linker format files to obtain at least one flattened data packet that can be independently burned to a non-volatile external storage medium.

[0108] The stripping process can be understood as removing the flattened data packets from the ELF file, making them data blocks independent of the final executable program. After stripping, each flattened data packet is no longer burned along with the final executable program, but is stored as an independent data block in a non-volatile storage medium.

[0109] In one embodiment, after stripping all flattened data packets from the ELF file, all flattened data packets can be arranged into a continuous physical data block in a predetermined order or in ascending order of offsets in each updated descriptor, and then the entire physical data block can be burned to a non-volatile external storage medium.

[0110] In one embodiment, after all flattened data packets are stripped from the ELF file, each flattened data packet is independently burned to a contiguous storage space in a non-volatile external storage medium in a predetermined order or in ascending order of the offsets in each updated descriptor, so that the flattened data packets are naturally and continuously arranged to form a physically existing whole data block after being burned to the non-volatile external storage medium.

[0111] After step 150, the final executable program will no longer contain the stripped static resource data, but the final executable program will still retain the descriptors corresponding to the stripped static resources, which will be used as indexes or location information for accessing these static resources when they are needed later.

[0112] For example, please refer to Figure 5 After the above processing is completed, the FLASH memory stores multiple flattened data packets arranged as whole data blocks, such as the flattened data packets of static_res1, static_res2, and static_res3 arranged in sequence. The SRAM memory does not contain this static resource data; it is only copied from the FLASH memory to the SRAM as needed when the program actually accesses it.

[0113] According to the static resource processing method of the above embodiments, the marked static resources to be stripped in the executable and linker format files are recursively traversed. The values ​​of all members in the tree-forming member structure that are neither structures nor pointers are copied sequentially and stored continuously in traversal order, forming flattened data packets. Simultaneously, the absolute address values ​​of pointer members encountered during traversal are rewritten as logical offsets. This reorganizes the originally discretely stored tree-shaped nested data, referenced by absolute addresses, into flattened data that is continuous and uses relative offset addressing internally. The target object referenced by the pointer no longer depends on its original absolute address in the executable and linker format files. After traversal, the offset and size information of the corresponding descriptors are automatically updated based on the actual size of each flattened data packet and its position in the overall data block composed of all flattened data packets. This establishes an accurate index for each stripped static resource. Then, all flattened data packets are stripped from the executable and linker format files, resulting in at least one flattened data packet that can be independently burned to a non-volatile external storage medium. Therefore, static resource data is completely separated from executable and linker format files, no longer occupying their storage space. Simultaneously, the independently stored flattened data package does not rely on the physical access characteristics of specific non-volatile storage media (such as the XIP capability of NOR Flash), and can adapt to any non-volatile external storage media, fundamentally solving the key problems of static resources being bound to program code and limited by the physical characteristics of specific non-volatile storage media. Furthermore, because it uses recursive traversal of member structures and automatically completes the continuous rearrangement of member data that is neither a structure nor a pointer, and the rewriting of pointer values ​​for pointer members, the entire flattening process requires no manual intervention. After flattening, the descriptor corresponding to each static resource is automatically updated to record the actual offset and size of the resource in the overall data block, providing accurate positioning information for subsequent on-demand loading and ensuring that the descriptor and the flattened data package remain synchronized.

[0114] As a supplementary explanation applicable to any of the above embodiments, it should be noted that the execution entity of each step involved in the above method, namely the program that performs operations such as scanning, recursive traversal, flattening, pointer rewriting, descriptor updating, and data stripping, can be a standalone command-line tool, or it can be integrated into the post-compilation stage of the build system, or it can be a plug-in module of an integrated development environment. These different deployment forms do not affect the essence of the technical solution of this embodiment and should not be construed as limiting this application.

[0115] Understandably, by using a complete automated toolchain to execute the static resource processing methods of any of the above embodiments, developers only need to mark which static resources need to be stripped using segment attribute indicators in the source code and define descriptor variables. Subsequent operations such as offset calculation, descriptor backfilling, and data contiguous arrangement can all be completed automatically by the toolchain. This enables automatic flattening of tree-nested static resources, eliminating the need for developers to manually calculate offsets or intervene in memory layout. Furthermore, the toolchain only processes static resource data in ELF files without modifying the original business logic in the source code. Therefore, it does not change the way static resources are accessed subsequently. Taking C language code as an example, the native C language access method can still be maintained during subsequent access stages.

[0116] Furthermore, based on the above embodiments, in order to more accurately and efficiently determine the type of member variables during the recursive traversal process, in some embodiments, the recursive traversal process is specifically described as follows:

[0117] Based on the debugging information in the executable and linker files containing attribute record format, determine the type of the currently traversed member; if the currently traversed member is a structure, enter the structure and perform the recursive traversal of its member structure; if the currently traversed member is a pointer, locate the target object pointed to by the pointer and perform the recursive traversal of the target object's member structure; if the currently traversed member is neither a structure nor a pointer, stop the recursive traversal of the currently traversed member.

[0118] The aforementioned debugging information with attribute recording format can be understood as debugging data generated by the compiler during the compilation phase using specific compilation options (such as GCC's "-g" option), which records detailed attribute information of every symbol (including variables and functions) in the program in a structured format.

[0119] In some embodiments, the debugging information with attributed record format is the DWARF (DebuggingWith Attributed Record Formats) information of the ELF file, which can accurately describe the type of each variable, such as whether each variable is a basic type, a structure type, a union type, a pointer type, or an array type.

[0120] Please refer to Figure 6 For each static resource to be stripped, the recursive traversal process includes the following steps:

[0121] Step 1201: For each static resource to be stripped, begin recursively traversing its member structure.

[0122] Step 1202: Determine whether there are any untraversed members in the member structure of the static resource to be stripped; if yes, proceed to step 1203; otherwise, proceed to step 1204.

[0123] Step 1203: Select an untraversed member as the current traversed member and perform recursive traversal, then jump to step 1205.

[0124] Step 1204: End the recursive traversal of the static resource to be stripped.

[0125] Step 1205: Determine the type of the currently traversed member based on the debugging information in the ELF file that contains attribute record format.

[0126] Step 1206: Determine if the currently traversed member is a structure; if yes, proceed to step 1207; otherwise, proceed to step 1208.

[0127] Step 1207: Enter the structure and perform a recursive traversal of its member structures; after the recursive traversal is completed, return to step 1202.

[0128] Step 1208: Determine if the currently traversed member is a pointer; if yes, proceed to step 1209; otherwise, proceed to step 1210.

[0129] Step 1209: Locate the target object pointed to by the pointer and perform a recursive traversal of the member structure of the target object; rewrite the pointer value of the pointer from an absolute address to a logical offset; after the recursive traversal is completed, return to execute step 1202.

[0130] Step 1210: Stop the recursive traversal of the current member, copy the value of the current member in the traversal order and store it continuously; return to step 1202.

[0131] The above judgment process accurately converges the recursive traversal behavior to the leaf node data, ensuring that no nested data is missed and no unnecessary recursive operations are performed on the leaf nodes.

[0132] Understandably, debug information with attribute record format is automatically generated by the compiler during the compilation phase. The variable type information it records is authoritative and accurate, requiring no additional type annotations or manual configuration. Compared to inferring variable types by reverse engineering binary programs, the debugging information-based judgment method is simpler to implement, more reliable, and adds almost no complexity to the development of post-processing tools.

[0133] It should be noted that using DWARF information in the ELF file to determine the member type is an optional implementation method provided in this embodiment, and not the only limitation on the member type determination method. In other embodiments of this application, when the ELF file does not contain DWARF information due to compilation options, the type of member variables can also be determined by other methods (such as parsing symbol table information, analyzing relocation tables, or comprehensively using multiple reverse analysis techniques). As long as it is possible to distinguish whether the currently traversed member is a structure, a pointer, or neither a structure nor a pointer, the purpose of this application can be achieved. However, it should be understood that as long as the compilation option that includes the generation of debugging information is selected during compilation (such as the "-g" option of GCC), the generated ELF file will definitely contain DWARF information. Therefore, in practice, ensuring that DWARF information is available is a simple and extremely low-cost operation, which only requires adding a compilation parameter to the compilation options.

[0134] Based on the above embodiments, the segment attribute indicator is further configured to link the static resource to be stripped to a preset segment, which is mapped to an invalid virtual address during the compilation stage, so that the preset segment does not occupy physical read-only memory or random access memory space.

[0135] The preset segment can be understood as a specific program segment pre-declared in the linker script, whose name matches the segment name specified by the segment attribute indicator in the source code. The invalid virtual address can be understood as a virtual address that does not actually exist on the chip and does not correspond to any physical ROM or RAM storage unit; in other words, the virtual address has no corresponding hardware memory in the chip's physical address space.

[0136] Understandably, after mapping the preset segment to such an invalid virtual address, the compiler and linker allocate only a "nominal" address space for the preset segment during the memory allocation stage (the address exists logically but has no physical counterpart), thus not actually occupying any physical ROM or RAM space.

[0137] For example, in a toolchain using the GCC compiler and GNU linker, the above configuration can be achieved by declaring an output segment in the linker script with its starting address set outside the chip's physical address space, and mapping the segments marked with __attribute__((section(...))) in the source code to that output segment.

[0138] Based on any of the above embodiments, the non-volatile external storage medium is any one of NOR Flash, NAND Flash, or EEPROM.

[0139] Among them, NOR Flash (or NOT gate flash memory) is a type of flash memory that supports XIP (Execute In Place) technology, but in this application, only its general read and write capabilities are utilized, and its XIP characteristics are not relied upon; NAND Flash (NAND gate flash memory) is another widely used type of flash memory, which usually does not support XIP, but it has high storage density and low cost, and can be used as a storage carrier for static resources after adopting the static resource processing method of any of the above embodiments of this application; EEPROM (Electrically Erasable Programmable Read-Only Memory) is a non-volatile memory that can be erased and written byte by byte, and is often used to store small amounts of static resources such as configuration parameters.

[0140] It is understood that, since the flattened data packets generated by the static resource processing method of this application exist in the form of ordinary binary data blocks, their burning and reading only rely on the basic read and write capabilities provided by the storage medium, and do not involve XIP or other special hardware access mechanisms. Therefore, there are no special requirements for the physical characteristics of the storage medium. This characteristic makes the static resource processing method of this application adaptable to a wide range of non-volatile storage devices, providing sufficient flexibility for hardware selection.

[0141] It should be noted that the storage media types listed above—NOR Flash, NAND Flash, and EEPROM—are merely illustrative examples and are not intended to limit the scope of protection of this application. Any external storage medium capable of providing non-volatile data storage functionality can be used as the subject of this embodiment.

[0142] Please refer to Figure 7 Some embodiments disclose a static resource access method 200, which is applied to embedded devices or any computing device that needs to access static resources on demand from non-volatile external storage media. This access method is used in conjunction with the aforementioned static resource processing method, and together they constitute a complete technical link from "storage stripping" to "on-demand loading." Figure 7 As shown, this static resource access method includes the following steps:

[0143] Step 210: In response to an access request for a static resource, for each requested static resource, obtain the descriptor corresponding to each static resource. The descriptor records the offset and size information of the flattened data packet of each static resource in the overall data block composed of all flattened data packets. The overall data block is stored in a non-volatile external storage medium. All flattened data packets are generated by any of the above static resource processing method embodiments. The pointer value of the pointer member in each static resource is rewritten from an absolute address to a logical offset in the flattened data packet of each static resource. The logical offset is the offset of the starting address of the target object originally pointed to by the pointer value in the flattened data packet relative to the starting address of the parent variable to which the pointer member belongs in the flattened data packet.

[0144] The access request can be understood as a triggering event during program execution that requires reading one or more static resource data. For example, the program may need to read device configuration parameters, query entries in a lookup table, or obtain string constants. The overall data block is stored in a non-volatile external storage medium. This can be understood as all the flattened data packets formed after the static resources to be stripped are flattened, combined into a continuous binary data block in a predetermined order, and independently burned to the non-volatile external storage medium; or, all the flattened data packets formed after the static resources to be stripped are flattened, and then independently burned to a continuous space in the non-volatile external storage medium in a predetermined order, forming an overall data block that is naturally and continuously arranged in the non-volatile external storage medium. Because the pointer values ​​in each flattened data packet have been rewritten as logical offsets, each static resource data in this overall data block has relocatability.

[0145] Step 220: Based on the offset and size information recorded in the descriptor, apply for random access memory space, and copy the flattened data packet of each static resource from the non-volatile external storage medium to the applied random access memory space.

[0146] In one embodiment, when a program needs to access a static resource during execution, it first obtains the descriptor corresponding to the static resource and reads its offset and size information. Based on the size recorded in the descriptor, a memory region of the corresponding size is allocated in the heap space of random access memory (such as SRAM). Based on the offset recorded in the descriptor and combined with the base address of the entire data block in the non-volatile external storage medium, the physical starting address of the flattened data packet of the static resource in the external storage medium is calculated. Then, the entire flattened data packet is copied from the external storage medium to the previously allocated random access memory space. Thus, the stripped static resource data is temporarily restored to random access memory that can be directly accessed by the program as needed.

[0147] Step 230: In response to the need to access the target object pointed to by the pointer member, read the logical offset of the pointer member, add the base address of the parent variable to which the pointer member belongs in the allocated random access memory space to the logical offset of the pointer member to obtain the actual physical address of the target object and access it.

[0148] In some embodiments, after the flattened data packet is loaded into a certain address in random access memory (such as SRAM), this load address (the base address of the parent variable) is completely different from the virtual address in the original ELF file. At this time, to locate the target object actually pointed to by the pointer member, an address relocation calculation needs to be performed: the current base address of the parent variable to which the pointer member belongs in random access memory is added to the logical offset stored in the pointer member, and the result is the actual physical address of the target object in random access memory.

[0149] In some embodiments, the address can be converted to a pointer of the corresponding structure type through pointer type conversion, and then the members in the target object can be accessed through the pointer access operator (->).

[0150] The static resource access method of this application, through descriptor-driven, on-demand loading from non-volatile external storage media, compresses the occupation window of static resources in random access memory (such as SRAM) from the "entire program execution cycle" in the prior art to the "actual access time window". Compared with the prior art's method of static resources residing in SRAM, infrequently used static data no longer resides in SRAM for extended periods. The same SRAM space can be time-division multiplexed by different static resources accessed at different times, thereby significantly improving the actual usable capacity and utilization rate of SRAM.

[0151] Furthermore, the address invalidation problem in cross-media access is solved through a relocation mechanism using a "base address plus logical offset". Since the pointer value in the flattened data packet has been rewritten from the absolute address in the original ELF file to a logical offset, when the data packet is copied from a non-volatile external storage medium to SRAM, the load address in SRAM is completely different from the address allocated in the original ELF file. However, the logical offset stored in the pointer value is unaffected by the change in load address. By adding the actual base address of the parent variable in SRAM to this unchanging logical offset, the actual SRAM address of the data to be accessed can be dynamically restored. Therefore, regardless of the external medium on which static resource data is stored or where it is loaded into SRAM, the correctness of the pointer reference is always maintained.

[0152] Furthermore, the static resource access method of this application avoids the overhead of complex file systems and achieves efficient data retrieval and loading through simplified dynamic scheduling logic. While ensuring high reliability, it significantly reduces system complexity and achieves lightweight system architecture.

[0153] Based on the above embodiments, the method further includes: in response to the need to access a member in the flattened data packet that is neither a structure nor a pointer, accessing the value of the member that is neither a structure nor a pointer through a structure member operator or a structure pointer access operator.

[0154] It should be noted that the above-mentioned "members that are neither structures nor pointers" include, but are not limited to, the following two cases:

[0155] Scenario 1: The member is a direct member of the static resource to be stripped, and its type is neither a structure nor a pointer. For example, an int type member or a char array type member defined in the root structure.

[0156] Scenario 2: The member is located inside a nested structure containing static resources to be stripped, or in data ultimately pointed to by one or more levels of pointers, and its own type is neither a structure nor a pointer. For example, an int type member inside a nested structure, or a character in a string constant ultimately pointed to by a pointer.

[0157] Understandably, the order of members (leaf nodes) that are neither structures nor pointers in the flattened data packet is consistent with their declaration order in the original structure definition. Therefore, their offsets in the flattened data packet are exactly the same as their offsets in the structure under normal compilation. The C language's "->" operator is essentially "base address + member offset determined at compile time." When compiling access code, the compiler generates a fixed offset for each member. As long as the layout of the flattened data packet is compatible with the original structure definition, this compile-time determined offset will correctly hit the corresponding position in the data packet.

[0158] Therefore, in scenario one above, the member that is neither a structure nor a pointer can be accessed directly using the structure member operator "." or the structure pointer access operator "->", without needing to perform address relocation. However, in scenario two, if the parent structure to which the member belongs is held by a pointer member (e.g., `struct config *config`), then an address relocation operation (base address + logical offset) is needed to obtain a valid pointer that correctly points to its parent structure before accessing the member that is neither a structure nor a pointer using the structure pointer access operator "->". If the parent structure to which the member belongs is directly held (e.g., `struct config config`), then no address relocation operation is needed; access can be done directly using the structure member operator "." level by level. Alternatively, an address relocation operation is needed to obtain a valid pointer that correctly points to its parent variable before accessing the member that is neither a structure nor a pointer using the structure pointer access operator "->".

[0159] Please refer to Figure 8 In some embodiments, the process of on-demand loading and accessing a static resource includes the following steps:

[0160] Step 2001: In response to an access request for a static resource, obtain the descriptor corresponding to the static resource.

[0161] Step 2002: Based on the offset and size information of the flattened data packet of the static resource in the overall data block composed of all flattened data packets, recorded in the descriptor corresponding to the static resource, apply for SRAM space and copy the flattened data packet of the static resource from the external FLASH to the applied SRAM space.

[0162] Step 2003: In response to a request to access a member of the static resource that is neither a structure nor a pointer, determine whether the member is the target object pointed to by the pointer member; if yes, proceed to step 2004; otherwise, proceed to step 2005.

[0163] Step 2004: Read the logical offset of the pointer member, add the base address of the parent variable to which the pointer member belongs in the allocated SRAM space to the logical offset of the pointer member to obtain the actual physical address of the member that is neither a structure nor a pointer; then execute step 2005.

[0164] Step 2005: Access the member that is neither a structure nor a pointer using the structure member operator "." or the structure pointer access operator "->".

[0165] For example, please refer to Figure 9Taking the static resources after flattening and stripping operations, including static_res1, static_res2, and static_res3, as an example, this illustrates the dynamic on-demand loading of static resources. Figure 9 As shown, when it is necessary to access static_res1, static_res2 and / or static_res3, their corresponding flattened data packets can be copied from the external FLASH to the dynamic resource area in the internal SRAM, which is independent of the program execution area.

[0166] Based on the above embodiments, the method further includes: releasing the requested random access memory space after completing the access to the flattened data packet.

[0167] This means that SRAM is only temporarily occupied when static resources are actually accessed, and becomes available again after the access is complete, returning the memory to the heap manager. This achieves on-demand, time-sharing multiplexing of limited SRAM resources. It should be noted that releasing SRAM after access is an optional step—if the system's SRAM space is relatively abundant, or static resources need to be accessed frequently, it is also possible to retain the loaded data packets to improve the performance of repeated accesses. These choices are engineering trade-offs and should not be construed as limitations on this application.

[0168] For example, the following uses the aforementioned static_res2 as an example to demonstrate the complete process of runtime on-demand loading and access.

[0169] When the program needs to access the static resource static_res2 during runtime, the following steps are performed:

[0170] (1) First, according to the resource size (total_size) recorded in the static_res2_desc descriptor, call the memory allocation function (e.g. malloc()) to dynamically request a memory region of the corresponding size in the heap space of SRAM, and record the returned pointer as static_res2_sram. This pointer is the starting address of the static_res2 flattened data packet in SRAM (i.e., the parent variable base address).

[0171] (2) Based on the offset recorded in the descriptor, add the base address of the entire data block in the non-volatile external storage medium to determine the physical starting address of the flattened data packet of static_res2 in FLASH, and copy the entire flattened data packet from FLASH to the newly allocated SRAM space.

[0172] (3) After loading is complete, access the data of each member:

[0173] To access the scalar member `version`, since `version` is neither a structure nor a pointer member, it can be accessed directly using the structure member operator, i.e., `static_res2_sram.version`, without any address translation.

[0174] To access `config_val` pointed to by the pointer member `config`, address relocation is required. First, read the logical offset `config_offset` stored in the `config` pointer member. Then, calculate the actual address of the `config` structure in SRAM using the following formula: `config_sram = &static_res2_sram + (intptr_t)(static_res2->config)`, where `static_res2_sram` is the base address of the parent variable `static_res2` in SRAM, and `(intptr_t)(static_res2->config)` is the logical offset relative to its parent variable `static_res2` stored in the `config` pointer member. After calculating `config_sram`, the value of `config_val` can be accessed via `config_sram->config_val`.

[0175] (4) After the access is completed, release the previously allocated SRAM space and return the memory to the heap manager.

[0176] Based on the same inventive concept as the various method embodiments described above, this application also provides corresponding apparatus and system embodiments.

[0177] Please refer to Figure 10 Some embodiments disclose a computer device 300, including: a first memory 310 for storing a first program; and a first processor 320 for executing the first program to implement the method as described in any static resource processing method embodiment of this application.

[0178] Please refer to Figure 11 Some embodiments disclose an embedded device 400, including: a second memory 410 for storing a second program; and a second processor 420 for executing the second program to implement the method as described in any static resource access method embodiment of this application.

[0179] Please refer to Figure 12Some embodiments disclose a static resource management system 500, including: a computer device 510, a non-volatile external storage medium 520, and an embedded device 530; the computer device 510 is used to execute the method described in any embodiment of the static resource access method of this application, to extract at least one flattened data packet formed by static resources from an executable and linker format file, and to write the extracted flattened data packet into the non-volatile external storage medium 520; the embedded device 530 is used to execute the method described in any embodiment of the static resource access method of this application, to load the corresponding flattened data packet from the non-volatile external storage medium 520 and access it in response to an access request for static resources. In this system, the computer device 510 is responsible for completing the flattening and burning of static resources during the post-compilation processing stage; the embedded device 530 is responsible for loading and accessing static resources from the non-volatile external storage medium 520 on demand during the program execution stage; the non-volatile external storage medium 520 acts as a data transfer medium between the two. The three work together to form a complete closed loop from "stripping storage" to "on-demand loading and access".

[0180] In the above embodiments, implementation can be achieved, in whole or in part, by software, hardware, firmware, or any combination thereof. Furthermore, as those skilled in the art will understand, the principles herein can be reflected in a computer program product on a computer-readable storage medium pre-loaded with computer-readable program code. Any tangible, non-transitory computer-readable storage medium may be used, including magnetic storage devices (hard disks, floppy disks, etc.), optical storage devices (CDs, DVDs, Blu-ray discs, etc.), flash memory, and / or the like. These computer program instructions can be loaded onto a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to form a machine, such that instructions executing on the computer or other programmable data processing apparatus can generate means for performing a specified function. These computer program instructions can also be stored in a computer-readable storage medium that can instruct the computer or other programmable data processing apparatus to operate in a particular manner, such that instructions stored in the computer-readable storage medium can form an article of manufacture, including means for implementing the specified function. The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to perform a series of operational steps on the computer or other programmable apparatus to produce a computer-implemented process, such that instructions executing on the computer or other programmable apparatus can provide steps for implementing the specified function.

[0181] This document describes various exemplary embodiments with reference to them. However, those skilled in the art will recognize that changes and modifications can be made to the exemplary embodiments without departing from the scope of this document. For example, various operational steps and components for performing operational steps can be implemented in different ways depending on the specific application or considering any number of cost functions associated with the operation of the system (e.g., one or more steps can be deleted, modified, or combined with other steps).

[0182] While the principles herein have been illustrated in various embodiments, numerous modifications to the structures, arrangements, proportions, elements, materials, and components, particularly suited to specific environments and operational requirements, may be used without departing from the principles and scope of this disclosure. These modifications and other alterations or alterations will be included within the scope of this document. Those skilled in the art will recognize that many changes can be made to the details of the above embodiments without departing from the fundamental principles of this application.

Claims

1. A static resource processing method, characterized in that, include: Obtain executable and linkable format files generated from source code, wherein at least one static resource to be stripped is marked by a segment attribute indicator and contains nested structures and / or pointer members, and a corresponding descriptor is defined for each static resource to be stripped in the source code; Scan the executable and linker format files to locate each static resource to be stripped and its corresponding descriptor; For each static resource to be stripped, recursively traverse its member structure, copy and store the values ​​of all members that are neither structures nor pointers in the traversal order to form a flattened data packet; during the traversal, if a pointer member is encountered, the pointer value of the pointer member is rewritten from an absolute address to a logical offset, where the logical offset is the offset of the starting address of the target object originally pointed to by the pointer value in the flattened data packet relative to the starting address of the parent variable to which the pointer member belongs in the flattened data packet; After traversing all the static resources to be stripped, based on the size of each flattened data packet and the position of each flattened data packet in the overall data block composed of all flattened data packets, update the offset and size information recorded in the descriptor corresponding to the static resource to be stripped that forms each flattened data packet. All flattened data packets are stripped from the executable and linker format files to obtain at least one flattened data packet that can be independently burned to a non-volatile external storage medium.

2. The static resource processing method according to claim 1, characterized in that, The recursive traversal process includes: Based on the debugging information containing attribute record format in the executable and link format files, determine the type of the currently traversed member; If the currently traversed member is a structure, then enter the structure and perform the recursive traversal on its member structure; If the currently traversed member is a pointer, then locate the target object pointed to by the pointer, and perform the recursive traversal on the member structure of the target object; If the currently traversed member is neither a structure nor a pointer, then stop the recursive traversal of the currently traversed member.

3. The static resource processing method according to claim 1, characterized in that, The segment attribute indicator is configured to link the static resource to be stripped to a preset segment, which is mapped to an invalid virtual address during the compilation phase, so that the preset segment does not occupy physical read-only memory or random access memory space.

4. The static resource processing method according to any one of claims 1-3, characterized in that, The non-volatile external storage medium is any one of NOR Flash, NAND Flash, or EEPROM.

5. A method for accessing static resources, characterized in that, include: In response to an access request for a static resource, for each requested static resource, a descriptor corresponding to each static resource is obtained. The descriptor records the offset and size information of the flattened data packet of each static resource in the overall data block composed of all flattened data packets. The overall data block is stored in a non-volatile external storage medium. All flattened data packets are generated by the static resource processing method according to any one of claims 1-4. The pointer value of the pointer member in each static resource is rewritten from an absolute address to a logical offset in the flattened data packet of each static resource. The logical offset is the offset of the starting address of the target object originally pointed to by the pointer value in the flattened data packet relative to the starting address of the parent variable to which the pointer member belongs in the flattened data packet. Based on the offset and size information recorded in the descriptor, random access memory space is requested, and the flattened data packet of each static resource is copied from the non-volatile external storage medium to the requested random access memory space. In response to the need to access the target object pointed to by the pointer member, the logical offset of the pointer member is read, the base address of the parent variable to which the pointer member belongs in the allocated random access memory space is added to the logical offset of the pointer member to obtain the actual physical address of the target object and then access it.

6. The static resource access method according to claim 5, characterized in that, Also includes: In response to a need to access a member in a flattened data packet that is neither a structure nor a pointer, the value of the member that is neither a structure nor a pointer is accessed via a structure member operator or a structure pointer access operator.

7. The static resource access method according to claim 5 or 6, characterized in that, Also includes: After completing access to the flattened data packet, release the requested random access memory space.

8. A computer device, characterized in that, include: The first memory is used to store the first program; A first processor is configured to implement the static resource processing method as described in any one of claims 1 to 4 by executing the first program.

9. An embedded device, characterized in that, include: The second memory is used to store the second program; A second processor is configured to implement the static resource access method as described in any one of claims 5 to 7 by executing the second program.

10. A static resource management system, characterized in that, include: Computer equipment, non-volatile external storage media, and embedded devices; The computer device is configured to perform the static resource processing method as described in any one of claims 1 to 4, to extract at least one flat data packet formed from static resources from an executable and linkable format file; And for writing the stripped flattened data packets into the non-volatile external storage medium; The embedded device is configured to execute the static resource access method as described in any one of claims 5 to 7, in response to an access request for a static resource, to load a corresponding flattened data packet from the non-volatile external storage medium and access it.

Images