Executable program generation method and device, and electronic device

Abstract

The application provides an executable program generation method, device and electronic equipment, relates to the technical field of computers, and the executable program generation method is applied to a first device and includes the following steps: acquiring a first intermediate file corresponding to target software source code and a record file corresponding to the target software source code sent by a second device; the record file is used for representing executable program link commands required when the target software source code is converted into a first executable program; and a second executable program is generated based on the first intermediate file, the executable program link commands and instruction set extension information corresponding to the second device. The application can ensure normal operation of the device when all versions of hardware are changed without modifying the target software source code and an original construction system, reduces the complexity of software, and realizes compatibility of software on all versions of hardware.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an executable program generation method, apparatus, and electronic device. Background Technology

[0002] In the field of computer science, executable programs must be compatible with the hardware instruction set architecture and software environment of a device to function properly. However, the Central Processing Unit (CPU), instruction set architecture, and microarchitecture are diverse. When the hardware performance of a device changes, the device may malfunction or some functions may fail to be implemented because the changed hardware is incompatible with the current software. Therefore, software needs to be compatible with various hardware types. Current technologies mostly employ methods such as modifying the compiler, creating plugins, compiling multiple versions simultaneously, or compiling the target software source code on the client machine. However, these methods increase software complexity and still cannot fully guarantee compatibility with all hardware versions. Summary of the Invention

[0003] This invention provides an executable program generation method, apparatus, and electronic device to address the shortcomings of existing technologies that, while increasing software complexity, fail to achieve full compatibility across all hardware versions due to methods such as modifying compilers, creating plugins, compiling multiple versions simultaneously, or compiling target software source code on a client machine. The invention enables the first device to regenerate an executable program using intermediate files, executable program linking commands, and instruction set extension information when the hardware or functionality of the first device is updated. This ensures the executable file is compatible with the changed hardware. Compared to methods involving modifying compilers, creating plugins, compiling multiple versions simultaneously, or compiling target software source code on a client machine, this method does not modify the target software source code or the original build system, reducing software complexity. Furthermore, it guarantees normal device operation across all hardware versions, achieving software compatibility across all hardware versions.

[0004] This invention provides an executable program generation method, applied to a first device, comprising the following steps:

[0005] Obtain the first intermediate file corresponding to the target software source code sent by the second device and the record file corresponding to the target software source code; the record file is used to characterize the executable program linking commands required when the target software source code is converted into the first executable program;

[0006] A second executable program is generated based on the first intermediate file, the executable program linking command, and the instruction set extension information corresponding to the second device.

[0007] According to an executable program generation method provided by the present invention, the second device is a client. The step of generating a second executable program based on the first intermediate file, the executable program linking command, and the instruction set extension information corresponding to the second device includes: generating an intermediate template file based on the instruction set extension information and an empty function template file of the client; adjusting the first intermediate file based on the intermediate template file and a first analysis tool to obtain a second intermediate file; and compiling the second intermediate file based on the executable program linking command to obtain the second executable program.

[0008] According to an executable program generation method provided by the present invention, the step of compiling the second intermediate file based on the executable program linking command to obtain the second executable program includes: determining a first configuration corresponding to the target instruction set architecture and a second configuration corresponding to the microarchitecture based on the target instruction set architecture and microarchitecture of the client; determining the environment variables and specified path of the client; and compiling the second intermediate file based on the first configuration, the second configuration, the environment variables, the specified path and the executable program linking command to obtain the second executable program.

[0009] According to an executable program generation method provided by the present invention, the second intermediate file is compiled based on the first configuration, the second configuration, the environment variables, the specified path, and the executable program linking command to obtain the second executable program. The method includes: pausing the compilation of the second intermediate file if the resource usage of the client is detected to be higher than a resource threshold during the compilation process; resuming the compilation of the second intermediate file if the resource usage of the client is detected to be lower than or equal to the resource threshold; and continuing to compile the second intermediate file based on the first configuration, the second configuration, the environment variables, the specified path, and the executable program linking command to obtain the second executable program.

[0010] According to an executable program generation method provided by the present invention, the second device is a server, and the instruction set extension information includes at least one instruction set architecture supported by the server and a microarchitecture corresponding to each instruction set architecture. The step of generating a second executable program based on the first intermediate file, the executable program linking command, and the instruction set extension information includes: generating a third intermediate file corresponding to each instruction set architecture based on a second analysis tool, the first intermediate file, each instruction set architecture, and the microarchitecture corresponding to each instruction set architecture; and compiling each of the third intermediate files based on the executable program linking command to obtain the second executable program corresponding to each instruction set architecture.

[0011] According to an executable program generation method provided by the present invention, after compiling each of the third intermediate files based on the executable program linking command to obtain a second executable program corresponding to each of the instruction set architectures, the method further includes: encapsulating the second executable program corresponding to each of the instruction set architectures to create a software installation and distribution package, and creating a software repository; in response to a client's call operation in the software repository, sending the software installation and distribution package called by the client to the client, and installing it on the client.

[0012] This invention provides an executable program generation method, applied to a second device, comprising the following steps:

[0013] Based on the packaging script, the original compilation command is called to compile the target software source code twice, resulting in a fourth intermediate file and a third executable program corresponding to the target software source code.

[0014] Link the fourth intermediate file to obtain the first intermediate file;

[0015] The third executable program is linked to obtain a log file corresponding to the first executable program; the log file is used to characterize the executable program linking commands required when the target software source code is converted into the first executable program;

[0016] The first intermediate file and the executable program linking command are sent to the first device, which generates a second executable program based on the first intermediate file, the executable program linking command, and the instruction set extension information corresponding to the second device.

[0017] The present invention also provides a first executable program generation apparatus, comprising the following modules:

[0018] The acquisition module is used to acquire a first intermediate file corresponding to the target software source code sent by the second device and a record file corresponding to the target software source code; the record file is used to characterize the executable program linking commands required when the target software source code is converted into a first executable program.

[0019] The generation module is used to generate a second executable program based on the first intermediate file, the executable program linking command, and the instruction set extension information corresponding to the second device.

[0020] The present invention also provides a second executable program generation apparatus, comprising the following modules:

[0021] The compilation module is used to compile the target software source code twice by calling the original compilation commands based on the packaging script, so as to obtain a fourth intermediate file and a third executable program corresponding to the target software source code.

[0022] The first linking module is used to link the fourth intermediate file to obtain the first intermediate file;

[0023] The second linking module is used to link the third executable program to obtain a record file corresponding to the first executable program; the record file is used to characterize the executable program linking commands required when the target software source code is converted into the first executable program;

[0024] The sending module is used to send the first intermediate file and the executable program linking command to the first device, and the first device is used to generate a second executable program based on the first intermediate file, the executable program linking command and the instruction set extension information corresponding to the second device.

[0025] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the executable program generation method described above.

[0026] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the executable program generation method as described above.

[0027] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the executable program generation method described above.

[0028] The executable program generation method, apparatus, and electronic device provided by this invention obtain a first intermediate file and a record file corresponding to the target software source code sent by a second device through a first device. The record file is used to characterize the executable program linking commands required when the target software source code is converted into a first executable program. Based on the first intermediate file, the executable program linking commands, and the instruction set extension information corresponding to the second device, a second executable program is generated. Thus, when the hardware of the first device is updated or its function changes, the first device can regenerate the executable program using the intermediate file, the executable program linking commands, and the instruction set extension information, making the executable file compatible with the changed hardware. Compared with methods such as modifying the compiler, creating plugins, compiling multiple versions simultaneously, or compiling the target software source code on a client machine, this method reduces software complexity without modifying the target software source code and the original build system, and ensures normal device operation under all hardware version changes, achieving software compatibility across all hardware versions. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0030] Figure 1 This is one of the flowcharts illustrating the executable program generation method provided by the present invention.

[0031] Figure 2 This is a structural diagram of an application scenario for the executable program generation method provided by the present invention.

[0032] Figure 3 This is a schematic diagram of the process by which a client generates a second executable program, as provided by the present invention.

[0033] Figure 4 This is a schematic diagram of the process by which the server generates a second executable program, as provided by the present invention.

[0034] Figure 5 This is the second flowchart of the executable program generation method provided by the present invention.

[0035] Figure 6 This is a schematic diagram of the structure of the first executable program generation device provided by the present invention.

[0036] Figure 7 This is a schematic diagram of the structure of the second executable program generation device provided by the present invention.

[0037] Figure 8This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0039] Currently, CPUs can be broadly classified according to performance, instruction set, and development unit. Among them, (1) performance: CPUs include cores with small area and power consumption for the embedded market; mid-range cores for mobile phones, tablets, laptops, etc.; and high-end processor intellectual property cores (CPU IP) for workstations and servers. For example, Intel has the Xeon series for servers, the Core series for laptops and desktops, and the Atom series for tablets, etc. Each core, and even each generation of each core, may exhibit different performance characteristics. (2) Instruction set: Existing instruction sets include x86, ARM, RISC-V, Power, SPARC, etc. Each instruction set includes different evolution versions, 32-bit versions and 64-bit versions, extended versions from different manufacturers, versions that lack some functions on the basic version for various reasons, etc. Taking the 64-bit x86-64 instruction set as an example, it has developed four major versions since 2004: x86-64-V1, x86-64-V2, x86-64-V3, and x86-64-V4. Each major version is a combination of a series of new features. There are very complex intermediate states between each major version. At the same time, there are some differences between the instruction sets implemented by Intel and those implemented by AMD. (3) Development units: Even when developing CPUs with the same instruction set and targeting the same scenarios, each development unit will make different technical choices, resulting in different performance characteristics. For example, instruction 1 may be slower on processor A than on processor B, but instruction 2 may be faster. When an instruction set consists of three to five instructions, the performance may be more complex.

[0040] Furthermore, most critical foundational software is currently written in compiled programming languages ​​and distributed in pre-compiled binary formats. Therefore, when distributing software, considering the potential market and to ensure compatibility with more user devices, development and compilation often only utilize a common subset of all CPUs. Consequently, new features in the instruction set and extended functions of the CPU are often not fully realized.

[0041] Furthermore, because microarchitectures are even more complex than instruction sets, software development and distribution can only be optimized for the most commonly used target markets, involving complex trade-offs between various microarchitectures. As a result, the best-performing CPUs are unable to reach their full potential, while lower-performance CPUs have to bear a heavier burden to run these software programs.

[0042] In existing technologies, the following methods are used to address software compatibility with different hardware and their respective problems: 1) Dynamically loading plugins: Frequently executed, performance-critical parts of the software are isolated and made into plugins; these plugins are compiled for different instruction sets and microarchitecture combinations. During software runtime, they are selectively loaded based on the characteristics of the current CPU. The main problems are: significantly increasing software complexity, including code and compilation system; increasing the likelihood of software failure; and causing a significant increase in software size. 2) Implementing multiple versions of the same function in a software library: By modifying the compiler, specified functions can be compiled multiple times, generating different implementations, which are then packaged into the same program. During program runtime, a specific implementation is selected based on the characteristics of the current CPU. The main problems are: requiring significant modifications to the compiler; requiring modifications to the software source code to specify a series of functions for whitelisting, which significantly increases software complexity; and only allowing optimization at the instruction set level, not for specific microarchitectures. 3) Compiling multiple versions simultaneously: Using a scripting language to determine which version to execute, integrating multiple versions of the software into the same installation package. The program's entry point is implemented using a scripting language. It first determines the characteristics of the current CPU and then selects the most suitable version. The main problems are: it significantly increases the package size, limiting the deployment of only a few optimizations; and it's not very compatible with current major operating system distribution methods. 4) Distributing the target software source code involves compiling it on the client machine. The main problems include: compilation depends on various header files, development libraries, compilers, etc.; for commercial software, it may leak the software source code; and users need to wait a long time from installation to being able to use it.

[0043] Therefore, in addition to increasing software complexity while still failing to fully support all hardware versions, existing technologies also present the following problems: the diversity of CPUs in instruction sets and microarchitecture designs contradicts the binary software distribution model; pre-compiled binary software can only choose a certain balance among multiple microarchitectures, resulting in optimization limitations on many microarchitectures; and pre-compiled binaries can only select one instruction set. If more CPUs are to be supported, CPUs with new features cannot use their new features; if new features from some CPUs are used, compatibility with some other CPUs is compromised.

[0044] To address the aforementioned issues, this invention proposes an executable program generation method. When the hardware of the first device is updated or its functions are changed, the first device can regenerate the executable program using intermediate files, executable program linking commands, and instruction set extension information. This ensures that the executable file is compatible with the changed hardware. Compared to methods such as modifying the compiler, creating plugins, compiling multiple versions simultaneously, or compiling the target software source code on the client machine, this method reduces software complexity and guarantees normal device operation even with changes in all hardware versions, achieving software compatibility across all hardware versions.

[0045] The following is combined with Figures 1-5 The present invention describes an executable program generation method applicable to any CPU, instruction set architecture, microarchitecture, and software. The execution subject of this method can be an electronic device or an executable program generation method installed in the electronic device. The executable program generation device can be implemented by software, hardware, or a combination of both.

[0046] Figure 1 This is one of the flowcharts illustrating the executable program generation method provided by the present invention, such as... Figure 1 As shown, the method is applied to the first device and includes the following:

[0047] Step 101: Obtain the first intermediate file corresponding to the target software source code sent by the second device and the record file corresponding to the target software source code.

[0048] The log file is used to characterize the executable linking commands required when the target software source code is converted into a first executable program.

[0049] Here, the first device can be a client or a server, and the second device can be a device developed by the researchers.

[0050] Here, the target software source code can be the code that implements any software.

[0051] The first intermediate file is a file located between the target software source code and the executable program. It can be an intermediate file of a single code or a file resulting from the linking of multiple intermediate files corresponding to the code. The intermediate file is independent of the specific instruction set and is used to represent the abstraction and standardization of the program's semantic structure.

[0052] In this embodiment of the invention, the second device can also send the first executable program, which is a version generated using the most basic instruction set, converted from the target software source code, to the first device. The first executable program client can directly install and use it.

[0053] Here, the first intermediate file can be generated by calling the packaging script through the first device, or it can be obtained by outputting the intermediate representation file in the compiler.

[0054] Here, the executable program can be a dynamic link library, which includes the files involved in linking (such as the compiled object file, linker script, etc.) and linking options (such as optimization level, dynamic library version information, etc.).

[0055] Here, executable programs include programs that can be executed directly on a computer, as well as computer binary files that may be needed for program execution, such as dynamic link libraries and static link libraries.

[0056] Step 102: Generate a second executable program based on the first intermediate file, the executable program linking command, and the instruction set extension information corresponding to the second device.

[0057] Instruction set extension information refers to the set of new instructions added to the existing basic instruction set architecture. A second executable program is generated based on the instruction set extension information and the first intermediate file, replacing the executable program corresponding to the basic instruction set version.

[0058] Optionally, when the first device is a client, only the instruction set extension information of the client itself is needed to convert the first intermediate file separately to obtain the second executable program; when the second device is a server, the instruction set extension information of all clients supported by the server is needed to convert the first intermediate file in batches to obtain the second executable program.

[0059] For example, Figure 2 This is a schematic diagram of the structure of the executable program generation system that implements the executable program generation method provided by the present invention, as shown below. Figure 2As shown, the executable program generation system 200 includes a build tool (RuyiBuild) 210, a client 220, and a server 230. The client 220 includes a first conversion module 221 and an application 222, while the server 230 includes a second conversion module 231 and a software repository 232. Specifically, the RuyiBuild tool compiles the target software source code twice, obtaining a first executable program 211 and a first intermediate file 212. The first executable program is sent to the client, which can directly install and use it. The first intermediate file is sent to both the client and the server. The first conversion module on the client compiles the first intermediate file to obtain a second executable program. The second conversion module on the server compiles the first intermediate file to obtain the second executable program. The second executable program is stored in the software repository for use by users on different platforms.

[0060] In this embodiment of the invention, when the hardware of the first device is updated or its function is changed, the first device can regenerate the executable program using intermediate files, executable program linking commands and instruction set extension information, so that the executable file is adapted to the changed hardware. Compared with the methods of modifying the compiler, making plugins, compiling multiple versions at the same time, or compiling the target software source code on the client, the complexity of the software is reduced, and the device can be guaranteed to run normally when all versions of hardware are changed, thus achieving software compatibility on all versions of hardware.

[0061] Example 1, Figure 3 This is a schematic diagram of the process by which a client generates a second executable program, as provided by the present invention. Figure 3 As shown, the second device is a client. The step of generating a second executable program based on the first intermediate file, the executable program linking command, and the instruction set extension information corresponding to the second device includes:

[0062] Step S301: Generate an intermediate template file based on the instruction set extension information and empty function template file of the client.

[0063] Step S302: Based on the intermediate template file and the first analysis tool, adjust the first intermediate file to obtain the second intermediate file.

[0064] Step S303: Based on the executable program linking command, compile the second intermediate file to obtain the second executable program.

[0065] Here, the empty function template file is a C language template file that contains only empty functions, namely empty.c.

[0066] Here, the intermediate template file contains instruction set extension information supported by the client and related intermediate file attributes.

[0067] Here, the first analysis tool is a tool for comparing and merging intermediate representation (IR) attributes and instruction set extensions (such as the llvm-attribute-adjust tool). It is used to analyze the attribute set of intermediate template files and intermediate files, and merge the instruction set extension attributes of the template files into the target LLVM IR files to achieve accurate matching of instruction set extensions in the IR files.

[0068] In this embodiment of the invention, a dynamic template-based instruction set extension adaptive mechanism and a microarchitecture fine-grained optimization mechanism effectively solve the software compatibility and performance optimization problems caused by instruction set fragmentation in the ecosystem, achieving fine-grained adaptation and optimization from unified intermediate files to diverse target devices. This mechanism not only greatly improves the efficiency and reliability of cross-platform software deployment, but also significantly enhances the actual operating performance of the software on specific target devices, fully demonstrating the innovation of the RuyiBuild toolchain.

[0069] Furthermore, the step of compiling the second intermediate file based on the executable linking command to obtain the second executable program includes: determining a first configuration corresponding to the target instruction set architecture and a second configuration corresponding to the microarchitecture based on the target instruction set architecture and microarchitecture of the client; determining the environment variables and specified path of the client; and compiling the second intermediate file based on the first configuration, the second configuration, the environment variables, the specified path, and the executable linking command to obtain the second executable program.

[0070] Here, the features of the microarchitecture include, but are not limited to, out-of-order execution capability, pipeline depth, and caching structure. The configuration file is generated based on the microarchitecture to adjust the optimization parameters of the intermediate files, and the configuration file is automatically loaded and applied during the conversion of the second intermediate file.

[0071] Here, the target instruction set architecture refers to the instruction set architecture supported by the client.

[0072] Here, when the executable is a dynamic link library, environment variables can be used to specify an additional path for the dynamic linker to load the program's dynamic library. This specified path is the path to the client's second executable instruction, requiring the application software to preferentially use the converted dynamic link library.

[0073] Here, when the executable program is a directly executable program, environment variables can be used to specify the path where the operating system searches for the directly executable program. In this case, the specified path is the path where the guest machine provides the instructions for the second executable program, requiring the application software to preferentially use the converted directly executable program.

[0074] In this embodiment of the invention, the application software is required to preferentially use the converted dynamic link library or optimized executable program by using the first configuration corresponding to the target instruction set architecture, the second configuration corresponding to the microarchitecture, environment variables, and specified paths, thereby improving the performance of the application the next time it is used.

[0075] Furthermore, the step of compiling the second intermediate file based on the first configuration, the second configuration, the environment variables, the specified path, and the executable program linking command to obtain the second executable program includes: pausing the compilation of the second intermediate file if the resource usage of the client is detected to be higher than a resource threshold during the compilation process; resuming the compilation of the second intermediate file if the resource usage of the client is detected to be lower than or equal to the resource threshold; and continuing to compile the second intermediate file based on the first configuration, the second configuration, the environment variables, the specified path, and the executable program linking command to obtain the second executable program.

[0076] Here, resource usage can include CPU load and memory usage. The resource usage threshold can be any suitable value, such as 80%, 85%, etc.

[0077] In practice, during the compilation of the second intermediate file, CPU load and memory usage need to be monitored. When system resources are strained (e.g., CPU usage exceeds 80% and memory usage exceeds 85%), the background service process automatically sends a pause (SIGSTOP) signal to the LLVM IR to Executable and Linkable Format (ELF) conversion process, immediately pausing the conversion process. Once system resources return to normal (e.g., CPU usage is below 40% and memory usage is below 45%), the background service process sends a resume (SIGCONT) signal to resume the conversion process.

[0078] In this embodiment of the invention, the conversion process, i.e. the compilation process, can also be restricted to execute within specific CPU cores and memory quotas to ensure that the conversion process on the client device is user-friendly and stable and will not interfere with the normal user experience.

[0079] In this embodiment of the invention, the pause and continuation of the conversion process are controlled according to the resource usage status to ensure that the conversion process on the client device is user-friendly and stable, and does not interfere with the normal user experience.

[0080] For example, the generation of a second executable program is illustrated using the RuyiBuild client:

[0081] The RuyiBuild automation script tool automatically queries the CPU instruction set extension information of the guest machine, especially on Reduced Instruction Set Computing-V (RISC-V) platforms. This is primarily achieved by parsing the system-provided ` / proc / cpuinfo` file or utilizing system call interfaces (such as the `riscv_hwprobe` system call). For example, the instruction set parsing script included in the RuyiBuild toolchain can automatically extract ISA extension information from the target device.

[0082] # Example: Automatically extract RISC-V device instruction set extension information:

[0083] ISA_EXTENSIONS=$(grep ^isa / proc / cpuinfo | head -n1 | awk '{print $2}')

[0084] echo "Detected ISA extensions: $ISA_EXTENSIONS"

[0085] After executing the above script, you will get information similar to the following:

[0086] Detected ISA extensions: rv64imafdcv_zicsr_zifencei

[0087] Subsequently, the RuyiBuild toolchain uses the instruction set extension information obtained above to automatically generate a C language template file (empty.c) containing only empty functions:

[0088] / / empty.c: Empty function template file

[0089] int empty_function(void) { return 0;}

[0090] It also uses the instruction set extension information of the target device to compile and generate the corresponding LLVM IR template file, i.e., the intermediate template file;

[0091] # Generate template IR file

[0092] clang -emit-llvm -march=$ISA_EXTENSIONS -c empty.c -o template.bc

[0093] Because the template file contains only a simple function, the compiled LLVM IR file (template.bc) does not contain any specific business logic, but it fully includes the instruction set extensions supported by the client and related LLVM IR attributes. The RuyiBuild toolchain then uses this template LLVM IR file to automatically adjust the LLVM IR file of the target software to be deployed, ensuring that its instruction set tags are completely matched with the target device.

[0094] Next, the RuyiBuild toolchain implements or calls a dedicated first analysis tool (such as llvm-attribute-adjust). The technical principle behind this tool is to analyze the attribute sets of the LLVM IR files in the intermediate template file and the first intermediate file, merging the instruction set extension information attributes of the intermediate template file into the target LLVM IR file, i.e., the aforementioned second intermediate file, to achieve precise matching of the instruction set extensions in the IR file. The command is as follows:

[0095] # Adjust the target IR file instruction set extended information attribute matching template

[0096] llvm-attribute-adjust --template=template.bc \

[0097] --input=target_software.bc \

[0098] --output=target_software_adjusted.bc

[0099] The `target_software_adjusted.bc` file generated after executing the above command has its instruction set extension attributes strictly matched to the guest machine's instruction set extension combination. Finally, the RuyiBuild toolchain calls the lld linker in the LLVM toolchain to generate an ELF file that is finely adapted to the target microarchitecture and instruction set extensions, as follows:

[0100] # Generate the final refined and optimized ELF format dynamic library

[0101] clang -shared target_software_adjusted.bc -fuse-ld=lld \

[0102] -march=$ISA_EXTENSIONS -O3 -o target_software_final.so

[0103] Through the aforementioned instruction set extension adaptive mechanism based on dynamic templates, the RuyiBuild toolchain ensures the quality of the final generated ELF file.

[0104] It's worth noting that RuyiBuild deploys a dedicated background service process to monitor device resource usage in real time, including CPU load and memory usage. On the app side, the path to the IR dependency library ( / var / lib / llvmir / lib) is specified via environment variables through configuration files to support accelerated operation after conversion. When system resources are strained (e.g., CPU usage exceeds 80% or memory usage exceeds 85%), the background service process automatically sends a SIGSTOP signal to the LLVM IR to ELF conversion process, immediately pausing the conversion. Once system resources return to normal (e.g., CPU usage below 40% or memory usage below 45%), the background service process sends a SIGCONT signal to resume the conversion process.

[0105] Example 2, Figure 4 This is a schematic diagram of the process by which the server generates a second executable program, as provided by the present invention. Figure 4 As shown, the second device is a server, and the instruction set extension information includes at least one instruction set architecture supported by the server and the microarchitecture corresponding to each instruction set architecture. The step of generating a second executable program based on the first intermediate file, the executable program linking commands, and the instruction set extension information includes:

[0106] Step 401: Based on the second analysis tool, the first intermediate file, each instruction set architecture and the microarchitecture corresponding to each instruction set architecture, generate a third intermediate file corresponding to each instruction set architecture.

[0107] Step 402: Based on the executable program linking command, compile each of the third intermediate files to obtain the second executable program corresponding to each instruction set architecture.

[0108] Here, the second analysis tool is a tool for comparing and merging IR attributes with the microarchitectures corresponding to each instruction set structure and instruction set architecture (such as the llvm-attribute-adjust tool). It is used to analyze the attribute set of each instruction set structure and the microarchitecture corresponding to each instruction set architecture and intermediate file, and merge multiple instruction sets and their corresponding microarchitecture attributes into the first intermediate file to generate the third intermediate file.

[0109] After obtaining the third intermediate file, the third intermediate file is compiled and converted according to the executable program linking command to obtain the second executable program corresponding to each instruction set architecture.

[0110] In this embodiment of the invention, a server batch parallel mechanism is used to achieve multi-architecture adaptation and efficient conversion, which greatly improves the conversion efficiency in the cloud environment, meets the needs of large-scale deployment, and provides efficient binary product supply capability for cross-architecture software distribution.

[0111] Furthermore, after compiling each of the third intermediate files based on the executable program linking command to obtain the second executable program corresponding to each instruction set architecture, the method further includes: encapsulating the second executable program corresponding to each instruction set architecture to create a software installation and distribution package, and creating a software repository; in response to the client's call operation in the software repository, sending the software installation and distribution package called by the client to the client, and installing it on the client.

[0112] Here, the software distribution package can be in the RPM format of Red Hat Package Manager (RPM), the DEB format of Debian Package Manager, or any other suitable software distribution format.

[0113] Here, users use software management tools (such as dnf, yum) to invoke and install RPM packages.

[0114] It should be noted that, based on the list of architectures and microarchitectures that the server needs to support (including machine1.bc, machine2.bc, etc.), the second analysis tool (i.e., llvm-attribute-adjust) first analyzes different architectures (machine1, machine2, etc.) and the first intermediate file, converts the first intermediate file, and generates a corresponding new intermediate file, i.e., the third intermediate file. Then, the compiler (such as clang+lld) executes the conversion task in parallel, generating batch optimized executable programs for different target instruction set extensions (such as rv64gc, rv64gcv, etc.) and microarchitectures (such as SiFive U74, Xiangshan Kunminghu, etc.). The generated files are further packaged into specification files for the corresponding architecture, build RPM packages and connect them to the software repository. Different users can call their respective files by calling the tool.

[0115] In another embodiment, the version number of the RPM package and the associated RPM macro definitions automatically include the target's microarchitecture and instruction set information to ensure the uniqueness and clarity of the package, making it easier for users and administrators to identify, install, and manage.

[0116] In this embodiment of the invention, an automated repository building mechanism is implemented by encapsulating the instruction set architecture, which greatly simplifies the software installation process for end users and significantly improves the efficiency of software deployment and distribution in the RISC-V architecture ecosystem. Users no longer need to perform complex LLVM IR local conversions, but can directly obtain finely optimized software packages for specific devices through standard software management tools.

[0117] For example, the RuyiBuild cloud server is used to illustrate the generation of a second executable program:

[0118] First, RuyiBuild automatically scans the specified directory on the cloud server for all packages ending in llvmir.rpm. It then uses RPM tools to automatically batch decompress the RPM packages, extracting the LLVM IR files and associated auxiliary files (such as _cmd files, version scripts, etc.). Next, RuyiBuild automatically calls the LLVM build toolchain to perform batch conversions from LLVM IR to ELF files. The conversion process is based on the original compilation and linking commands recorded in the auxiliary files, automatically performing fine-grained compilation optimizations for different target instruction set extensions and microarchitectures. For example, for different combinations of instruction set extensions or microarchitecture options, RuyiBuild automatically executes batch conversion commands similar to the following:

[0119] # Batch conversion example (for different instruction sets and microarchitectures)

[0120] for rpm_dir in / cloud / llvmir_rpm_extract / ; do

[0121] ir_file=$(find $rpm_dir -name ' .so.bc')

[0122] cmd_file=$(find $rpm_dir -name ' _cmd')

[0123] # Extract the original conversion command

[0124] original_cmd=$(cat $cmd_file)

[0125] # Batch conversion for different instruction set extensions

[0126] for isa in rv64gc rv64gcv; do

[0127] elf_output=${ir_file%.so.bc}.$isa.so

[0128] clang -shared $ir_file -march=$isa -fuse-ld=lld -O3 -o $elf_output

[0129] done

[0130] done

[0131] After completing the batch conversion, RuyiBuild further automatically generates the specification file (spec file) of the RPM package and calls the RPM build tool to generate regular ELF RPM packages in batches.

[0132] Finally, the RuyiBuild toolchain uses RPM repository management tools (such as createrepo) to automatically build RPM repository metadata, forming a standard RPM software repository in the cloud environment. Users or end devices only need to configure the corresponding yum / dnf software repository address to easily install these pre-optimized RPM packages directly through standard software management tools. For example, users can directly install a package with a specific microarchitecture optimized version using the following command:

[0133] # Example of installing DNF on the user's client

[0134] dnf config-manager --add-repo http: / / cloud.example.com / repos / rv64gc /

[0135] dnf install example-package

[0136] The design and implementation of the aforementioned batch RPM conversion and automated repository build mechanism greatly simplifies the software installation process for end users and significantly improves the efficiency of software deployment and distribution within the RISC-V architecture ecosystem. End users no longer need to perform complex LLVM IR local conversions; instead, they can quickly obtain finely optimized software packages for specific devices directly through standard software management tools.

[0137] Regarding the sources of intermediate files and linkers, and in order to be compatible with existing systems, this invention proposes an executable program generation method for use in a second device.

[0138] Figure 5 This is a second flowchart illustrating the executable program generation method provided by the present invention, as shown below. Figure 5 As shown, the method is applied to a second device and includes the following:

[0139] Step 501: Based on the packaging script, call the original compilation command to compile the target software source code twice to obtain the fourth intermediate file and the third executable program corresponding to the target software source code.

[0140] Here, the packaging script is pre-written by the developers and is used to call the original compilation command twice. The first call produces the third executable program, and the second call produces the fourth intermediate file.

[0141] Step 502: Link the fourth intermediate file to obtain the first intermediate file;

[0142] Here, a linker can be used to link the fourth intermediate file to obtain the first intermediate file.

[0143] Step 503: Link the third executable program to obtain the record file corresponding to the first executable program.

[0144] The log file is used to characterize the executable linking commands required when the target software source code is converted into a first executable program.

[0145] Step 504: Send the first intermediate file and the executable program linking command to the first device.

[0146] The first device is used to generate a second executable program based on the first intermediate file, the executable program linking command, and the instruction set extension information corresponding to the second device.

[0147] For example, when the wrapper script recognizes the dynamic linking flag `-shared` in the compilation options, it first calls the native clang commands to generate a traditional ELF-format dynamic link library file. This operation ensures the compatibility and effectiveness of the original build system. Subsequently, RuyiBuild calls the `llvm-link` tool in the LLVM toolchain to merge all the independent LLVM IR bitcode files involved in linking into a single, unified LLVM IR module file. The wrapper script automatically records the original clang dynamic linking commands into a specially generated `_cmd` file; then, the RuyiBuild wrapper script further modifies this `_cmd` file, uniformly replacing all `.o` object file references in the original commands with the newly merged single LLVM IR file, and explicitly specifies the use of the `lld` linker from the LLVM toolchain (by adding the `-fuse-ld=lld` option). In addition, for symbol version control scripts that may be involved in the dynamic linking process (such as the version control script specified by the --version-script option), the wrapper script automatically copies the script file to the LLVM IR output path and uniformly names it as *_verscript file to ensure the consistency and accuracy of symbol version control during the conversion process. This automated script processing mechanism further guarantees the integrity and ease of use of RuyiBuild.

[0148] If the executable is a directly executable program, perform similar processing.

[0149] In its implementation, the wrapper script needs to automatically process various path information in the original compilation commands, especially the paths of output files (specified by the -o option) and auxiliary files, i.e., the paths of the executable linking commands mentioned above (such as dependency files, specified by options like -MF and -MT). If the original path is a relative path (e.g., output.o), the wrapper script automatically obtains the current working directory (CWD) and maps the output path of the LLVM IR file to the directory set by the user through the environment variable LLVMIR_BASEDIR, making the LLVM IR file path $LLVMIR_BASEDIR / $CWD / output.o. When the original path is an absolute path (e.g., / home / ir / pkg / build / output.o), the IR output path is directly mapped to $LLVMIR_BASEDIR / home / ir / pkg / build / output.o. This ingenious path mapping mechanism ensures that the path structure of the LLVM IR file strictly corresponds to that of the traditional compiled files, avoiding file conflicts or path confusion.

[0150] In another embodiment, during the generation of the LLVM IR file, the wrapper script directs detailed log information to a separate .o_log file. If an error occurs during the LLVM IR compilation process, the wrapper script automatically deletes the previously generated traditional ELF file and immediately terminates the compilation, allowing the original build system to promptly detect the error and stop the build. This mechanism ensures RuyiBuild's complete transparency and high compatibility with the original build system.

[0151] In this embodiment of the invention, when the hardware of the first device is updated or its function is changed, the first device can regenerate the executable program using intermediate files, executable program linking commands, and instruction set extension information, so that the executable file is adapted to the changed hardware. Compared with methods such as modifying the compiler, creating plugins, compiling multiple versions at the same time, or compiling the target software source code on the client machine, this method reduces the complexity of the software without modifying the target software source code and the original build system, and ensures that the device can operate normally when all versions of hardware change, thus achieving software compatibility on all versions of hardware.

[0152] The executable program generation apparatus provided by the present invention will be described below. The executable program generation apparatus described below can be referred to in correspondence with the executable program generation method described above.

[0153] Figure 6 This is a schematic diagram of the structure of the first executable program generation device provided by the present invention, as shown below. Figure 6 As shown, the first executable program generation device 600 includes the following modules:

[0154] The acquisition module 610 is used to acquire a first intermediate file corresponding to the target software source code sent by the second device and a record file corresponding to the target software source code; the record file is used to characterize the executable program linking commands required when the target software source code is converted into a first executable program.

[0155] The generation module 620 is used to generate a second executable program based on the first intermediate file, the executable program linking command, and the instruction set extension information corresponding to the second device.

[0156] In another embodiment, the second device is a client, and the generation module 620 is specifically used to: generate an intermediate template file based on the instruction set extension information and empty function template file of the client; adjust the first intermediate file based on the intermediate template file and a first analysis tool to obtain a second intermediate file; and compile the second intermediate file based on the executable program linking command to obtain the second executable program.

[0157] In another embodiment, the generation module 620 is further configured to: determine a first configuration corresponding to the target instruction set architecture and a second configuration corresponding to the microarchitecture based on the target instruction set architecture and microarchitecture of the client; determine the environment variables and specified path of the client; and compile the second intermediate file based on the first configuration, the second configuration, the environment variables, the specified path and the executable program linking command to obtain the second executable program.

[0158] In another embodiment, the generation module 620 is further configured to: pause the compilation of the second intermediate file if the resource usage of the client is detected to be higher than the resource threshold during the compilation of the second intermediate file; resume the compilation of the second intermediate file if the resource usage of the client is detected to be lower than or equal to the resource threshold; and continue to compile the second intermediate file based on the first configuration, the second configuration, the environment variables, the specified path, and the executable program linking command to obtain the second executable program.

[0159] In another embodiment, the second device is a server, and the instruction set extension information includes at least one instruction set architecture supported by the server and the microarchitecture corresponding to each instruction set architecture. The generation module 620 is further specifically used to: generate a third intermediate file corresponding to each instruction set architecture based on the second analysis tool, the first intermediate file, each instruction set architecture, and the microarchitecture corresponding to each instruction set architecture; and compile each third intermediate file based on the executable program linking command to obtain a second executable program corresponding to each instruction set architecture.

[0160] In another embodiment, after compiling each of the third intermediate files based on the executable linking command to obtain the second executable program corresponding to each of the instruction set architectures, the first executable program generation device 600 further includes a building module, specifically used for: packaging the second executable program corresponding to each of the instruction set architectures to create a software installation and distribution package, and creating a software repository; responding to the client's call operation in the software repository, sending the software installation and distribution package called by the client to the client, and installing it on the client.

[0161] Figure 7 This is a schematic diagram of the structure of the second executable program generation device provided by the present invention, as shown below. Figure 7 As shown, the second executable program generation device 700 includes the following modules:

[0162] The compilation module 710 is used to compile the target software source code twice by calling the original compilation command based on the packaging script, so as to obtain a fourth intermediate file and a third executable program corresponding to the target software source code.

[0163] The first linking module 720 is used to link the fourth intermediate file to obtain the first intermediate file;

[0164] The second linking module 730 is used to link the third executable program to obtain a record file corresponding to the first executable program; the record file is used to characterize the executable program linking commands required when the target software source code is converted into the first executable program;

[0165] The sending module 740 is used to send the first intermediate file and the executable program linking command to the first device, and the first device is used to generate a second executable program based on the first intermediate file, the executable program linking command and the instruction set extension information corresponding to the second device.

[0166] Figure 8 This is a schematic diagram of the structure of the electronic device provided by the present invention, such as... Figure 8 As shown, the electronic device may include: a processor 810, a communications interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communications interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 can call logical instructions in the memory 830 to execute an executable program generation method. This method includes: obtaining a first intermediate file corresponding to the target software source code sent by a second device and a record file corresponding to the target software source code; the record file is used to characterize the executable program linking commands required when the target software source code is converted into a first executable program; generating a second executable program based on the first intermediate file, the executable program linking commands, and instruction set extension information corresponding to the second device; and / or:

[0167] Based on the packaging script, the target software source code is compiled twice using the original compilation commands to obtain a fourth intermediate file and a third executable program corresponding to the target software source code. The fourth intermediate file is linked to obtain a first intermediate file. The third executable program is linked to obtain a log file corresponding to the first executable program. The log file is used to characterize the executable program linking commands required when the target software source code is converted into the first executable program. The first intermediate file and the executable program linking commands are sent to a first device, which generates a second executable program based on the first intermediate file, the executable program linking commands, and the instruction set extension information corresponding to the second device.

[0168] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0169] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program, which can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer is able to execute the executable program generation method provided by the above methods. The method includes: obtaining a first intermediate file corresponding to the target software source code sent by a second device and a record file corresponding to the target software source code; the record file being used to characterize the executable program linking commands required when the target software source code is converted into a first executable program; generating a second executable program based on the first intermediate file, the executable program linking commands, and instruction set extension information corresponding to the second device; and / or:

[0170] Based on the packaging script, the target software source code is compiled twice using the original compilation commands to obtain a fourth intermediate file and a third executable program corresponding to the target software source code. The fourth intermediate file is linked to obtain a first intermediate file. The third executable program is linked to obtain a log file corresponding to the first executable program. The log file is used to characterize the executable program linking commands required when the target software source code is converted into the first executable program. The first intermediate file and the executable program linking commands are sent to a first device, which generates a second executable program based on the first intermediate file, the executable program linking commands, and the instruction set extension information corresponding to the second device.

[0171] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements an executable program generation method provided by the above methods. This method includes: acquiring a first intermediate file corresponding to target software source code sent by a second device and a record file corresponding to the target software source code; the record file being used to characterize executable program linking commands required when the target software source code is converted into a first executable program; generating a second executable program based on the first intermediate file, the executable program linking commands, and instruction set extension information corresponding to the second device; and / or:

[0172] Based on the packaging script, the target software source code is compiled twice using the original compilation commands to obtain a fourth intermediate file and a third executable program corresponding to the target software source code. The fourth intermediate file is linked to obtain a first intermediate file. The third executable program is linked to obtain a log file corresponding to the first executable program. The log file is used to characterize the executable program linking commands required when the target software source code is converted into the first executable program. The first intermediate file and the executable program linking commands are sent to a first device, which generates a second executable program based on the first intermediate file, the executable program linking commands, and the instruction set extension information corresponding to the second device.

[0173] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0174] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0175] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for generating an executable program, characterized in that, Applied to the first device, including: Obtain the first intermediate file corresponding to the target software source code sent by the second device and the record file corresponding to the target software source code; the record file is used to characterize the executable program linking commands required when the target software source code is converted into the first executable program; A second executable program is generated based on the first intermediate file, the executable program linking command, and the instruction set extension information corresponding to the second device; The second device is a server, and the instruction set extension information includes at least one instruction set architecture supported by the server and the microarchitecture corresponding to each instruction set architecture. The step of generating a second executable program based on the first intermediate file, the executable program linking commands, and the instruction set extension information includes: Based on the second analysis tool, the first intermediate file, each instruction set architecture and the microarchitecture corresponding to each instruction set architecture, a third intermediate file corresponding to each instruction set architecture is generated; the second analysis tool is used to analyze the attribute set of each instruction set architecture and the microarchitecture corresponding to each instruction set architecture and the first intermediate file, and merge multiple instruction sets and corresponding microarchitecture attributes into the first intermediate file to generate the third intermediate file. Based on the executable linking commands, each of the third intermediate files is compiled to obtain a second executable program corresponding to each instruction set architecture.

2. The executable program generation method according to claim 1, characterized in that, The second device is a client. The step of generating a second executable program based on the first intermediate file, the executable program linking commands, and the instruction set extension information corresponding to the second device includes: Based on the instruction set extension information and empty function template file of the client, an intermediate template file is generated; Based on the intermediate template file and the first analysis tool, the first intermediate file is adjusted to obtain the second intermediate file; Based on the executable linking command, the second intermediate file is compiled to obtain the second executable program.

3. The executable program generation method according to claim 2, characterized in that, The step of compiling the second intermediate file based on the executable linking command to obtain the second executable program includes: Based on the target instruction set architecture and microarchitecture of the client, determine the first configuration corresponding to the target instruction set architecture and the second configuration corresponding to the microarchitecture; Determine the client's environment variables and specified path; Based on the first configuration, the second configuration, the environment variables, the specified path, and the executable program linking command, the second intermediate file is compiled to obtain the second executable program.

4. The executable program generation method according to claim 3, characterized in that, The process of compiling the second intermediate file based on the first configuration, the second configuration, the environment variables, the specified path, and the executable program linking command to obtain the second executable program includes: If, during the compilation of the second intermediate file, the resource usage of the client is detected to be higher than the resource threshold, the compilation of the second intermediate file is paused. If the resource usage of the client is detected to be lower than or equal to the resource threshold, the compilation of the second intermediate file is resumed; The second intermediate file is then compiled based on the first configuration, the second configuration, the environment variables, the specified path, and the executable linking command to obtain the second executable program.

5. The executable program generation method according to claim 1, characterized in that, After compiling each of the third intermediate files based on the executable program linking commands to obtain the second executable program corresponding to each instruction set architecture, the method further includes: The second executable program corresponding to each instruction set architecture is packaged to create a software installation and distribution package, and a software repository is created. In response to a client's call operation in the software repository, the software installation and distribution package invoked by the client is sent to the client and installed on the client.

6. A method for generating an executable program, characterized in that, Applied to a second device, including: Based on the packaging script, the original compilation command is called to compile the target software source code twice, resulting in a fourth intermediate file and a third executable program corresponding to the target software source code. Link the fourth intermediate file to obtain the first intermediate file; The third executable program is linked to obtain a log file corresponding to the first executable program; the log file is used to characterize the executable program linking commands required when the target software source code is converted into the first executable program; The first intermediate file and the executable program linking command are sent to a first device. The first device generates a second executable program based on the first intermediate file, the executable program linking command, and the instruction set extension information corresponding to the second device. The second device is a server. The instruction set extension information includes at least one instruction set architecture supported by the server and the microarchitecture corresponding to each instruction set architecture. The first device generates a third intermediate file corresponding to each instruction set architecture based on a second analysis tool, the first intermediate file, each instruction set architecture, and the microarchitecture corresponding to each instruction set architecture. The second analysis tool analyzes the attribute set of each instruction set architecture and its corresponding microarchitecture with the attribute set of the first intermediate file, merging multiple instruction sets and their corresponding microarchitecture attributes into the first intermediate file to generate a third intermediate file. Based on the executable program linking command, each third intermediate file is compiled to obtain the second executable program corresponding to each instruction set architecture.

7. An executable program generation apparatus, characterized in that, include: The acquisition module is used to acquire the first intermediate file corresponding to the target software source code sent by the second device and the record file corresponding to the target software source code; The log file is used to characterize the executable linking commands required when the target software source code is converted into a first executable program; A generation module is used to generate a second executable program based on the first intermediate file, the executable program linking command, and the instruction set extension information corresponding to the second device, wherein the second device is a server, and the instruction set extension information includes at least one instruction set architecture supported by the server and the microarchitecture corresponding to each instruction set architecture. Based on a second analysis tool, the first intermediate file, each instruction set architecture, and the microarchitecture corresponding to each instruction set architecture, a third intermediate file corresponding to each instruction set architecture is generated. The second analysis tool is used to analyze the attribute set of each instruction set architecture and its corresponding microarchitecture with the attribute set of the first intermediate file, merging multiple instruction sets and their corresponding microarchitecture attributes into the first intermediate file to generate a third intermediate file. Based on the executable program linking command, each of the third intermediate files is compiled to obtain the second executable program corresponding to each instruction set architecture.

8. An executable program generation apparatus, characterized in that, include: The compilation module is used to compile the target software source code twice by calling the original compilation commands based on the packaging script, so as to obtain a fourth intermediate file and a third executable program corresponding to the target software source code. The first linking module is used to link the fourth intermediate file to obtain the first intermediate file; The second linking module is used to link the third executable program to obtain a record file corresponding to the first executable program; the record file is used to characterize the executable program linking commands required when the target software source code is converted into the first executable program; A sending module is used to send the first intermediate file and the executable program linking command to a first device. The first device is used to generate a second executable program based on the first intermediate file, the executable program linking command, and instruction set extension information corresponding to the second device. The second device is a server, and the instruction set extension information includes at least one instruction set architecture supported by the server and the microarchitecture corresponding to each instruction set architecture. The first device is used to generate a third intermediate file corresponding to each instruction set architecture based on a second analysis tool, the first intermediate file, each instruction set architecture, and the microarchitecture corresponding to each instruction set architecture. The second analysis tool is used to analyze the attribute set of each instruction set architecture and the corresponding microarchitecture of each instruction set architecture with the attribute set of the first intermediate file, merge multiple instruction sets and their corresponding microarchitecture attributes into the first intermediate file, and generate a third intermediate file. Based on the executable program linking command, each of the third intermediate files is compiled to obtain the second executable program corresponding to each instruction set architecture.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the executable program generation method as described in any one of claims 1 to 5 or 6.

Images