WO2024088053A1 - Code debugging method, electronic device, and computer readable storage medium - Google Patents

Abstract

Provided are a code debugging method, an electronic device, and a computer readable storage medium. The method comprises: in response to a received debugging command, running a program code to be debugged; in the process of running the program code, detecting a trigger event of calling a function in a second code segment by means of a first function call statement; on the basis of an association relationship between the first function call statement and the called first function in the second code segment, determining that the address of the first function meets a trigger condition for adding a breakpoint; and adding the breakpoint at the address of the first function. The objective of automatically setting a breakpoint in a code segment to be debugged and checked can be achieved, and when a program code resumes execution and hits a breakpoint, a corresponding code debugging interface can display codes of a code segment corresponding to the breakpoint for a user to check, thereby improving the debugging efficiency.

Description

Code debugging method, electronic device and computer readable storage medium

This application claims priority to the Chinese patent application filed with the China Patent Office on October 25, 2022, with application number 202211313299.7 and application name “Code debugging method, electronic device and computer-readable storage medium”, the entire contents of which are incorporated by reference in this application.

Technical Field

The present invention relates to the field of computer technology, and in particular to a code debugging method, an electronic device and a computer-readable storage medium.

Background technique

When developing applications (Apps), developers often use an integrated development environment (IDE). An IDE is an application that integrates multiple development tools to provide a program development environment, generally including editors, compilers, debuggers, and graphical user interfaces.

At present, the development direction of IDE is to support multiple programming languages, such as C/C++, Java, JavaScript, Python, etc. For applications applied to different operating systems, the combination of multiple programming languages used during development will also be different. For example, in the application development process of the Hongmeng ^TM operating system (HarmonyOS ^TM ), JavaScript is usually used to write user interface (UI) related logic code, while the application function part with higher performance requirements can use C/C++ language to write related code. In this way, the development process of these applications can involve a multi-language mixed development scenario combining C/C++ and JavaScript programming languages. In the multi-language mixed development scenario, when debugging the code of each part of the application, it is necessary to face the situation of cross-language debugging including JavaScript and C/C++ two programming languages. How to quickly discover problems in JavaScript and C/C++ related codes during cross-language debugging and solve them in time is also one of the problems that need to be solved in the multi-language mixed development scenario.

At present, in the process of multi-language mixing, developers need to frequently switch programming languages for debugging, which is very cumbersome and not conducive to quickly and accurately locating specific problems. For example, in the JavaScript files of some applications, there may be a situation where a C/C++ function is called. At this time, if you need to stop at the running interface of the C/C++ file to check the code problem, you need to manually analyze the calling relationship from the JavaScript to C/C++ and find the corresponding file, and then you can add a breakpoint at a line of code in the found C/C++ file, that is, a breakpoint. In this way, the application to be debugged can only stop when it executes to the line of code marked by the breakpoint in the C/C++ file. When there are many cross-language code calls, the debugging workload will inevitably increase and the debugging efficiency will be low.

Summary of the invention

The embodiments of the present application provide a code debugging method, an electronic device, and a computer-readable storage medium, which can simplify the user's operations in the process of debugging application code and realize automatic breakpoints in the code segment to be checked, so as to help the user quickly locate the code segment to be checked, quickly find code problems, and improve debugging efficiency.

In a first aspect, an embodiment of the present application provides a code debugging method, which is applied to an electronic device, wherein a program code to be debugged running on the electronic device includes a first code segment written in a first language, the first code segment includes a first function call statement that calls a second code segment written in a second language, and the method includes: in response to a received debugging command, running the program code to be debugged; in the process of running the program code, detecting a triggering event of calling a function in the second code segment through a first function call statement; based on the association relationship between the first function call statement and the first function called in the second code segment, determining that the address of the first function meets the triggering condition of a breakpoint; and setting a breakpoint at the address of the first function.

For example, the first code segment may be a JavaScript code segment, the second code segment may be a C/C++ code segment, and the trigger event may be a local function call event triggered by the corresponding thread running to the local function call statement in the JavaScript code segment to jump to the corresponding associated first function in the C/C++ code segment. Therefore, the code debugging method provided in the first aspect above can determine that the first function meets the triggering condition of the breakpoint based on the association relationship between the predetermined first function call statement (existing in the first code segment, such as the JavaScript code segment) and the first function (existing in the second code segment, such as the C/C++ code segment) when a local function call event is detected, and then set a breakpoint at the address of the first function.

In this way, for example, a predefined code segment can be used to predetermine the association relationship between the first function call statement and the called first function, thereby achieving the purpose of automatically setting a breakpoint in the second code segment to be debugged and checked (for example, a C/C++ code segment). When the program code resumes execution and hits the breakpoint, the breakpoint can automatically stop at the entry of the first function in the C/C++ code segment. Correspondingly, the C/C++ code segment that hits the breakpoint can also be displayed on the interface of the integrated development environment (IDE) connected to the electronic device, and the entry address of the first function can also be highlighted, which is convenient for users to check and helps to improve debugging efficiency.

In a possible implementation of the first aspect, the association relationship between the first function call statement and the first function called in the second code segment is determined in the following manner:

defining an export object in the second code segment, and defining and initializing a first attribute for the export object, wherein the first attribute corresponds to a first function call statement in the first code segment;

Setting the first function called in the second code segment as a callback function of the first attribute, and establishing an association relationship between the first attribute and the first function;

The first attribute of the export object is loaded in the first code segment, and the association relationship between the first function call statement and the first function called in the second code segment is determined.

For example, the export object may be an exports object, and the first attribute may be an add attribute. Therefore, the function for defining and initializing the first attribute for the export object may be an Init function, that is, the predefined exports object attribute may be defined as the add attribute through the Init function. The first function call statement may be "testNapi.add(1,2);" in the JavaScript code segment, and the first function may be the Add function in the C/C++ code segment. The first attribute of the export object may be loaded in the first code segment, for example, by defining a local module (napi_module), for example, defining a local module as "demoModule", and setting the initialization function of the local module to the Init function. Then, the local module is registered using a module registration function (for example, RegisterHelloModule). Thus, when the exports object attribute add is loaded and initialized through the first function call statement in the JavaScript code segment, the corresponding relationship between the first function call statement and the Add function in the corresponding C/C++ code segment may be determined. It can be understood that the above method for determining the association relationship may be implemented by a predefined code segment, and the predefined code segment may be, for example, the code segment illustrated in FIG. 2 below.

In a possible implementation of the first aspect above, satisfying the triggering condition of the breakpoint includes: determining that the address of the first function is within a predetermined address range of a second code segment, wherein the address range of the second code segment is determined based on a shared library-related attribute corresponding to the program code loaded by the electronic device.

For example, the address range of the second code segment may be the first address range corresponding to the C/C++ code segment. The address range may be determined based on the relevant attributes of the shared library (SO) loaded by the system of the electronic device. The relevant attributes may include, but are not limited to, the name of the SO file, the load address, and the address range of the called C/C++ code segment, etc., which are not limited here.

In a possible implementation of the first aspect above, a debugging session is established between the electronic device and the integrated development environment, the debugging command is a command sent by the integrated development environment to the electronic device through the debugging session in response to a user operation, and a triggering event of calling a function in the second code segment through a first function call statement is detected, including: the electronic device reports the detected triggering event to the integrated development environment, and suspends execution of a thread for running program code.

For example, when a user needs to debug the application code installed on an electronic device, the electronic device can be connected to an integrated development environment (IDE), which can run on another electronic device. In this way, the user can control the debugging progress on the debugging interface of the IDE, such as clicking the StepInto control. Furthermore, the IDE can send the above-mentioned debugging command to the electronic device, triggering the electronic device to step into debugging, etc. When the electronic device runs to the first function call statement that triggers the call to the first function in the second code segment, that is, when a local function call event is triggered, the event can be reported to the IDE. After the report is completed, the execution of the corresponding thread in the application process can be suspended.

In a possible implementation of the first aspect above, the integrated development environment determines the address range of the second code segment based on the shared library related attributes reported by the electronic device to the integrated development environment through a loading completion event, and sets a breakpoint at the address of the first function, including: the integrated development environment determines the address of the first function based on the received trigger event; the integrated development environment determines that the address of the first function is within the address range of the second code segment, and generates a breakpoint setting command sent to the electronic device, the breakpoint setting command is used to instruct the electronic device to set a breakpoint at the address of the first function; the electronic device responds to the received breakpoint setting command and sets a breakpoint at the address of the first function.

For example, the integrated development environment (IDE) can predetermine the address range of the C/C++ code segment corresponding to the SO file when the program code file of the application is loaded by the electronic device, such as a shared library (SO) file. Furthermore, when receiving a local function call event reported by the electronic device, the integrated development environment (IDE) can determine whether the address of the first function called corresponding to the local function call event (e.g., the C/C++ function address) is within the above-mentioned predetermined address range. If it is, it indicates that the address of the first function can be located to the C/C++ code segment to be checked, so it can be determined to breakpoint at the address of the first function. It can be understood that the breakpoint refers to automatically setting a virtual breakpoint on the above-mentioned C/C++ function address. When the breakpoint is hit, the code line corresponding to the C/C++ function address can be highlighted on the debugging interface of the IDE, and the corresponding C/C++ code segment is displayed.

In a possible implementation of the first aspect, setting a breakpoint at the address of the first function includes: the integrated development environment sends the determined address range of the second code segment to the electronic device; the electronic device determines that the address of the first function is within the address range of the second code segment, and sends a The integrated development environment reports the address of the first function; based on the address of the first function, the integrated development environment generates a breakpoint setting command to be sent to the electronic device; and the electronic device sets a breakpoint at the address of the first function in response to the received breakpoint setting command.

For example, the integrated development environment (IDE) may also predetermine the address range of the C/C++ code segment corresponding to the shared library (SO) file loaded by the electronic device and send it to the electronic device. Then, when the electronic device detects a local function call event, it may determine whether the address of the first function called corresponding to the local function call event (e.g., the C/C++ function address) is within the above-mentioned predetermined address range. If so, it indicates that the address of the first function can be located to the C/C++ code segment to be checked, and the C/C++ function address can be reported to the IDE. The IDE may generate a breakpoint setting command, i.e., a command to set a breakpoint, to be sent to the electronic device based on the reported C/C++ function address. Then, based on the received breakpoint setting command, the electronic device may set a breakpoint at the C/C++ function address called corresponding to the local function call event.

In a possible implementation of the first aspect above, after setting a breakpoint at the address of the first function, the method further includes: receiving a command to resume thread execution sent by the integrated development environment; and resuming execution of the thread running the program code in response to the command to resume thread execution.

In a possible implementation of the first aspect above, after resuming execution of the thread running the program code, the method further includes: detecting that the thread runs to the first function and hitting a breakpoint, and controlling the thread to stop at the function entry of the first function in the second code segment.

In a second aspect, an embodiment of the present application provides an electronic device, comprising: one or more processors; one or more memories; one or more memories storing one or more programs, and when the one or more programs are executed by one or more processors, the electronic device executes the code debugging method provided in the above-mentioned first aspect and various possible implementations of the first aspect.

In a third aspect, an embodiment of the present application provides a computer-readable storage medium having instructions stored thereon. When the instructions are executed on a computer, the computer executes the code debugging method provided in the above-mentioned first aspect and various possible implementations of the first aspect.

In a fourth aspect, an embodiment of the present application provides a computer program product, including a computer program/instruction, which, when executed by a processor, implements the code debugging method provided in the above-mentioned first aspect and various possible implementations of the first aspect.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1a is a schematic diagram of a cross-language debugging scenario.

FIG. 1 b is a schematic diagram showing a code display interface corresponding to a called code file in a cross-language debugging scenario.

FIG2 shows a code example of a predefined code segment provided in Example 1 of the present application.

FIG. 3 a is a schematic diagram of a system architecture of an electronic device 100 provided in an embodiment of the present application.

FIG3 b is a schematic diagram of a debugging system provided in an embodiment of the present application.

FIG4 shows an interactive process corresponding to the implementation of a code debugging method provided in Example 1 of the present application.

FIG5 is a schematic diagram of a debugging interface for displaying JavaScript code provided in Example 1 of the present application.

FIG6 is a schematic diagram of a debugging interface for displaying C/C++ code provided in Example 1 of the present application.

FIG. 7 is a schematic diagram showing the interaction process between the electronic device 100 and the electronic device 200 provided in Embodiment 1 of the present application.

FIG8 shows an interactive process corresponding to an implementation of a code debugging method provided in Example 2 of the present application.

FIG9 is a schematic diagram showing the hardware structure of an electronic device 100 provided in an embodiment of the present application.

Detailed ways

In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described in detail below in conjunction with the accompanying drawings and specific implementation methods.

In order to facilitate those skilled in the art to understand the solutions in the embodiments of the present application, some concepts and terms involved in the embodiments of the present application are explained below.

(1) Debug session

Establishing a debugging session is a necessary step to single-step into debugging. Before the debugging session is established, most commands are prohibited except for a few option settings and commands for establishing the debugging session. Therefore, when using an integrated development environment (IDE) to debug the code of an application installed on a terminal electronic device used by a user, it is necessary to first establish a debugging session with a debugger corresponding to the debugging service installed/configured on the electronic device, and then the integrated development environment (IDE) can send various commands to the debugging service on the electronic device.

(2) Shared Object (SO)

The shared library file ends with .so. You can mark it when linking the program, and then dynamically load the required modules when the program starts running. Therefore, the application still needs the support of shared libraries when running. Shared libraries are also called dynamic libraries. When the application is packaged, it will contain the user SO file compiled by the developer, and the system SO file required for the application to run can be found in the electronic device. Directly call the system.

It is understandable that during the code compilation phase, the application source code compiled by the IDE can be compiled in different languages, and the corresponding compilation tools and output compilation products will also be different. For example, in the application code compiled by JavaScript language and C/C++ language, the JavaScript code can generate a ".abc" file, and the C/C++ code can generate an SO file. Among them, the SO file generated by the C/C++ code written by the developer when developing the application is usually also called a user SO file, which will not be elaborated here.

During the debugging/running phase, when the above application is run on the target device, the user SO required by the application will be loaded and executed.

It is understandable that during the debugging/running phase, if the developer detects problems with some code segments in the source code in the IDE, the developer can also modify the corresponding code segments in the source code on the IDE, such as modifying the C/C++ code, and recompiling to generate a new shared library (SO) file, which can be repackaged into an application installation package, such as an Android ^TM application installation package (apk) or a Harmony ^OS application installation package (hap). When re-debugging the application code, the updated installation package can be reinstalled, which will not be elaborated here.

After the target device system has loaded the SO required by the application, the corresponding debugging service (such as lldb-server) will report the library-loaded event to the IDE. Therefore, the IDE side can receive the SO file reported by the loading completion event (library-loaded), filter out the address range belonging to the user's SO, and send it to the JS debugging service in the electronic device where the debugged application is running through the newly added protocol.

FIG. 1a and FIG. 1b are schematic diagrams showing a cross-language debugging scenario.

It should be noted that the user of the electronic device to which the code debugging method provided in the embodiment of the present application is applicable can generally be the developer of the application code, and this is not limited here. Unless otherwise specified, in the embodiment of the present application, "user" and "developer" refer to the same content, both referring to a person who has a need to debug the application code.

As shown in FIG. 1 a , the debugging scenario may include an electronic device 100 on which a debugged application is running and an electronic device 200 on which an integrated development environment (IDE) is running.

Taking the electronic device 100 as a mobile phone and the electronic device 200 as a personal computer (PC) as an example, as shown in FIG1a, the debugged application installed on the mobile phone 100 may be one or more, such as App01, App02, App03, App04, etc. shown in FIG1a. When it is necessary to debug a certain application on the mobile phone 100, for example, when it is necessary to debug App01, the mobile phone 100 and the PC 200 may be connected through a data cable with a debugging port or other communication methods, and the access device may be selected on the debugging interface 210 of the integrated development environment (IDE) running on the PC 200. Referring to operation ① shown in FIG1a, the developer may select the mobile phone 100 as the access device under the device option control 211 of the debugging interface 210.

Furthermore, the developer can operate the mobile phone 100 to run App01, and click the step into debugging control 212 on the debugging interface 210 to debug the application code of App01. The area 213 displaying the debugged application code on the debugging interface 210 can correspondingly display the code being debugged.

In the debugging scenario shown in FIG. 1a above, if the debugged application code includes a cross-language call relationship, for example, the function call statement "testNapi.add(1,2);" in the 16th line of code in the JavaScript file shown in FIG. 1a indicates that a call to a C/C++ function is added in the JavaScript language. Therefore, during the debugging of the application code, if no breakpoint is added, when the code is executed to the 16th line of code in the JavaScript file shown in FIG. 1a, it will switch to the corresponding C/C++ function to continue executing the corresponding code.

At this time, the debugging interface of the IDE can be switched to display the code in the C/C++ file, such as the code displayed in area 213 of the debugging interface 220 shown in FIG. 1b. When the code in the C/C++ file is executed, the mobile phone 100 can continue to execute the code in the JavaScript file to continue the debugging process, such as continuing the 17th line of code in the JavaScript file shown in FIG. 1a, and area 213 in the debugging interface 210 of the IDE switches back to display the code in the JavaScript file accordingly.

In the debugging scenario shown in Figures 1a and 1b above, if the developer needs to check the code files that may have problems on the debugging interface of the IDE, for example, to check whether the program code corresponding to App01 has problems, it is necessary to analyze the C/C++ function called by the 16th line of code in the JavaScript code shown in Figure 1a, and find the location of the function in the C/C++ file, that is, the function address. Then, the developer can open the corresponding C/C++ file on the debugging interface of the IDE and set a breakpoint on the corresponding C/C++ function address.

As shown in FIG1b, for example, the developer can click once on the third line of code of the C/C++ file displayed by the IDE, and refer to operation ② shown in FIG1b to complete the process of setting a breakpoint. Accordingly, the third line of code with a breakpoint can display a breakpoint mark 230. Furthermore, the developer can click the StepInto control 221 on the debugging interface 220 shown in FIG1b again to trigger the mobile phone 100 to run App01 to continue the debugging process. Furthermore, when the program code of App01 runs to line 16 in the JavaScript file and jumps to line 3 in the C/C++ file, IDE can also stop at the debugging interface 220 shown in FIG. 1 b , and the developer can check whether there is any problem with the code in the C/C++ file.

However, the current method of breaking points, which requires developers to analyze call relationships, find corresponding files, and manually click code lines, is inefficient in debugging application codes that involve cross-language calls from languages such as JavaScript, Java, Python, etc. to C/C++. It requires more developer participation and a large debugging workload.

In order to solve the above problems, the present application provides a code debugging method, which is applied to electronic devices. Specifically, the method pre-sets a predefined code segment in the second code file (such as a C/C++ code file) that provides the called function (such as the C/C++ code displayed in area 213 of the debugging interface 220 in the debugging scene shown in Figure 1b above), and the predefined code segment can associate the second code file that provides the called function with the first code file that uses the called function (such as the JavaScript file corresponding to the JavaScript code displayed in area 213 of the debugging interface 210 in the debugging scene shown in Figure 1a above). Specifically, for example, for the scenarios shown in Figures 1a and 1b, the predefined code can establish an association relationship between the address of the C/C++ function called in the second code file and the function call statement that calls the C/C++ function in the first code file (such as a JavaScript file) (such as the field corresponding to the 16th line of code shown in Figure 1a). In this way, based on the association relationship established by the above process, when the electronic device executes a function call statement in the JavaScript file during the running of the program code of the debugged application, it can automatically identify the C/C++ function address associated with the field in the C/C++ file, and then automatically set a virtual breakpoint at the function address, without the developer having to analyze the function call relationship in the JavaScript code segment to determine the address of the C/C++ function that needs a breakpoint.

In this way, when the program code of the debugged application is resumed and hits the virtual breakpoint set above, the C/C++ code (the code segment shown in FIG1b) is displayed on the corresponding test interface of the integrated development environment (IDE) to which the electronic device is connected, and the C/C++ code is automatically stopped at the entry of the function corresponding to the address where the breakpoint is located (the position where the third line of code in the C/C++ code segment shown in FIG1b begins), so that it is convenient for the debugger or developer to check each line of code in the C/C++ file. For example, the developer can check whether the C/C++ code segment in the currently displayed C/C++ file has vulnerabilities to be repaired on the debugging interface 220 of the IDE shown in FIG1b above.

As an example, FIG2 shows a code example of a predefined code segment according to an embodiment of the present application.

As shown in Figure 2, the predefined code segment includes code examples for defining export object properties and registering and initializing native modules. Specifically, the code segment defines the export object property add and its C/C++ callback function Add. Therefore, calling the add property in JavaScript through the function call statement "testNapi.add(1,2);" will eventually call back to the Add function in C/C++. The specific process can include the following three steps:

① Predefine the exports object in the C/C++ code segment and add properties, and associate it with the C/C++ function called in the C/C++ code file. For example, define the add property in the exports object and associate it with the Add function in the C/C++ code segment, where the Add function serves as the callback function of add.

② Define a variable of type napi_module, such as demoModule, and assign the correct attributes, such as the ".nm_register_func" attribute shown in Figure 2.

③ Define the module registration function, for example, define the RegisterHelloModule function, which can register the demoModule defined above through the NAPI interface.

Based on the above association process, when debugging and running the application code, if the "import" part in the JavaScript code includes the loading of the SO file, such as "import testNapi from "libentry.so"" as shown in Figure 2, the system will load libenrty.so and run the RegisterHelloModule function when loading. The function will call the "Init" function assigned by the attribute ".nm_register_func". Furthermore, the Init function defines the add attribute in the exports object and returns. In this way, after the import is executed, the exports object attribute add can be loaded through the function call statement corresponding to testNapi.

For example, based on the predefined code segment shown in FIG2, the load call of the exports object attribute add in the function call statement "testNapi.add(1,2);" corresponding to the 16th line of code in the JavaScript code segment shown in FIG1a can be directly associated with the address corresponding to the called function "Add(napi_env env,napi_callback_info info)" in the 3rd line of code in the C/C++ code segment shown in FIG1b. That is, the association between the add attribute in the JavaScript code and the function Add in the C/C++ code is bound, so calling the add attribute in JavaScript will call back to the Add function in C/C++.

As shown in Figure 2, in the Init function, the properties defined on the exports object can be used in JavaScript through the import statement to obtain the export object, and then the C/C++ function can be called in JavaScript. For example, in Figure 2, the add property is declared through napi_property_descriptor, and the callback function is set to the C/C++ function Add, and finally the properties are defined on the exports object through napi_define_properties.

In addition, the code segment shown in FIG. 2 also includes a code segment for assigning relevant properties of the example module (demoModule) that loads the above export object (exports object). For example, ".nm_register_func = Init" shown in FIG. 2 is used for the IDE to run the example module based on the above parameters when obtaining the code shown in FIG. 2, thereby initializing the debugging environment including the association relationship between add and Add. For example, when the import function "import" in the JavaScript code is executed, the registration module (register_moudle) can be triggered, and the function corresponding to the above attribute ".nm_register_func = Init" (for example, Init) can be called.

It can be understood that the above-mentioned first code file and the second code file are both program code components of the called code, and the first code file can be, for example, a compiled product of a programming language such as JavaScript or Java, Python, etc. The second code file can be, for example, a compiled product of a native language such as C/C++, such as a user SO compiled by the developer of the debugged application through an integrated development environment IDE, etc. In an embodiment of the present application, the call to the pre-defined export object attribute expressed by the function call statement in the above-mentioned first code file can be called a local function call. The function in the above-mentioned second code file that is associated with the export object attribute called by the function call statement in the first code file can be called a local function.

It can be understood that the process of automatically identifying the function address associated with the function call statement based on the association relationship can be achieved, for example, by identifying whether the second code function address corresponding to the local function call event reported during the running of the program code of the debugged application is within a preset address range. For example, based on the association relationship established between the function call statement of the second code file in the first code file and the corresponding function address in the second code file, the electronic device or the IDE to which the electronic device is connected can predetermine that the function address in the association relationship in the second code file corresponds to the code segment address range in the second code file. Furthermore, when the local function call event reported during the running of the program code of the debugged application is obtained, it can be determined whether the function address corresponding to the event is within the above-determined code segment address range, and then whether the function address corresponding to the event is the function address in the second code file for which a breakpoint needs to be set.

It can be understood that the above scheme provided based on the embodiment of the present application can effectively simplify the cumbersome process of developers analyzing the calling relationship of the code called across languages, finding the called code file and opening the code file for inspection in the process of debugging the application code. When it is necessary to set breakpoints for code segments or code files compiled in native languages such as C/C++ in the program code of the debugged application, the above scheme provided based on the embodiment of the present application can automatically identify the function address of the provider code (i.e., the second code) that needs to set breakpoints during the running of the user code (i.e., the first code) and complete the process of automatically setting breakpoints, thereby helping to improve debugging efficiency.

The following takes the example that the coding language corresponding to the first code is JavaScript language and the coding language corresponding to the second code is C/C++ language as an example, and describes in detail the specific implementation process of the code debugging method provided in the embodiment of the present application in combination with the accompanying drawings.

It can be understood that the code debugging method provided in the embodiment of the present application is applicable to the electronic device 100 running the debugged application, which may include but is not limited to mobile phones, tablet computers, desktops, laptops, handheld computers, netbooks, as well as augmented reality (AR) and virtual reality (VR) devices, smart TVs, smart watches and other wearable devices, servers, mobile email devices, car equipment, portable game consoles, portable music players, reader devices, televisions in which one or more processors are embedded or coupled, or other electronic devices that can access the Internet.

In addition, the code debugging method provided in the embodiment of the present application may be applicable to an electronic device 200 running an IDE, including but not limited to a personal computer (PC), a tablet computer, a desktop computer, a laptop computer, a handheld computer, a netbook, a server, or other electronic devices embedded or coupled with one or more processors with relatively strong processing capabilities.

FIG3 a shows a schematic diagram of a system architecture of an electronic device 100 according to an embodiment of the present application.

As shown in Figure 3a, the electronic device 100 can be equipped with a distributed system architecture. The distributed system architecture may include an application layer, an application framework layer, a system service layer, and a kernel layer. It is understood that the distributed system architecture shown in Figure 3a can be HarmonyOS ^TM or other distributed systems with a software structure similar to that shown in Figure 3a, and is not limited here.

The application layer may include an application being debugged, i.e., a debugged application. The debugged application may include a native module (e.g., a JavaScript Native Module) and native code (e.g., JavaScript code). The Native module is used to provide a Native interface to the JavaScript code.

The application framework layer provides the application with a multi-language user program framework and meta-capability framework in Java/C/C++/JS, as well as a multi-language framework API for various software and hardware services. For example, a multi-language framework API in C/C++/JS can be provided for devices that also use a distributed system architecture. The APIs supported by different devices are related to the degree of componentization of the system. The application framework layer can also provide a user interface framework (such as the ArkUI framework) for the application, which is not limited here.

Among them, the ArkUI framework is a declarative UI development framework for building distributed application interfaces. The ArkUI framework can include local applications Native Application Programming Interface (NAPI). The NAPI component is a native module extension development framework with an external interface based on the Node.js N-API specification, which is used to provide an interface to C/C++ to provide access to the underlying JS engine. In the embodiment of the present application, the local function call is detected by the module and notified to the JS engine, which further notifies the JS debugging service.

The system service layer is a set of core capabilities of the distributed system, and provides services to applications through the application framework layer. The system service layer includes a set of system basic capability subsystems, which provide basic capabilities for the operation, scheduling, migration, and other operations of distributed applications on multiple devices with the distributed system shown in Figure 3a. The system basic capability subsystem set may include the Ark multi-language runtime subsystem (referred to as the Ark runtime), the public basic library subsystem, etc., which are used to provide multi-language debugging services. Among them, the Ark runtime provides C/C++/JS multi-language runtime and basic system class libraries, and also provides runtime for Java programs statically generated using the Ark compiler (i.e., the part developed using the Java language in the application or framework layer). For example, the Ark runtime can provide JS debugging services (JavaScript debugger, JS debugger), as well as JS engines, etc. Among them, the JS debugging service is used to provide debugging capabilities for JavaScript code files and is responsible for handling the debugging of JavaScript threads.

The public basic library subsystem can be used to provide C/C++ debugging services (low level debugger-sever, lldb-server), which is used to provide debugging capabilities for C/C++ code files and is responsible for handling the debugging of C/C++ threads.

It can be understood that the multi-language debugging services such as the above-mentioned JS debugging service and C/C++ debugging service are responsible for interacting with the execution threads of each code file of the debugged application.

The system service layer may also include a debugging protocol processing module (not shown in the figure), which is responsible for interacting with the IDE or debugging client, and the debugging client may be, for example, the electronic device 200 in the scenario shown in FIG. 1a above. For example, the debugging protocol processing module is responsible for receiving information such as debugging commands passed in by the IDE or debugging client. The debugging protocol processing module can parse debugging commands that comply with the universal debugging interface protocol, and send the parsed legal debugging commands to the multilingual core module for processing. The debugging protocol processing module is also used to receive debugging response information returned by the multilingual core module, and translate and encapsulate the debugging response information based on the universal debugging interface protocol, and then return the encapsulated debugging response information to the IDE or debugging client.

It can be understood that in the embodiment of the present application, the process corresponding to the debugged application may include JavaScript (JS) thread 1, C/C++ thread 1, JS thread 2, C/C++ thread 2, etc. In other embodiments, the process corresponding to the debugged application may also include Java thread 1, Java thread 2, Python thread 1, Python thread 2, etc., which is not limited here.

In some embodiments, the multi-language debugging service may also have the computing capability to identify whether the address currently loaded or debugged is within a preset address range. For example, the C/C++ debugging service may preset the address range of each line of C/C++ code in the corresponding C/C++ code file when loading the shared library corresponding to the debugged application. Furthermore, upon receiving the address of the C/C++ function corresponding to the local function call event sent by the IDE, it is possible to determine whether the address is within the above-mentioned preset address range. Furthermore, the C/C++ debugging service can automatically identify the address of the C/C++ function corresponding to the local function call event sent by the IDE, and can set a virtual breakpoint at the code position corresponding to the address. For details, please refer to the relevant description below, which will not be repeated here.

The kernel layer includes the kernel subsystem and the driver subsystem. The kernel subsystem supports the selection of suitable OS kernels for different resource-constrained devices. The driver subsystem is used to provide unified peripheral access capabilities and driver development and management frameworks. The kernel layer also includes the kernel abstract layer (KAL), which shields the differences between multiple kernels and provides basic kernel capabilities to the upper layer, including process/thread management, memory management, file system, network management, and peripheral management. I will not go into details here.

Based on the system architecture shown in FIG. 3a above, the specific implementation process of the application debugging method provided in the embodiment of the present application is described in detail below in combination with some flow charts, some schematic diagrams of the interaction between the electronic device 100 and the IDE, and some schematic diagrams of the IDE interface.

It should also be stated that the steps in the methods and processes in the embodiments of the present application are numbered for ease of reference, rather than to limit the order of precedence. If there is an order between the steps, the text description shall prevail.

FIG3 b shows a schematic diagram of a debugging system according to an embodiment of the present application.

As shown in FIG3b, the debugging system may include an electronic device 100 and an electronic device 200. The electronic device 100 may be a device equipped with the distributed system architecture shown in FIG3a. Therefore, the electronic device 100 may include a debugging service 310, a NAPI component 320, a JS engine 330 of the system service and application framework layer, and a debugged application 340 of the application layer.

Among them, the debugging service 310 may include the above-mentioned JS debugging service 311 and C/C++ debugging service 312. The NAPI component 320 may include a native engine (NativeEngine), such as a JS engine abstraction layer, which is used to unify the interface behavior of the JS engine 330 at the NAPI layer. The debugged application 340 may include a Native module 341 and a JavaScript code 342. The JavaScript code 342 may be interpreted and executed by the JS engine 330, and the C/C++ code may be packaged into a shared library (SO) file to be loaded and executed by the system.

It is understandable that in other embodiments, the above-mentioned JS debugging service 311 can also be a debugger for debugging Java, Python and other codes, which is not limited here.

The various structural functions included in the debugging service 310 and the debugged application 340 in the above electronic device 100 can refer to the relevant description of Figure 3a above, and will not be repeated here.

Continuing as shown in FIG. 3b , the electronic device 200 can run an integrated development environment IDE 201 to debug the application code of the debugged application 340 in the currently connected electronic device 100. It can be understood that the IDE 201 may include a debugging protocol processing module, as well as multi-language debugging cores such as JS debugging core (JavaScript debug core) and Native debugging core. These debugging cores can be used to receive debugging commands passed in by the debugging protocol processing module (not shown in the figure), perform related debugging operations on the corresponding debugging thread, and further feed back the results of the operation to the debugging protocol processing module for processing. The debugging protocol processing module in the IDE 201 running on the electronic device 200 can communicate feedback information with the debugging protocol processing module included in the debugging service on the electronic device 100.

Based on the debugging system shown in FIG. 3b , the following first describes in combination with Example 1 an interactive implementation method among the debugging service 310 (including JS debugging service 311 and C/C++ debugging service 312) run by the electronic device 100, the debugged application 340 and the IDE 201 run by the electronic device 200 in the above debugging system.

Example 1

FIG. 4 shows an interactive process for implementing an application debugging method according to an embodiment of the present application.

As shown in Figure 4, the interaction process involves the interaction between the IDE 201 running on the electronic device 200 in the debugging system shown in Figure 3b above, the JS debugging service 311 and C/C++ debugging service 312 included in the debugging service 310 in the electronic device 100, and the NAPI component 320 and JS engine 330 included in the debugged application 340.

Specifically, the interaction process includes the following steps:

401: IDE 201 establishes a debugging session with JS debugging service 311, and sends a command to JS debugging service 311 to set the hybrid debugging switch.

Exemplarily, when the electronic device 100 is connected to the electronic device 200, the IDE 201 running on the electronic device 200 can also establish communication with the electronic device 100, and then establish a debugging session with the JS debugging service 311 in the debugging service 310 configured on the electronic device 100. Further, after the IDE 201 establishes a debugging session with the JS debugging service 311, a command for setting a hybrid debugging switch can be sent to the JS debugging service 311 through the following protocol command:

{"method":"Debugger.setMixedDebugEnabled","params":{"enabled":true}}

Among them, the above-mentioned hybrid debugging switch can be used to control whether the JS debugging service 311 reports the detected native function call (NativeCalling) event to the IDE 201.

It can be understood that in other embodiments, the protocol command for the IDE 201 to send the setting command to the JS debugging service 311 may also adopt other command forms, which are not limited here.

402: JS debugging service 311 sets the hybrid debugging switch.

Exemplarily, the JS debugging service 311 responds to the received command, i.e., the IDE 201 executes the command for setting the hybrid debugging switch sent in the above step 401, and sets the above hybrid debugging switch.

Afterwards, when the JS debugging service 311 receives the local function call event reported by the JS engine 330, the C/C++ function address can be reported to the IDE 201 through the local function call event. For details, please refer to the execution process of the following steps 409 to 411, which will not be repeated here. Among them, the above-mentioned local function call event is used to call the native code. In the embodiment of the present application, the native code can be the code developed in the C/C++ language, and the JavaScript code that calls the native code developed in the C/C++ language can be the main language used for application development. Therefore, calling the function exported by the Native module in the JavaScript code can be called a local function call.

403: IDE 201 establishes a debugging session with C/C++ debugging service 312.

Exemplarily, after the IDE 201 running on the electronic device 200 establishes communication with the electronic device 100, if the IDE 201 wants to send a command to the C/C++ debugging service 312, it can also establish a debugging session with the C/C++ debugging service 312. No further details will be given here.

404: After the C/C++ debugging service 312 monitors that the shared library (SO) that the application process depends on has been loaded, it reports the relevant properties of the loaded SO.

For example, the shared library (SO) is generally a coding product of a compiled language such as C/C++ or rust, so in the application code developed based on JavaScript/C/C++, the code in the SO is generally C/C++ code. In other words, the SO loaded by the C/C++ debugging service 312 can be C/C++ code, and is usually a user SO written by the developer of the application. The C/C++ debugging service 312 can obtain the related properties of the shared library (SO) loaded by the application process and report it through library-loaded. Therefore, the execution process of this step 404 is: after the IDE 201 and the C/C++ debugging service 312 establish a native debugging session, the debugging session includes mixed debugging and native debugging, and the C/C++ debugging service 312 reports the SO loading completion event (library-loaded) to the IDE 201, and the content reported by the event includes the so name, loading address, and code segment address range. In addition, the C/C++ code segment corresponding to the shared library (SO) can pre-define the export object and the corresponding added properties, and the JavaScript code segment can correspond to the function call statement that imports the pre-defined export object. That is, the function call statement in the JavaScript code segment has established an association relationship with the corresponding function address in the C/C++ code segment. Therefore, the shared library (SO) related attributes reported by the C/C++ debugging service 312 through library-loaded may include attributes such as the name of the SO file, the loading address, and the address range of the called C/C++ code segment.

When debugging an application, the C/C++ debugger 312 can monitor the system's loading of shared libraries, and report the loaded SO-related properties, such as the name of the SO file, the loading address, the address range of the code segment, and other properties, to the IDE 201 through the library-loaded event.

405: C/C++ debugging service 312 reports the loading completion event to IDE 201.

Exemplarily, after the C/C++ debugging service 312 completes loading of the shared library (SO), it can report a loading completion (library-loaded) event to the IDE 201. The content of the library-loaded event reported by the C/C++ debugging service 312 can refer to the following example: library-loaded, hostname = "\data\storage\el1\bundle\libs\arm\libentry.so", loaded_addr = "0x00000000d4c41000", codeRange = "0x00000000d4c43c44 ~ 0x00000000d4c480e0"

Among them, hostname corresponds to the path of the libentry.so file stored in the electronic device reported. loaded_addr corresponds to the first address of libentry.so loaded. codeRange corresponds to the address range corresponding to the C/C++ code segment reported. The above address or address range is expressed in hexadecimal. In other embodiments, the above first address or address range can also be expressed in decimal or other digits, which is not limited here.

406: IDE 201 determines the first address range corresponding to the loaded C/C++ code segment.

Exemplarily, IDE 201 can obtain the address range corresponding to the C/C++ code segment as the first address range based on the received loading completion (library-loaded) event reported by the C/C++ debugging service 312. The address range can be used as a basis for judgment in the judgment process of executing the following step 413. For details, please refer to the relevant description in the following step 413, which will not be repeated here.

As an example, continuing to refer to the aforementioned example, the first address range determined by the above IDE 201 may be, for example, "0x00000000d4c43c44～0x00000000d4c480e0", which may be determined based on codeRange="0x00000000d4c43c44～0x00000000d4c480e0" in the loading completion event (library-loaded) reported by the C/C++ debugging service 312 in the above step 405.

407: IDE 201 detected a user operation of single-stepping into debugging.

For example, a user can click a "StepInto" control on the debugging interface displayed when the electronic device 200 runs the IDE, i.e., a single-step into debugging control/button, and accordingly, the IDE 201 can detect the user operation of single-step into debugging. The user who inputs the operation to the IDE 201 can be, for example, the developer.

As an example, FIG5 shows a schematic diagram of a debugging interface for displaying JavaScript code according to an embodiment of the present application.

As shown in FIG5 , after the electronic device 200 runs the IDE 201 and connects to the device where the debugged application 340 runs, the debugging interface 510 can be displayed. After the IDE 201 executes the above steps 401 and 403, if the user clicks the StepInto control 511 on the debugging interface 510, the debugging process of the target application, i.e., the debugged application, can be started. At this time, the IDE 201 running on the electronic device 200 can detect the user operation of single-step into debugging.

It is understood that the user can select the 16th line of code in the JavaScript code segment displayed on the debugging interface 510 shown in FIG5 , and then click the StepInto control 511. The user can also manually add a breakpoint on the line of code in advance, and the breakpoint mark 512 can be displayed accordingly on the debugging interface 510. In other embodiments, the operation of triggering the single-step into debugging at the corresponding position of the function call statement in the JavaScript code segment (such as the 16th line of code mentioned above) can also be other, which is not limited here.

408: IDE 201 sends a StepInto command to JS debugging service 311.

Exemplarily, after detecting the StepInto operation, the IDE 201 may send a debugging command to the JS debugging service 311 provided by the debugging service in the electronic device 100. The debugging command may stop at the entrance of the called function.

409: The NAPI component 320 detects a local function call and generates a local function call event.

As mentioned above, the Native module 321 is usually a module developed in C/C++, and its function is to provide a native interface to the JavaScript code. JavaScript imports the exports object of the Native module through "import" and calls back to the C/C++ function. Furthermore, when the JS debugging service 311 debugs and runs the JavaScript code to the above-mentioned native function call, it can trigger the interface to obtain the native function call (NativeCalling) event reported by the debugged application 340.

410 : The NAPI component 320 reports the local function call event to the JS debugging service 311 through the JS engine 330 .

Exemplarily, the NAPI component 320 may report the local function call event generated by detecting the local function call to the JS debugging service 311 through the JS engine 330. As an example, the method of reporting the local function call event may refer to the following example:

{"method":"Debugger.NativeCalling","params":{"NativeAddress":0xd4c43de8}}

Among them, "NativeAddress": 0xd4c43de8 represents the memory address of the C/C++ function to be called. In other embodiments, the method of reporting the native function call event can also be other, which is not limited here.

411: JS debugging service 311 reports local function call events to IDE 201.

Exemplarily, after the JS debugging service 311 receives the local function call event reported by the JS engine 330, based on the indication that the hybrid debugging switch set in the above step 402 is in the on state, it can continue to report the local function call event to the IDE 204.

412: JS debugging service 311 suspends thread execution.

Exemplarily, the JS debugging service 311 can further suspend the thread execution after executing the above step 411 in response to the received local function call event. This is because after the JS debugging service 311 reports the address in the above step 411, the IDE usually needs to set a virtual breakpoint for the C/C++ function to be called before the thread can continue to execute, that is, call the corresponding C/C++ callback function. Therefore, the JS debugging service 311 can execute this step 412 to suspend the thread execution after completing the address reporting process in the above step 411.

It can be understood that the above-mentioned method of suspending execution can be achieved, for example, by executing sleep, etc., and is not limited here.

413: IDE 201 determines whether the C/C++ function address determined based on the local function call event is within the first address range. If the determination result is yes, that is, the C/C++ function address is within the first address range, the following step 414 may be executed; if the determination result is no, that is, the C/C++ function address is not within the first address range, the following step 415 may be executed.

Exemplarily, after receiving a local function call event reported by the JS debugging service 311, IDE 201 can determine whether the address is within the code segment address range of the user SO (i.e., the first address range mentioned above) based on the C/C++ function address reported in the event, wherein the address range is reported to IDE 201 via the above-mentioned library-loaded event.

Referring to FIG. 2 above, the C/C++ function may be the Add function, which is the native callback function of add in the JavaScript code, and add is the property of the object imported by "import" in the JavaScript code. Referring to the example in the aforementioned step 410, the C/C++ function address may be, for example, "0xd4c43de8", which is actually the hexadecimal address "0x0000000d4c43de8". In other embodiments, the C/C++ function address reported by the JS debugging service 311 may also be, for example, an address expressed in decimal, etc., which is not limited here.

Furthermore, after determining the above-mentioned C/C++ function address, IDE 201 can compare the address with the first address range determined when executing the above-mentioned step 406 to determine whether the C/C++ function address is within the first address range.

As an example, referring to the above example, the first address range previously determined by IDE 201 is, for example, "0x00000000d4c43c44～0x00000000d4c480e0", and the C/C++ function address received by IDE 201 is, for example, "0xd4c43de8", i.e., "0x0000000d4c43de8". By comparing the size of "0x0000000d4c43de8" with the lower limit threshold "0x00000000d4c43c44" of the first address range, and with the upper limit threshold "0x00000000d4c480e0" of the first address range, it can be determined that the C/C++ function address is within the first address range. Therefore, IDE 201 can continue to execute the following step 414 to send a command to set a breakpoint.

414: IDE 201 sends a command to set a breakpoint to C/C++ debugging service 312.

Exemplarily, when IDE 201 executes the above step 413 to determine that the received C/C++ function address is within the first address range, it can send a command to set a breakpoint to the C/C++ debugging service 312 that has established a debugging session.

Accordingly, in response to the received command, the C/C++ debugging service 312 may set a breakpoint at the corresponding address of the debugged process.

After sending the breakpoint setting command and completing the breakpoint setting, IDE 201 can continue to execute the following step 416 and send the reply thread execution command.

415: IDE 201 ignored the received C/C++ function address.

Exemplarily, when IDE 201 determines that the received C/C++ function address is not within the first address range during the execution of step 413, the received C/C++ function address may be ignored. At this time, IDE 201 may continue to execute step 416 to send a command to resume thread execution to JS debugging service 311.

416: IDE 201 sends a command to resume thread execution to JS debugging service 311.

Exemplarily, after executing the above step 414 or 415, IDE 201 may continue to execute this step 416, sending a command to resume thread execution to JS debugging service 311, instructing JS debugging service 311 to resume thread execution.

417: JS debugging service 311 resumes thread execution.

Exemplarily, the JS debugging service 311 may continue to run the JavaScript code file or run the C/C++ code in response to the received command to resume the execution of the execution thread, which will not be described in detail here.

418: The C/C++ debugging service 312 reports the message of hitting the breakpoint to the IDE 201.

Exemplarily, after the thread resumes execution, it runs to the C/C++ callback function and hits the virtual breakpoint. Specifically, after the thread resumes execution, the previously suspended C/C++ callback function can continue to run. If the C/C++ debugging service 312 sets a breakpoint at the address corresponding to the above function after IDE 201 executes the above step 414, the breakpoint can be hit. At this time, the C/C++ debugging service 312 can report the message of hitting the breakpoint to IDE 201 through the established debugging session. After the breakpoint is hit, the C/C++ function entry line corresponding to the debugging interface of IDE 201 can be highlighted or displayed in other eye-catching ways.

It can be understood that the above-mentioned "hitting" virtual breakpoint or breakpoint, as the name implies, means that when the code of the line marked by the breakpoint is executed, the C/C++ debugging service (lldb-server) recognizes the breakpoint and pauses the thread execution. The above-mentioned "virtual breakpoint" and "breakpoint" can be understood as stop marks with the same function, which may or may not be the same in different marking forms. I will not elaborate on them here.

FIG6 shows a schematic diagram of a debugging interface for displaying C/C++ codes according to an embodiment of the present application.

As shown in FIG6 , when the IDE 201 running on the electronic device 200 receives a feedback message of hitting a breakpoint, the debugging interface of the IDE 201 can automatically stop at the code line corresponding to the entry address of the C/C++ callback function and display the code segment in the C/C++ file, such as the C/C++ code segment displayed by the debugging interface 610 shown in FIG6 . At the same time, the code line corresponding to the entry address of the C/C++ callback function when the breakpoint is hit can be highlighted or displayed in other eye-catching forms.

419: IDE 201 sends a command to delete the breakpoint to C/C++ debugging service 312.

Exemplarily, after receiving the message of the breakpoint being hit reported by the JS debugging service 311, the IDE 201 may also send a command to delete the set breakpoint to the C/C++ debugging service 312. In this way, the breakpoint mark set in the second code file or the C/C++ code file can be cleared in time during the debugging process, so as to avoid the problem that when the JavaScript code file or the C/C++ code file is run again after the code problem is repaired, the JS debugging service 311 repeatedly stops at the position of the breakpoint mark, resulting in reduced debugging efficiency.

It can be understood that in some embodiments, after a code debugging is completed, if the hybrid debugging switch is not turned off, then after executing the above step 418, the above step 419 may not be executed, so that when the application code is debugged and run again, it can automatically stop at the set virtual breakpoint, which is conducive to improving the efficiency of repeated debugging. In other embodiments, after a code debugging is completed, if the hybrid debugging switch is turned off, then after executing the above step 418, the above step 419 can be continued to be executed to delete the breakpoint, so that when the application code is debugged and run again, the above steps 401 to 418 can be re-executed to complete the process of automatically adding breakpoints and hitting breakpoints, which is conducive to improving debugging efficiency.

The interaction process of steps 401 to 419 shown in FIG. 4 can be summarized as a schematic diagram of the interaction process between the electronic device 100 and the electronic device 200 shown in FIG. 7 below.

FIG. 7 shows an interaction process between an electronic device 100 and an electronic device 200 in a debugging system according to an embodiment of the present application.

It is understood that the process of the debugged application may include multiple threads. For the debugged application written in multiple languages, each thread may include cross-language code calls during execution. For example, a thread executing JavaScript code may include a call to a C/C++ function. In other embodiments, cross-language code calls may also occur in cross-threaded running scenarios, which are not limited here.

As an example, the JavaScript code running in a thread of the debugged application process includes a call to C/C++ code, so the execution process of the thread may be, for example, to first execute the JavaScript code segment, and when the execution reaches the local function call position, it may jump to execute the called C/C++ code segment, and then jump back to execute the JavaScript code after the execution is completed. In this scenario, the interaction process shown in FIG7 mainly includes the following four stages:

Phase ①: After the integrated development environment (IDE) running on the electronic device 200 establishes a debugging session with the JS debugging service (JS debugger) running on the electronic device 100, it can send a protocol command to the JS debugging service to instruct the JS debugger to set the hybrid debugging switch. Accordingly, after the JS debugging service completes the setting of the hybrid debugging switch, the switch can be set to the "on" state, and the switch can be set to "off" when the debugging task does not need to be performed.

Phase ②: After the IDE establishes a debugging session with the C/C++ debugging service (lldb-server) running on the electronic device 100, the lldb-server can report to the IDE the loading completion event of the shared library (SO). Accordingly, the IDE can obtain information about all shared libraries (SO) loaded by the debugged application process, including system SOs and user SOs developed by developers.

Phase ③: During the debugging process, when the user clicks the single-step into the debugging control (StepInto) on the IDE debugging interface, if the JS engine in the electronic device 100 detects a native function call during the execution of the JavaScript code, a native function call (NativeCalling) event can be reported to the IDE. In addition, the JS debugging service can send the address corresponding to the C/C++ function to the IDE in the reported event, and suspend the thread and pause the execution of the code. In other embodiments, after the JS debugging service reports the native function call event, the IDE can also send a command to stop the thread execution to the JS debugging service, such as the debugger.pause command, to instruct the JS debugging service to stop the thread execution, which is not limited here.

Phase ④: After receiving the NativeCalling event reported by the JS debugger, the IDE can determine whether the C/C++ function address reported with the event is within the determined code segment address range of the user SO. If so, the IDE can set a virtual breakpoint at the code location corresponding to the address, such as the entry of the C/C++ function, through the lldb-server. After that, the IDE can send a resume command to the JS debugger. When the thread execution is resumed and runs to the C/C++ callback function corresponding to the JavaScript method, the above breakpoint will be hit, and the thread will be suspended again and stop at the function entry.

It can be understood that based on the execution process of the interaction flow shown in FIG. 4 or the interaction process between the electronic device 100 and the electronic device 200 in the debugging system shown in FIG. 7, the code debugging method provided in the embodiment of the present application can realize the process of using the IDE to debug the application code, and automatically set breakpoints for the application code written in multiple languages. In this way, the debugging process can make the debugging interface of the IDE automatically stop at the called C/C++ code file, for example, stop at the local function call location.

The corresponding indicated code position and the code in the C/C++ file corresponding to the called C/C++ function are displayed, so that developers can quickly locate cross-language program code, check code problems and repair them, which is conducive to improving debugging efficiency.

Based on the debugging system shown in FIG. 3b , another interaction implementation method between the debugging service 310 running on the electronic device 100, the debugged application 340 and the IDE 201 running on the electronic device 200 in the above debugging system will be described below in conjunction with Example 2.

Example 2

Different from the interaction process shown in FIG. 4 in the above-mentioned embodiment 1, in the embodiment of the present application, the electronic device 100 running the debugged application 340 can execute the related processes of step 406 and steps 413 to 415 shown in the above-mentioned FIG. 4 .

Specifically, as shown in FIG8 , the interaction process may include the following steps:

FIG8 shows an interactive process for implementing an application debugging method according to an embodiment of the present application.

As shown in Figure 8, the interaction process involves the interaction between the IDE 201 running on the electronic device 200 in the debugging system shown in Figure 3b above, the JS debugging service 311 and C/C++ debugging service 312 included in the debugging service 310 in the electronic device 100, and the NAPI component 320 and JS engine module 330 provided by the system.

Specifically, the interaction process includes the following steps:

801: IDE 201 establishes a debugging session with JS debugging service 311, and sends a command to JS debugging service 311 to set the hybrid debugging switch.

802: JS debugging service 311 sets the hybrid debugging switch.

803: IDE 201 establishes a debugging session with C/C++ debugging service 312.

804: After the C/C++ debugging service 312 monitors that the shared library (SO) that the application process depends on has been loaded, it reports the relevant properties of the loaded SO.

805: C/C++ debugging service 312 reports the loading completion event to IDE 201.

The execution process of the above steps 801 to 805 is the same as the execution process of steps 401 to 405 in the above embodiment 1. For details, please refer to the relevant descriptions of steps 401 to 405 in the above embodiment 1, and no further details will be given here.

806: IDE 201 sends the first address range corresponding to the C/C++ code segment determined based on the loading completion event to the JS debugging service 311.

Exemplarily, in response to the received loading completion event, IDE 201 can determine the code segment address range corresponding to the shared library (i.e., user SO) loaded by the C/C++ debugging service 312. In the embodiment of the present application, the user SO is, for example, C/C++ code. Therefore, the address range determined by IDE 201 is the first address range corresponding to the C/C++ code segment. Furthermore, IDE 201 can send the first address range to JS debugging service 311 for executing the following step 814. For details, please refer to the relevant description in the following step 814, which will not be repeated here.

807: IDE 201 detected a user operation to single-step into debugging.

808: IDE 201 sends a StepInto command to JS debugging service 311.

809: The NAPI component 320 detects a local function call and generates a local function call event.

810 : The NAPI component 320 reports the local function call event to the JS debugging service 311 through the JS engine 330 .

811: JS debugging service 311 reports local function call events to IDE 201.

812: JS debugging service 311 suspends thread execution.

The execution process of the above steps 807 to 812 is the same as the execution process of steps 407 to 412 in the above embodiment 1. For details, please refer to the relevant descriptions of steps 407 to 412 in the above embodiment 1, and no further details will be given here.

813: IDE 201 sends the C/C++ function address determined based on the local function call event to the JS debugging service 311.

Exemplarily, in the embodiment of the present application, IDE 201 can determine the detected C/C++ function address corresponding to the local function call event reported by the JS debugging service 311 based on the event, and forward the address to the JS debugging service 311, so that the JS debugging service 311 can continue to execute the judgment process of the following step 814.

814: The JS debugging service 311 determines whether the C/C++ function address is within the first address range. If the determination result is yes, that is, the C/C++ function address is within the first address range, the following step 815 may be executed; if the determination result is no, that is, the C/C++ function address is not within the first address range, the following step 817 may be executed.

Exemplarily, the JS debugging service 311 may compare the received C/C++ function address with the first address range determined when executing the above step 806 to determine whether the C/C++ function address is within the first address range. For specific examples, reference may be made to the relevant description in step 413 of the above embodiment 1, which will not be described in detail here.

815: JS debugging service 311 reports the local function address to IDE 201.

Exemplarily, when the JS debugging service 311 determines that the C/C++ function address is within the first address range, that is, when the judgment result corresponding to the above step 814 is yes, it determines the native function address (NativeAddress), that is, the address of the above C/C++ function in the C/C++ code segment. At this time, the JS debugging service 311 can report the native function address to the IDE 201.

816: IDE 201 sends a command to set a breakpoint to C/C++ debugging service 312.

The execution process of the above step 816 is the same as the execution process of step 414 in the above embodiment 1. For details, please refer to the relevant description of step 414 in the above embodiment 1, which will not be repeated here.

After sending the breakpoint setting command and completing the breakpoint setting, IDE 201 can continue to execute the following step 818 and send the reply thread execution command.

817: The JS debugging service 311 ignores the received C/C++ function address.

Exemplarily, when the JS debugging service 311 determines that the received C/C++ function address is not within the first address range during the execution of the above step 814, the received C/C++ function address may be ignored. At this time, the IDE 201 may continue to execute the following step 818 to send a command to the JS debugging service 311 to resume thread execution.

818: IDE 201 sends a command to resume thread execution to JS debugging service 311.

The execution process of the above step 818 is the same as the execution process of step 416 in the above embodiment 1. For details, please refer to the relevant description of step 416 in the above embodiment 1, which will not be repeated here.

819: JS debugging service 311 resumes thread execution.

The execution process of the above step 819 is the same as the execution process of step 417 in the above embodiment 1. For details, please refer to the relevant description of step 417 in the above embodiment 1, which will not be repeated here.

820: JS debugging service 311 reports the message of hitting the breakpoint to IDE 201.

The execution process of the above step 820 is the same as the execution process of step 418 in the above embodiment 1. For details, please refer to the relevant description of step 418 in the above embodiment 1, which will not be repeated here.

821: IDE 201 sends a command to delete the breakpoint to C/C++ debugging service 312.

The execution process of the above step 820 is the same as the execution process of step 419 in the above embodiment 1. For details, please refer to the relevant description of step 419 in the above embodiment 1, which will not be repeated here.

It can be understood that based on the execution process of the interactive flow shown in FIG8 above, the code debugging method provided in the embodiment of the present application can also realize the process of using IDE to debug application code, automatically setting breakpoints for application code written in multiple languages. In this way, the debugging process can make the debugging interface of the IDE automatically stop at the called C/C++ and other code files, for example, stop at the code position corresponding to the indicated local function call position, and display the code in the C/C++ file corresponding to the called C/C++ function, so as to facilitate developers to quickly locate cross-language program code, check code problems and repair them, which is conducive to improving debugging efficiency.

FIG9 shows a schematic diagram of the hardware structure of an electronic device 100 according to an embodiment of the present application.

The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile Communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, button 190, motor 191, indicator 192, camera 193, display screen 194, and subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, etc.

It is to be understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

In addition, it is understandable that the electronic device 200 in the debugging system shown in FIG. 3 b may also have the hardware structural components shown in FIG. 9 , or may have more or fewer components than those shown in FIG. 9 , or may combine certain components, or may split certain components, or may have different component arrangements. This is not limited here.

The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and/or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated in one or more processors.

The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

In the embodiment of the present application, the processor 110 of the electronic device 100 can generate a control signal through the controller to control the electronic device 100 provided in the above embodiment 1 or embodiment 2 to implement each interaction step of the code debugging method during the interaction with the IDE running on the electronic device 200. For details, please refer to the relevant description of the interaction process shown in Figure 4 of the above embodiment 1 or the interaction process shown in Figure 8 of the above embodiment 2, which will not be repeated here.

The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

In some embodiments, the processor 110 may include one or more interfaces. The interface may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver/transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input/output (GPIO) interface, a subscriber identity module (SIM) interface, and/or a universal serial bus (USB) interface, etc.

The USB interface 130 is an interface that complies with USB standard specifications, and may be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 130 may be used to connect a charger to charge the electronic device 100, and may also be used to transmit data between the electronic device 100 and a peripheral device.

It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present invention is only a schematic illustration and does not constitute a structural limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

The charging management module 140 is used to receive charging input from the charger. The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charging management module 140 to power the processor 110, the internal memory 121, the display screen 194, the camera 193, and the wireless communication module 160.

The wireless communication function of the electronic device 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of antennas. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

The mobile communication module 150 can provide solutions for wireless communications including 2G/3G/4G/5G etc. applied to the electronic device 100. The wireless communication module 160 can provide solutions including wireless local area networks (WLANs, Wireless communication solutions such as WLAN (such as wireless fidelity (Wi-Fi) network), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared technology (IR), etc.

In some embodiments, the antenna 1 of the electronic device 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the electronic device 100 can communicate with the network and other devices through wireless communication technology. The above wireless communication technology may include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, and/or IR technology. The above-mentioned GNSS may include the global positioning system (GPS), the global navigation satellite system (GLONASS), the Beidou navigation satellite system (BDS), the quasi-zenith satellite system (QZSS) and/or the satellite based augmentation system (SBAS).

The electronic device 100 implements the display function through a GPU, a display screen 194, and an application processor.

The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. In some embodiments, the electronic device 100 may include 1 or N display screens 194, where N is a positive integer greater than 1.

The electronic device 100 can realize the shooting function through ISP, camera 193, video codec, GPU, display screen 194 and application processor.

The ISP is used to process data fed back by the camera 193. The camera 193 is used to capture static images or videos. In some embodiments, the electronic device 100 may include 1 or N cameras 193, where N is a positive integer greater than 1.

The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, files such as music and videos can be stored in the external memory card.

The internal memory 121 can be used to store computer executable program codes, which include instructions. The internal memory 121 can include a program storage area and a data storage area. Among them, the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area can store data created during the use of the electronic device 100 (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (universal flash storage, UFS), etc. The processor 110 executes various functional applications and data processing of the electronic device 100 by running instructions stored in the internal memory 121 and/or instructions stored in a memory provided in the processor.

In an embodiment of the present application, the processor 110 of the electronic device 100 can implement the debugging service in the electronic device 100 and the functions of each module in the debugged application provided in the above-mentioned embodiment 1 or embodiment 2 by running relevant instructions for debugging application code stored in the internal memory 121 or stored in a memory provided in the processor. These functions can be used to implement the code debugging method provided in the embodiment of the present application.

The electronic device 100 can implement audio functions such as music playing and recording through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D, and the application processor.

The pressure sensor 180A is used to sense the pressure signal and can convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A can be set on the display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, capacitive pressure sensors, etc. The capacitive pressure sensor can be a parallel plate including at least two conductive materials. When a force acts on the pressure sensor 180A, the capacitance between the electrodes changes. The electronic device 100 determines the intensity of the pressure according to the change in capacitance. When a touch operation acts on the display screen 194, the electronic device 100 detects the intensity of the touch operation according to the pressure sensor 180A. The electronic device 100 can also calculate the position of the touch according to the detection signal of the pressure sensor 180A. In some embodiments, touch operations acting on the same touch position but with different touch operation intensities can correspond to different operation instructions. For example: when a touch operation with a touch operation intensity less than the first pressure threshold acts on the short message application icon, an instruction to view the short message is executed. When a touch operation with a touch operation intensity greater than or equal to the first pressure threshold acts on the short message application icon, an instruction to create a new short message is executed.

The acceleration sensor 180E can detect the magnitude of the acceleration of the electronic device 100 in all directions (generally three axes). When the electronic device 100 is stationary, the magnitude and direction of gravity can be detected. It can also be used to identify the posture of the electronic device and is applied to applications such as horizontal and vertical screen switching and pedometers.

The fingerprint sensor 180H is used to collect fingerprints. The electronic device 100 can use the collected fingerprint characteristics to implement fingerprint unlocking, access application locks, fingerprint photography, fingerprint call answering, etc.

The touch sensor 180K is also called a "touch control device". The touch sensor 180K can be set on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, also called a "touch control screen". The touch sensor 180K is used to detect touch operations acting on or near it. The touch sensor can pass the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 194. In other embodiments, the touch sensor 180K can also be set on the surface of the electronic device 100, which is different from the position of the display screen 194.

The key 190 includes a power key, a volume key, etc. The key 190 may be a mechanical key or a touch key. The electronic device 100 may receive key input and generate key signal input related to user settings and function control of the electronic device 100.

Motor 191 can generate vibration prompts. Motor 191 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback.

The indicator 192 may be an indicator light, which may be used to indicate the charging status, power changes, messages, missed calls, notifications, etc.

The SIM card interface 195 is used to connect a SIM card. The SIM card can be connected to or disconnected from the electronic device 100 by inserting the SIM card into or removing the SIM card from the SIM card interface 195 .

References to "one embodiment" or "an embodiment" in the specification mean that the specific features, structures, or characteristics described in conjunction with the embodiment are included in at least one exemplary implementation or technology disclosed according to the embodiment of the present application. The appearance of the phrase "in one embodiment" in various places in the specification does not necessarily all refer to the same embodiment.

The disclosure of the embodiment of the present application also relates to an operating device for executing the text. The device can be specially constructed for the required purpose or it can include a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program can be stored in a computer-readable medium, such as, but not limited to any type of disk, including a floppy disk, an optical disk, a CD-ROM, a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an EPROM, an EEPROM, a magnetic or optical card, an application-specific integrated circuit (ASIC) or any type of medium suitable for storing electronic instructions, and each can be coupled to a computer system bus. In addition, the computer mentioned in the specification may include a single processor or may be an architecture involving multiple processors for increased computing power.

In addition, the language used in this specification has been primarily selected for readability and instructional purposes and may not be selected to describe or limit the disclosed subject matter. Therefore, the present application embodiment disclosure is intended to illustrate rather than limit the scope of the concepts discussed herein.

Claims (10)

1. A code debugging method is applied to an electronic device, wherein a program code to be debugged running on the electronic device includes a first code segment written in a first language, the first code segment includes a first function call statement that calls a second code segment written in a second language, and

   The method comprises:

   In response to the received debugging command, running the debugged program code;

   During the execution of the program code, a triggering event of calling a function in the second code segment through a first function call statement is detected;

   Determining, based on an association relationship between the first function call statement and the first function called in the second code segment, whether the address of the first function satisfies a breakpoint triggering condition;

   Set a breakpoint at the address of the first function.
2. The method according to claim 1, characterized in that the association relationship between the first function call statement and the first function called in the second code segment is determined by:

   defining an export object in the second code segment, and defining and initializing a first attribute for the export object, wherein the first attribute corresponds to a first function call statement in the first code segment;

   Setting the first function called in the second code segment as a callback function of the first attribute, and establishing an association relationship between the first attribute and the first function;

   The first attribute of the export object is loaded in the first code segment, and the association relationship between the first function call statement and the first function called in the second code segment is determined.
3. The method according to claim 2, wherein the triggering condition for satisfying the breakpoint includes:

   It is determined that the address of the first function is within a predetermined address range of the second code segment, wherein the address range of the second code segment is determined based on a shared library-related attribute corresponding to the program code loaded by the electronic device.
4. The method according to claim 3 is characterized in that a debugging session is established between the electronic device and the integrated development environment, the debugging command is a command sent by the integrated development environment to the electronic device through the debugging session in response to a user operation, and

   The detecting a triggering event of calling a function in the second code segment through a first function calling statement comprises:

   The electronic device reports the detected trigger event to the integrated development environment and suspends execution of a thread for running the program code.
5. The method according to claim 4, characterized in that the integrated development environment determines the address range of the second code segment based on the shared library related attributes reported by the electronic device to the integrated development environment through the loading completion event, and

   Setting a breakpoint at the address of the first function includes:

   The integrated development environment determines the address of the first function based on the received trigger event;

   The integrated development environment determines that the address of the first function is within the address range of the second code segment, and generates a breakpoint setting command to be sent to the electronic device, wherein the breakpoint setting command is used to instruct the electronic device to set a breakpoint at the address of the first function;

   The electronic device sets a breakpoint at the address of the first function in response to the received breakpoint setting command.
6. The method according to claim 5, characterized in that setting a breakpoint at the address of the first function comprises:

   The integrated development environment sends the determined address range of the second code segment to the electronic device;

   The electronic device determines that the address of the first function is within the address range of the second code segment, and reports the address of the first function to the integrated development environment;

   The integrated development environment generates a breakpoint setting command to be sent to the electronic device based on the address of the first function;

   In response to the received breakpoint setting command, the electronic device sets a breakpoint at the address of the first function.
7. The method according to any one of claims 4 to 6, characterized in that, after setting a breakpoint on the address of the first function, the method further comprises:

   receiving a command for resuming thread execution sent by the integrated development environment;

   In response to the command to resume thread execution, execution of the thread running the program code is resumed.
8. The method according to any one of claims 1 to 7, characterized in that after resuming execution of the thread running the program code, the method further comprises:

   It is detected that the thread runs to the first function and hits the breakpoint, and the thread is controlled to stop at the function entry of the first function in the second code segment.
9. An electronic device, characterized in that it comprises: one or more processors; one or more memories; the one or more memories store one or more programs, and when the one or more programs are executed by the one or more processors, the electronic device executes the code debugging method described in any one of claims 1 to 8.
10. A computer-readable storage medium, characterized in that instructions are stored on the storage medium, and when the instructions are executed on a computer, the computer executes the code debugging method according to any one of claims 1 to 8.