CN112052007A - Source code debugging method, device, server and storage medium - Google Patents

Abstract

The present disclosure relates to a source code debugging method, device, server and storage medium. The source code debugging method includes: obtaining a compiled file of a target static library in a target project, and the compiled file is obtained by compiling a first source code file; parsing the compiled file to obtain a first storage path of the first source code file, the first storage path The path is the storage path when the first source code file is compiled into a compiled file; a second storage path that is the same as the first storage path is created in the local device; the second source code file is stored in the second storage path, and the second source code file passes through Obtained by parsing the configuration file of the target static library; reading the second source code file based on the second storage path to debug the second source code file. The source code debugging method, device, server and storage medium provided by the present disclosure can solve the problem of inconvenient reading and debugging of source code when using static library integration.

Description

Source code debugging method, device, server and storage medium

technical field

The present disclosure relates to the field of communication technologies, and in particular, to an information processing method, device, server, and storage medium.

Background technique

With the gradual complexity and diversification of computer development projects, the problem of slow project compilation has become more and more obvious. The industry has proposed many compilation and optimization schemes, among which static library integration is widely used due to its simple operation and rapid compilation.

However, a static library is a compiled file. When debugging a program, developers can only see computer code instructions in the form of assembly. Program debugging is a process of compiling the source code to find the location of errors and dislocations, while static libraries are not It supports source code debugging, which brings a lot of inconvenience to the debugging work of developers.

At present, among related technologies, in order to facilitate the reading of source code and debugging, developers would rather use a source code integration solution with a slower compilation speed than a static library integration solution that can greatly improve the compilation speed, so that the static library integration does not play its role. some effect.

SUMMARY OF THE INVENTION

The present disclosure provides a source code debugging method, device, server and storage medium to at least solve the problem of wasting developers' time and affecting development efficiency due to inconvenience in reading and debugging source code when using static library integration in the related art.

The technical solutions of the present disclosure are as follows:

According to a first aspect of the embodiments of the present disclosure, there is provided a source code debugging method, comprising: in the debugging process of a target project, obtaining a compilation file of a target static library in the target project, and the compiled file is obtained by compiling a first source code file ; Analyze the compiled file to obtain the first storage path of the first source code file, and the first storage path is the storage path when the first source code file is compiled into a compiled file; Create a second storage path identical to the first storage path in the local device path; store the second source code file in the second storage path, the second source code file is obtained by parsing the configuration file of the target static library, and the content of the second source code file is the same as that of the first source code file; read the second source code file based on the second storage path source file to debug the second source file.

According to a second aspect of the embodiments of the present disclosure, a source code debugging device is provided, including: an obtaining module configured to execute a debugging process of a target project to obtain a compiled file of a target static library in the target project, and the compiled file The first source code file is obtained by compiling; the parsing module is configured to execute parsing and compiling the file to obtain a first storage path of the first source code file, and the first storage path is the storage path when the first source code file is compiled into a compiled file; creating The module is configured to execute the creation of a second storage path that is the same as the first storage path in the local device; the storage module is configured to execute the second source code file to be stored in the second storage path, and the second source code file is statically generated by parsing the target The configuration file of the library is obtained, and the content of the second source code file is the same as that of the first source code file; the reading module is configured to read the second source code file based on the second storage path, so as to debug the second source code file.

According to a third aspect of the embodiments of the present disclosure, there is provided a server, comprising: a processor; a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement the first aspect Source code debugging method.

According to a fourth aspect of the embodiments of the present disclosure, a storage medium is provided, when an instruction in the storage medium is executed by a processor of a server, the server can execute the source code debugging method described in the first aspect.

According to a fifth aspect of the embodiments of the present disclosure, there is provided a computer program product, which enables the server to execute the source code debugging method according to the first aspect when the instructions in the computer program product are executed by the processor of the server.

The technical solutions provided by the embodiments of the present disclosure bring at least the following beneficial effects:

In the embodiment of the present disclosure, by analyzing the compiled file of the target static library, the first storage path of the first source code file when compiled is determined, and the second storage path that is the same as the first storage path is created locally, and then The second source code file determined based on the configuration file of the target static library is stored in the second storage path, so that the second source code file stored in the second storage path can be automatically read during debugging, so that only the machine can The identified compiled file is directly converted into a second source code file that is readable by the debugger and supports source code debugging, thereby facilitating the debugger to debug the second source code file, saving the work time of the debugger and improving the development efficiency.

It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure.

Description of drawings

The accompanying drawings, which are incorporated into and constitute a part of this specification, illustrate embodiments consistent with the present disclosure, and together with the description, serve to explain the principles of the present disclosure and do not unduly limit the present disclosure.

Fig. 1 is a schematic diagram showing a static library integration according to an exemplary embodiment.

FIG. 2 is a schematic diagram of an application environment of a source code debugging method, apparatus, electronic device, and storage medium according to an exemplary embodiment.

Fig. 3 is a flowchart of a source code debugging method according to an exemplary embodiment.

Fig. 4 is a flowchart of another source code debugging method according to an exemplary embodiment.

Fig. 5 is a block diagram of a source code debugging apparatus according to an exemplary embodiment.

Fig. 6 is a block diagram of a server according to an exemplary embodiment.

FIG. 7 is a block diagram of an apparatus for data processing according to an exemplary embodiment.

Detailed ways

In order to make those skilled in the art better understand the technical solutions of the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings.

It should be noted that the terms "first", "second" and the like in the description and claims of the present disclosure and the above drawings are used to distinguish similar objects, and are not necessarily used to describe a specific sequence or sequence. It is to be understood that the data so used may be interchanged under appropriate circumstances such that the embodiments of the disclosure described herein can be practiced in sequences other than those illustrated or described herein. The implementations described in the illustrative examples below are not intended to represent all implementations consistent with this disclosure. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present disclosure as recited in the appended claims.

With the gradual complication and diversification of computer development projects (such as super application programs (Application, APP)), the accompanying slow project compilation problem becomes more and more obvious.

Super APP refers to those basic applications that have a huge number of users and become "must have" on the user's mobile phone. Super APP can fulfill people's needs for the functions of many APPs. Once a super APP is installed, there is no need to install too many APPs on one electronic device, and it can meet people's daily needs. Super APP has gradually become a popular trend because of its diversified characteristics, but because of its complex functions, the problem of slow project compilation has become more and more obvious.

Due to the diverse functions and complex implementation of super APPs, it usually takes 40 minutes to 1 hour to compile the source code of the APP, which seriously affects the development efficiency. In order to solve the above problem of slow source code compilation, the static library compilation technology came into being. The library compilation technology allows developers to compile and package the project by integrating the compiled files, which greatly improves the compilation speed of the project. Practice has proved that it is indeed effective.

The compilation file refers to compiling and linking the source file written by the developer to generate an executable file, such as a binary file.

It should be noted that the present disclosure is not only applicable to super APPs, but can also be applied to any programs, software, and computer engineering that are integrated using static libraries.

Hereinafter, a specific implementation manner of static library integration in the related art will be described by taking FIG. 1 as an example.

Fig. 1 is a schematic diagram showing a static library integration according to an exemplary embodiment. As shown in FIG. 1 , the source code 110 is precompiled to obtain a static library 120 , and then the development of the project 130 is facilitated by integrating multiple static libraries. Among them, pre-compilation is a translation process from source code (usually a high-level language) to object code (ie, assembly instructions) that can be directly executed by a computer or a virtual machine. At present, the static library compilation technology compiles the target source code library into compiled files in advance, and directly uses the compiled secondary files during project integration, thereby saving the time for developers to compile this part of the source code, so as to realize the compilation optimization of the project, gradually Become the mainstream of compilation optimization. Here, the solution of directly using the compiled secondary files during project integration is the static library integration solution.

However, a static library is a kind of compiled file. After being loaded at compile time, developers can only see computer code instructions in assembly form during debugging, which brings a lot of inconvenience to developers in source code reading and debugging.

Due to the dilemma that the above-mentioned developers cannot view the source code corresponding to the static library and debug the source code, most developers still use the form of source code integration. In order to facilitate reading the source code and debugging, developers would rather accept extremely slow compilation time, but also give up the static library integration solution that can greatly improve the compilation speed, making the static library integration solution unable to play its due role.

In order to solve the problem in the above-mentioned related technologies that it is inconvenient to read the source code when using the static library integration, so that the static library integration does not play its due role.

The present disclosure provides a source code debugging method, device, electronic device and storage medium. The source code debugging method, device, electronic device and storage medium can determine the first storage path of the first source code file when it is compiled by analyzing the compiled file of the target static library, and locally create the same storage path as the first storage path. The second storage path, and then store the second source code file determined based on the configuration file of the target static library in the second storage path, so that the second source code file stored in the second storage path can be automatically read during debugging , to debug the second source file. In this way, the compiled file that can only be recognized by the machine can be directly converted into the second source code file readable by the debugger, so as to realize the debugging of the second source code file. In this way, the working time of the debugging personnel can be saved, and the development efficiency can be improved.

As shown in FIG. 2 , it is a schematic diagram of an application environment of the source code debugging method, apparatus, electronic device and storage medium provided by one or more embodiments of the present disclosure. As shown in FIG. 2 , the server 100 is communicatively connected with one or more clients 200 through the network 300 for data communication or interaction. The server 100 may be a web server, a database server, or the like. The client 200 may be, but is not limited to, a personal computer (personal computer, PC), a smart phone, a tablet computer, a personal digital assistant (PDA), and the like. The network 300 may be a wired or wireless network.

The source code debugging method provided by the embodiments of the present disclosure will be described in detail below.

The source code debugging method provided by the embodiment of the present disclosure can be applied to the client 200. For the convenience of description, unless otherwise specified, the embodiment of the present disclosure is described by taking the client 200 as the execution body. It can be understood that the described execution body does not constitute a limitation of the present disclosure.

In order to better understand the technical solution of the present disclosure, before describing how to obtain the source code file corresponding to the target static library shown in FIG. 3 , the following describes the process before using the target static library for integration.

In order to improve the compilation speed, static library integration is often used when developing projects. Next, let's introduce the source of the target static library. For example: Developer 1 wrote a piece of source code A on device 1. The functions that this source code A can implement can be used by many projects. Developer 1 compiles source code A into a target static library, and combines source code A with the target static library. Libraries are published on the web. Here, when the source code A is compiled into a compiled file (ie, the target static library), the storage path on device 1 is the first storage path. The source code A on the network is the second source code file. It can be understood that the contents of the first source code file and the second source code file are the same.

Then, when developer 2 develops the target project, the target static library is integrated into the target project, and the process of debugging the target project on device 2 (ie, the local device) cannot be realized due to viewing the compiled file. Source code debugging, so I want to find the source code 1 corresponding to the target static library, and I want to convert each line of the compiled file of the target static library into each line of the corresponding source code line by line.

Next, the source code debugging method provided by the present disclosure will be described.

Fig. 3 is a flowchart of a source code debugging method according to an exemplary embodiment.

As shown in FIG. 3 , the source code debugging method may include the following steps.

S310 , in the debugging process of the target project, obtain a compiled file of the target static library in the target project, and the compiled file is obtained by compiling the first source code file.

S320, parse the compiled file to obtain a first storage path of the first source code file, where the first storage path is a storage path when the first source code file is compiled into a compiled file.

S330. Create a second storage path that is the same as the first storage path in the local device.

S340: Store the second source code file in the second storage path, where the second source code file is obtained by parsing the configuration file of the target static library, and the content of the second source code file is the same as that of the first source code file.

S350: Read the second source code file based on the second storage path to debug the second source code file.

The specific implementation of the above steps will be described in detail below.

In the embodiment of the present disclosure, by analyzing the compiled file of the target static library, the first storage path of the first source code file when compiled is determined, and the second storage path that is the same as the first storage path is created locally, and then Store the second source code file determined based on the configuration file of the target static library in the second storage path, so that the second source code file stored in the second storage path can be automatically read during debugging to debug the second source code document. In this way, the compiled file that can only be recognized by the machine can be directly converted into the second source code file readable by the debugger, so as to realize the debugging of the second source code file. In this way, the working time of the debugging personnel can be saved, and the development efficiency can be improved.

The specific implementation manner of each of the above steps is described below.

First, the S310 is introduced.

Specifically, in the debugging process of the target project mentioned above, breakpoint debugging can be performed on the target project.

Breakpoints, one of the functions of the debugger, allow the program to break where needed to facilitate its analysis. A breakpoint is a signal that notifies the debugger to temporarily suspend program execution at a specific point. A program can be said to be in break mode when execution is suspended at some breakpoint. Entering break mode does not terminate or end program execution. Execution can continue at any time. Among them, the debugger can start some process and then debug it, or attach itself to an existing process. It can step through code, set breakpoints and then run the program, inspect the values of variables, and trace the call stack.

Among them, the static library mentioned above means that in our application, there are some common codes that need to be used repeatedly, and these codes are compiled into "library" files; in the linking step, the linker will obtain the required files from the library files. code, copy this library into the generated executable.

The compiled file of the target static library is obtained by compiling the first source code file. When the static library is compiled, it will be copied directly to the target project, and this code will not be changed in the target program.

Taking the iOS system as an example, iOS is a mobile operating system developed by Apple. It is mainly used for iPhone, iPodtouch and iPad. By integrating the pre-compiled compiled files, Apple developers directly integrate the target library in the form of source code as a static library, and Xcode does not need to compile again during compilation, thus saving compilation time. In this solution, the change from the source code integration form to the static library integration form needs to be realized by means of tooling. The compiled library contains header files, compiled files, resources, etc. Static libraries have the suffix .a. Among them, Xcode is an integrated development tool running on the operating system Mac OS X.

Precompiling static library integration in the iOS system mainly includes two tasks: First, specify the code integration method through the library management tool, that is, the target project can choose source code integration or static library integration. For example, the description of the library uses "vendored_libraries" to specify the way the code is integrated "ios/libOne_CGPUImage.a". Here, the suffix of the static library is .a, and it can be determined that the current target project is a static library integration. Then, replace the original integration mode with the path form, where the path is the precompiled static library path stored locally, that is, the compiled file of the target static library in the target project can be found through the path pointed to by the path.

Here, through the library management tool, the target static library can be quickly determined among the multiple static libraries of the target project, and the compiled file of the target static library can be obtained.

In one or more embodiments, the storage path of the target static library is obtained; based on the storage path of the target static library, the compiled file of the target static library is obtained.

First of all, when the static library is packaged and integrated, the compiled file of the static library can be stored on the specified server (that is, the remote device). Then, when preparing for development, the library name information and version information of the static library can be used as needed to download the specified file. The compiled file of the static library is stored in the local device, and each static library corresponds to a storage path locally on the user's electronic device. After this, the compiled file of the target static library can be obtained through the storage path of the target static library.

Since the target project is obtained by integrating multiple static libraries, here, based on the storage path of the target static library, the storage path of the target static library can be determined from the storage paths of multiple static libraries in the project directory, and then the target static library can be quickly determined. .

Next, introduce the S320.

The compiled file is parsed by using a preset parsing tool. Since the compiled file is obtained by compiling, it is necessary to parse to obtain the storage path of the first source code file before the compiled file is compiled.

Among them, the path is the folder line that the user goes through when searching for the file on the disk, which is called the path. Paths are divided into absolute paths and relative paths. The path involved in the present disclosure is an absolute path, and an absolute path is a path starting from the root folder, starting with "/".

Illustratively, the path may be "Users/Jackson/target folder/target subfolder".

In one or more embodiments, the debugging information of the target static library is loaded by using a preset component; and the first storage path of the first source code file is determined according to the debugging information.

Among them, the debugging information is from the compiled file. When compiling, the compiler will collect a lot of information from the source file, such as variable name, variable type, line number where the variable is located, function name, function parameters, address range of the function, correspondence between line numbers and addresses, etc. It is then written to the compiled file in a specific format. When debugging, the debugger reads and parses this information from the file to produce more human-readable information.

Here, the debugging information obtained by parsing the target static library also includes the mapping relationship between the target static library and the target source code. A function of N lines. Subsequently, according to the mapping relationship, the assembly instructions corresponding to the target static library can be converted into source code files, so as to realize the debugging of the target static library.

Taking the iOS system as an example, the Objective-C language and the Swift language are used in the application development of the iOS system. Both the Objective-C language and the Swift language are a compiled language. When a compiled language is executed, the machine code must be generated by the compiler first, and the machine code can be directly executed on the processor, so the execution efficiency is high.

Among them, the Objective-C language is a strict superset of the C language. Any C language program can directly pass the Objective-C compiler without modification, and it is completely legal to use the C language code in Objective-C. Objective-C is described as a thin layer over the C language, because the original intention of Objective-C is to add object-oriented features to the main body of the C language. Swift language can run on MAC OS and iOS platform together with Objective-C language to build applications based on Apple platform.

In order to realize that Xcode converts/parses the corresponding assembly debug signals and displayed assembly code instructions into the source code of the objective-c and/or switft language familiar to the developer, it is necessary to establish a mapping between the symbols of the compiled file and the local source code file. Assembly code instructions are some operators and mnemonics used in assembly language, and also include some pseudo-instructions, which correspond one-to-one with machine instructions. Each CPU has its own assembly instruction set.

The compiled files in the static library are compiled and generated by the clang compiler in the low level virtual machine (Low Level Virtual Machine, LLVM), and the internal structure of the compiled files is complex. To understand the composition of compiled files, we must use relevant tools to understand and analyze them. Among them, LLVM is a framework system for building a compiler (compiler), which is used to optimize the compile-time (compile-time), link-time (link-time), run-time (run-time) and idle time of programs written in any programming language. idle-time, open to developers and compatible with existing scripts. LLVM can perform compile-time optimization, link optimization, online compilation optimization, and code generation of programming languages. Clang is an LLVM-based C/C++/Objective-C compiler written by Apple and able to compile quickly.

Here, you can use the commonly used dwarfdump command to parse the Apple App crash log file to load the Debugging With Attributed RecordFormats (DWARF) debugging information of the compiled file (ELF format) under the Apple system, and understand the composition of the compiled file through the debugging information. . The DWARF debug information includes an "AT_comp_dir" attribute record whose value is a null-terminated string containing the current working directory of the compilation command that generated the compilation unit in DWARF debug information format. The working directory here may be the first storage path of the first source code file.

Here, the first storage path of the first source code file can be determined through simple and easy-to-obtain debugging information, and then the second source code information downloaded online can be downloaded to the second storage path in the local device that is the same as the first storage path path, and then realize source code debugging. There is no need to compile the compiled files of the static library back to the source code files to realize source code debugging, saving costs and reducing time.

Next, S330 is introduced.

The first storage path is determined in the above S320, and the first storage path may be a storage path on the remote device, and then a second storage path that is the same as the first storage path may be created in the local device.

Exemplarily, the first storage path is "Users/Jackson/target folder/target subfolder", then creating a second storage path that is the same as the first storage path in the local device is also: "Users/Jackson/target folder/target subfolder".

Then, S340 is introduced.

The configuration file of the target static library includes some attribute information of the target static library. By parsing the configuration file of the target static library, the second source code file corresponding to the target static library can be downloaded from the network. Here, the second source code file is the same as the first source code file. content is the same. Then, the second source code file is stored in the second storage path.

It should be noted that the content of the second source code file here is the same as that of the first source code file, but the first source code file is the source code file stored on the remote device, and the second source code file is the source code file downloaded through the network.

As shown in FIG. 4, as another implementation manner of the present disclosure, in order to improve the accuracy of the source code, before S340, the following steps may also be included:

S360: Obtain the configuration file of the target static library; determine the online address and version information of the target static library according to the configuration file of the target static library; download the second source code file corresponding to the target static library according to the online address and version information.

The above-mentioned version information includes a version number, and the version number is an identification number of the version. Every operating system (or broadly speaking, every software) has a version number. The version number enables the user to know whether the operating system in use is the latest version and the features and facilities it provides. There are various ways of dividing the version number, for example, according to authorization, function, language, etc. The version information involved in the present disclosure is specifically adapted to change according to the actual version information.

Exemplarily, the application X has multiple versions, including: X1.0, X2.0, and X3.0, etc. "1.0, 2.0, and 3.0" represent multiple versions of the application X. In fact, the application or software version number is more complex and can be composed of four parts, the first 1 is the main version number, the second 1 is the subversion number, the third 1 is the stage version number, and the fourth part is The date version number plus the Greek letter version number, there are 5 types of Greek letter version numbers: base, alpha, beta, RC, release. For example: 1.1.1.051021_beta.

The above-mentioned online address can be a website or a link. The online address points to the online storage address of the second source code file corresponding to the target static library, and the corresponding second source code file can be downloaded through the online address of the target static library.

Here, according to the online address and version information of the target static library, the second source code file corresponding to the target static library can be uniquely determined, so that the online second source code file can be downloaded to the local device to ensure the accuracy of the second source code file. Spend.

In one or more embodiments, the second source code file is downloaded to the temporary storage path; the second source code file is moved from the temporary storage path to the second storage path.

Because the files downloaded through the network are generally saved in the default path, that is, the temporary path. Therefore, when the second source code file is automatically downloaded to the temporary storage path, the second source code file needs to be moved from the temporary storage path to the second storage path.

Here, by moving the second source code file from the temporary storage path to the second storage path, the second storage path of the local device can be guaranteed to be the same as the first storage path of the source code file used to compile and generate the target static library on the remote device The same source code file can also exist in the path, which can support subsequent debugging functions.

As another implementation manner of the present disclosure, in order to clearly identify the second source code file, before the above-mentioned steps related to downloading the second source code file to the temporary storage path, the following steps may also be included:

Delete the third source code file in the temporary path, where the third source code file is a source code file other than the second source code file.

In order to avoid previous files from overwriting the second source code file and to clearly identify the second source code file, before downloading the second source code file to the temporary storage path, the third source code file in the temporary path may be cleared first.

Here, by deleting the source code files other than the second source code file in the temporary path, the second source code file can be found quickly and accurately, and the second source code file can be prevented from being overwritten by previous files.

Finally, introduce the S350.

After the above steps S310-S340, it can be ensured that the same source code file exists in the second storage path of the local device that is the same as the first storage path of the source code file used for compiling and generating the target static library on the remote device. At this time, the corresponding source code can be automatically read and the debugging function can be supported during debugging. That is, the second source code file can be read based on the second storage path to debug the second source code file.

As another implementation manner of the present disclosure, in order to ensure the accuracy and security of the second source code file, before S350, the following steps may also be included:

Based on the MD5 Message-Digest Algorithm (MD5), it is verified whether the second source code file is the target second source code file.

Specifically, the first MD5 value of the second source code file is calculated, the first MD5 value and the second MD5 value included in the second source code file are used, and in the case that the first MD5 value and the second MD5 value are the same, the The second source code file is the target second source code file. Correspondingly, only when the verification is passed, the second source code file can be read based on the second storage path to debug the second source code file.

If the verification fails, it means that the second source code file obtained by parsing the configuration file of the target static library in S340 is incorrectly downloaded, and it is not the second source code file corresponding to the target static library; or the second source code file obtained by parsing the configuration file of the target static library is incorrect. Two source files were tampered with. At this time, the second source code file will not be read based on the second storage path to debug the second source code file.

Among them, MD5 is a widely used cryptographic hash function, which can generate a 128-bit (16-byte) hash value to ensure complete and consistent information transmission. A typical application of MD5 is to generate a message digest for a piece of information to prevent tampering.

For example, when many software are downloaded, there is a file with the same file name and the file extension of .md5. There is usually only one line of text in this file, and the general structure is: MD5(dieryuanmawenjian.tar.gz)=0ca175b9c0f795e269332461. This is the digital signature of the dieryuanmawenjian.tar.gz file. MD5 treats the entire file as a large text message, and generates this unique MD5 message digest through its irreversible string transformation algorithm. MD5 can generate a unique "digital fingerprint" for any file. If anyone makes any changes to the file name, its MD5 value, that is, the corresponding "digital fingerprint" will change.

After downloading the software, the MD5 value can be checked by a special inspection tool (such as WindowsMD5 Check, etc.) on the downloaded file to ensure that the file we obtained is the same file as the one provided by the site. MD5 can also effectively prevent "tampering". For example, write a paragraph in a file, generate an MD5 value for the file and record it, and then spread the file to others. If others modify any content in the file, recalculate the MD5 for the file again. You will find that the two MD5 values are not the same.

Here, the security, correctness and validity of the second source code file can be guaranteed.

As another implementation manner of the present disclosure, in order to avoid wasting the disk space of the local device, after S350, the following steps may be further included:

S370, when the debugging of the second source code file is completed, delete the second source code file in the second storage path.

When the debugging of the second source code file is completed, the second source code file can be deleted from the second storage path, so that the second source code file of the static library can be dynamically loaded and unloaded, which can avoid wasting the disk space of the local device .

It should be noted that, in the actual application process, the above steps and methods of S310-S370 can be implemented by one or more lines of command lines. Here, the first storage path of the first source code file and the target static library can be A series of process engineering such as downloading the corresponding second source code file and debugging the second source code file. Among them, the systematic, strictly constrained and quantifiable methods applied in the development, testing, deployment and maintenance process can be called engineering. The higher the degree of engineering, the fewer defects or shortcomings caused by individual differences, and the quality of the project can be more effectively guaranteed.

In the embodiment of the present disclosure, by analyzing the compiled file of the target static library, the first storage path of the first source code file when compiled is determined, and the second storage path that is the same as the first storage path is created locally, and then Store the second source code file determined based on the configuration file of the target static library in the second storage path, so that the second source code file stored in the second storage path can be automatically read during debugging to debug the second source code document. In this way, the compiled file that can only be recognized by the machine can be directly converted into the second source code file readable by the debugger, so as to realize the debugging of the second source code file. In this way, the working time of the debugging personnel can be saved, and the development efficiency can be improved.

Based on the above source code debugging method, the present disclosure also provides a source code debugging device. The specific description will be made with reference to FIG. 5 .

Fig. 5 is a block diagram of a source code debugging apparatus according to an exemplary embodiment. 5 , the source code debugging apparatus 500 may include an acquisition module 510 , a parsing module 520 , a creation module 530 , a storage module 540 and a reading module 550 .

The obtaining module 510 is configured to obtain a compiled file of the target static library in the target project during the debugging process of the target project, and the compiled file is obtained by compiling the first source code file.

The parsing module 520 is configured to perform parsing of the compiled file to obtain a first storage path of the first source code file, where the first storage path is the storage path when the first source code file is compiled into a compiled file.

The creating module 530 is configured to perform creating a second storage path that is the same as the first storage path in the local device.

The storage module 540 is configured to store the second source code file in the second storage path. The second source code file is obtained by parsing the configuration file of the target static library, and the content of the second source code file is the same as that of the first source code file.

The reading module 550 is configured to read the second source code file based on the second storage path, so as to debug the second source code file.

In the embodiment of the present disclosure, the source code debugging apparatus 500 determines the first storage path of the first source code file when it is compiled by analyzing the compiled file of the target static library, and locally creates a first storage path that is the same as the first storage path. Second storage path, and then store the second source code file determined based on the configuration file of the target static library in the second storage path, so that the second source code file stored in the second storage path can be automatically read during debugging, to debug the second source code file. In this way, the compiled file that can only be recognized by the machine can be directly converted into the second source code file readable by the debugger, so as to realize the debugging of the second source code file. In this way, the working time of the debugging personnel can be saved, and the development efficiency can be improved.

In some embodiments of the present disclosure, the obtaining module 510 is further configured to execute: obtaining the storage path of the target static library; and obtaining the compiled file of the target static library based on the storage path of the target static library.

In some embodiments of the present disclosure, the obtaining module 510 is further configured to execute obtaining the configuration file of the target static library;

Correspondingly, the source code debugging apparatus 500 may further include: a first determination module and a first download module.

The first determining module is configured to determine the online address and version information of the target static library according to the configuration file of the target static library;

The first download module is configured to download the second source code file corresponding to the target static library according to the online address and version information.

In some embodiments of the present disclosure, the parsing module 520 includes: a loading module and a second determining module.

The loading module is configured to execute debug information for loading the target static library by using the preset component;

The second determining module is configured to execute determining the first storage path of the first source code file according to the debugging information.

In some embodiments of the present disclosure, the storage module 540 includes: a second download module and a mobile module.

The second downloading module is configured to execute the downloading of the second source code file to the temporary storage path;

The moving module is configured to execute moving the second source code file from the temporary storage path to the second storage path.

In some embodiments of the present disclosure, the source code debugging apparatus 500 may further include: a first deletion module.

The first deletion module is configured to delete the third source code file in the temporary path, where the third source code file is a source code file other than the second source code file.

In some embodiments of the present disclosure, the source code debugging apparatus 500 may further include: a second deletion module.

The second deletion module is configured to delete the second source code file in the second storage path when the debugging of the second source code file is completed.

Regarding the apparatus in the above-mentioned embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be described in detail here.

Fig. 6 is a block diagram of a server according to an exemplary embodiment. 6 , an embodiment of the present disclosure further provides a server, including a processor 610 , a communication interface 620 , a memory 630 and a communication bus 640 , wherein the processor 610 , the communication interface 620 and the memory 630 communicate with each other through the communication bus 640 Communication.

The memory 630 is used for storing instructions executable by the processor 610 .

When the processor 610 is used to execute the instructions stored in the memory 630, the following steps are implemented:

During the debugging process of the target project, the compiled file of the target static library in the target project is obtained, and the compiled file is obtained by compiling the first source code file; the compiled file is parsed to obtain the first storage path of the first source code file, and the first storage The path is the storage path when the first source code file is compiled into a compiled file; a second storage path that is the same as the first storage path is created in the local device; the second source code file is stored in the second storage path, and the second source code file passes through The configuration file of the target static library is analyzed to obtain that the content of the second source code file is the same as that of the first source code file; the second source code file is read based on the second storage path to debug the second source code file.

It can be seen that, applying the embodiment of the present disclosure, by analyzing the compiled file of the target static library, the first storage path of the first source code file when compiled is determined, and the second storage path that is the same as the first storage path is created locally, Then, the second source code file determined based on the configuration file of the target static library is stored in the second storage path, so that the second source code file stored in the second storage path can be automatically read during debugging to debug the second source code file. source file. In this way, the compiled file that can only be recognized by the machine can be directly converted into the second source code file readable by the debugger, so as to realize the debugging of the second source code file. In this way, the working time of the debugging personnel can be saved, and the development efficiency can be improved.

FIG. 7 is a block diagram of an apparatus for data processing according to an exemplary embodiment. For example, the device 700 may be provided as a server. 7, server 700 includes processing component 722, which further includes one or more processors, and a memory resource, represented by memory 732, for storing instructions executable by processing component 722, such as application programs. An application program stored in memory 732 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 722 is configured to execute the instructions to execute the source code debugging method described in any one of the above embodiments.

The device 700 may also include a power component 726 configured to perform power management of the device 700, a wired or wireless network interface 750 configured to connect the device 700 to a network, and an input output (I/O) interface 758. Device 700 may operate based on an operating system stored in memory 732, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™ or the like.

In some embodiments of the present disclosure, a storage medium is also provided, when the instructions in the storage medium are executed by the processor of the server, the server can execute the source code debugging method described in any of the foregoing embodiments.

Alternatively, the storage medium may be a non-transitory computer-readable storage medium, for example, the non-transitory computer-readable storage medium may be ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage devices, etc.

In some embodiments of the present disclosure, a computer program product is also provided, when the instructions in the computer program product are executed by the processor of the server, the server can execute the source code debugging method described in any of the above embodiments.

Other embodiments of the present disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common general knowledge or techniques in the technical field not disclosed by this disclosure . The specification and examples are to be regarded as exemplary only, with the true scope and spirit of the disclosure being indicated by the following claims.

It is to be understood that the present disclosure is not limited to the precise structures described above and illustrated in the accompanying drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims (10)

1. A source code debugging method is characterized by comprising the following steps:

in the debugging process of a target project, obtaining a compiling file of a target static library in the target project, wherein the compiling file is obtained by compiling a first source code file;

analyzing the compiled file to obtain a first storage path of the first source code file, wherein the first storage path is a storage path when the first source code file is compiled into the compiled file;

creating a second storage path in the local device that is the same as the first storage path;

storing a second source code file to the second storage path, wherein the second source code file is obtained by analyzing the configuration file of the target static library, and the second source code file has the same content as the first source code file;

and reading the second source code file based on the second storage path so as to debug the second source code file.

2. The method of claim 1, wherein prior to said storing the second source code file to the second storage path, the method further comprises:

acquiring a configuration file of the target static library;

determining the online address and version information of the target static library according to the configuration file of the target static library;

and downloading a second source code file corresponding to the target static library according to the online address and the version information.

3. The method of claim 1, wherein after the reading the second source code file based on the second storage path to debug the second source code file, the method further comprises:

and deleting the second source code file under the second storage path under the condition that debugging of the second source code file is completed.

4. The method of claim 1, wherein obtaining the compiled file of the target static library in the target project comprises:

acquiring a storage path of the target static library;

and acquiring a compiled file of the target static library based on the storage path of the target static library.

5. The method of claim 1, wherein parsing the compiled file to obtain a first storage path of the first source code file comprises:

loading debugging information of the target static library by using a preset component;

and determining a first storage path of the first source code file according to the debugging information.

6. The method of claim 1, wherein storing the second source code file to the second storage path comprises:

downloading the second source code file to a temporary storage path;

and moving the second source code file from the temporary storage path to the second storage path.

7. The method of claim 6, wherein prior to said downloading said second source code file to a temporary storage path, said method further comprises:

and deleting a third source code file under the temporary path, wherein the third source code file is a source code file except the second source code file.

8. A source code debugging apparatus, comprising:

the system comprises an acquisition module, a debugging module and a control module, wherein the acquisition module is configured to acquire a compiled file of a target static library in a target project in the debugging process of the target project, and the compiled file is obtained by compiling a first source code file;

the analysis module is configured to analyze the compiled file to obtain a first storage path of the first source code file, wherein the first storage path is a storage path of the first source code file when the first source code file is compiled into the compiled file;

a creation module configured to perform creating a second storage path identical to the first storage path in a local device;

a storage module configured to store a second source code file to the second storage path, where the second source code file is obtained by analyzing a configuration file of the target static library, and the second source code file has the same content as the first source code file;

a reading module configured to perform reading the second source code file based on the second storage path to debug the second source code file.

9. A server, comprising:

a processor;

a memory for storing the processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the source code debugging method of any of claims 1 to 7.

10. A storage medium, wherein instructions in the storage medium, when executed by a processor of a server, enable the server to perform a source code debugging method as claimed in any one of claims 1 to 7.

Images