Automatic extension function calling method, medium and equipment

Abstract

The invention relates to an automatic extension function calling method, a medium and equipment, and the method comprises the steps: generating a calling request module and a function calling module according to an original header file, deploying the calling request module to a request calling party, and deploying the function calling module to an actual implementation party. And constructing a shared memory between the call request module and the function call module, acquiring a call request of a user by a request caller, writing the call request into the shared memory, releasing a request semaphore to inform an actual implementation party, reading the call request in the shared memory by the actual implementation party according to the request semaphore, and sending the call request to the function call module. The input parameters are input into the corresponding local extension function according to the calling request, an execution result is obtained and written back to the shared memory, the request calling party reads the execution result in the shared memory, and extension library calling is completed. While the development convenience of the dynamic link library is maintained, the unstable factors of the external dynamic link library are effectively isolated, and the overall safety and stability of the automatic test software when calling the expansion function are improved.

Description

Technical Field

[0001] This invention relates to the field of software testing, and in particular to an automated method, medium, and device for extending function calls. Background Technology

[0002] With the widespread application of embedded systems, their software size and complexity are increasing daily, making automated testing a key means to ensure the quality of embedded software. Currently, automated testing of embedded systems mainly simulates various test scenarios by running test scripts (such as C++) and enriches test behaviors by extending dynamic link libraries (.dll files) to achieve comprehensive coverage of different hardware platforms and functional modules.

[0003] In the field of software extension plugin technology, there are three main common implementation methods: dynamic link library (DLL) method, scripting language method, and inter-process communication (IPC) method. For example... Figure 1 As shown, dynamic link libraries (DLLs) are the most widely adopted technology due to their high calling efficiency and low performance overhead. However, this method has significant security vulnerabilities: since the DLL shares the same memory space as the calling party, if the external DLL crashes or malfunctions, the entire automated testing process will crash, severely affecting the continuity and stability of the testing task. Furthermore, the loading and unloading of DLLs may introduce memory leaks and resource conflicts, further reducing system reliability.

[0004] While scripting languages ​​(such as JavaScript and Python) offer good flexibility and security, they require an additional script execution engine, increasing system resource overhead. Furthermore, they necessitate handling data type conversions and interactions between different languages, resulting in higher development costs. Inter-process communication (IPC), by encapsulating dynamic link libraries as independent processes and utilizing message pipes, network sockets, HTTP / RPC, etc., effectively isolates the instability of dynamic link libraries and improves system security. However, its development and deployment are relatively complex and require higher technical skills from developers.

[0005] Current embedded automated testing software commonly uses direct calls to dynamic link libraries, lacking effective security isolation mechanisms. Testers need to manually handle the process encapsulation of dynamic link libraries, which is not only inefficient but also prone to introducing human error and makes it difficult to guarantee consistent encapsulation quality. This current technological situation leads to a high risk of crashes in automated testing systems during long-term operation, and the reliability and repeatability of test results cannot be fully guaranteed.

[0006] Therefore, there is an urgent need for a technical solution that can automatically convert dynamic link libraries into process call methods, so as to maintain the convenience of dynamic link library development, effectively isolate the unstable factors of external dynamic link libraries, and improve the overall security and stability of automated testing software when calling extension functions. Summary of the Invention

[0007] To address the aforementioned technical issues and provide a technical solution for automatically converting dynamic link libraries into process-invoking methods, this application offers an automated extension function call method, medium, and device that can effectively isolate external dynamic link library instability while maintaining the convenience of dynamic link library development.

[0008] Firstly, this application provides an automated method for extending function calls, including: Obtain function declaration information from the original header file to generate separate binary components, including a call request module and a function call module; Deploy the call request module to the caller, deploy the function call module to the implementation, and build a shared memory and semaphore communication mechanism between the call request module and the function call module. The requesting party obtains the user's call request and writes it to shared memory, and releases the request semaphore to notify the actual implementation party according to the semaphore communication mechanism; the call request includes the extended function name and input parameters; The actual implementation reads the call request from the shared memory based on the request semaphore, inputs the input parameters into the corresponding local extended function according to the call request, obtains the execution result and writes it back to the shared memory, and releases the response semaphore to notify the requesting caller according to the semaphore communication mechanism; The requesting caller reads the execution result from shared memory based on the response semaphore and completes the extended function call.

[0009] Further steps for obtaining function declaration information from the original header file include: Parse the original header file and generate an abstract syntax tree; Traverse the abstract syntax tree to extract function declaration information, which includes the function name, return type, parameter list, parameter direction markers, and parameter constraint metadata.

[0010] Furthermore, parameter direction markers include input parameter markers, output parameter markers, or input / output parameter markers; parameter constraint metadata includes maximum string length, buffer size dependency, or non-null pointer constraint.

[0011] Furthermore, the steps for generating the call request module include: Based on the parameter list and parameter direction markings, the input parameters and output parameters are classified and obtained. Generate request serialization code based on the function name and input parameters; Generate response deserialization code based on the return value type and output parameters; Based on the predefined shared memory access logic, semaphore operation logic, and heartbeat status detection logic, the request serialization code and response deserialization code are compiled to generate the call request module.

[0012] Further steps in generating the function call module include: Generate dynamic symbol registry build code, which is used to load the original dynamic link library at runtime and establish a mapping from function names to function addresses; Generate request parsing code to deserialize the extended function name and input parameters from shared memory; Generate parameter validation code to perform semantic validation on input parameters based on parameter direction markers and parameter constraint metadata; Generate function routes and execution code, used to query function addresses based on extension function names and call the corresponding local extension functions; Generate response encapsulation code to serialize the execution result or error code and write it to shared memory; Based on the predefined semaphore notification logic and heartbeat update logic, compile the dynamic symbol registry construction code, request parsing code, parameter validation code, function routing and execution code, and response encapsulation code to generate the function call module.

[0013] Furthermore, shared memory, including main shared memory and heartbeat shared memory; the steps for constructing a shared memory and semaphore communication mechanism between the call request module and the function call module include: Create a main shared memory to store call requests and execution results; Create a heartbeat shared memory to store the process identifier, startup timestamp, and last active time of the actual implementer; Create request and response semaphores to achieve inter-process synchronization between the requesting party and the actual implementer.

[0014] Furthermore, before the requesting caller obtains the user's call request and writes it to shared memory, it also includes: Read the process identifier, startup timestamp, and last active time from the heartbeat shared memory; Determine if the difference between the current time and the last active time exceeds the preset timeout threshold, if the process identifier is invalid, and if the startup timestamp is earlier than the last startup record. If all conditions are met, start the process of the function call module and wait for it to complete initialization before performing the write operation.

[0015] Furthermore, the actual implementation involves reading the call request from shared memory based on the request semaphore, inputting the input parameters into the corresponding local extended function according to the call request, obtaining the execution result and writing it back to shared memory, and releasing the response semaphore to notify the requesting caller according to the semaphore communication mechanism. This process includes: Read the call request from shared memory to obtain the extended function name and input parameters, and obtain the actual function address corresponding to the extended function name based on the function calling module; The input parameters are semantically validated based on the parameter constraint metadata and parameter direction markers. The semantic validation includes: if the parameter has a maximum string length constraint, then verify that its actual length does not exceed the maximum length; if the parameter has a buffer size dependency, then verify that the size of the target buffer is not less than the value of the dependent parameter; if the parameter has a non-null pointer constraint, then verify that it is not zero. Determine whether the semantic validation passes. If it does, input the input parameters into the corresponding local extended function based on the actual function address to obtain the execution result; otherwise, generate an error code as the execution result. The execution result is written to shared memory, and the response semaphore is released according to the semaphore communication mechanism.

[0016] Secondly, this application also provides a computer storage medium storing executable program code; the executable program code is used to execute the automated extended function call method described in any one of the first aspects.

[0017] Thirdly, this application also provides a terminal device, including a memory and a processor; the memory stores program code executable by the processor; the program code is used to execute the automated extended function call method described in any one of the first aspects.

[0018] This invention provides an automated method, medium, and device for extending function calls. It obtains function declaration information from the original header file to generate separate binary components, including a call request module and a function call module. The call request module is deployed to the requesting caller, and the function call module is deployed to the actual implementation. A shared memory and semaphore communication mechanism is established between the call request module and the function call module. The requesting caller obtains the user's call request and writes it to shared memory, then releases a request semaphore to notify the actual implementation based on the semaphore communication mechanism. The call request includes the extended function name and input parameters. The actual implementation reads the call request from shared memory based on the request semaphore, inputs the input parameters into the corresponding local extended function according to the call request, obtains the execution result, writes it back to shared memory, and releases a response semaphore to notify the requesting caller based on the semaphore communication mechanism. The requesting caller reads the execution result from shared memory based on the response semaphore, completing the extended function call. This achieves effective isolation of unstable factors from external dynamic link libraries while maintaining the ease of development of dynamic link libraries, improving the overall security and stability of automated testing software when calling extended functions. Attached Figure Description

[0019] Figure 1 A flowchart illustrating the calling method of extended functions in existing dynamic link libraries; Figure 2 This is a flowchart of the automated extended function call method according to an embodiment of the present invention; Figure 3 This is another flowchart of the automated extended function call method according to an embodiment of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0021] It should be noted that if the embodiments of the present invention involve directional indications, such as up, down, left, right, front, back, etc., these directional indications are only used to explain the relative positional relationships and movement of the components in a specific posture. If the specific posture changes, the directional indications will also change accordingly. Furthermore, if the embodiments of the present invention involve descriptions such as "first," "second," "S1," "S2," "step one," "step two," etc., these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance, or implicitly indicating the number of technical features indicated or the execution order of the method. Those skilled in the art will understand that anything that does not violate the inventive concept should be included within the scope of protection of the present invention.

[0022] like Figure 2 , Figure 3 As shown, the present invention provides an automated extended function call method, including: S1: Obtain function declaration information from the original header file to generate separate binary components, including the call request module and the function call module; Specifically, a priori parsing tool can be used to extract function declaration information from the original header file of the dynamic link library where the extension function is located. Based on the function declaration information, a separate binary component (i.e., an independent executable file or library) can be generated, including a call request module and a function call module. This allows for distributed deployment of the call request module and the function call module, thereby achieving data isolation between the caller and the actual implementer in subsequent steps.

[0023] Preferably, the original header file can be parsed using a priori parsing tool (such as the Clang library tool) to generate a separate binary component. This eliminates the need to manually write inter-process communication code, adapt message formats, or adjust the dynamic link library source code. Only the .dll and .h files of the dynamic link library need to be provided, allowing the toolchain to automatically complete the parsing, code generation, and compilation. This improves adaptation efficiency by tens of times and is especially suitable for the need to frequently change / integrate dynamic link libraries in testing scenarios.

[0024] Preferably, the step of obtaining function declaration information from the original header file may include: S11: Parse the original header file and generate an abstract syntax tree; Specifically, a priori parsing tool (such as the Clang library tools) can be used to parse the original header file of the dynamic link library containing the extension function, generating an abstract syntax tree. This allows for the complete expansion of each custom macro (such as ARG_IN, ARG_OUT, ARG_IN_OUT, etc.) to restore the true decorative intent of the parameters, avoiding ambiguity in text-level regular expression parsing, and accurately handling macro definitions. Simultaneously, different types of syntax are automatically processed to obtain a clean, standardized syntax structure, eliminating preprocessor interference. By converting human-readable header files into machine-parseable contract data, a unique input source is provided for subsequent code generation, ensuring that the requesting caller and the actual implementation code are based on the same protocol specification. Automated parsing avoids human analysis errors, accurately captures function signatures and parameter semantics, and supports accurate identification of complex types (pointers, strings, structures), laying the foundation for code generation. Furthermore, parsing header files unifies compiler differences across different platforms (such as Windows, Linux, macOS, etc.), ensuring consistent parsing behavior and cross-platform compatibility.

[0025] S12: Traverse the abstract syntax tree and extract function declaration information; function declaration information includes function name, return type, parameter list, parameter direction markers, and parameter constraint metadata; Specifically, the abstract syntax tree can be traversed to extract function declaration information such as function name, return type, parameter list, parameter direction markers, and parameter constraint metadata. The function name can be used to call the corresponding extended function in subsequent steps; the return type can be used to receive the function return value to determine whether the call was successful; the parameter list and parameter direction markers can confirm the input and output directions of each parameter; and the parameter constraint metadata can be used to perform semantic validation on the parameters. Preferably, the parameter direction markers include input parameter markers, output parameter markers, or input-output parameter markers; and the parameter constraint metadata includes maximum string length, buffer size dependency, or non-null pointer constraints.

[0026] For example, since the header files of dynamic link libraries export C language functions (if compiled with C++, they are exported using the extern "C" flag), the function parameters are represented by the three macros ARG_IN, ARG_OUT, and ARG_IN_OUT, indicating whether the function parameter is an input parameter, an output parameter, or an input / output parameter, respectively. Therefore, the Clang library tool can be used to analyze the header file. For example, the header file "bool FuncA(ARG_IN int id, ARG_IN const char* name, ARG_IN_OUT char* retData, ARG_IN_OUT int* retDataSize, ARG_OUT int* Taking `retID` as an example: Calling the `clang_getCursorSpelling` method yields the function name `FuncA`, and calling the `clang_getCursorResultType` method yields the function's return value (optionally boolean). Using the `clang_visitChildren` function to iterate through the functions and combining it with the `clang_getCursorKind` function, the parameter list and parameter direction markers can be analyzed. These include int type, `id` input parameter, `name` string input parameter, `retData` string output parameter, int pointer, `retDataSize` input / output parameter, and int pointer output parameter `retID`, thus obtaining function declaration information such as the function name, function return value, parameter list, and parameter direction markers.

[0027] S13: Generate separate binary components based on function declaration information, including a call request module and a function call module.

[0028] Specifically, separate binary components such as a call request module and a function call module can be generated based on function declaration information such as function name, return value type, parameter list, parameter direction marker, and parameter constraint metadata. This distributed deployment, where the call request module is deployed to the caller and the function call module is deployed to the implementation, achieves data isolation between the caller and the implementation, preventing the implementation process from crashing and affecting the stability of the caller process.

[0029] Preferably, the step of generating the call request module includes: S131: Based on the parameter list and parameter direction markings, classify and obtain the input parameters and output parameters; S132: Generate request serialization code based on the function name and input parameters; Specifically, based on the parameter list and parameter direction markers obtained in step S12, input parameters and output parameters can be categorized to generate request serialization code based on the function name and input parameters. This allows the request module to perform data filling operations (including filling the function name length, function name string, and sequentially filling input parameter data) to obtain a data packet containing complete request information. This serializes the user call request into a binary byte stream, and then sends the data packet to shared memory through a semaphore communication mechanism, thereby achieving data isolation between the request caller and the actual implementation when calling the extended library function.

[0030] S133: Generate response deserialization code based on the return value type and output parameters; Specifically, the response deserialization code can be generated based on the return value type and output parameters, enabling the calling request module to parse the data obtained through the semaphore communication mechanism and obtain the restored C++ data type. This data is then used to deserialize the binary byte stream returned by the actual implementation into specific program data, thus completing the return of the execution result of the remote call.

[0031] S134: Based on the predefined shared memory access logic, semaphore operation logic, and heartbeat status detection logic, compile the request serialization code and response deserialization code to generate the call request module.

[0032] Specifically, the request serialization code and response deserialization code can be compiled according to predefined shared memory access logic, semaphore operation logic, and heartbeat status detection logic to generate a call request module. This allows subsequent steps to deploy the call request module to the requesting party, completing distributed deployment.

[0033] More specifically, the shared memory access logic is a high-speed inter-process data channel access method based on a memory mapping mechanism, used to directly read and write the physical memory region shared by the two processes, which can be represented as follows: Connection establishment: Obtain an operable virtual address pointer by mapping the shared memory name to the created memory region; Data writing: Serialize the extended function name hash value and input parameters according to the set protocol format and write them to the request buffer in memory; Result reading: After waiting for semaphore notification, retrieve the return value and output parameters from the response buffer; State Reset: After completing the data exchange, clear the buffer markers to prepare for the next call.

[0034] Shared memory access logic can avoid the data copying overhead in traditional pipe or network communication, enabling zero-copy transmission of large data volumes (such as images and file blocks); by isolating the address spaces of the two calling parties through independent memory regions, it prevents implementation failures from directly affecting the memory security of the calling party.

[0035] The semaphore operation logic is an inter-process synchronization and cooperation mechanism based on kernel semaphore primitives, used to control the execution sequence of the requesting caller and the actual implementer, and can be represented as follows: Request notification: After writing the call request to shared memory, a release operation (Post / V operation) is performed to notify the request semaphore and wake up the implementing process; Blocking wait: Immediately execute the wait operation (Wait / P operation) on the response semaphore, suspend its own thread until the implementation party completes processing; Timeout protection: Set a maximum waiting time limit. If no response is received within the time limit, a communication failure is determined to avoid permanent blockage.

[0036] Semaphore operation logic can ensure the correctness of the "write data first, then notify to read" timing, preventing the implementer from reading incomplete data; it can enable the caller to release CPU resources and enter a sleep state during the waiting period, improving the overall energy efficiency of the system; and it can quickly detect implementation abnormalities through a timeout mechanism, supporting failover decisions.

[0037] The heartbeat status detection logic allows the caller to periodically check the status metadata in the heartbeat shared memory to determine whether the actual implementation process is alive and healthy. This mechanism can be represented as follows: Periodic inspection: Read the last active timestamp and process identifier in the heartbeat region at fixed intervals (such as every second or before each call); Activity determination: Compare whether the difference between the current time and the timestamp exceeds the threshold, and verify whether the process identifier still exists in the system; Fault handling: If the implementation is determined to be dead or crashed, a restart process is triggered to create a new implementation process instance and wait for it to complete initialization.

[0038] The heartbeat status detection logic can prevent the caller from sending requests to processes that have lost their responsiveness, thus avoiding prolonged business suspension; it enables fault self-healing through automatic restart, ensuring continuous service availability; and it identifies process restart events by comparing startup timestamps, promptly resetting the session context to avoid state confusion.

[0039] For example, optionally, based on predefined shared memory access logic, semaphore operation logic, and heartbeat status detection logic, the request serialization code and response deserialization code are compiled to generate the plugin library makefile, plugin library header file (i.e., the original header file of the extension library dynamic link library), and semaphore request communication code (mainly the system function calls CreateFileMappingA, MapViewOfFile, and CreateSemaphoreA). Then, the Mingw compiler mingw32-make.exe is called to compile the plugin library ClientLib.dll dynamic link library, which is the request module.

[0040] For example, the partial implementation code of the request module can be optionally represented as follows: / / Populate requestData char requestData

[1024] {0}; int pos = 0; / / Fill function method name int funcNameSize = strlen("FuncA"); memcpy(requestData + pos,&funcNameSize, sizeof(int)); pos += sizeof(int); memcpy(requestData + pos, "FuncA", funcNameSize); pos += funcNameSize; / / Fill in the input parameters sequentially memcpy(requestData + pos,&id, sizeof(int)); pos += sizeof(int); intnameSize = (0 == name)? 0 : strlen(name); memcpy(requestData + pos,&nameSize, sizeof(int)); pos += sizeof(int); memcpy(requestData + pos, name, funcNameSize); pos += nameSize; / / The binary data received after requesting data using requestData (semaphore communication mechanism) char* responseData; int responseDataSize; / / The size of the returned data. / / Parse the return value int responsePos=0; bool ret = *(bool*)(responseData + responsePos); responsePos += sizeof(bool); / / Parse the string and return the string value. The string return value includes an input buffer and the buffer size. Fill the buffer with data and return the size of the filled data. int getDataSize = *(int*)(responseData + responsePos); responsePos += sizeof(int); if(retData&&retDataSize) { int minSize = (getDataSize>*retDataSize) ? (*retDataSize) :getDataSize; *retDataSize = minSize; memcpy(retData, responseData + responsePos, minSize); } responsePos += getDataSize; / / Fill the int return value if(retID) memcpy(retID, responseData + responsePos, sizeof(int)); responsePos += sizeof(int); return ret; Preferably, the steps for generating a function call module include: S131': Generate dynamic symbol registry build code, which is used to load the original dynamic link library at runtime and establish a mapping from function names to function addresses; Specifically, optional code for generating a dynamic symbol registry can be generated based on any existing technology. This code is used during the module loading phase (runtime initialization) to automatically open the specified original dynamic link library file (such as a business logic library), traverse its exported symbol table, convert the function names declared in the header file into actual entry addresses in memory, and establish a function name-address mapping dictionary (symbol registry). This allows subsequent calls to be made by quickly looking up the function name to obtain the executable function pointer, avoiding repeated searches of the dynamic link library.

[0041] S132': Generate request parsing code to deserialize the extended function name and input parameters from shared memory; Specifically, request parsing code can be generated using any existing technology to read the serialized user call request from a specific area of ​​shared memory and perform structured decoding according to a preset protocol format (optionally header + payload). Preferably, the request parsing code can be used to identify the target function name (or function ID), parse the type and length of the input parameters, and determine which data needs to be read based on the parameter direction marker (input / output / bidirectional).

[0042] S133': Generate parameter validation code, used to perform semantic validation of input parameters based on parameter constraint metadata and parameter direction markers; Specifically, parameter validation code can be generated using any existing technology to perform mandatory semantic review of input parameters before the formal execution of the business function, based on parameter constraint metadata (such as maximum string length, buffer size dependencies, and non-null pointer requirements). For example: checking if the length of the input string exceeds the upper limit declared in the metadata; verifying if the size of the pointer-type output buffer meets the requirements specified by the input parameters; and confirming that critical pointers are not null. If validation fails, an error code is returned directly, blocking subsequent execution.

[0043] S134': Generates function routing and execution code, used to query the function address based on the extended function name and call the corresponding local extended function; Specifically, function routing and execution code can be generated using any existing technology. After parameter validation, the code queries the symbol registry based on the parsed function name to obtain the corresponding local function address (function pointer) and then calls it.

[0044] S135': Generate response encapsulation code, used to serialize the execution result or error code and write it to shared memory; Specifically, response encapsulation code can be generated using any existing technology. After the local function execution is complete, the return value, output parameters (identified by direction markers), and execution status (success / error code) are serialized into a byte stream and written to the response area in shared memory, following the reverse process of request parsing, thus completing the request-response closed loop. Preferably, for large data outputs, a binary format of "length + data" can be used; for error scenarios, a standardized error structure containing the error type and a brief description is used.

[0045] S136': Based on the predefined semaphore notification logic and heartbeat update logic, compile the dynamic symbol registry construction code, request parsing code, parameter validation code, function routing and execution code, and response encapsulation code to generate the function call module.

[0046] Specifically, the system can optionally compile dynamic symbol registry construction code, request parsing code, parameter validation code, function routing and execution code, and response encapsulation code based on predefined semaphore notification logic and heartbeat update logic to obtain a function call module. This allows subsequent steps to deploy the function call module to the actual implementation, completing distributed deployment. The predefined semaphore notification logic and heartbeat update logic can be arbitrarily set by those skilled in the art.

[0047] Preferably, the semaphore notification logic is an inter-process synchronization mechanism based on operating system kernel semaphores, which can be represented as follows: Request phase: When the function calling module has completed initialization and is ready to receive requests, it blocks on the "request semaphore" and waits; when the caller writes data to shared memory, it releases the semaphore and wakes up the implementation process to start processing.

[0048] Response phase: After the implementer finishes processing and writes the result to shared memory, it releases the "response semaphore" to notify the caller that the data is ready and the result can be read.

[0049] Mutual exclusion protection: When accessing the critical section of shared memory, a mutex lock is implemented using a semaphore to prevent data races caused by concurrent calls.

[0050] Semaphore notification logic can ensure that both parties will not read or write to the same memory area simultaneously (mutual exclusion), and there will be no race conditions where one party reads empty data or writes overwritten data.

[0051] The heartbeat update logic is a keep-alive mechanism used to monitor process activity, and can be represented as follows: Periodic writes: The function calling module writes the current timestamp to a specific field in a dedicated "heartbeat shared memory" in a background thread or after each request is processed.

[0052] Status identifier: Simultaneously records its own process ID (PID) and startup timestamp, enabling the monitoring party (the requesting party or the independent watchdog process) to distinguish between "process restart" and "process zombie".

[0053] Fault detection: The caller periodically reads the timestamp. If it finds that the time difference exceeds the threshold (e.g., 5 seconds) or the PID is invalid, it is determined that the implementer has lost its response.

[0054] In a cross-process architecture, the implementation may become unresponsive due to business logic flaws (such as infinite loops or deadlocks) or resource exhaustion, but the process ID still exists. Heartbeat update logic can promptly detect such "alive but unresponsive" failure states, triggering automatic restarts or alarms to ensure overall system high availability. Simultaneously, comparing startup timestamps can identify whether a process has undergone a restart, allowing the caller to reset the session state or resynchronize the context.

[0055] For example, optionally, based on predefined semaphore notification logic and heartbeat update logic, the system compiles dynamic symbol registry construction code, request parsing code, parameter validation code, function routing and execution code, and response encapsulation code to generate the plugin process Makefile, semaphore return communication code (mainly the system function calls CreateFileMappingA, MapViewOfFile, and CreateSemaphoreA), and the Makefile includes references and links to the extension library's dynamic link library header files. The MinGW compiler mingw32-make.exe is then used to compile the plugin process ServerLib.exe, which is the function call module.

[0056] For example, a portion of the implementation code of the function call module can be optionally represented as follows: void processMsg(const char* data,int dataSize) { char* retData = nullptr; int retDataSize = 0; / / Read method name int pos = 0; int funcNameSize = *(int*)(data); pos += sizeof(int); std::string funcName(data + pos, funcNameSize); pos += funcNameSize; if(funcName == "FuncA") process_FuncA((char*)(data + pos), dataSize - pos, retData,retDataSize); / / Send retData data to the client delete[] retData; } void process_FuncA(char* data,int dataSize,char*&retData,int&retDataSize) { int pos = 0; / / Parse input parameters int id = *(int*)(data); pos += sizeof(int); int nameSize = *(int*)(data + pos); pos += sizeof(int); std::string funcName(data+pos,nameSize); pos += nameSize; / / Calling the function char retDataBuffer

[1024] {0}; int retDataBufferSize = 1024; int retID = 0; bool ret = FuncA(id, funcName.c_str(), retDataBuffer,&retDataBufferSize,&retID); / / Return data population int responseDataSize = sizeof(bool) + sizeof(int) + retDataBufferSize+ sizeof(int); retData = new char[responseDataSize]{0}; int responsePos = 0; / / Fill the return value *(bool*)(retData + responsePos) = ret; responsePos += sizeof(bool); / / Fill in the return parameters *(int*)(retData + responsePos) = retDataBufferSize; responsePos += sizeof(int); memcpy(retData + responsePos, retDataBuffer, retDataBufferSize); responsePos += retDataBufferSize; *(int*)(retData + responsePos) = retID; } S2: Deploy the call request module to the caller and the function call module to the implementation side, and build a shared memory and semaphore communication mechanism between the call request module and the function call module; Specifically, the call request module can be deployed to the requesting caller, and the function call module can be deployed to the actual implementation. By deploying the call request module and the function call module independently, the stability of the other party can be avoided if the process of either party crashes. At the same time, a shared memory and semaphore communication mechanism can be built between the call request module and the function call module, thereby establishing a high-speed, bidirectional inter-process communication channel between the requesting caller and the actual implementation, providing a foundation for subsequent data transmission.

[0057] Preferably, shared memory may include main shared memory and heartbeat shared memory; the steps of constructing a shared memory and semaphore communication mechanism between the call request module and the function call module include: S21: Create a main shared memory to store call requests and execution results; Specifically, a shared physical memory page between processes can be allocated in the operating system kernel (usually implemented through POSIX shared memory objects or memory-mapped files). This memory area has read and write permissions for both the requesting caller (client process) and the actual implementer (server process). Its logical structure is divided into a request area (used to store extended function names and serialized input parameter data) and a response area (used to store execution results, return values, and output parameters). The requesting caller and the actual implementer exchange data directly through this memory area without going through the kernel protocol stack or disk I / O.

[0058] S22: Create a heartbeat shared memory to store the process identifier, start timestamp, and last active time of the actual implementer; Specifically, a small, independent shared memory area can be created as a heartbeat shared memory, dedicated to storing the process identifier (PID, used for system-level process location), startup timestamp (reflecting the process creation time, used to identify process restart events), and last active time (LastAliveTimestamp, reflecting the time of the most recent successful request processing or self-reporting). This memory area is periodically written to and updated by the implementation party and monitored by the caller in read-only mode.

[0059] S23: Create request and response semaphores to achieve inter-process synchronization between the requesting party and the actual implementer.

[0060] Specifically, two operating system-level semaphore objects can be optionally created: the request semaphore is initialized to 0, and the caller performs a "post" operation after writing the request, while the implementer performs a "wait" operation to block listening; the response semaphore is also initialized to 0, but in the opposite direction, and is released by the implementer after writing the result, while the caller waits. The two constitute a "producer-consumer" synchronization model, which strictly controls the timing of access to the main shared memory.

[0061] Preferably, after step S2, the method further includes: S24: Build the test script; S25: Execute the test script to verify whether the function call was completed. Determine whether the verification failed. If yes, return to step S1. If no, unload the test script.

[0062] Specifically, test scripts can be built using any existing technology to test the deployed call request module and function call module to determine whether they can perform function calls. If they can, the test is passed and the deployment is successful. If not, a vulnerability exists during the deployment process and the process needs to return to step S1 for redeployment.

[0063] More specifically, test scripts can be used to verify the correctness, performance, and stability of the entire system, ensuring that the request-response protocol, parameter serialization / deserialization, semaphore synchronization, and other aspects work properly. Automated regression testing can be performed to ensure the reliability of the toolchain; call latency data can be captured for performance analysis; and the complete startup-execution-cleanup process closely resembles real-world usage scenarios, verifying the correctness of resource management.

[0064] For example, optional test script code and a Makefile are generated. The Makefile references the plugin library header file, linking to the plugin library ClientLib.dll. The MinGW compiler mingw32-make.exe is called to compile the test script dynamic link library, loads and executes it, and simultaneously starts the plugin process ServerLib.exe. After the test script finishes execution, the library is unloaded, and the ServerLib.exe process exits.

[0065] For example, the plugin library ClientLib.dll and the process ServerLib.exe communicate using semaphores during the execution of the test script. First, a semaphore name is assigned to each extension library. The system functions CreateFileMappingA, MapViewOfFile, and CreateSemaphoreA are called to generate two semaphores and two memory mappings for them. One semaphore is used to send request data, and the other is used to receive return data. An incrementing call number is written to the header of each request, and the return data is retrieved by checking the call number. ClientLib.dll writes the request data and receives the return data; ServerLib.exe reads the request data and writes the return data.

[0066] S3: The requesting party obtains the user's call request and writes it into shared memory, and releases the request semaphore to notify the actual implementation party according to the semaphore communication mechanism; the call request includes the extended function name and input parameters; Specifically, the user's call request can be obtained by requesting the caller, the extended function name and input parameters can be extracted and serialized according to the call request module and written into shared memory. Then, the request semaphore can be released to interrupt the waiting state of the actual implementation, thereby initiating a cross-process remote call. The zero-copy feature of shared memory can be used to achieve efficient data transmission, and the semaphore mechanism can be used to ensure the synchronization of the execution time between the two processes and avoid data competition.

[0067] Preferably, before the requesting caller obtains the user's call request and writes it to shared memory, the process further includes: S31: Read the process identifier, start timestamp, and last active time from the heartbeat shared memory; S32: Determine whether the difference between the current time and the last active time exceeds the preset timeout threshold, or whether the process identifier is invalid, or whether the start timestamp is earlier than the last start record. If all conditions are met, start the process of the function call module and wait for it to complete its initialization before performing the write operation.

[0068] Specifically, before writing the call request to shared memory, the system can read the process identifier, start timestamp, and last active time from the heartbeat shared memory. By comparing the difference between the current time and the last active time to see if it exceeds a preset threshold, verifying the validity of the process identifier, and confirming that the start timestamp is consistent with historical records, the system can determine whether the actual implementation is in a healthy state. If a process is detected to be dead, crashed, or abnormally restarted, a new function call module process is automatically started and waited for to be ready. This completes the service availability pre-check before the actual call is initiated, avoiding long-term blocking or business failures caused by sending requests to failed nodes. This enables automatic fault detection and self-healing, significantly improving the continuous availability and service robustness of the system.

[0069] S4: The actual implementer reads the call request from the shared memory based on the request semaphore, inputs the input parameters into the corresponding local extended function according to the call request, obtains the execution result and writes it back to the shared memory, and releases the response semaphore to notify the requesting caller according to the semaphore communication mechanism; Specifically, after receiving the request semaphore notification, the actual implementer deserializes and extracts the extended function name and input parameters from shared memory, obtains the local function entry address through dynamic symbol resolution, executes the business logic, serializes the result and writes it back to shared memory, and then releases the response semaphore to wake up the requesting caller, thus completing a complete request-response closed loop. Shared memory is used to achieve zero-copy data transmission to reduce latency, while the semaphore mechanism ensures timing synchronization and prevents data races, providing an efficient and reliable execution engine for cross-process function calls.

[0070] Preferably, the specific steps of S4 may include: S41: Read the call request in shared memory, obtain the extended function name and input parameters, and obtain the actual function address corresponding to the extended function name according to the function calling module; Specifically, the serialized call request in shared memory can be parsed to obtain the extended function name and input parameters. Then, the dynamic symbol registry is queried to establish a mapping relationship between the extended function name and the memory address, thereby quickly locating the actual entry point of the local extended function. This avoids repeatedly searching the dynamic library every time it is called, improves function routing efficiency, and ensures the consistency between the call target and the original header file declaration.

[0071] S42: Perform semantic validation on the input parameters based on parameter constraint metadata and parameter direction markers; semantic validation includes: if a parameter has a maximum string length constraint, then validate that its actual length does not exceed the maximum length; if a parameter has a buffer size dependency, then validate that the size of the target buffer is not less than the value of the dependent parameter; if a parameter has a non-null pointer constraint, then validate that it is not zero. Specifically, based on the parameter direction markers (input / output / bidirectional) and constraint metadata (string length limit, buffer capacity dependency, non-null requirement) extracted during compilation, mandatory boundary checks and semantic verification can be performed on the input parameters. This intercepts illegal operations such as out-of-bounds access, buffer overflow, and null pointer dereferencing before execution, building a defense-in-depth system to prevent malicious or malformed input from penetrating to the business logic layer and ensuring the memory safety and operational stability of the actual implementation process.

[0072] S43: Determine whether the semantic validation passes. If yes, input the input parameters into the corresponding local extended function according to the real function address to obtain the execution result; otherwise, generate an error code as the execution result. Specifically, it can optionally determine whether semantic validation passes. If it does, it jumps to the local extended function via a function pointer to execute the actual business logic and capture the return value. If it does not, it directly constructs a standardized error code and skips function execution, thereby decoupling business logic from security validation, ensuring that illegal input will not trigger potential crash points, and providing the caller with accurate error diagnosis information to facilitate exception handling and fault location by the upper-layer business.

[0073] S44: Write the execution result to shared memory and release the response semaphore according to the semaphore communication mechanism.

[0074] Specifically, the execution results, such as function return value, output parameters, and execution status (success / error code), can be serialized and written to a shared memory response buffer. Then, the response semaphore is released to notify the requesting caller that the data is ready, thereby completing the cross-process return of the execution results, ensuring data integrity and timing correctness, and waking up the blocked caller thread so that it can obtain the results in a timely manner, thus improving the overall system throughput and response speed.

[0075] S5: The requesting caller reads the execution result from the shared memory based on the response semaphore and completes the extension library call.

[0076] Specifically, the requesting caller can choose to read the execution result from the shared memory based on the response semaphore, complete the extension library call, and thus complete the full closed loop of the extension function call.

[0077] In this embodiment, the present invention provides an automated extended function call method. This method automatically generates separate binary components, including a call request module and a function call module, by parsing the original header file of the extended function. The two modules are then distributed and deployed between the requesting caller and the actual implementation. A high-speed inter-process communication channel based on shared memory and semaphores is constructed, achieving at least the following technical effects: 1. Automated code generation based on abstract syntax trees significantly reduces development and maintenance costs: Traditional cross-process calls require developers to manually write a large amount of code for serialization, deserialization, memory synchronization, and concurrency control, which is tedious and prone to introducing protocol mismatch defects. This application generates an abstract syntax tree by parsing the original header file, automatically extracting function names, return values, parameter direction markers, and constraint metadata. Based on this, it automatically generates request serialization / response deserialization code for the call request module and request parsing / response encapsulation code for the function call module, achieving end-to-end automation from interface definition to communication implementation. When the original dynamic link library interface changes, only the header file needs to be re-parsed to synchronously update both modules, avoiding omissions from manual modifications, achieving single-point changes with global effects, and effectively improving development efficiency and interface consistency.

[0078] 2. Distributed deployment of separate binary components enables process-level fault isolation and improved stability: Due to the inherent risk of third-party extension libraries crashing (such as segmentation faults and unhandled exceptions), in traditional monolithic architectures, library function crashes directly lead to the failure of the main process, triggering cascading failures. This application generates separate binary components, deploying the call request module on the requesting party and the function call module on the actual implementation party, allowing both to run in independent address spaces. Even if the actual implementation party crashes due to extension function exceptions, the requesting party process remains alive and can quickly restart the implementation party to restore service through a heartbeat mechanism, effectively blocking fault propagation and improving the overall robustness and isolation of the system.

[0079] 3. Building a defense-in-depth security system based on semantic pre-validation of parameter constraint metadata: Due to the vulnerability of memory safety such as out-of-bounds access and null pointer dereferencing when passing pointers and buffers across processes, traditional methods lack automated verification methods. This application extracts parameter direction markers (input / output / bidirectional) and parameter constraint metadata (maximum string length, buffer size dependency, non-null pointer constraint) to automatically generate parameter validation code in the function call module. Before actually calling the local extension function, mandatory boundary checks (such as length verification, non-null verification, and buffer capacity verification) are performed on the input parameters to block illegal input outside the business logic. Even if the original dynamic link library has security vulnerabilities, pre-validation can prevent malicious input penetration and effectively protect the memory safety and operational stability of the actual implementation process.

[0080] 4. Combining heartbeat shared memory with a pre-check mechanism enables rapid fault detection and service self-healing: Since the actual implementation may become deadlocked or unresponsive due to resource exhaustion, causing the requesting caller to be blocked for a long time, this application creates a heartbeat shared memory to store the process identifier, start timestamp, and last active time, and performs an activity pre-check before initiating the call; by comparing the time difference, verifying the validity of the process, and identifying restart events, the health status of the implementation is accurately determined. If a timeout or process failure is detected, the function call module is automatically restarted and waits for initialization to complete, realizing rapid fault detection and automatic recovery, avoiding unnecessary waiting, and ensuring continuous service availability.

[0081] 5. Compile-time type safety and interface contract consistency guarantee: Since cross-process calls involve complex data type conversions and memory layout alignment, manual coding can easily lead to type mismatch or version inconsistency issues. This application automatically generates dual-end code at compile time based on the original header file, ensuring strict symmetry between request serialization and response deserialization logic. Parameter direction markers and constraint metadata are fixed in the generated code at compile time. A mapping from function name to address is established through a dynamic symbol registry to ensure that the calling target is strictly consistent with the header file declaration, realizing strong type constraints on the interface contract and avoiding undefined behavior caused by interface mismatch at runtime.

[0082] This application transforms the traditionally tedious and error-prone cross-process call encapsulation work into a standardized metadata-driven code generation problem through a fully automated pipeline of "parsing-generation-deployment-running". Combined with high-performance communication with shared memory and a heartbeat fault self-healing mechanism, it achieves automated, high-performance, high-security and high-availability encapsulation of cross-process extended function calls. It is particularly suitable for enterprise-level application scenarios that require isolation of unstable third-party libraries or have strict requirements for system stability and security.

[0083] On the other hand, the present invention also provides a computer storage medium storing executable program code; the executable program code is used to execute any of the above-mentioned automated extended function call methods.

[0084] On the other hand, the present invention also provides a terminal device, including a memory and a processor; the memory stores program code that can be executed by the processor; the program code is used to execute any of the above-mentioned automated extended function call methods.

[0085] For example, the program code can be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the program code in the terminal device.

[0086] The terminal device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The terminal device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that the terminal device may also include input / output devices, network access devices, buses, etc.

[0087] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0088] The memory can be an internal storage unit of the terminal device, such as a hard drive or RAM. The memory can also be an external storage device of the terminal device, such as a plug-in hard drive, SmartMediaCard (SMC), SecureDigital (SD) card, or FlashCard. Furthermore, the memory can include both internal and external storage units of the terminal device. The memory is used to store the program code and other programs and data required by the terminal device. The memory can also be used to temporarily store data that has been output or will be output.

[0089] The computer storage medium and terminal device described above are created based on the automated extended function call method described above. Their technical functions and beneficial effects will not be elaborated here. The technical features of the above embodiments can be combined arbitrarily. 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.

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

Claims

1. An automated extended function call method, characterized in that, include: Obtain function declaration information from the original header file to generate separate binary components, including a call request module and a function call module; Deploy the call request module to the caller, deploy the function call module to the implementation, and build a shared memory and semaphore communication mechanism between the call request module and the function call module. The requesting party obtains the user's request and writes it into shared memory, and releases the request semaphore to notify the actual implementation party according to the semaphore communication mechanism; The call request includes the extended function name and input parameters; The actual implementation reads the call request from the shared memory based on the request semaphore, inputs the input parameters into the corresponding local extended function according to the call request, obtains the execution result and writes it back to the shared memory, and releases the response semaphore to notify the requesting caller according to the semaphore communication mechanism; The requesting caller reads the execution result from shared memory based on the response semaphore and completes the extended function call.

2. The method according to claim 1, characterized in that, The steps to obtain function declaration information from the original header file include: Parse the original header file and generate an abstract syntax tree; Traverse the abstract syntax tree to extract function declaration information, which includes the function name, return type, parameter list, parameter direction markers, and parameter constraint metadata.

3. The method according to claim 2, characterized in that, Parameter direction markers include input parameter markers, output parameter markers, or input / output parameter markers; parameter constraint metadata includes maximum string length, buffer size dependency, or non-null pointer constraint.

4. The method according to claim 2, characterized in that, The steps for generating the call request module include: Based on the parameter list and parameter direction markings, the input parameters and output parameters are classified and obtained. Generate request serialization code based on the function name and input parameters; Generate response deserialization code based on the return value type and output parameters; Based on the predefined shared memory access logic, semaphore operation logic, and heartbeat status detection logic, the request serialization code and response deserialization code are compiled to generate the call request module.

5. The method according to claim 2, characterized in that, The steps for generating a function call module include: Generate dynamic symbol registry build code, which is used to load the original dynamic link library at runtime and establish a mapping from function names to function addresses; Generate request parsing code to deserialize the extended function name and input parameters from shared memory; Generate parameter validation code to perform semantic validation on input parameters based on parameter direction markers and parameter constraint metadata; Generate function routes and execution code, used to query function addresses based on extension function names and call the corresponding local extension functions; Generate response encapsulation code to serialize the execution result or error code and write it to shared memory; Based on the predefined semaphore notification logic and heartbeat update logic, compile the dynamic symbol registry construction code, request parsing code, parameter validation code, function routing and execution code, and response encapsulation code to generate the function call module.

6. The method according to claim 1, characterized in that, Shared memory includes main shared memory and heartbeat shared memory; The steps for constructing a shared memory and semaphore communication mechanism between the call request module and the function call module include: Create a main shared memory to store call requests and execution results; Create a heartbeat shared memory to store the process identifier, startup timestamp, and last active time of the actual implementer; Create request and response semaphores to achieve inter-process synchronization between the requesting party and the actual implementer.

7. The method according to claim 6, characterized in that, Before the caller obtains the user's call request and writes it to shared memory, the process also includes: Read the process identifier, startup timestamp, and last active time from the heartbeat shared memory; Determine if the difference between the current time and the last active time exceeds the preset timeout threshold, if the process identifier is invalid, and if the startup timestamp is earlier than the last startup record. If all conditions are met, start the process of the function call module and wait for it to complete initialization before performing the write operation.

8. The method according to claim 3, characterized in that, The actual implementation involves reading the call request from shared memory based on the request semaphore, inputting the input parameters into the corresponding local extended function according to the call request, obtaining the execution result and writing it back to shared memory, and releasing the response semaphore to notify the requesting caller according to the semaphore communication mechanism. This process includes: Read the call request from shared memory to obtain the extended function name and input parameters, and obtain the actual function address corresponding to the extended function name based on the function calling module; The input parameters are semantically validated based on the parameter constraint metadata and parameter direction markers. The semantic validation includes: if the parameter has a maximum string length constraint, then verify that its actual length does not exceed the maximum length; if the parameter has a buffer size dependency, then verify that the size of the target buffer is not less than the value of the dependent parameter; if the parameter has a non-null pointer constraint, then verify that it is not zero. Determine whether the semantic validation passes. If it does, input the input parameters into the corresponding local extended function based on the actual function address to obtain the execution result; otherwise, generate an error code as the execution result. The execution result is written to shared memory, and the response semaphore is released according to the semaphore communication mechanism.

9. A computer storage medium, characterized in that, It stores executable program code; the executable program code is used to execute the automated extended function call method according to any one of claims 1 to 8.

10. A terminal device, characterized in that, It includes a memory and a processor; the memory stores program code that can be executed by the processor; the program code is used to execute the automated extended function call method according to any one of claims 1 to 8.

Images