A method and apparatus for generating a software system for debugging

Abstract

The application discloses a generation method of a software system for debugging. GN is used to generate a Ninja build file for a current software system, and a link response file is generated when the Ninja build file is required to build. Ninja is used as a build tool for the current software system, and the modified Ninja build file is used for building. A target path is newly created, and a linker script, a link response file, static library files and object files listed in the link response file in the current software system are copied to the target path. Absolute paths of all object files and static library files recorded in the link response file in the target path are updated. A CMake special configuration file is modified, and all directories and files in the target path constitute a software system for debugging. The application generates a simplified software system for debugging from an originally huge software system, and the copyright is protected.

Description

Technical Field

[0001] This invention relates to a method and apparatus for rapidly generating software systems for debugging. Background Technology

[0002] Build refers to the process of transforming source files into executable files using automated tools, mainly including compilation and linking steps. Compilation involves converting human-readable source files into machine-readable object files. Multiple object files can be integrated into a library file, specifically divided into static libraries and dynamic libraries. Linking involves integrating multiple object files and library files into an executable file or a shared library. The linker script file is used to instruct the linker on how to work.

[0003] CMake is a software development tool used to build applications. It is cross-platform (Windows, Linux, macOS) and compiler-independent. CMake generates build files for other build tools based on its configuration file CMakeLists.txt, and these build tools then execute their build processes according to these build files. Supported build tools include Make and Ninja.

[0004] Make is a software build tool whose configuration file is a text file called Makefile, which describes the dependencies between source files and the build rules. Make uses these dependencies and build rules to determine which files need to be recompiled and executes the corresponding compilation commands to ensure that an executable file or other object file is generated in the end.

[0005] Ninja is a small, fast software build system. Ninja build files are typically generated by build management tools such as CMake and GN (Generate-Ninja). Ninja build files have the .ninja extension. The Toolchain.ninja file is a core Ninja build file used to specify toolchain-related settings such as compiler, linker, and build flags. BUILD.gn is the GN build description file.

[0006] When building software using Ninja, the linking step involves parameters for the linker commands, including the input object files, the library files to be linked, and the library search paths. If the linker command has few parameters, below the operating system's command line length limit, all parameters are listed directly in the command line. If the linker command has many parameters, exceeding the operating system's command line length limit, a linker response file is used to record all parameters, and this response file is referenced in the command line.

[0007] For an embedded product—such as a smartwatch—software project, Ninja is often chosen as the build tool to maximize build speed, and GN is used to generate Ninja build files. Embedded products also utilize hardware modules from third-party vendors, such as GPUs (graphics processors) and various sensors. The main functionality of these hardware modules is implemented in firmware, and the provided software code is relatively simple, mostly consisting of static libraries and header files. Because the software code is minimal, third-party vendors typically choose CMake to generate Make configuration files and Make as the build tool. When embedded software development encounters problems, the embedded product manufacturer needs to provide the third-party vendor with the embedded product hardware and embedded software systems for debugging, enabling both parties to jointly debug and resolve issues.

[0008] Please see Figure 1 Existing methods for generating software systems for debugging include the following steps.

[0009] Step S11: Copy the entire software system's source code (C files), compilation scripts, and GN's build description file BUILD.gn to the target path. This target path is newly created for the purpose of developing and debugging software code for third-party vendors.

[0010] Step S12: Modify the compilation script of the source code to store the compilation results of the source code—object files and static library files—into the target path.

[0011] Step S13: Modify the GN build description file BUILD.gn to generate an executable file directly using object files and static libraries instead of using source code to generate a static library.

[0012] Step S14: Provide the source code, modified compilation script, and modified GN build description file BUILD.gn from the target path to the third-party vendor.

[0013] The drawback of the above method is that some files copied to the target path in step S11 contain trade secrets or technical secrets, such as customer names, chip names, and hardware module performance data. Manual processing of these is time-consuming and unsustainable. Furthermore, some third-party vendors do not use Ninja as their build tool and require a Make configuration file. Summary of the Invention

[0014] The technical problem to be solved by this invention is: how to generate a software system for debugging that contains only the library files and object files necessary for the recipient, without exposing unnecessary information to the recipient.

[0015] To address the aforementioned technical problems, this invention proposes a method for generating a software system for debugging, comprising the following steps: Step S21: Using GN to generate a Ninja build file for the current software system, modifying the Ninja build file to require the generation of a linker response file during the build process, and limiting the linker response file to only contain the names and absolute paths of the object files used to generate the executable file and the linked static library files. Step S22: Using Ninja as the build tool for the current software system, build based on the modified Ninja build file; after the build, multiple object files are obtained, some of which are integrated into static library files; after the build, a linker response file is also obtained, which records the names and absolute paths of the linked object files and static library files. Step S23: Create a new target path, and according to the absolute paths of each static library file and object file recorded in the linker response file, copy the linker script, the linker response file, the static library files listed in the linker response file, and the object files in the current software system to the target path. Step S24: Based on the new locations of all copied static library files and object files in the target path, update the absolute paths of all object files and static library files recorded in the link response file in the target path. Step S25: Modify the CMake configuration file to require that the updated link response file in the target path be called before linking, and to require that the linking be performed in the order of the object files and static library files in the updated link response file in the target path. It also requires that the executable file be generated directly using the object files and static library files in the target path. The modified CMake configuration file is stored in the target path. All directories and files in the target path constitute the software system used for debugging.

[0016] Furthermore, in step S21, the Ninja build file is modified to restrict the linking response file from including the name and path of the standard library.

[0017] Furthermore, in step S22, the order of the object files and static library files in the link response file is the linking order, which reflects the dependencies during linking.

[0018] Further, in step S23, an SDK script is constructed to automatically parse the link response file and obtain the absolute path of each static library file and object file; the linker script, link response file, static library files and object files listed in the link response file in the current software system are automatically copied to the target path.

[0019] Further, in step S23, the target path is represented by / ; the linker script in the current software system is copied to the root directory / of the target path, the link response file in the current software system is copied to the first-level directory / sdk under the target path; all static library files are copied to the second-level directory / sdk / libs under the target path, and all object files are copied to the second-level directory / sdk / objs under the target path.

[0020] Furthermore, step S24 is executed automatically by the build script, and when updating the link response file in the target path, the order of the target file and the static library file recorded in the link response file remains unchanged.

[0021] Furthermore, after step S25 is completed, the software system used for debugging is provided to a third-party vendor. The third-party vendor uses CMake and, based on the modified CMake-specific configuration file CMakeLists.txt, generates a Make configuration file. Then, using Make as the build tool, based on the Make configuration file, the build process is completed, and an executable file is generated.

[0022] Furthermore, the current software system is designated as the first project, and the software system used for debugging is designated as the second project. The first project is a complete embedded product software system, including source code, using Ninja as the build tool, and GN to generate Ninja build files. The second project is a simplified embedded product software system for debugging, without source code, using Make as the build tool, and CMake to generate Make configuration files.

[0023] Furthermore, the construction process of the first project includes compiling source files into object files, integrating object files into static library files, and linking object files and static library files into an executable file; the construction process of the second project only includes linking object files and static library files into an executable file, and does not include compiling source files into object files, nor does it include integrating object files into static library files.

[0024] This invention also proposes a software system generation device for debugging, including a Ninja build file modification unit, a Ninja build unit, a target path copying unit, a linker response file updating unit, and a CMake-specific configuration file modification unit. The Ninja build file modification unit is used to generate Ninja build files for the current software system using GN, modifying the Ninja build files to require the generation of a linker response file during the build process, and limiting the linker response file to only contain the names and absolute paths of the object files used to generate the executable file and the linked static library files. The Ninja build unit is used to build the current software system using Ninja as the build tool, based on the modified Ninja build files; after building, multiple object files are obtained, some of which are integrated into static library files; a linker response file is also obtained after building, which records the names and absolute paths of the linked object files and static library files. The target path copying unit is used to create a new target path, obtain the absolute paths of each static library file and object file according to the linker response file, and copy the linker script, linker response file, and static library files and object files listed in the linker response file from the current software system to the target path. The link response file update unit is used to update the absolute paths of all object files and static library files recorded in the link response file in the target path according to the new locations of all copied static library files and all object files in the target path. The CMake dedicated configuration file modification unit is used to modify the CMake dedicated configuration file, which requires that the updated link response file in the target path must be called before linking, and also requires that the linking must be performed in the order of object files and static library files in the updated link response file in the target path, and also requires that the executable file be generated directly using the object files and static library files in the target path; the modified CMake dedicated configuration file is stored in the target path; all directories and files in the target path constitute the software system for debugging.

[0025] The technical advantages achieved by this invention are as follows: By making minor modifications to the Ninja build files and adding script files, a simplified software system (second project) containing only static library files and object files is generated from the originally large software system (first project) for debugging. The second project simplifies the directory structure of the first project but retains the dependencies between library files and object files, and does not expose the structure of the first project to the client. This ensures that the second project can be correctly compiled and linked in the new compilation environment, facilitates rapid development for the client, greatly improves efficiency for both parties, and protects copyright. Attached Figure Description

[0026] Figure 1This is a flowchart illustrating existing software methods used for debugging.

[0027] Figure 2 This is a flowchart illustrating the method for generating a software system for debugging proposed in this invention.

[0028] Figure 3 This is a schematic diagram of the directory structure of the first project (a complete embedded software system) proposed in this invention.

[0029] Figure 4 This is a schematic diagram of the directory structure of the second project (software system for debugging) proposed in this invention.

[0030] Figure 5 This is a schematic diagram of the structure of the software system generation device for debugging proposed in this invention.

[0031] The attached figures are labeled as follows: Ninja build file modification unit 21, Ninja build unit 22, target path copying unit 23, link response file update unit 24, and CMake-specific configuration file modification unit 25. Detailed Implementation

[0032] Please see Figure 2 The method for generating a software system for debugging proposed in this invention includes the following steps.

[0033] Step S21: Designate the current software system as the first project. The first project is a complete embedded software system project. Use GN to generate Ninja build files for the current software system. Modify the Ninja build files—for example, modify Toolchain.ninja—to require the generation of a linker response file during the build process. Limit the linker response file to only include the names and absolute paths of the object files used to generate the executable and the linked static library files; do not include the name and path of the standard library. Since the computers used for building can provide standard libraries, it is unnecessary to include the name and path of the standard library, thus reducing the code size of the software system used for debugging.

[0034] Step S22: Use Ninja as the build tool for the current software system and build it based on the modified Ninja build file. After building, multiple object files are obtained, some of which are integrated into static library files. A link response file is also obtained after building, which records the names and absolute paths of the linked object files and static library files. The order of the object files and static library files in the link response file indicates the linking order, reflecting the dependencies during linking.

[0035] Step S23: Create a new target path – This is a directory, for example, represented by " / ". The contents of the target path will serve as the second project. The second project is a software system provided to a third-party vendor for debugging the behavior of the third-party vendor's software code (e.g., library files) in the embedded software system. The SDK (Software Development Kit) script is built to automatically parse the linker response file, obtaining the absolute paths of each static library file and object file; it automatically copies the linker script, linker response file, and the static library files and object files listed in the linker response file from the current software system to the target path.

[0036] In this step, the object files and static library files listed in the current software system's link response file—that is, the object files used to generate the executable file and the linked static library files—need to be copied from the current software system to the target path. Object files and static library files not listed in the current software system's link response file do not need to be copied to the target path. It is important to note that this step does not copy the current software system's source code to the target path; therefore, any trade secrets or technical secrets contained in the source code will not be leaked.

[0037] As an example, the linker scripts in the current software system are copied to the root directory ` / ` of the target path; the linker response files in the current software system are copied to the first-level directory ` / sdk` under the target path; all static library files are copied to the second-level directory ` / sdk / libs` under the target path; and all object files are copied to the second-level directory ` / sdk / objs` under the target path. In this example, the directory structure itself is the root directory ` / `, with one first-level directory ` / sdk`, two second-level directories ` / sdk / libs` and ` / sdk / objs`, and no further subdirectories. Compared to the current software system, the directory hierarchy under the target path is simplified.

[0038] Step S24: Based on the new locations of all copied static library files and object files in the target path, update the absolute paths of all object files and static library files recorded in the link response file in the target path. This can be automated by the build script, ensuring that the order of object files and static library files recorded in the link response file is not changed during the update. At this point, there is one link response file in the current software system and another copied link response file in the target path. This step does not modify the former, only the latter.

[0039] Step S25: Modify the CMake-specific configuration file CMakeLists.txt to require that the updated linker response file in the target path must be called before linking, and that the linking process must be performed in the order of object files and static library files in the updated linker response file in the target path. This resolves dependency issues. It also requires that the executable file be generated directly using object files and static library files in the target path. The modified CMakeLists.txt configuration file is placed in the target path. At this point, the second project is complete, and all directories and files in the target path constitute the software system for debugging.

[0040] The software system used for debugging is provided to a third-party vendor. The third-party vendor uses CMake and generates a Make configuration file based on the modified CMake-specific configuration file CMakeLists.txt. Then, it uses Make as the build tool and, based on the Make configuration file, completes the build process and generates an executable file.

[0041] After a third-party vendor modifies its software code—for example, by adding debugging information—it copies the generated new static library file to the static library directory of the second project—corresponding to / sdk / libs in the example. The new static library file replaces the old one. The third-party vendor then recompiles and links based on the new static library file to generate a new executable file. Loading the new executable file on the embedded product will display the debugging results. Once debugging is complete, the third-party vendor provides the new static library file to the embedded product manufacturer.

[0042] This invention proposes separate management of the code for a complete software system (first project) and a simplified software system for debugging (second project).

[0043] The first project is a complete embedded product software system, including source code. It uses Ninja as the build tool and GN to generate Ninja build files, supporting rapid compilation of large source code.

[0044] Please see Figure 3This is an example of the first project. The first project includes Ninja build files (such as Toolchain.ninja), linker scripts, object files in the output directory, static library files and link response files, SDK scripts for parsing and copying, and various module directories. All module directories are divided into two categories: open-source module directories and closed-source module directories. Open-source modules refer to code developed by embedded product manufacturers; for embedded product manufacturers, this is open-source code. Closed-source modules refer to code provided by third-party hardware module manufacturers to embedded product manufacturers; for embedded product manufacturers, this is closed-source code. The open-source module directory contains C source code files, header files, and the GN build descriptor file BUILD.gn. The closed-source module directory contains static library files, header files, and the GN build descriptor file BUILD.gn provided by third-party manufacturers.

[0045] The second project is a simplified software system for embedded products used for debugging. It does not contain source code, uses Make as the build tool, and uses CMake to generate Make configuration files, which has better versatility.

[0046] Please see Figure 4 This is an example of the second project, with Figure 3 The example in the first project shown has a corresponding relationship. The second project includes a linker script, linker response files in the sdk directory, libs and objs directories, a script for updating the linker response files, and a CMake-specific configuration file CMakeLists.txt. The libs directory contains static library files. The objs directory contains object files.

[0047] Compare Figure 3 and Figure 4 It can be observed that the second project removed all module directories from the first project, which means removing all the source code from the first project. The second project also removed Ninja and GN-related files, replacing them with CMake-specific configuration files.

[0048] The executable file generated by the second project has the same running effect as the executable file generated by the first project. The difference is that the first project's build process includes compiling the source files into object files, integrating the object files into a static library file, and linking the object files and static library files into an executable file. The second project's build process only includes linking the object files and static library files into an executable file; it does not include compiling the source files into object files or integrating the object files into a static library file, thus saving the time spent compiling the object files and static library files.

[0049] Please see Figure 5 The software system generation device for debugging proposed in this invention includes a Ninja build file modification unit 21, a Ninja build unit 22, a target path copying unit 23, a link response file updating unit 24, and a CMake dedicated configuration file modification unit 25. Figure 5 The device shown corresponds to Figure 2 The method shown.

[0050] The Ninja build file modification unit 21 is used to generate Ninja build files for the current software system using GN, modify the Ninja build file to require the generation of a link response file during the build, and limit the link response file to only contain the names and absolute paths of the object files used to generate the executable file and the linked static library files.

[0051] The Ninja build unit 22 is used to build the current software system using Ninja as the build tool, based on the modified Ninja build files. After building, multiple object files are obtained, some of which are integrated into static library files. A link response file is also obtained after building, which records the names and absolute paths of the linked object files and static library files.

[0052] The target path copying unit 23 is used to create a new target path, obtain the absolute path of each static library file and target file according to the link response file, and copy the linker script, link response file, static library files and target files listed by the link response file in the current software system to the target path.

[0053] The link response file update unit 24 is used to update the absolute paths of all target files and static library files recorded in the link response file in the target path according to the new positions of all copied static library files and all target files in the target path.

[0054] The CMake-specific configuration file modification unit 25 is used to modify the CMake-specific configuration file CMakeLists.txt, restricting the linking process to calling the updated link response file in the target path before linking, and further restricting the linking to be performed in the order of object files and static library files in the updated link response file in the target path. It also restricts the use of object files and static library files in the target path to directly generate the executable file. The modified CMake-specific configuration file CMakeLists.txt is stored in the target path. All directories and files in the target path constitute the software system used for debugging.

[0055] Compared with the prior art, the method for constructing a software system for debugging proposed in this invention has the following beneficial effects.

[0056] First, the software system for debugging constructed in this invention does not contain any source files, thus avoiding the risk of leaking or exposing trade secrets or technical secrets.

[0057] Secondly, this invention only modifies the Ninja build file of the current software system (first project), adds SDK scripts for parsing and copying, adds scripts for updating link response files and CMake-specific configuration file CMakeLists.txt in the target path, and achieves the goal of generating a software system for debugging (second project) with very little new code, which is simple and fast.

[0058] Third, the linker response file in the Ninja build tool was originally used to solve the command line length limitation problem. This invention cleverly uses the linker response file to pass the interdependencies during linking, ensuring that the Make build tool strictly maintains the file dependencies under the Ninja build tool. The software system built by this invention for debugging includes a CMake-specific configuration file CMakeLists.txt, which can be used to generate configuration files for other build tools, thus allowing third-party vendors to use the Make build tool, resulting in better versatility and compatibility.

[0059] The above are merely preferred embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for generating a software system for debugging, characterized in that, Includes the following steps; Step S21: Use GN to generate Ninja build files for the current software system, modify the Ninja build file to require the generation of a link response file during the build process, and limit the link response file to only contain the names and absolute paths of the object files used to generate the executable file and the linked static library files; Step S22: Use Ninja as the build tool for the current software system and build it based on the modified Ninja build file; after the build, multiple target files are obtained, some of which are integrated into static library files; after the build, a link response file is also obtained, which records the names and absolute paths of the linked target files and static library files; Step S23: Create a new target path. Based on the absolute paths of each static library file and object file recorded in the link response file, copy the linker script, link response file, static library files and object files listed in the link response file from the current software system to the target path. Step S24: Based on the new locations of all copied static library files and all object files in the target path, update the absolute paths of all object files and static library files recorded in the link response file in the target path; Step S25: Modify the CMake configuration file to require that the updated link response file in the target path must be called before linking, and to require that the linking be performed in the order of the object files and static library files in the updated link response file in the target path. It also requires that the executable file be generated directly using the object files and static library files in the target path. The modified CMake configuration file is stored in the target path. All directories and files in the target path constitute the software system for debugging.

2. The method for generating a software system for debugging according to claim 1, characterized in that, In step S21, the Ninja build file is modified to restrict the linking response file from including the name and path of the standard library.

3. The method for generating a software system for debugging according to claim 1, characterized in that, In step S22, the order of the object files and static library files in the link response file is the linking order, which reflects the dependencies during linking.

4. The method for generating a software system for debugging according to claim 1, characterized in that, In step S23, an SDK script is constructed to automatically parse the link response file and obtain the absolute path of each static library file and object file; the linker script, link response file, static library files and object files listed in the link response file in the current software system are automatically copied to the target path.

5. The method for generating a software system for debugging according to claim 1, characterized in that, In step S23, the target path is represented by / ; the linker script in the current software system is copied to the root directory / of the target path, the link response file in the current software system is copied to the first-level directory / sdk under the target path; all static library files are copied to the second-level directory / sdk / libs under the target path, and all object files are copied to the second-level directory / sdk / objs under the target path.

6. The method for generating a software system for debugging according to claim 1, characterized in that, Step S24 is executed automatically by the build script, and when updating the link response file in the target path, the order of the target file and the static library file recorded in the link response file remains unchanged.

7. The method for generating a software system for debugging according to claim 1, characterized in that, After step S25 is completed, the software system used for debugging is provided to a third-party vendor. The third-party vendor uses CMake and, based on the modified CMake-specific configuration file CMakeLists.txt, generates a Make configuration file. Then, using Make as the build tool, based on the Make configuration file, the build process is completed, and an executable file is generated.

8. The method for generating a software system for debugging according to claim 1, characterized in that, The current software system is designated as the first project, and the software system used for debugging is designated as the second project. The first project is a complete embedded product software system, including source code, using Ninja as the build tool and GN to generate Ninja build files; The second project is a simplified software system for embedded products used for debugging. It does not contain source code, uses Make as the build tool, and uses CMake to generate Make configuration files.

9. The method for generating a software system for debugging according to claim 8, characterized in that, The construction process of the first project includes compiling source files into object files, integrating object files into static library files, and linking object files and static library files into an executable file; the construction process of the second project only includes linking object files and static library files into an executable file, and does not include compiling source files into object files or integrating object files into static library files.

10. An apparatus for generating a software system for debugging, characterized in that, Includes Ninja build file modification unit, Ninja build unit, target path copying unit, link response file update unit, and CMake-specific configuration file modification unit; The Ninja build file modification unit is used to generate Ninja build files for the current software system using GN, modify the Ninja build files to require the generation of a link response file during the build process, and limit the link response file to only contain the names and absolute paths of the object files used to generate the executable file and the linked static library files; The Ninja build unit is used to build the current software system using Ninja as the build tool, based on the modified Ninja build file; after the build, multiple target files are obtained, some of which are integrated into static library files; after the build, a link response file is also obtained, which records the names and absolute paths of the linked target files and static library files; The target path copying unit is used to create a new target path, obtain the absolute path of each static library file and target file according to the link response file, and copy the linker script, link response file, static library files and target files listed by the link response file in the current software system to the target path. The link response file update unit is used to update the absolute paths of all target files and static library files recorded in the link response file in the target path according to the new positions of all copied static library files and all target files in the target path; The CMake-specific configuration file modification unit is used to modify the CMake-specific configuration file, which requires that the updated link response file in the target path must be called before linking, and also requires that the linking be performed in the order of the object files and static library files in the updated link response file in the target path. It also requires that the executable file be generated directly using the object files and static library files in the target path. The modified CMake-specific configuration file is stored in the target path. All directories and files in the target path constitute the software system for debugging.

Images