Module loading method and device, computer device, storage medium and program product

Abstract

The application relates to a module loading method and device, computer equipment, a storage medium and a program product. The method comprises the following steps: in response to a loading instruction for a secondary development module, obtaining the loaded times of the secondary development module and a dynamic library file; according to the loaded times, determining the module index identifier of the secondary development module under the current loading times; extracting the symbol data of the secondary development module from the dynamic library file; and binding the module index identifier and the symbol data, and loading into the process memory of the secondary development module under the current loading times. The method can improve the system running stability and maintainability.

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to a module loading method, apparatus, computer equipment, storage medium, and computer program product. Background Technology

[0002] During system development, to adapt to diverse product needs across various scenarios, most systems adopt a modular and scalable architecture, supporting users to extend system functionality through secondary development. External secondary development modules typically exist in the form of Dynamic Linked Libraries (DLLs) or Shared Objects (SOs), and are dynamically loaded and called by the main system program at runtime.

[0003] However, during the loading process of secondary development modules, due to the reloadable nature of dynamic link libraries, loading conflicts are prone to occur, leading to loading anomalies or process crashes, which greatly reduces the stability and maintainability of the system. Summary of the Invention

[0004] Therefore, it is necessary to provide a module loading method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the stability and maintainability of system operation in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a module loading method. The method includes:

[0006] Get the number of times the secondary development module has been loaded and the dynamic library files;

[0007] Based on the number of times the module has been loaded, determine the module index identifier of the secondary development module at the current number of loads;

[0008] Extract the symbol data of the secondary development module from the dynamic library file;

[0009] The module index identifier is bound to the symbol data and loaded into the internal storage area of ​​the secondary development module at the current loading count.

[0010] In one embodiment, determining the module index identifier of the secondary development module at the current load count based on the number of loads includes:

[0011] Obtain the module identifier of the secondary development module;

[0012] When the number of loaded times is zero, the basic index identifier is determined as the module index identifier of the secondary development module under the current number of loaded times;

[0013] If the number of times the module has been loaded is not zero, the instance index identifier of the secondary development module is determined based on the number of times the module has been loaded.

[0014] By combining the basic index identifier and the instance index identifier, the module index identifier of the secondary development module under the current loading count is obtained.

[0015] In one embodiment, the method further includes:

[0016] In response to the symbol generation instruction for the secondary development module, the original dynamic library file and symbol file of the secondary development module are obtained;

[0017] The symbol file is structured by calling a symbol generation tool and written into the original dynamic library file to obtain the dynamic library file of the secondary development module.

[0018] In one embodiment, the step of structuring the symbol file and writing it into the original dynamic library file to obtain the dynamic library file of the secondary development module includes:

[0019] Extract the original symbol information of the secondary development module from the symbol file;

[0020] The original symbol information is structured according to a preset symbol data structure to obtain the symbol data of the secondary development module;

[0021] The symbol data is encrypted using a preset encryption algorithm to obtain encrypted symbol data.

[0022] The encrypted symbol data is written into the original dynamic library file to obtain the dynamic library file of the secondary development module.

[0023] In one embodiment, extracting the symbol data of the secondary development module from the dynamic library file includes:

[0024] Extract the encrypted symbol data of the secondary development module from the dynamic library file;

[0025] The encrypted symbol data is decrypted using a preset decryption algorithm to obtain the symbol data of the secondary development module.

[0026] In one embodiment, the method further includes:

[0027] Once the secondary development module is loaded, extract all variable objects from the symbol data.

[0028] Each variable object is identified based on the module index identifier to obtain the variable identifier of each variable object at the current load count; the variable identifier includes the module index identifier and the variable index identifier of the corresponding variable object;

[0029] Get the list of variables in the current data acquisition interface;

[0030] Based on the variable identifiers, the variable objects are added to the variable list to obtain the updated data acquisition interface.

[0031] In one embodiment, the method further includes:

[0032] In response to a data acquisition operation on a target variable in the data acquisition interface, the target variable identifier of the target variable is determined;

[0033] The target variable identifier is parsed to obtain the target module index identifier of the target software to which the target variable belongs under the corresponding number of loads, and the target variable index identifier of the target variable;

[0034] Based on the target module index identifier, the target symbol data of the target software is obtained from the internal storage area of ​​the target software at the corresponding loading number;

[0035] Search for variable symbol data that matches the target variable identifier from the target symbol data;

[0036] The storage address of the target variable is located based on the variable symbol data, and the variable data of the target variable is collected from the storage address.

[0037] Secondly, this application also provides a module loading device. The device includes:

[0038] The instruction response module is used to obtain the number of times the secondary development module has been loaded and the dynamic library files;

[0039] The index identifier determination module is used to determine the module index identifier of the secondary development module at the current loading count based on the number of loadings.

[0040] A symbol data extraction module is used to extract symbol data of the secondary development module from the dynamic library file;

[0041] The data storage module is used to bind the module index identifier with the symbol data and load it into the process memory of the secondary development module at the current loading count.

[0042] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the above-described method.

[0043] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the steps of the above-described method.

[0044] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the steps of the above-described method.

[0045] The aforementioned module loading method, apparatus, computer equipment, storage medium, and computer program product, when loading a secondary development module, first obtains the number of times the secondary development module has been loaded and the dynamic library file. Based on the number of loads, it determines the module index identifier of the secondary development module at the current load count. Simultaneously, it extracts the symbol data of the secondary development module from the dynamic library file, binds the module index identifier with the symbol data, and loads it into the process memory of the secondary development module at the current load count. This method, by generating a unique module index identifier for each secondary development module load and allocating independent, isolated process memory, and storing the bound module index identifier and symbol data in the process memory, can construct an independent logical namespace and data storage context for each load. This fundamentally reduces secondary development module loading conflicts in multi-instance loading scenarios and improves the system's operational stability and maintainability in complex secondary development environments. Attached Figure Description

[0046] Figure 1 This is an application environment diagram of the module loading method in one embodiment;

[0047] Figure 2 This is a flowchart illustrating a module loading method in one embodiment;

[0048] Figure 3 This is a flowchart illustrating the process of determining the module index identifier of a secondary development module based on the number of times it has been loaded, as described in one embodiment.

[0049] Figure 4 This is a flowchart illustrating the process of structuring a symbol file and writing it into the original dynamic library file to obtain the dynamic library file of the secondary development module in one embodiment.

[0050] Figure 5 This is a flowchart illustrating the module loading method in another embodiment;

[0051] Figure 6 This is a flowchart illustrating the module loading method in another embodiment;

[0052] Figure 7 This is a flowchart illustrating the module loading method in another embodiment;

[0053] Figure 8 This is a structural block diagram of the module loading device in one embodiment;

[0054] Figure 9 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0056] The module loading method provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, the loading system 102 communicates with the user terminal 104 via a network. A data storage system can store the data that the loading system 102 needs to process. The data storage system can be integrated into the loading system 102 or placed in the cloud or on another network server. The user can trigger a loading command for the secondary development module through the user terminal 104. In response to the loading command, the loading system 102 obtains the number of times the secondary development module has been loaded and the dynamic library file. Based on the number of loads, it determines the module index identifier of the secondary development module at the current loading count, extracts the symbol data of the secondary development module from the dynamic library file, binds the module index identifier with the symbol data, and loads it into the process memory of the secondary development module at the current loading count. The loading system 102 can be integrated into the user terminal 104, which can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart vehicle devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc.

[0057] Understandably, the loading system 102 can be a functional subsystem set up in any business system. For example, the loading system 102 can be an internally integrated functional subsystem of an industrial control system, embedded system, cloud computing and virtualization system, automotive electronic system, medical equipment system, etc.

[0058] In industrial control systems, the loading system 102 can be used to load and run dynamic loading software for industrial control equipment such as PLCs, frequency converters, and servo drives. In embedded systems, the loading system 102 can be used to load and monitor the status of third-party drivers or plugins in device firmware. In cloud computing and virtualization systems, the loading system 102 can be used to load and monitor the performance of dynamically loaded components such as virtual machines and containers. In automotive electronic systems, the loading system 102 can be used to load, acquire data, and diagnose multi-vendor software for vehicle ECUs. In medical device systems, the loading system 102 can be used to load and acquire the status of dynamic loading algorithm software for medical imaging equipment and vital sign monitors.

[0059] In one embodiment, such as Figure 2 As shown, a module loading method is provided, which can be applied to Figure 1 Taking the loading system 102 as an example, the following steps are included:

[0060] S202, retrieve the number of times the secondary development module has been loaded and the dynamic library files.

[0061] Secondary development modules are software modules that are independent of the main program compilation unit of the loading system. These are modules developed by external developers and are typically written independently by third-party developers or users to implement extended functionality. Secondary development modules are usually compiled into dynamic link libraries or software function extension packages with shared object files.

[0062] The "load count" is a metric maintained internally by the loading system, recording the total number of times the secondary development module has been successfully loaded since the current main program process started. For example, a load count of 2 indicates that the secondary development module has been loaded twice during the current main program execution.

[0063] Dynamic library files are binary data files organized according to the system's defined dynamic link library format, and are the sole physical carrier of secondary development modules. Dynamic library files contain structured information such as exported functions that can be dynamically called by the main program at runtime, global data, and import and export tables used for dynamic linking.

[0064] In one embodiment, the dynamic library file may include two different executable formats: PE (Portable Executable) and ELF (Executable and Linkable Format), for Windows and Unix / Linux systems, respectively. Under Windows, the PE file is an exe or dll file, while under Linux, the ELF file is a dynamic library file or a so file.

[0065] For example, when a secondary development module needs to be loaded, the loading system can first obtain the number of times the secondary development module has been loaded and the dynamic library file.

[0066] In one embodiment, the loading system can respond to a loading command for the secondary development module by obtaining the number of times the secondary development module has been loaded and its dynamic library files. The loading command is a signal instructing the loading system to load the secondary development module within the system.

[0067] In one embodiment, the loading system can automatically load secondary development modules based on configuration information.

[0068] In one embodiment, the loading system has a counter for each loaded secondary development module to record the number of times the corresponding secondary development module has been loaded. The loading system can determine the number of times the secondary development module has been loaded by the counter corresponding to the module identifier. It is understood that if the secondary development module is being loaded for the first time, the loading system determines that the number of times the secondary development module has been loaded is zero.

[0069] S204. Based on the number of times the secondary development module has been loaded, determine the module index identifier of the secondary development module under the current number of loads.

[0070] The module index identifier is a unique label used to distinguish the running instance of the secondary development module at the current loading count. It can uniquely identify the running instance of the secondary development module at the current loading count.

[0071] Understandably, the module index identifier can be determined based on the number of times the secondary development module has been loaded in the loading system. For example, a unique integer value or handle can be generated directly based on the number of loads, and combined with the software name of the secondary development module as the module index identifier for the current load count. Alternatively, the corresponding identifier generation information can be determined based on the recorded number of loads, and the module index identifier for the secondary development module for the current load count can be generated based on the identifier generation information.

[0072] In one embodiment, the loading system can add 1 to the number of loads already loaded to obtain the loading number for the current loading count. The loading number is then combined with the software name of the secondary development module to obtain the module index identifier for the current loading count.

[0073] S206, Extract symbol data of secondary development modules from dynamic library files.

[0074] Symbol data is a collection of metadata mapping between binary machine instructions and logical names in the source code. It consists of structured records parsed and extracted from specific structural regions of a dynamic library file. Each record contains at least one publicly visible name and its corresponding entry point's relative virtual address or offset. Symbol data can be obtained by structuring the symbol file corresponding to the dynamic library file according to a predefined data structure. A symbol file is a special data file generated by the software compiler when compiling a dynamic library file for a secondary development module. It contains the mapping relationship between program code and memory addresses. For example, a symbol file can be a PDB file under Windows or a debug file under Linux.

[0075] For example, after the loading system obtains the dynamic library file of the secondary development module, it can perform information extraction operations on the dynamic library file to extract the symbol data of the secondary development module from the dynamic library file.

[0076] In one embodiment, the symbol information of the secondary development module can be directly generated and integrated into the compilation toolchain, and symbol data can be directly generated and embedded during the compilation of dynamic library files.

[0077] In one embodiment, symbol data can be written into the dynamic library file in the form of a data segment. Taking a PE file under the Windows system as an example, the PE file editing interface can be used to add a custom data segment named "inodbg" in the dynamic library file (DLL), and the symbol data can be written into this segment to obtain a dynamic library file containing symbol data.

[0078] S208 binds the module index identifier with the symbol data and loads it into the process memory of the secondary development module at the current loading count.

[0079] Among them, process memory is a virtual address space in the local storage space of the loading system main program, which is specially allocated for the secondary development module under the current loading count. It is used to store software instance information of the secondary development module under the current loading count.

[0080] For example, the loading system can allocate a dedicated internal storage area for the secondary development module under the current loading count in the local storage space, and then bind the module index identifier with symbol data and load it into the internal storage area to complete the loading of the secondary development module.

[0081] In the module loading method described above, when loading a secondary development module, the system first obtains the number of times the module has been loaded and the dynamic library file. Based on the number of loads, it determines the module index identifier for the current load count. Simultaneously, it extracts the symbol data of the secondary development module from the dynamic library file, binds the module index identifier with the symbol data, and loads it into the process memory for the current load count. This method generates a unique module index identifier for each secondary development module load and allocates independent, isolated process memory. By storing the bound module index identifier and symbol data in the process memory, it establishes an independent logical namespace and data storage context for each load, fundamentally reducing secondary development module loading conflicts in multi-instance loading scenarios and improving the system's operational stability and maintainability in complex secondary development environments.

[0082] In one embodiment, such as Figure 3 As shown in S204, based on the number of times the module has been loaded, determine the module index identifier of the secondary development module under the current number of loads, including:

[0083] S302, obtain the module identifier of the secondary development module.

[0084] Among them, the module identifier is the unique identification information of the secondary development module in the loading system, which is mainly used to distinguish different secondary development modules.

[0085] For example, the loading system can obtain the module identifier of the secondary development module.

[0086] In one embodiment, the module identifier can be the module name of the secondary development block.

[0087] In one embodiment, the module identifier may be a simple auto-incrementing integer number.

[0088] In another embodiment, if more complex scenarios need to be supported, such as multiple CNC system protocols in a distributed system, a globally unique identifier such as a UUID can be used instead of a local integer number.

[0089] In one embodiment, the system supports the hierarchical namespace of modules, such as vendor:module:version.

[0090] In one embodiment, the loading system can also support dynamic alias management, meaning users can give frequently used module instances more easily recognizable names.

[0091] S304, when the number of loads is zero, the module identifier is determined as the module index identifier of the secondary development module under the current number of loads.

[0092] For example, a load count of zero indicates that the secondary development module is being loaded for the first time in this loading system, and it does not need to be distinguished from the same secondary development module in other load counts. Therefore, the loading system can directly determine the module identifier of the secondary development module as the module index identifier of the secondary development module in the current load count when the load count is zero.

[0093] S306, if the number of times it has been loaded is not zero, determine the instance index identifier of the secondary development module based on the number of times it has been loaded.

[0094] The instance index identifier is a distinguishing suffix used to differentiate between different loaded copies of the same secondary development module, distinguishing software instances of the same secondary development module at different loading counts. For example, if a secondary development module has been loaded 1 time, the instance index identifier recorded this time can be set to 0, indicating that this is the second loaded copy of the software.

[0095] For example, if the number of loads is not zero, it indicates that the secondary development module is not being loaded for the first time in the loading system and needs to be distinguished from other secondary development modules with different load counts. Therefore, the loading system can determine the instance index identifier of the secondary development module based on the number of loads when the number of loads is not zero.

[0096] S308, combine the module identifier and the instance index identifier to obtain the module index identifier of the secondary development module under the current load count.

[0097] For example, after obtaining the module identifier and instance index identifier of the secondary development module, the loading system can combine the module identifier and instance index identifier to obtain the module index identifier of the secondary development module under the current loading count.

[0098] In one embodiment, when the same secondary development module is loaded multiple times, that is, when the dynamic link library of the secondary development module is loaded multiple times, the index name can be increased with the instance index during the second loading. The format can be "dll_ + module name + [instance number]", for example, dll_CommonEdi[1].

[0099] In the above embodiments, when the same secondary development module is loaded multiple times, a globally unique module index identifier is constructed for each load by combining the module identifier of the secondary development module with the instance index identifier generated based on the number of times the corresponding secondary development module has been loaded. Based on this, when the same secondary development module is loaded multiple times, different loaded copies obtain different identifiers due to the different instance index identifiers. This enables the system to distinguish between copies when querying symbols or accessing resources, reducing the risk of address conflicts and data overwriting caused by the same symbol name, thereby improving the operational stability and maintainability in multi-instance loading scenarios.

[0100] In one embodiment, the module loading method may further include: in response to a symbol generation instruction for the secondary development module, obtaining the original dynamic library file and symbol file of the secondary development module; performing structured processing on the symbol file by calling a symbol generation tool and writing it into the original dynamic library file to obtain the dynamic library file of the secondary development module.

[0101] The symbol generation instruction is a signal used to instruct the secondary development module to rewrite the dynamic library file and insert symbol data into the original dynamic library file.

[0102] Raw dynamic library files refer to dynamic library files that have not had their symbol data written into them after structured processing; that is, dynamic library files that are directly compiled by a compiler.

[0103] The symbol generation tool is a specialized processing tool for extracting and structuring symbol data. It has functions such as reading symbol files, reorganizing the original symbol information according to a preset data structure, encrypting the reorganized data, and writing it to a dynamic library file. Understandably, the symbol generation tool can be pre-developed by the system developers of the loading system based on the actual loading requirements of the loading system. It can generate symbol data for any secondary development module. Secondary development users only need to develop their own modules according to their own needs, without having to adhere to complex interface specifications. They have autonomy over the specific variables to be collected, effectively reducing the development burden and threshold for secondary development users, and improving their development flexibility and maintenance convenience.

[0104] Structured processing involves reorganizing the raw symbol information in a symbol file from a flat storage format into a custom symbol data structure format. The raw symbol information can include all symbol information from the program in the dynamic library file, such as global variable names, offset addresses, type information, and member structures.

[0105] For example, the loading system can respond to a symbol generation instruction for the secondary development module, obtain the original dynamic library file and symbol file of the secondary development module, and then call a pre-configured symbol generation tool to perform structured processing on the symbol file and write it into the original dynamic library file to obtain the dynamic library file of the secondary development module.

[0106] In one embodiment, the custom symbol data structure format may include a hierarchical index format. The preset symbol data structure may include a custom symbol data header, a lookup table, symbol segments, type segments, and index segments, etc.

[0107] The symbol header may include:

[0108] ino magic number: Data header used to verify the validity of symbolic data.

[0109] table offset: Points to the offset address of the retrieved table.

[0110] symbol offset: Points to the offset address of the symbol segment.

[0111] type offset: Points to the offset address of the type segment.

[0112] index offset; points to the offset address of the index segment.

[0113] The index table can include a mapping between symbol names and symbol segment offset addresses, used to quickly locate the position of a variable identifier within a symbol segment. Understandably, the lookup table can use hashing or dictionary methods to implement the mapping between symbol names and symbol segment offset addresses.

[0114] The symbol segment stores all symbol identifiers and symbol information in the software code, and may include:

[0115] Variable identifiers, i.e., the variable names of global variables or member variables, are used to locate symbolic information.

[0116] Offset address, that is, the offset address of a variable. The offset address of a member variable is a relative offset, while the offset address of a non-member variable is a virtual address.

[0117] Type segment index: The index of the type information of the variable identifier in the type segment.

[0118] Type information: The symbol identifies the type of the variable, such as basic types like double, float, and int, or composite types like structures, unions, and pointers.

[0119] The type field is used to store data type information and may include:

[0120] Type size: The number of bytes occupied by the variable, such as the size of int type is 4.

[0121] Number of members: The number of members in the type. For user-defined types, this represents the number of member variables.

[0122] Member Index: The offset address of the first member of the type within the index segment. Understandably, the offsets of other members within the index segment are arranged in the order of their definitions, based on the offset of the first member.

[0123] The index segment is used to store the offset address of the member's symbol in the symbol segment.

[0124] In the above embodiments, the pre-built symbol generation tool can be used to structurally reorganize the original symbol information of any secondary development module and write it into the original dynamic library file. This can effectively reduce the development burden and threshold for secondary development users. Secondary development users do not need to define additional data export interfaces and can directly select and collect the user-defined global variables used in the software, thereby improving the development flexibility and maintenance convenience of secondary development users.

[0125] Furthermore, in one embodiment, such as Figure 4 As shown, the symbol file is structured and written into the original dynamic library file to obtain the dynamic library file of the secondary development module, including:

[0126] S402, extract the original symbol information of the secondary development module from the symbol file.

[0127] For example, a symbol generation tool can extract the original symbol information of a secondary development module from a symbol file.

[0128] In one embodiment, taking the original dynamic library file as a DLL file and the symbol file as the corresponding PDB symbol file of the DLL file as an example, the symbol generation tool can use a public API interface to read the original symbol information in the symbol file. For example, under Windows, the dbghelp API can be used to traverse the PDB file and extract the original symbol information of the secondary development module. Under Linux, the dwarf library can be used to read the original symbol information in the debug file.

[0129] S404: The original symbol information is structured according to the preset symbol data structure to obtain the symbol data of the secondary development module.

[0130] For example, the symbol generation tool can serialize and organize the original symbol information according to a preset symbol data structure to generate binary symbol data in a custom format, that is, the symbol data of the secondary development module.

[0131] S406, use a preset encryption algorithm to encrypt the symbol data to obtain encrypted symbol data.

[0132] The preset encryption algorithm is an encryption algorithm pre-set in the symbol generation tool. It is used to encrypt symbol data, reducing the security risk of symbol information being exposed in plaintext when the software is released, and enhancing data confidentiality. Understandably, the specific type of preset encryption algorithm can be selected according to the actual security requirements of the data. For example, the preset encryption algorithm may include, but is not limited to, symmetric encryption algorithms and asymmetric encryption algorithms.

[0133] For example, the symbol generation tool can use a pre-set encryption algorithm to encrypt the symbol data to obtain encrypted symbol data.

[0134] S408 writes the encrypted symbol data into the original dynamic library file to obtain the dynamic library file of the secondary development module.

[0135] For example, the symbol generation tool can write encrypted symbol data into the original dynamic library file to obtain the dynamic library file of the secondary development module.

[0136] In one embodiment, taking the Windows system as an example, the symbol generation tool can use the PE file editing interface to add a custom data segment named "inodbg" in the DLL, and write the encrypted symbol data into this segment to obtain a dynamic library file that embeds the encrypted symbol data.

[0137] In one embodiment, the encryption key for the symbolic data can be securely managed by the developer of the business system to which the loading system belongs, and can typically be stored in the system's secure storage area, such as the HSM hardware security module or the system's protected memory area.

[0138] In the above embodiments, by extracting the original symbol information from the symbol file and serializing and recombining it according to a preset structure, the original symbol information can be transformed from a flat record into indexed data that supports hierarchical retrieval. During subsequent data collection, the storage address can be quickly located based on the variable identifier, improving retrieval efficiency. Simultaneously, encrypting the symbol data before writing it to the dynamic library file prevents the symbol data in the dynamic library file from being directly read, reducing the security risk of plaintext exposure of symbol information upon software release and enhancing data confidentiality.

[0139] In one embodiment, S206, extracting symbol data of the secondary development module from the dynamic library file includes: extracting encrypted symbol data of the secondary development module from the dynamic library file, decrypting the encrypted symbol data using a preset decryption algorithm, and obtaining the symbol data of the secondary development module.

[0140] The preset decryption algorithm is a reverse algorithm pre-configured in the loading system and matches the preset encryption algorithm in the symbol generation tool. It is used to decrypt the encrypted symbol data and restore it to plaintext to obtain the symbol data for the secondary development module. For example, if the preset encryption algorithm is AES-256 symmetric encryption, then the preset decryption algorithm can be the corresponding implementation of AES-256 decryption.

[0141] For example, after the loading software obtains the dynamic library file, it can extract the encrypted symbol data of the secondary development module from the dynamic library file, and then use a predetermined decryption algorithm to decrypt the encrypted symbol data to obtain the symbol data of the secondary development module.

[0142] In one embodiment, the data decryption process can be executed in the system kernel mode or a protected user mode, and the key is not exposed in external components such as the data acquisition interface.

[0143] In one embodiment, the loading system may use a periodic key rotation mechanism to ensure the long-term security of the key.

[0144] In one embodiment, the loading system can directly locate a custom data segment in the dynamic library file, such as the inodebg segment, read the encrypted symbol data in the segment, and apply a preset decryption algorithm to restore the symbol data of the custom structure.

[0145] In one embodiment, after obtaining the symbol data, the loading system can further parse and restore the symbol data into a structured symbol table object, bind it with the module index identifier, and load it into the process memory.

[0146] In the above embodiments, by directly extracting encrypted symbol data from the dynamic library file and decrypting it at runtime, the acquisition of symbol data does not depend on the existence of external independent symbol files. The software does not need to carry or search for matching symbol files during deployment and operation, which reduces decryption failures or retrieval anomalies caused by missing symbol files, version inconsistencies, or incorrect search paths, thereby improving the reliability of data acquisition in the secondary development module.

[0147] As the number of secondary development modules increases, the demand for expansion of the user interface also gradually increases. In one embodiment, such as... Figure 5 As shown, the module loading method may also include:

[0148] S502, once the secondary development module is loaded, extracts all variable objects from the symbol data in the secondary development module.

[0149] Among them, a variable object is a symbolic record in the symbolic segment of symbolic data whose type field is marked as "variable". It can include global variables, static variables, and local static variables.

[0150] For example, once the secondary development module has been loaded, the loading system can extract all variable objects from the symbolic data in the secondary development module.

[0151] S504: Identify each variable object based on the module index identifier to obtain the variable identifier of each variable object under the current load count.

[0152] The variable identifier includes the module index identifier and the variable index identifier of the corresponding global variable. The variable index identifier is the inherent name identifier of the corresponding variable in the symbolic data. It can be understood that the same variable object has the same variable index identifier, but the variable identifier is different under different loads.

[0153] For example, the loading system can obtain the variable index identifier of each variable object. For each variable object, the variable index identifier is combined with the module index identifier to obtain the variable identifier of the variable object in the current loading count.

[0154] For example, if the variable index of a variable object is varB, its variable identifier can be dll_UserModule.varB in the first load, dll_UserModule[0].varB in the second load, dll_UserModule[1].varB in the third load, and so on.

[0155] S506, Get the variable list of the current data acquisition interface.

[0156] The data acquisition interface is a visual interactive window provided by the loading system for users to view and select collectable data items. It is a graphical user interface component in the main program of the system, used to display all currently collectable variables and their hierarchical structure to the operator, and to receive variable selection operations and acquisition control commands from the operator.

[0157] The variable list is a data source control in the data acquisition interface used to display the set of collectable variables. It is an ordered data structure maintained internally by the data acquisition interface, typically a list or tree structure, which stores the set of variable identifiers currently available for user selection and controls the specific items displayed in the interface's navigation pane.

[0158] For example, the loading system can obtain the variable list of the current data acquisition interface.

[0159] In one embodiment, the variable navigation pane in the data acquisition interface can be expanded to support multi-level nesting, with the top-level nodes being different secondary development modules identified by their index names, such as "dll_UserModule", "UserModule[1]", etc. The second-level nodes can be global variables within each secondary development module, and the third-level and lower-level nodes can be nested structural members. When the user selects a variable, the system will automatically record the complete module index and variable path, such as "dll_UserModule.structdata.fieldx", to ensure the accuracy of the subsequent acquisition process.

[0160] In one embodiment, the permission system in the loading system can also be finely controlled according to modules, allowing different access permission levels to be set for different secondary development modules. For example, module 0 can be set to be accessible to users, while module 1 can be set to be accessible only to administrators, thereby achieving flexible permission management.

[0161] S508, based on the variable identifiers, adds each variable object to the variable list to obtain the updated data acquisition interface.

[0162] For example, the loading system can add each variable object to the variable list based on each variable identifier, that is, add each variable identifier to the variable list to obtain an updated data acquisition interface, so that users can see all the collectable variables of the newly loaded secondary development module through the updated data acquisition interface.

[0163] In the above embodiments, by identifying the variable objects with module index identifiers, each variable in the interface can be traced back to its specific loading instance. When the same secondary development module is loaded multiple times, variable objects with the same name in different loading instances can be distinguished from each other in the interface due to different variable identifiers. This reduces the risk that users may select the wrong collection target due to the inability to distinguish the source of variables during data collection, thereby improving the correctness of data collection operations and the usability of the interface in multi-instance scenarios.

[0164] In one embodiment, such as Figure 6 As shown, the module loading method may also include:

[0165] S602, in response to a data acquisition operation for a target variable in the data acquisition interface, determines the target variable identifier of the target variable.

[0166] The target variable refers to the specific data object selected by the user in the data acquisition interface, for which the user expects to collect values. Data acquisition operations can include clicking, checking boxes, or other interactive actions. The target variable identifier is the complete composite identifier of the target variable within the loading system.

[0167] For example, the loading system can determine the target variable identifier of the target variable in response to the user's data acquisition operation on the target variable in the data acquisition interface.

[0168] For example, a user can select a variable from a secondary development module on the data acquisition interface for acquisition. This variable is the target variable. The loading system will respond to the user's variable selection action and determine the target variable identifier of the target variable.

[0169] S604, perform identifier parsing on the target variable identifier to obtain the target module index identifier of the target module to which the target variable belongs under the corresponding number of loads, and the target variable index identifier of the target variable.

[0170] Identifier parsing refers to the reverse decoding operation that breaks down a composite identifier into its constituent components. It can decompose the target variable identifier into module index identifier and variable index identifier.

[0171] Here, the target module is the instance of the secondary development module to which the target variable belongs. The target module index identifier is the module index identifier under the load count corresponding to the target variable in the target module. The target variable index identifier is the original name of the target variable in the symbolic data.

[0172] For example, the loading system can perform identifier parsing on the target variable identifier to obtain the target module index identifier and the target variable index identifier.

[0173] Taking the target variable identifier as dll_UserModule[1].axis_data.position.x as an example, the loading system can perform identifier parsing on the target variable identifier to obtain the module index identifier as: dll_UserModule[1], that is, the module index name is dll_UserModule[1], and the index number corresponding to the internal positioning index name is 1. Extract the variable level path, that is, the target variable index identifier is: axis_data.position.x.

[0174] S606: Based on the target module index identifier, obtain the target symbol data of the target module from the process memory of the target module at the corresponding loading count.

[0175] Among them, the target symbol data is a complete set of structured symbol information of the target module under the corresponding number of loads. That is, the complete binary data body that the system reads from the process memory of the target module and conforms to the preset symbol data structure, which is used for subsequent variable symbol lookup.

[0176] For example, the loading system can determine the process memory of the target module at the corresponding number of loadings based on the target module index identifier, and then obtain the target symbol data of the target module from the process memory.

[0177] For example, if the loading system determines that the module index identifier is dll_UserModule[1], it can search for the target symbol data of the target module in the process memory modulesymbolmap according to the software index number 1, which is the symbol table object.

[0178] S608, Search for variable symbol data that matches the target variable identifier from the target symbol data.

[0179] Among them, variable symbol data is the symbol record information corresponding to the target variable in the target symbol data, which may include fields such as the target variable's offset address, type segment index, type information, and size in bytes.

[0180] For example, the loading system can search for variable symbol data that matches the target variable identifier from the target symbol data.

[0181] In one embodiment, the loading system can use a hierarchical symbol lookup approach. For example, the first level is the symbol segment index. The loading system can search for `axis_data` in the symbol table's lookup table to obtain its symbol segment index. From the symbol segment, it finds the type of `axis_data`, assuming it's a structure `AxisData`, and obtains its type index and base address offset (relative offset). It then searches for the member information of `AxisData` in the type segment to find the `position` member, and finally finds the symbol segment index corresponding to the `position` member from the index segment. The second level is similar, searching for `position`, assuming it's a structure `PositionData`. The third level is searching for `x`, assuming it's of type `double`.

[0182] S610 locates the storage address of the target variable based on the variable symbol data and collects the variable data of the target variable from the storage address.

[0183] The storage address is the specific memory location of the target variable in the target module's memory space. This address points to the actual storage location of the target variable in the secondary development module's data segment and is a memory pointer that directly reads the variable's value.

[0184] Among them, variable data is the actual numerical content stored in the memory address of the target variable, that is, the binary identifier of the specific value corresponding to the variable at the current moment, which is read from the memory address of the target variable.

[0185] For example, the loading system can locate the storage address of the target variable based on the variable symbol data, and collect the variable data of the target variable from the storage address.

[0186] In one embodiment, the loading system can accumulate the relative offsets of each level to obtain the storage address of the target variable, i.e., the absolute address:

[0187] Absolute address = module base address + axis_data offset + position offset + x offset.

[0188] After obtaining the absolute address, the loading system can read the corresponding byte data based on the absolute address and data type, and return the variable data of the target variable. For example, if the data type is double, the loading system can read 8 bytes of data from the absolute address and return the acquisition results to the user through the data acquisition interface.

[0189] In the above embodiments, by resolving the variable identifier into a module index identifier and a variable index identifier, and directly locating the process memory of the corresponding loading instance based on the module index identifier to obtain independent and accurate symbolic data, the variable data collection operation can be strictly limited to the context of the software instance. Variables with the same name in different loading instances do not interfere with each other because their respective storage areas are isolated, which effectively improves the accuracy and efficiency of variable data collection in secondary development modules.

[0190] In one embodiment, the loading system may further respond to an unloading command for the target loading module by determining the target module index identifier of the target loading module, and determining the process memory of the target loading module based on the target module index identifier. The binding information between the target module index identifier and symbol data of the target loading module is then cleared from the process memory. The variable list of the current data acquisition interface is obtained, and the software variable corresponding to the target loading module is located from the variable list based on the target module index identifier. This module variable is then deleted from the variable list, completing the module unloading process.

[0191] In one embodiment, to reduce the performance impact on the main system program, the loading system can employ a multi-threaded model during data acquisition, reading, and feedback. These threads can include an acquisition thread and a feedback thread. The acquisition thread can periodically read data from memory and write it to a buffer queue based on a user-selected list of variables and their addresses, for example, reading data every 10ms. The feedback thread is responsible for continuously reading data from the buffer queue and feeding the data back to the data acquisition interface via shared memory or a network protocol. The loading system can also be configured with a buffering mechanism, such as double or triple buffering, to reduce the risk of data loss due to a mismatch between the acquisition and feedback frequencies.

[0192] In one embodiment, such as Figure 7 As shown, a module loading method is provided. Taking the application of this method to the secondary development module loading and dynamic variable acquisition process of a CNC system as an example, the method can specifically include the following steps:

[0193] S701, in response to a load command for a secondary development module, obtains the number of times the secondary development module has been loaded and the dynamic library files.

[0194] The dynamic library file of the secondary development module is a dynamic library file obtained by processing the original dynamic library file and embedding symbol data. The processing is completed by an offline symbol generation tool.

[0195] The symbol generation tool can be mainly composed of the following parts:

[0196] The symbol extraction module uses standard APIs provided by the compiler tools to read the raw symbol information from the symbol file. Standard APIs can be, for example, the dbghelp library under Windows or the dwarf library under Linux.

[0197] The symbol organization module organizes, deduplicates, and compresses the extracted symbol information according to a preset custom symbol data structure.

[0198] The symbol encryption module encrypts the generated symbol data and supports various encryption algorithms, such as symmetric encryption like AES and asymmetric encryption like RSA.

[0199] The data writing module uses a dynamic library file editing tool to add a new data segment to the module's dynamic library file and write the encrypted symbolic data into that segment.

[0200] The workflow of a symbol generation tool can include the following processing stages:

[0201] First, input parsing, which means receiving the dynamic library file path and symbol file path of the secondary development module. Specifically, it can be the input target DLL file and the corresponding PDB symbol file.

[0202] In one embodiment, the loading system in the CNC system can call SymInitialize to initialize the symbol processing environment and call SymLoadModuleEx to load the PDB file.

[0203] Second, symbol extraction, which involves using standard APIs to read raw symbol information from symbol files. Specifically, this can be done by using the dbghelp API to traverse the PDB file and extract all symbol information, including global variable names, offset addresses (virtual addresses), type information, member structures, etc.

[0204] In one embodiment, the loading system can traverse all symbols in the PDB and extract the symbol name (variable name), symbol address (virtual address or relative offset), symbol type (basic type such as int, double or custom structure), type size (number of bytes occupied by the variable) for each global variable. For structure types, the above information of its member variables is extracted recursively.

[0205] Third, data organization, which involves organizing and compressing data according to a custom structure. Specifically, this can be done by serializing and organizing the extracted symbol information based on a preset symbol data structure, such as a search table, symbol segment, type segment, index segment, etc., to generate binary symbol data in a custom format.

[0206] The lookup table is used to establish a fast mapping between symbol names and symbol segment offsets, and can be implemented using hash tables or B-trees. The symbol segment can store metadata such as the identifier, address, and type index of each symbol sequentially. The type segment can centrally store all unique type definitions, such as size, number of members, and member indexes. The index segment can store member index information for composite types, supporting efficient nested queries.

[0207] Fourth, encryption processing, which involves applying encryption algorithms to protect the security of symbolic data. Users can choose symmetric encryption (such as AES-256) or asymmetric encryption (such as RSA) algorithms based on their security requirements. The encryption key is pre-configured by the CNC system developer and stored internally. A checksum is appended to the encrypted symbolic data to prevent tampering. Specifically, this can be achieved by applying a pre-configured encryption algorithm to encrypt the symbolic data, using a PE file editing interface to add a custom data segment named "inodbg" to the DLL, writing the encrypted symbolic data into this segment, and finally outputting a modified DLL file containing the embedded encrypted symbolic data.

[0208] Fifth, file modification, which involves writing the encrypted symbol data into the dynamic library file. Specifically, this can be done by using the PE file editing interface to add a custom data segment named "inodbg" to the DLL, writing the encrypted symbol data into this segment, updating the segment table in the PE file header, and ensuring that the operating system loads this segment synchronously.

[0209] Sixth, output verification, which involves verifying the integrity of the modified file. Specifically, this could involve outputting the modified dynamic library file.

[0210] Understandably, symbol generation tools can tightly bind symbol information with executable modules, avoiding the security risks caused by the separate release of unencrypted symbol files. At the same time, the generated symbol data uses an optimized data structure, making the query efficiency much higher than directly reading symbol files.

[0211] S702, determine the module index identifier of the secondary development module under the current loading count based on the number of loadings.

[0212] S703 extracts encrypted symbol data of secondary development modules from dynamic library files.

[0213] S704 uses a preset decryption algorithm to decrypt the encrypted symbol data to obtain the symbol data of the secondary development module.

[0214] S705 binds the module index identifier with symbol data and loads it into the process memory of the secondary development module at the current loading count.

[0215] For example, the system can locate a custom data segment in a dynamic library file, read the encrypted symbol data in that segment, and apply the corresponding decryption algorithm to restore the original symbol data and parse the symbol data back into a structured symbol table object.

[0216] Then, an index mapping is assigned to the newly loaded module. Assuming the module name of the secondary development module is UserModule, the index name is dll_UserModule. Assuming that the index names of the same name have been loaded before, dll_UserModule, dll_UserModule[1], dll_UserModule[2], the newly loaded module will get the index name dll_UserModule[3]. Assuming that the index number corresponding to dll_UserModule[3] is 3, a mapping relationship is established: `modulesymbolmap[3] = symbolsofUserModule`, that is, the index name dll_UserModule[3] is associated with the symbol table of UserModule and loaded into the internal storage area of ​​the system, while recording the module base address, symbol table pointer and other key information of the module.

[0217] S706: Once the secondary development module is loaded, extract all variable objects from the symbol data in the secondary development module.

[0218] S707 identifies each variable object based on the module index identifier, and obtains the variable identifier of each variable object under the current load count.

[0219] S708, retrieve the variable list of the current data acquisition interface.

[0220] S709: Based on the variable identifiers, add each variable object to the variable list to obtain the updated data acquisition interface.

[0221] For example, the data acquisition module built into the CNC system listens for module loading events. When it captures a notification of a new module loading, it extracts information of all variable objects from the module symbol table, classifies these variables according to their module index names, such as dll_UserModule.varA, dll_UserModule[1].varB, etc., and updates the variable list tree of the data acquisition interface according to the variable identifier of the classified variable objects, so that the user can see all the collectable variables of the newly added module.

[0222] S710, in response to a data acquisition operation for a target variable in the data acquisition interface, determines the target variable identifier of the target variable.

[0223] S711, perform identifier parsing on the target variable identifier to obtain the target module index identifier of the target module to which the target variable belongs under the corresponding number of loads, and the target variable index identifier of the target variable.

[0224] S712, based on the target module index identifier, retrieves the target symbol data of the target module from the process memory of the target module at the corresponding load count.

[0225] S713, find variable symbol data that matches the target variable identifier from the target symbol data.

[0226] S714 locates the storage address of the target variable based on the variable symbol data and collects the variable data of the target variable from the storage address.

[0227] For example, suppose a secondary development module UserModule.dll defines global variables X and Y. In practical applications, users might load two independent instances of this module to support different parallel processing tasks.

[0228] First load: HMODULE hModule1 = SymLoadLibrary("UserModule.dll"), the system assigns index number 0 to the first instance, the index name is dll_UserModule, and the symbol table is stored in modulesymbolmap[0].

[0229] Second loading: HMODULE hModule2 = SymLoadLibrary("UserModule.dll"), the system assigns index number 1 to the second instance, the index name is dll_UserModule[1], and the symbol table is stored in modulesymbolmap[1].

[0230] Although both modules come from the same DLL file, they each have their own independent memory space and independent global variable instances after being loaded at runtime.

[0231] When collecting variable data, if it is necessary to collect variable X in the first instance, the full name of which is dll_UserModule.X, the symbol table of modulesymbolmap[0] is located by index number 0 corresponding to the index name dll_UserModule. The symbol information of X is searched to obtain its relative offset in the memory space of instance 1. The absolute address is obtained by adding the module base address of instance 1, and the collection is completed.

[0232] If it is necessary to collect the variable X in the second instance, the full name of which is dll_UserModule[1].X, the symbol table of modulesymbolmap[1] is located by index number 1 corresponding to the index name dll_UserModule[1]. The same process is followed to finally obtain the absolute address of X in instance 2 and complete the collection.

[0233] Although the variable names are the same, they are clearly distinguished by different index numbers, thus avoiding conflicts and confusion.

[0234] The above module loading method offers the following advantages for developers of secondary development modules:

[0235] First, zero interface development cost: Secondary development users do not need to design, implement, or maintain any special data export interfaces. Modules can be developed according to standard C / C++ programming specifications, compiled, and processed by tools, so that the CNC system can automatically discover and collect its internal global variables.

[0236] Second, it improves development efficiency: it reduces the cost of learning and following development standards, shortens the development cycle, and accelerates the iteration and application speed of modules.

[0237] Third, flexible data visibility: users can decide at runtime which variables need to be collected and monitored, without being restricted by predefined parameters at compile time.

[0238] For CNC system developers, there are the following advantages:

[0239] First, modular architecture support: It improves the scalable architecture of the CNC system, enabling the system to flexibly integrate secondary development modules from different developers, thus enriching the system's functional ecosystem.

[0240] Second, multi-module parallel management: By introducing an indexing mechanism, the system can efficiently manage dozens or even hundreds of secondary development modules, while supporting multiple instances of the same module, thus improving the system's adaptability to industrial applications.

[0241] Third, runtime observability: It improves the observability of the CNC system for its own state and the state of the loaded modules, which facilitates high-end applications such as fault diagnosis, performance analysis, and data traceability.

[0242] Fourth, backward compatibility: This technology is compatible with existing modular data acquisition solutions and will not disrupt existing data acquisition functions.

[0243] For industrial equipment such as CNC machine tools, the following advantages exist:

[0244] First, enhanced fault diagnosis capabilities: By collecting internal variables from secondary development modules, the causes of faults can be diagnosed more finely, shortening troubleshooting time and reducing downtime costs.

[0245] Second, process optimization support: The collected multi-source data can be used for high-level applications such as process parameter optimization and production efficiency analysis to improve product quality and production efficiency.

[0246] Third, industrial upgrading support: Supporting new business models such as the Industrial Internet and Industry 4.0, enabling equipment to generate and aggregate richer data assets.

[0247] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0248] Based on the same inventive concept, this application also provides a module loading apparatus for implementing the module loading method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more module loading apparatus embodiments provided below can be found in the limitations of the module loading method described above, and will not be repeated here.

[0249] In one embodiment, such as Figure 8 As shown, a module loading device 800 is provided, including: an instruction response module 801, an index identifier determination module 802, a symbol data extraction module 803, and a data storage module 804, wherein:

[0250] The instruction response module 801 is used to obtain the number of times the secondary development module has been loaded and the dynamic library files.

[0251] The index identifier determination module 802 is used to determine the module index identifier of the secondary development module under the current loading count based on the number of times it has been loaded.

[0252] The symbol data extraction module 803 is used to extract symbol data of secondary development modules from dynamic library files.

[0253] The data storage module 804 is used to bind the module index identifier with symbol data and load it into the process memory of the secondary development module at the current loading count.

[0254] In one embodiment, the index identifier determination module 802 is used to: obtain the module identifier of the secondary development module; determine the module identifier as the module index identifier of the secondary development module under the current loading count when the number of loading counts is zero; determine the instance index identifier of the secondary development module based on the number of loading counts when the number of loading counts is not zero; and combine the module identifier and the instance index identifier to obtain the module index identifier of the secondary development module under the current loading counts.

[0255] In one embodiment, the module loading device 800 may further include:

[0256] The file acquisition module is used to obtain the original dynamic library files and symbol files of the secondary development module in response to the symbol generation command for the secondary development module.

[0257] The tool calling module is used to perform structured processing on symbol files by calling the symbol generation tool and write them into the original dynamic library file to obtain the dynamic library file of the secondary development module.

[0258] In one embodiment, the tool calling module is used to: extract the original symbol information of the secondary development module from the symbol file; perform structured processing on the original symbol information according to a preset symbol data structure to obtain the symbol data of the secondary development module; encrypt the symbol data using a preset encryption algorithm to obtain encrypted symbol data; and write the encrypted symbol data into the original dynamic library file to obtain the dynamic library file of the secondary development module.

[0259] In one embodiment, the symbol data extraction module 803 is used to: extract encrypted symbol data of the secondary development module from the dynamic library file; and decrypt the encrypted symbol data using a preset decryption algorithm to obtain the symbol data of the secondary development module.

[0260] In one embodiment, the module loading device 800 may further include:

[0261] The variable extraction module is used to extract all variable objects from the symbol data of the secondary development module after the secondary development module has been loaded.

[0262] The variable identification module is used to identify each variable object based on the module index identifier, and obtain the variable identifier of each variable object under the current load count; the variable identifier includes the module index identifier and the variable index identifier of the corresponding variable object.

[0263] The variable list retrieval module is used to retrieve the variable list of the current data acquisition interface.

[0264] The variable addition module is used to add variable objects to the variable list based on the variable identifier, resulting in an updated data acquisition interface.

[0265] In one embodiment, the module loading device 800 may further include:

[0266] The data acquisition operation response module is used to respond to data acquisition operations on the target variable in the data acquisition interface and to determine the target variable identifier.

[0267] The identifier resolution module is used to resolve the identifiers of target variables, obtain the target module index identifier of the target module to which the target variable belongs under the corresponding number of loads, and the target variable index identifier of the target variable.

[0268] The data acquisition module is used to obtain the target symbol data of the target module from the process memory of the target module at the corresponding number of loads, based on the target module index identifier.

[0269] The data matching module is used to find variable symbol data that matches the target variable identifier from the target symbol data.

[0270] The address location module is used to locate the storage address of the target variable based on the variable symbol data, and to collect the variable data of the target variable from the storage address.

[0271] Each module in the aforementioned module loading device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0272] In one embodiment, a computer device is provided, which may be a server integrated with loading software, and its internal structure diagram may be as follows: Figure 9As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data related to the module loading method. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements a module loading method.

[0273] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0274] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the specific steps of the above-described module loading method embodiment.

[0275] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the specific steps of the above-described module loading method embodiment.

[0276] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the specific steps of the above-described module loading method embodiment.

[0277] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the acquisition, storage, processing, and transmission of the data all comply with relevant laws and regulations.

[0278] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0279] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0280] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A module loading method, characterized in that, The method includes: Get the number of times the secondary development module has been loaded and the dynamic library files; Based on the number of times the module has been loaded, determine the module index identifier of the secondary development module at the current number of loads; Extract the symbol data of the secondary development module from the dynamic library file; The module index identifier is bound to the symbol data and loaded into the process memory of the secondary development module at the current loading count.

2. The method according to claim 1, characterized in that, The step of determining the module index identifier of the secondary development module at the current loading count based on the number of loadings includes: Obtain the module identifier of the secondary development module; When the number of loaded times is zero, the module identifier is determined as the module index identifier of the secondary development module under the current number of loaded times; If the number of times the module has been loaded is not zero, the instance index identifier of the secondary development module is determined based on the number of times the module has been loaded. By combining the module identifier and the instance index identifier, the module index identifier of the secondary development module under the current loading count is obtained.

3. The method according to claim 1, characterized in that, The method further includes: In response to the symbol generation instruction for the secondary development module, the original dynamic library file and symbol file of the secondary development module are obtained; The symbol file is structured by calling a symbol generation tool and written into the original dynamic library file to obtain the dynamic library file of the secondary development module.

4. The method according to claim 3, characterized in that, The step of structuring the symbol file and writing it into the original dynamic library file to obtain the dynamic library file of the secondary development module includes: Extract the original symbol information of the secondary development module from the symbol file; The original symbol information is structured according to a preset symbol data structure to obtain the symbol data of the secondary development module; The symbol data is encrypted using a preset encryption algorithm to obtain encrypted symbol data. The encrypted symbol data is written into the original dynamic library file to obtain the dynamic library file of the secondary development module.

5. The method according to claim 4, characterized in that, The step of extracting symbol data for the secondary development module from the dynamic library file includes: Extract the encrypted symbol data of the secondary development module from the dynamic library file; The encrypted symbol data is decrypted using a preset decryption algorithm to obtain the symbol data of the secondary development module.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Once the secondary development module is loaded, extract all variable objects from the symbol data. Each variable object is identified based on the module index identifier to obtain the variable identifier of each variable object at the current load count; the variable identifier includes the module index identifier and the variable index identifier of the corresponding variable object; Get the list of variables in the current data acquisition interface; Based on the variable identifiers, the variable objects are added to the variable list to obtain the updated data acquisition interface.

7. The method according to claim 6, characterized in that, The method further includes: In response to a data acquisition operation on a target variable in the data acquisition interface, the target variable identifier of the target variable is determined; The target variable identifier is parsed to obtain the target module index identifier of the target module to which the target variable belongs under the corresponding number of loads, and the target variable index identifier of the target variable; Based on the target module index identifier, obtain the target symbol data of the target module from the process memory of the target module at the corresponding loading count; Search for variable symbol data that matches the target variable identifier from the target symbol data; The storage address of the target variable is located based on the variable symbol data, and the variable data of the target variable is collected from the storage address.

8. A module loading device, characterized in that, The device includes: The instruction response module is used to obtain the number of times the secondary development module has been loaded and the dynamic library files; The index identifier determination module is used to determine the module index identifier of the secondary development module at the current loading count based on the number of loadings. A symbol data extraction module is used to extract symbol data of the secondary development module from the dynamic library file; The data storage module is used to bind the module index identifier with the symbol data and load it into the process memory of the secondary development module at the current loading count.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images