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

Abstract

The application relates to the computer technical field, in particular to a code debugging method, an electronic device and a computer readable storage medium. The method comprises the following steps: 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 through a first function calling statement; based on an association relationship between the first function calling statement and the called first function in the second code segment, determining that an address of the first function satisfies a trigger condition of setting a breakpoint; and setting the breakpoint at the address of the first function. In this way, the purpose of automatically setting a breakpoint in a code segment to be debugged and checked can be achieved. When the breakpoint is hit during the resuming execution of the program code, a corresponding code debugging interface can display the code segment code corresponding to the breakpoint for the user to check, so that the debugging efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically to a code debugging method, an electronic device, and a computer-readable storage medium. Background Technology

[0002] When developing applications (Apps), developers often use integrated development environments (IDEs). An IDE is an application that integrates various development tools to provide a program development environment, typically including an editor, compiler, debugger, and graphical user interface.

[0003] Currently, the development trend of IDEs is to support multiple programming languages, such as C / C++, Java, JavaScript, Python, etc. The combination of multiple programming languages ​​used in development will also differ depending on the application being used on different operating systems. For example, in HarmonyOS... TM Operating System (HarmonyOS) TM In the development of applications, JavaScript is typically used to write the user interface (UI) logic, while performance-critical functionalities can be written in C / C++. This results in a multi-language development scenario combining C / C++ and JavaScript. In such scenarios, debugging the code of different parts of the application involves cross-language debugging of both JavaScript and C / C++. How to quickly identify and resolve issues in the JavaScript and C / C++ code during cross-language debugging is a crucial problem that needs to be addressed in multi-language development.

[0004] Currently, in the process of mixing multiple languages, developers need to frequently switch programming languages ​​for debugging, which is cumbersome and not conducive to quickly and accurately locating specific problems. For example, some applications' JavaScript files may call C / C++ functions. If it is necessary to stop at the C / C++ file's runtime interface to check code problems, it is necessary to manually analyze the JavaScript-to-C / C++ call relationship and find the corresponding file. Then, a breakpoint can be added at a certain line of code in the found C / C++ file. In this way, the application being debugged can only stop when it reaches the line of code marked by the breakpoint in the C / C++ file. When there are many such cross-language code calls, the debugging workload will inevitably increase, and the debugging efficiency will be low. Summary of the Invention

[0005] This application provides a code debugging method, an electronic device, and a computer-readable storage medium, which can simplify the user's operation in the process of debugging application code, realize automatic breakpoints on the code segment to be inspected, so as to help the user quickly locate the code segment to be inspected, quickly find code problems, and improve debugging efficiency.

[0006] In a first aspect, embodiments of this application provide a code debugging method applied to an electronic device. The 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. The method includes: running the program code to be debugged in response to a received debugging command; detecting a triggering event of calling a function in the second code segment through the first function call statement during the execution of the program code; determining that the address of the first function satisfies the triggering condition for setting a breakpoint based on the association between the first function call statement and the first function called in the second code segment; and setting a breakpoint at the address of the first function.

[0007] For example, the first code segment mentioned above could be a JavaScript code segment, the second code segment mentioned above could be a C / C++ code segment, and the triggering event mentioned above could be a local function call event triggered when the corresponding thread jumps to the corresponding associated first function in the C / C++ code segment from a local function call statement in the JavaScript code segment. Therefore, the code debugging method provided in the first aspect mentioned above, when a local function call event is detected, can determine that the first function meets the triggering condition for setting a breakpoint based on the pre-determined association between the 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), and then set a breakpoint at the address of the first function.

[0008] Thus, for example, the relationship between the first function call statement and the called first function can be predetermined by predefined code segments. This allows for the automatic setting of breakpoints in the second code segment (e.g., C / C++ code segment) to be debugged. When the program code resumes execution and hits the breakpoint, it will automatically stop at the entry point of the first function in the C / C++ code segment. Correspondingly, the interface of the integrated development environment (IDE) connected to the electronic device can also display the C / C++ code segment that hits the breakpoint, and can also highlight the entry address of the first function, etc., which is convenient for users to check and helps to improve debugging efficiency.

[0009] In one possible implementation of the first aspect above, the association between the first function call statement and the first function called in the second code segment is determined in the following way:

[0010] In the second code segment, an exported object is defined, and a first property is defined and initialized for the exported object, wherein the first property corresponds to the first function call statement in the first code segment;

[0011] Set the first function called in the second code segment as the callback function of the first attribute, and establish the association between the first attribute and the first function;

[0012] The first property of the exported object is loaded in the first code segment to determine the association between the first function call statement and the first function called in the second code segment.

[0013] For example, the exported object mentioned above could be an `exports` object, and the first property could be an `add` property. Therefore, the function that defines and initializes the first property of the exported object could be an `Init` function, meaning that the predefined `exports` object property can be defined as the `add` property through the `Init` function. The first function call statement could be "testNapi.add(1,2);" in the JavaScript code snippet, and the first function could be the `Add` function in the C / C++ code snippet. Loading the first property of the exported object in the first code snippet can be done, for example, by defining a local module (`napi_module`), for example, defining a local module as "demoModule", and setting the initialization function of this local module as the `Init` function. Then, the local module can be registered using a module registration function (e.g., `RegisterHelloModule`). Thus, when the `exports` object property `add` is loaded and initialized in the JavaScript code snippet through the first function call statement, the correspondence between the first function call statement and the corresponding `Add` function in the C / C++ code snippet can be determined. It can be understood that the above method for determining the association can be implemented through a predefined code snippet, which could be, for example, the following... Figure 2 The code snippet shown.

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

[0015] For example, the address range of the second code segment mentioned above could be the first address range corresponding to the C / C++ code segment. This address range can be determined based on the relevant attributes of the shared library (SO) loaded by the electronic device's system. These relevant attributes may include, but are not limited to, the name of the SO file, its load address, and the address range of the called C / C++ code segment, etc., and are not limited here.

[0016] In one possible implementation of the first aspect above, a debugging session is established between the electronic device and the integrated development environment (IDE). The debugging command is a command sent by the IDE to the electronic device through the debugging session in response to a user operation. Furthermore, a triggering event is detected in which a function in the second code segment is called through a first function call statement. This includes the electronic device reporting the detected triggering event to the IDE and pausing the execution of the thread used to run the program code.

[0017] For example, when a user needs to debug the application code installed on an electronic device, they can connect the electronic device to an Integrated Development Environment (IDE), which can then run on another electronic device. The user can then control the debugging progress within the IDE's debugging interface, such as by clicking the StepInto control. The IDE can then send the aforementioned debugging commands to the electronic device, triggering it to step into the debug environment. When the electronic device reaches the point where the first function call statement triggers a call to the first function in the second code segment—that is, when a native function call event is triggered—it can report this event to the IDE. After reporting, the execution of the corresponding thread in the application process can be paused.

[0018] In one possible implementation of the first aspect described above, the integrated development environment (IDE) determines the address range of the second code segment based on the shared library-related attributes reported to the IDE by the electronic device via a load completion event, and sets a breakpoint at the address of the first function, including: the IDE determining the address of the first function based on the received trigger event; the IDE determining that the address of the first function is within the address range of the second code segment, generating a breakpoint setting command to be sent to the electronic device, the breakpoint setting command being used to instruct the electronic device to set a breakpoint at the address of the first function; and the electronic device responding to the received breakpoint setting command by setting a breakpoint at the address of the first function.

[0019] For example, when an integrated development environment (IDE) loads an application's code file, such as a shared library (SO) file, onto an electronic device, it can pre-determine the address range of the C / C++ code segment corresponding to that SO file. Then, upon receiving a native function call event reported by the electronic device, the IDE can determine whether the address of the first function called (e.g., the address of a C / C++ function) is within the pre-determined address range. If it is, it indicates that the address of the first function can locate the C / C++ code segment to be inspected, and therefore a breakpoint can be set at that address. This breakpoint refers to automatically setting a virtual breakpoint at the address of the C / C++ function. When the breakpoint is hit, the IDE's debugging interface can highlight the line of code corresponding to the C / C++ function address and display the corresponding C / C++ code segment.

[0020] In one possible implementation of the first aspect described above, setting a breakpoint at the address of the first function includes: the integrated development environment (IDE) sending a determined address range of the second code segment to the electronic device; the electronic device determining that the address of the first function is within the address range of the second code segment and reporting the address of the first function to the IDE; the IDE generating a breakpoint setting command to be sent to the electronic device based on the address of the first function; and the electronic device setting a breakpoint at the address of the first function in response to the received breakpoint setting command.

[0021] For example, an Integrated Development Environment (IDE) can pre-determine the address range of the C / C++ code segment corresponding to a shared library (SO) file loaded by an electronic device and send it to the electronic device. Then, when the electronic device detects a native function call event, it can determine whether the address of the first function called (e.g., the address of a C / C++ function) corresponding to that event is within the pre-determined address range. If it is, it indicates that the address of the first function can locate the C / C++ code segment to be inspected, and the electronic device can report the C / C++ function address to the IDE. The IDE can then generate a breakpoint setting command based on the reported C / C++ function address and send it to the electronic device. The electronic device can then set a breakpoint at the address of the C / C++ function called corresponding to the native function call event based on the received breakpoint setting command.

[0022] In one 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 from the integrated development environment to resume thread execution; and, in response to the command to resume thread execution, resuming the execution of the thread running the program code.

[0023] In one possible implementation of the first aspect above, after resuming the execution of the thread running the program code, the method further includes: detecting that the thread has reached a breakpoint in the first function, and controlling the thread to stop at the function entry point of the first function in the second code segment.

[0024] Secondly, embodiments of this application provide an electronic device, including: one or more processors; one or more memories; the one or more memories storing one or more programs, which, when executed by one or more processors, cause the electronic device to execute the code debugging method provided in the first aspect and various possible implementations of the first aspect.

[0025] Thirdly, embodiments of this application provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the code debugging methods provided in the first aspect and various possible implementations of the first aspect.

[0026] Fourthly, embodiments of this application provide a computer program product, including a computer program / instruction that, when executed by a processor, implements the code debugging method provided in the first aspect and various possible implementations of the first aspect. Attached Figure Description

[0027] Figure 1a The diagram illustrates a cross-language debugging scenario.

[0028] Figure 1b The image shows a schematic diagram of the code display interface corresponding to the called code file in a cross-language debugging scenario.

[0029] Figure 2 The image shown is a code example of a predefined code segment provided in Embodiment 1 of this application.

[0030] Figure 3a The diagram shown is a system architecture diagram of an electronic device 100 provided in an embodiment of this application.

[0031] Figure 3b The diagram shown is a schematic of a debugging system provided in an embodiment of this application.

[0032] Figure 4 The diagram shows the interactive flow of a code debugging method provided in Embodiment 1 of this application.

[0033] Figure 5 The diagram shown is a schematic of a debugging interface for displaying JavaScript code provided in Embodiment 1 of this application.

[0034] Figure 6 The diagram shown is a schematic of a debugging interface for displaying C / C++ code provided in Embodiment 1 of this application.

[0035] Figure 7 The diagram shown is a schematic diagram of the interaction process between electronic device 100 and electronic device 200 provided in Embodiment 1 of this application.

[0036] Figure 8 The diagram shows the interactive flow of a code debugging method provided in Embodiment 2 of this application.

[0037] Figure 9 The diagram shown is a hardware structure diagram of an electronic device 100 provided in an embodiment of this application. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be described in detail below with reference to the accompanying drawings and specific implementation methods.

[0039] To facilitate understanding of the solutions in the embodiments of this application by those skilled in the art, some concepts and terms involved in the embodiments of this application will be explained below.

[0040] (1) Debugging session

[0041] Establishing a debug session is a necessary step to step into debugging. Before a debug session is established, most commands are disabled, except for a few option settings and commands used to establish the debug session. Therefore, when using an Integrated Development Environment (IDE) to debug code on an application installed on a user's terminal electronic device, a debug session needs to be established with the corresponding debugger in the debugging service installed / configured on that electronic device before the IDE can send various commands to the debugging service on that electronic device.

[0042] (2) Shared Object (SO)

[0043] Shared library files end with .so. They can be marked during program linking, and the required modules are dynamically loaded when the program starts running. Therefore, applications still require the support of shared libraries at runtime; shared libraries are also called dynamic libraries. Application packaging includes user-compiled .so files, while the system .so files required for the application to run can be directly called by the electronic device's system.

[0044] It's understandable that during the code compilation phase, application source code compiled through an IDE can be compiled using different languages, resulting in different compilation tools and output artifacts. For example, in applications compiled with JavaScript and C / C++, JavaScript code can generate a ".abc" file, while C / C++ code can generate an SO file. The SO file generated from the C / C++ code written by the developer is often referred to as a user SO file, which will not be elaborated upon here.

[0045] During the debugging / running phase, when the above application runs on the target device, the user SO required by the application will be loaded and executed.

[0046] Understandably, if developers find issues with parts of the source code in the IDE during the debugging / running phase, they can modify the corresponding code segments within the IDE, such as modifying C / C++ code. Recompiling can then generate a new shared library (SO) file, which can be repackaged into the application installation package, such as Android. TMApplication installation package (Android application package, APK) or HarmonyOS TM Application installation packages (harmonyos abilitypackage, hap, etc.). When re-debugging the application code, you can reinstall updated installation packages, which will not be elaborated on here.

[0047] After the target device system loads the required SO files for the application, the corresponding debugging service (such as lldb-server) will report a library-loaded event to the IDE. Therefore, the IDE can receive the SO files reported by the library-loaded event, filter out the address ranges of the user's SO files, and send them to the JS debugging service on the electronic device running the application being debugged through a new protocol.

[0048] Figures 1a to 1b This diagram illustrates a cross-language debugging scenario.

[0049] It should be noted that the users of the electronic devices to which the code debugging method provided in this application is applicable can generally be the developers of the application code, and this is not limited thereto. Unless otherwise specified, in this application, "user" and "developer" refer to the same thing, both referring to a person who needs to debug the application code.

[0050] like Figure 1a As shown, the debugging scenario may include electronic device 100 running the application being debugged and electronic device 200 running the integrated development environment (IDE).

[0051] Taking electronic device 100 as a mobile phone and electronic device 200 as a personal computer (PC) as an example, refer to... Figure 1a As shown, the application being debugged installed on mobile phone 100 can be one or more, for example... Figure 1a The examples shown are App01, App02, App03, and App04. When debugging a specific application on mobile phone 100 is required, such as debugging App01, mobile phone 100 can be connected to PC 200 via a data cable with a debugging port or other communication method. The connected device can be selected on the debugging interface 210 of the integrated development environment (IDE) running on PC 200. (Reference) Figure 1a As shown in operation ①, the developer can select mobile phone 100 as the access device under the device option control 211 in the debugging interface 210.

[0052] Furthermore, the developer can operate the mobile phone 100 to run App01, and click on the single step on the debugging interface 210 to enter the debugging control 212 to debug the application code of App01. The area 213 on the debugging interface 210 that displays the application code being debugged can correspondingly display the code that is being debugged and running.

[0053] In the above Figure 1a In the debugging scenario shown, if the application code being debugged includes cross-language call relationships, for example... Figure 1a The function call statement "testNapi.add(1,2);" on line 16 of the JavaScript file shows that a call to a C / C++ function has been added to the JavaScript code. Therefore, during debugging of this application's code, if no breakpoints are added, when the code executes to... Figure 1a When the JavaScript file reaches line 16, execution will switch to the corresponding C / C++ function and continue executing the code.

[0054] At this point, the IDE's debugging interface can be switched to display the code in the C / C++ file, for example... Figure 1b The code displayed in area 213 of the debugging interface 220 is shown. After the code in the C / C++ file finishes executing, the mobile phone 100 can continue to execute the code in the JavaScript file to continue the debugging process, for example, continue... Figure 1a The code in line 17 of the JavaScript file shown will be displayed in area 213 of the IDE's debugging interface 210, which will then switch back to displaying the code in the JavaScript file.

[0055] In the above Figures 1a to 1b In the debugging scenario shown, if the developer needs to inspect potentially problematic code files in the IDE's debugging interface, such as checking if there are any issues with the program code corresponding to App01, then they need to... Figure 1a The JavaScript code shown is analyzed to determine the C / C++ function called on line 16, and the corresponding location of that function in the C / C++ file, i.e., its address, is found. Developers can then open the corresponding C / C++ file in their IDE's debugging interface and set breakpoints at the address of the relevant C / C++ function.

[0056] refer to Figure 1b As shown, for example, a developer can click once on the third line of code in the C / C++ file displayed in the IDE, see reference. Figure 1b Operation ②, as shown, completes the process of setting a breakpoint. Correspondingly, the breakpoint marker 230 will be displayed on line 3 of the code where the breakpoint is set. Furthermore, the developer can click again... Figure 1bThe StepInto control 221 on the debugging interface 220 triggers the phone 100 to run App01 to continue the debugging process. Then, when the program code of App01 runs to line 16 of the JavaScript file and jumps to line 3 of the C / C++ file, it will stop. The IDE can also stop at the corresponding line. Figure 1b On the debugging interface 220 shown, developers can now check for problems in the code of C / C++ files.

[0057] However, the current method, which requires developers to analyze call relationships, find relevant files, and manually click on lines of code to set breakpoints, is inefficient when debugging application code that involves cross-language calls from JavaScript, Java, Python, etc. to C / C++. It requires a lot of developer involvement and a large amount of debugging work.

[0058] To address the aforementioned problems, this application provides a code debugging method applied to electronic devices. Specifically, this method pre-defines the called function (as described above)... Figure 1b In the debugging scenario shown, the second code file (such as the C / C++ code file) to which the C / C++ code displayed in area 213 of the debugging interface 220 belongs is configured with a predefined code segment. This predefined code segment enables the second code file that provides the called function to be used by the first code file (such as the first code file that uses the called function). Figure 1a The JavaScript file corresponding to the JavaScript code displayed in area 213 of the debugging interface 210 in the debugging scenario shown is associated. Specifically, for example, for Figure 1a and Figure 1b In the scenario shown, the predefined code can match the address of the C / C++ function called in the second code file with the function call statement in the first code file (such as a JavaScript file) that calls that C / C++ function. Figure 1a An association is established between the field corresponding to line 16 of the code shown. Based on this association, during the execution of the application being debugged, when the electronic device executes a function call statement in a JavaScript file, it can automatically identify the address of the C / C++ function associated with that field in the C / C++ file. This allows for the automatic setting of a virtual breakpoint at that function address, eliminating the need for the developer to manually analyze function call relationships within the JavaScript code segment to determine the address of the C / C++ function where the breakpoint should be set.

[0059] Thus, when the program code of the application being debugged resumes execution and hits the virtual breakpoints set above, the test interface displayed by the integrated development environment (IDE) connected to the electronic device will show C / C++ code (such as...). Figure 1b The code segment shown will automatically stop at the entry point of the function corresponding to the address where the breakpoint is located (e.g., the code segment shown). Figure 1b The location shown indicates the start of line 3 in the C / C++ code segment, making it easier for debuggers or developers to inspect each line of code in the C / C++ file. For example, developers can use the above... Figure 1b The IDE's debugging interface 220 shows how to check whether there are any unfixable vulnerabilities or other issues in the C / C++ code segments of the currently displayed C / C++ file.

[0060] As an example, Figure 2 An example code snippet of a predefined code segment is shown according to an embodiment of this application.

[0061] like Figure 2 As shown, this predefined code snippet includes code examples for defining exported object properties and registering and initializing native modules. Specifically, the code snippet defines the exported object property `add` and its C / C++ callback function `Add`. Therefore, calling the `add` property in JavaScript using the function call statement `testNapi.add(1,2);` will ultimately call back to the `Add` function in C / C++. The specific process can include the following three steps:

[0062] ① Predefine an `exports` object in the C / C++ code segment and add properties, then associate these properties with the C / C++ functions called in the C / C++ code file. For example, define an `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 for `add`.

[0063] ② Define a variable of type `napi_module`, for example, `demoModule`, and assign the correct attributes, for example... Figure 2 The “.nm_register_func” attribute is shown.

[0064] ③ Define a module registration function, such as the RegisterHelloModule function, which can register the demoModule defined above through the NAPI interface.

[0065] Based on the above association process, when debugging and running application code, if the "import" section in the JavaScript code includes loading an SO file, for example... Figure 2The code shows "import testNapi from "libentry.so". The system will then load libentry.so and execute the RegisterHelloModule function during loading. This function will call the "Init" function, which is assigned the value through the attribute ".nm_register_func". The Init function then defines the add attribute in the exports object and returns. Thus, after the import is executed, the add attribute of the exports object can be loaded through the function call statement corresponding to testNapi.

[0066] For example, based on Figure 2 The predefined code segment shown Figure 1a The function call statement "testNapi.add(1,2);" on line 16 of the JavaScript code snippet shown loads the `add` property of the `exports` object, which can be directly associated with... Figure 1b The address of the called function "Add(napi_envenv,napi_callback_info info)" in line 3 of the C / C++ code snippet shown is used to bind the association between the add property in the JavaScript code and the add function in the C / C++ code. Therefore, calling the add property in JavaScript will trigger a callback to the add function in C / C++.

[0067] refer to Figure 2 As shown, the properties defined on the `exports` object in the `Init` function can be obtained in JavaScript using the `import` statement, thus enabling the calling of C / C++ functions from JavaScript. For example... Figure 2 In the code, the add property is declared through napi_property_descriptor, and the callback function is set to the C / C++ function Add. Finally, the property is defined on the exports object through napi_define_properties.

[0068] In addition, the above Figure 2 The code snippet shown also includes code that assigns values ​​to the relevant properties of the demoModule, which loads the aforementioned exported object (exports object). For example... Figure 2 The ".nm_register_func=Init" example shown is used by the IDE to obtain... Figure 2The code shown can be used to run the example module based on the parameters mentioned above, thereby initializing the debugging environment, including the relationship between `add` and `Add`. For example, when the import function "import" is executed in the JavaScript code, the module registration (register_module) can be triggered, calling the function (e.g., `Init`) corresponding to the attribute ".nm_register_func = Init".

[0069] It is understood that both the first and second code files mentioned above are components of the program code of the called code. The first code file may be, for example, a compiled product of a JavaScript language or a programming language such as Java or Python. The second code file may be, for example, a compiled product of a native language such as C / C++, such as a user-defined SO file compiled by the developer of the application being debugged using an integrated development environment (IDE). In the embodiments of this application, the function call statements in the first code file that correspond to the calls to predefined exported object properties can be called native function calls. The functions in the second code file associated with the exported object properties called by the function call statements in the first code file can be called native functions.

[0070] It is understandable that the process of automatically identifying the function address associated with the function call statement based on the above-mentioned association can be achieved, for example, by identifying whether the address of the second code function corresponding to the local function call event reported during the execution of the program code of the application being debugged is within a preset address range. For example, based on the association established between the function call statement in the first code file and the corresponding function address in the second code file, the electronic device or the IDE connected to the electronic device can pre-determine the code segment address range in the second code file corresponding to the function address in the association relationship. Therefore, when a local function call event reported during the execution of the program code of the application being debugged is obtained, it can be determined whether the function address called by the event is within the determined code segment address range, and whether the function address called by the event is the function address in the second code file where the breakpoint needs to be set.

[0071] It is understood that the above-described solution provided by the embodiments of this application can effectively simplify the tedious process for developers when debugging application code, which involves analyzing call relationships, finding the called code files, and opening and inspecting them. When it is necessary to set breakpoints in the program code of the application being debugged, on code segments or code files compiled using native languages ​​such as C / C++, the above-described solution provided by the embodiments of this application can automatically identify the function addresses in the provider code (i.e., the second code) that require breakpoints during the execution of the user code (i.e., the first code mentioned above) and complete the automatic breakpoint setting process, thereby improving debugging efficiency.

[0072] The following section uses JavaScript as the encoding language for the first code and C / C++ as the encoding language for the second code as an example, and describes in detail the specific implementation process of the code debugging method provided in the embodiments of this application with reference to the accompanying drawings.

[0073] It is understood that the code debugging method provided in this application embodiment can be applied to electronic devices 100 running the application being debugged, including but not limited to mobile phones, tablets, desktops, laptops, handheld computers, netbooks, augmented reality (AR) / virtual reality (VR) devices, smart TVs, smartwatches and other wearable devices, servers, mobile email devices, in-vehicle devices, portable game consoles, portable music players, e-reader devices, televisions with one or more processors embedded or coupled thereto, or other electronic devices capable of accessing the network.

[0074] Furthermore, the code debugging method provided in this application embodiment can be applied to electronic devices 200 running an IDE, including but not limited to personal computers (PCs), tablet computers, desktop computers, laptop computers, handheld computers, netbooks, servers, and other electronic devices that have one or more processors with strong processing capabilities embedded or coupled thereto.

[0075] Figure 3a A schematic diagram of the system architecture of an electronic device 100 is shown according to an embodiment of this application.

[0076] like Figure 3a As shown, the electronic device 100 can be equipped with a distributed system architecture. This distributed system architecture may include an application layer, an application framework layer, a system service layer, and a kernel layer. It can be understood that... Figure 3a The distributed system architecture shown can be HarmonyOS TM Or other similar Figure 3aThe software architecture shown is a distributed system, and no restrictions are imposed here.

[0077] The application layer can include the application being debugged. The application being debugged can include native modules (such as JavaScript Native Modules) and native code (such as JavaScript code). Native modules provide native interfaces to the JavaScript code.

[0078] The application framework layer provides applications with user program frameworks and meta-capability frameworks in multiple languages ​​such as Java, C, C++, and JavaScript, as well as multi-language framework APIs exposed for various software and hardware services. For example, it can provide framework APIs in multiple languages ​​such as C / C++ and JavaScript for devices that also adopt a distributed system architecture. The APIs supported by different devices are related to the degree of componentization and customization of the system. The application framework layer can also provide user interface frameworks (such as the ArkUI framework) for applications, etc., without further restrictions.

[0079] The ArkUI framework is a declarative UI development framework for building distributed application interfaces. The ArkUI framework may include a Native Application Programming Interface (NAPI) component. This NAPI component is a native module extension development framework with external interfaces based on the Node.js N-API specification, used to provide interfaces to C / C++ to enable access to the underlying JS engine. In this embodiment, local function calls are detected by this module and notified to the JS engine, which in turn notifies the JS debugging service.

[0080] The system service layer, comprising the core capabilities of a distributed system, provides services to applications through the application framework layer. It includes a set of basic system capability subsystems, enabling distributed applications to operate within a given environment. Figure 3aThe system provides fundamental capabilities for operation, scheduling, and migration across multiple devices in the distributed system. The set of basic system capability subsystems may include the Ark Multi-Language Runtime Subsystem (hereinafter referred to as the Ark Runtime) and the Common Basic Library Subsystem, which provide multi-language debugging services. The Ark Runtime provides C / C++ / JS multi-language runtimes and basic system class libraries, and also provides runtime for Java programs statically generated using the Ark compiler (i.e., the parts of the application or framework layer developed using the Java language). For example, the Ark Runtime can provide JS debugging services (JavaScript debugger) and a JS engine. The JS debugging service provides debugging capabilities for JavaScript code files and is responsible for handling JavaScript thread debugging.

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

[0082] It is understandable that the aforementioned JS debugging service, C / C++ debugging service, and other multi-language debugging services are responsible for interacting with the execution threads of each code file of the application being debugged.

[0083] The system service layer may also include a debug protocol processing module (not shown in the figure), which is responsible for interacting with the IDE or debug client, such as the one described above. Figure 1a In the scenario shown, electronic device 200. For example, the debug protocol processing module is responsible for receiving debug commands and other information from the IDE or debug client. The debug protocol processing module can parse debug commands that conform to the general debug interface protocol and send the parsed and valid debug commands to the multi-language core module for processing. The debug protocol processing module is also used to receive debug response information returned by the multi-language core module, translate and encapsulate the debug response information based on the general debug interface protocol, and then return the encapsulated debug response information to the IDE or debug client.

[0084] It is understood that, in the embodiments of this application, the process corresponding to the application being debugged 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 application being debugged may also include Java thread 1, Java thread 2, Python thread 1, Python thread 2, etc., and there is no limitation herein.

[0085] In some embodiments, the multi-language debugging service may also have the capability to identify whether the currently loaded or debugged address is within a preset address range. For example, the C / C++ debugging service can 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 application being debugged. Furthermore, upon receiving the address of the C / C++ function called corresponding to a native function call event from the IDE, it can determine whether the address is within the aforementioned preset address range. Consequently, the C / C++ debugging service can automatically identify the address of the C / C++ function called corresponding to the native function call event from the IDE, and can set a virtual breakpoint at the code location corresponding to that address. For details, please refer to the relevant description below, which will not be elaborated upon here.

[0086] The kernel layer comprises the kernel subsystem and the driver subsystem. The kernel subsystem supports selecting the appropriate OS kernel for different resource-constrained devices. The driver subsystem provides unified peripheral access capabilities and a framework for driver development and management. The kernel layer also includes the Kernel Abstraction Layer (KAL), which shields the differences between multiple kernels and provides basic kernel capabilities to higher layers, including process / thread management, memory management, file system, network management, and peripheral management. These will not be elaborated upon here.

[0087] Based on the above Figure 3a The system architecture shown below, along with some flowcharts, some interactive diagrams between electronic devices 100 and the IDE, and some IDE interface diagrams, will be used to explain in detail the specific implementation process of the application debugging method provided in this application embodiment.

[0088] It should also be stated that the steps in the methods and processes in this application are numbered for ease of reference, not to limit the order of steps. If there is an order between the steps, the textual description shall prevail.

[0089] Figure 3b A schematic diagram of a debugging system is shown according to an embodiment of this application.

[0090] like Figure 3b As shown, the debugging system may include electronic device 100 and electronic device 200. Electronic device 100 may be equipped with the aforementioned... Figure 3a The device is designed with a distributed system architecture. Therefore, the electronic device 100 may include a system service and application framework layer debugging service 310, NAPI component 320, JS engine 330, and the application being debugged 340 in the application layer.

[0091] The debugging service 310 may include the aforementioned JS debugging service 311 and C / C++ debugging service 312. The NAPI component 320 may include a native engine, such as a JS engine abstraction layer, used to unify the interface behavior of the JS engine 330 at the NAPI layer. The application being debugged 340 may include a native module 341 and JavaScript code 342. The JavaScript code 342 can be interpreted and executed by the JS engine 330, while the C / C++ code can be packaged into a shared library (SO) file and loaded and executed by the system.

[0092] It is understood that in other embodiments, the JS debugging service 311 described above can also be a debugger for debugging Java, Python, and other code, and this is not a limitation.

[0093] The structural functions of the debugging service 310 and the application being debugged 340 in the above electronic device 100 can be referred to the above. Figure 3a The relevant descriptions will not be repeated here.

[0094] Continue as Figure 3b As shown, an integrated development environment (IDE) 201 can run on electronic device 200 to debug the application code of the application 340 being debugged on 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 a JavaScript debug core and a Native debug core. These debugging cores can receive debugging commands from the debugging protocol processing module (not shown in the figure), perform related debugging operations on the corresponding debugged threads, and further feed the results of the operations back to the debugging protocol processing module for processing. The debugging protocol processing module in the IDE 201 running on electronic device 200 can exchange feedback information with the debugging protocol processing modules included in the debugging service on electronic device 100.

[0095] Based on the above Figure 3b The debugging system shown below will be described in conjunction with Embodiment 1, which describes an interaction between the debugging service 310 (including JS debugging service 311 and C / C++ debugging service 312) running on the electronic device 100, the application being debugged 340, and the IDE 201 running on the electronic device 200.

[0096] Example 1

[0097] Figure 4 An interactive flow for implementing an application debugging method is shown in an embodiment of this application.

[0098] like Figure 4 As shown, this interaction process involves the above. Figure 3b The debugging system shown interacts with the IDE 201 running on the electronic device 200, 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 application being debugged 340.

[0099] Specifically, the interaction process includes the following steps:

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

[0101] For example, when electronic device 100 is connected to electronic device 200, the IDE 201 running on electronic device 200 can also establish communication with electronic device 100, and thus establish a debugging session with the JS debugging service 311 in the debugging service 310 configured on electronic device 100. Further, after the IDE 201 establishes a debugging session with the JS debugging service 311, it can send a command to the JS debugging service 311 to set the hybrid debugging switch using the following protocol commands:

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

[0103] The aforementioned hybrid debugging switch can be used to control whether the JS debugging service 311 reports detected native function call events to the IDE 201.

[0104] It is understood that in other embodiments, the protocol command for the IDE 201 to send the setup command to the JS debugging service 311 may also take other command forms, which are not limited here.

[0105] 402: JS debugging service 311 setting mixed debugging switch.

[0106] For example, the JS debugging service 311 responds to the received command, namely the command sent by the IDE 201 in step 401 above to set the hybrid debugging switch, and sets the hybrid debugging switch.

[0107] Subsequently, when the JS debugging service 311 receives the native function call event reported by the JS engine 330, it can report the C / C++ function address to the IDE 201 through the corresponding native function call event. For details, please refer to the execution process of steps 409 to 411 below, which will not be elaborated here. The aforementioned native function call event is used to call native code. In this embodiment, the native code can be code developed in C / C++, and the JavaScript code that calls the native code developed in C / C++ can be the primary language used in application development. Therefore, calling a function exported by a native module in JavaScript code can be called a native function call.

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

[0109] For example, the IDE 201 running on the electronic device 200 can also establish communication with the electronic device 100. If the IDE 201 wants to send commands to the C / C++ debugging service 312, it can also establish a debugging session with the C / C++ debugging service 312. This will not be elaborated further here.

[0110] 404: The C / C++ debugging service 312 has detected that a shared library (SO) that the application process depends on has been loaded and has reported the relevant attributes of the loaded SO.

[0111] For example, the aforementioned shared libraries (SOs) are generally the coding products of compiled languages ​​such as C / C++ or Rust. Therefore, in application code developed based on JavaScript / C / C++, the code in the SO is generally C / C++ code. That is to say, the SO loaded by the C / C++ debugging service 312 can be C / C++ code, and is usually a user SO written by the application developer. The C / C++ debugging service 312 can obtain the relevant attributes of the shared libraries (SOs) loaded by the application process and report them via library-loaded. Therefore, the execution process of step 404 is as follows: after the IDE 201 establishes a native debugging session with the C / C++ debugging service 312, which includes mixed debugging and native debugging, the C / C++ debugging service 312 reports an SO loading completion event (library-loaded) to the IDE 201. The content reported by this event includes the SO name, loading address, and code segment address range. Furthermore, the C / C++ code segment corresponding to the shared library (SO) can predefine exported objects and corresponding added properties, and the JavaScript code segment can contain function call statements that import the predefinitive exported objects. That is, the function call statements in the JavaScript code segment are associated with the corresponding function addresses in the C / C++ code segment. Therefore, the shared library (SO) related attributes reported by the C / C++ debugging service 312 through library-loaded can include attributes such as the SO file name, load address, and the address range of the called C / C++ code segment.

[0112] 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 load address, and the address range of the code segment, to the IDE 201 through the library-loaded event.

[0113] 405: C / C++ debugging service 312 reports a load completion event to IDE 201.

[0114] For example, after the C / C++ debugging service 312 completes loading the shared library (SO), it can report a "library-loaded" event to the IDE 201. The content of the "library-loaded" event reported by the C / C++ debugging service 312 can be seen in the following example:

[0115] library-loaded,hostname="\data\storage\el1\bundle\libs\arm\libentry.so", loaded_addr="0x00000000d4c41000", codeRange="0x00000000d4c43c44~0x00000000d4c480e0"

[0116] Here, `hostname` corresponds to the path where the libentry.so file is stored in the reported electronic device. `loaded_addr` corresponds to the starting address of the loaded libentry.so. `codeRange` corresponds to the address range corresponding to the reported C / C++ code segment. The above addresses or address ranges are represented in hexadecimal. In some other embodiments, the starting address or address range may also be represented in decimal or other number bases, which is not limited here.

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

[0118] For example, IDE 201 can obtain the address range corresponding to the C / C++ code segment based on the library-loaded event reported by the C / C++ debugging service 312, and use it as the first address range. This address range can be used as the basis for judgment during the judgment process of step 413 below. For details, please refer to the relevant description in step 413 below, which will not be repeated here.

[0119] As an example, continuing to refer to the previous example, the first address range determined by the IDE 201 above could be, for example, "0x00000000d4c43c44~0x00000000d4c480e0". This range can be determined based on the codeRange="0x00000000d4c43c44~0x00000000d4c480e0" in the library-loaded event reported by the C / C++ debugging service 312 in step 405 above.

[0120] 407: IDE 201 detected a user stepping into debug mode.

[0121] For example, a user can click the "Step Into" control on the debugging interface displayed when the IDE is running on the electronic device 200, i.e., step into the debugging control / button. Correspondingly, the IDE 201 can detect the user's step-in debugging operation. The user who inputs the operation into the IDE 201 can be, for example, the aforementioned developer.

[0122] As an example, Figure 5 A schematic diagram of a debugging interface for displaying JavaScript code is shown according to an embodiment of this application.

[0123] like Figure 5 As shown, after the electronic device 200 connects to the device running the application being debugged 340 via IDE 201, it can display the debugging interface 510. After IDE 201 completes the steps 401 and 403 described above, if the user clicks the StepInto control 511 on the debugging interface 510, the debugging process for the target application, i.e., the application being debugged, can be started. At this time, the IDE 201 running on the electronic device 200 can detect the user's single-step debugging operation.

[0124] Understandably, users can... Figure 5 In the JavaScript code segment displayed on the debugging interface 510, select line 16 and then click the StepInto control 511. The user can also manually add a breakpoint to this line of code beforehand, and the debugging interface 510 will display the breakpoint marker 512 accordingly. In other embodiments, the operation of triggering step-in debugging at the corresponding position of the function call statement in the JavaScript code segment (e.g., line 16 above) can be other than these, and is not limited here.

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

[0126] For example, after detecting a StepInto operation, IDE 201 can send a debugging command to the JS debugging service 311 provided by the debugging service in electronic device 100. This debugging command can stop at the entry point of the called function.

[0127] 409: NAPI component 320 detected a native function call and generated a native function call event.

[0128] As mentioned above, the Native module 321 is typically a C / C++ module that provides native interfaces to JavaScript code. JavaScript imports the native module's exports object via "import" and uses this object to call back to the C / C++ function. Therefore, when the JS debugging service 311 debugs and runs the JavaScript code to the point of the aforementioned native function call, it can trigger this interface to obtain the native function call (NativeCalling) event reported by the application being debugged 340.

[0129] 410: NAPI component 320 reports local function call events to JS debugging service 311 through JS engine 330.

[0130] For example, NAPI component 320 can report native function call events generated by detecting native function calls to JS debugging service 311 via JS engine 330. As an example, the method for reporting native function call events can be seen in the following example:

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

[0132] Here, "NativeAddress":0xd4c43de8 represents the memory address of the C / C++ function to be called. In other embodiments, the method of reporting native function call events may also be different, and there are no restrictions here.

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

[0134] For example, 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 step 402 above is in the enabled state, it can continue to report the local function call event to the IDE 204.

[0135] 412: JS debugging service 311 pauses thread execution.

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

[0137] It is understandable that the above-mentioned methods of pausing execution can be achieved, for example, by executing a sleep function, and no restrictions are imposed here.

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

[0139] For example, after receiving a local function call event reported by the JS debugging service 311, the 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 the IDE 201 through the library-loaded event mentioned above.

[0140] Refer to the above Figure 2 As shown, the C / C++ function can be the `Add` function, which serves as a native callback function for `add` in JavaScript code. `add` is a property of an object imported via `import` in JavaScript code. Referring to the example in step 410 above, the address of the aforementioned C / C++ function could be, for example, "0xd4c43de8", which is actually the hexadecimal address "0x0000000d4c43de8". In other embodiments, the address of the C / C++ function reported by the JS debugging service 311 can also be an address represented in decimal, etc., and this is not a limitation here.

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

[0142] As an example, continuing with the previous example, the first address range determined by IDE 201 is, for example, "0x00000000d4c43c44~0x00000000d4c480e0", and the address of the C / C++ function received by IDE 201 is, for example, "0xd4c43de8", i.e., "0x0000000d4c43de8". By comparing "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 address of the C / C++ function is within the first address range. Therefore, IDE 201 can continue to execute step 414 below to send the command to set a breakpoint.

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

[0144] For example, when the IDE 201 determines the received C / C++ function address within the first address range in step 413 above, it can send a command to set a breakpoint to the C / C++ debugging service 312 that has established a debugging session.

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

[0146] After sending the breakpoint setting command and setting the breakpoint, IDE 201 can continue to execute step 416 below, sending the command to reply to the thread execution.

[0147] 415: IDE 201 ignores received C / C++ function addresses.

[0148] For example, if IDE 201 determines in step 413 that the received C / C++ function address is not within the first address range, it can ignore the received C / C++ function address. In this case, IDE 201 can continue to execute step 416, sending a command to the JS debugging service 311 to resume thread execution.

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

[0150] For example, after executing the above steps 414 or 415, IDE 201 can continue to execute this step 416, sending a command to JS debugging service 311 to resume thread execution, instructing JS debugging service 311 to resume thread execution.

[0151] 417: JS debugging service 311 resumes thread execution.

[0152] For example, the JS debugging service 311 can respond to a received command to resume execution of the execution thread and continue running JavaScript code files or C / C++ code. Further details are omitted here.

[0153] 418: C / C++ debugging service 312 reports a breakpoint hit message to IDE 201.

[0154] For example, after the thread resumes execution, it runs to the C / C++ callback function and hits the virtual breakpoint. Specifically, after the thread resumes execution, it can continue running the previously paused C / C++ callback function. If the C / C++ debugging service 312 sets a breakpoint at the address corresponding to the function after the IDE 201 performs step 414 above, the breakpoint will be hit. At this time, the C / C++ debugging service 312 can report the breakpoint hit message to the IDE 201 through the established debugging session. After the breakpoint is hit, the corresponding C / C++ function entry line in the IDE 201's debugging interface can be highlighted or displayed in other prominent ways.

[0155] As the name suggests, "hitting" a virtual breakpoint or a breakpoint means that when the code corresponding to the line marked by the breakpoint is executed, the C / C++ debugging service (lldb-server) recognizes the breakpoint and pauses thread execution. The aforementioned "virtual breakpoint" and "breakpoint" can be understood as stop markers with the same function, but their forms may differ or be the same. Further details will not be elaborated upon here.

[0156] Figure 6 An embodiment of this application illustrates a schematic diagram of a debugging interface for displaying C / C++ code.

[0157] like Figure 6 As shown, when the IDE 201 running on the electronic device 200 receives a breakpoint hit feedback message, the debugging interface of the IDE 201 can automatically stop at the line of code 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 in the debugging interface 610 shown in Figure 6. Simultaneously, the line of code corresponding to the entry address of the C / C++ callback function when the breakpoint is hit can be highlighted or displayed in other prominent ways.

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

[0159] For example, after receiving a breakpoint hit message reported by the JS debugging service 311, the IDE 201 can also send a command to the C / C++ debugging service 312 to delete the set breakpoints. This allows breakpoints set in the second code file or C / C++ code file to be cleared promptly during debugging, avoiding the problem of the JS debugging service 311 repeatedly stopping at breakpoint positions when the JavaScript or C / C++ code file is run again after the detected code problems have been fixed, thus preventing a decrease in debugging efficiency.

[0160] It is understandable that in some embodiments, after a code debugging session is completed and the hybrid debugging switch is not turned off, step 419 can be skipped after step 418. This allows the application code to automatically stop at the set virtual breakpoints when debugging again, improving the efficiency of repeated debugging. In other embodiments, after a code debugging session is completed and the hybrid debugging switch is turned off, step 419 can be executed after step 418 to delete breakpoints. This allows steps 401 to 418 to be re-executed when debugging the application code again, automatically adding and hitting breakpoints, further improving debugging efficiency.

[0161] The above Figure 4 The interaction flow of steps 401 to 419 shown can be summarized as follows: Figure 7 The diagram shows the interaction process between electronic device 100 and electronic device 200.

[0162] Figure 7 An embodiment of this application illustrates an interaction process between electronic devices 100 and 200 within a debugging system.

[0163] It is understood that the process of the application being debugged can include multiple threads. For applications written in multiple languages, each thread may include cross-language code calls during execution. For example, a thread executing JavaScript code may include calls to C / C++ functions. In other embodiments, cross-language code calls may also occur in cross-thread execution scenarios, which is not limited here.

[0164] As an example, the JavaScript code running in a thread within the application process being debugged includes calls to C / C++ code. Therefore, the execution process of this thread could be, for example, first executing the JavaScript code segment, then jumping to execute the called C / C++ code segment when it reaches the location of a native function call, and finally jumping back to execute the JavaScript code. In this scenario, Figure 7 The interactive process shown mainly includes the following four stages:

[0165] Phase 1: After the integrated development environment (IDE) running on electronic device 200 establishes a debugging session with the JS debugger running on electronic device 100, it can send protocol commands to the JS debugger to instruct the JS debugger to set a hybrid debugging switch. Correspondingly, after the JS debugger completes the setting of the hybrid debugging switch, it can set the switch to the "on" state; when debugging tasks are not required, the switch can be set to "off".

[0166] Phase 2: 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 a completion event to the IDE indicating that shared libraries (SOs) have been loaded. Accordingly, the IDE can obtain information on all shared libraries (SOs) loaded by the debugged application process, including system SOs and user SOs developed by the developer.

[0167] Phase 3: During debugging, when the user clicks the StepInto control on the IDE debugging interface, if the JS engine in the electronic device 100 detects a native function call while running JavaScript code, it can report a native function call event to the IDE. Furthermore, the JS debugging service can send the address of the corresponding C / C++ function to the IDE in the reported event and suspend the thread, halting code execution. In other embodiments, after reporting a native function call event, the IDE can also send a command to the JS debugging service to stop thread execution, such as the debugger.pause command, instructing the JS debugging service to stop thread execution; this is not limited here.

[0168] Phase 4: After receiving the NativeCalling event reported by the JS debugger, the IDE can determine whether the address of the C / C++ function reported with the event is within the defined code segment address range of the user's SO. If so, the IDE can set a virtual breakpoint at the code location corresponding to that address, such as the entry point of the C / C++ function, via lldb-server. Then, the IDE can send a resume command to the JS debugger. The resumed thread executes, and when it reaches the C / C++ callback function corresponding to the JavaScript method, the breakpoint will be hit, and the thread will pause execution again, stopping at the function entry point.

[0169] It is understandable, based on the above Figure 4 The execution process of the interactive flow shown or Figure 7 The diagram illustrates the interaction process between electronic devices 100 and 200 within the debugging system. The code debugging method provided in this embodiment can automatically set breakpoints for application code written in multiple languages ​​during the debugging process using an IDE. This allows the IDE's debugging interface to automatically stop at the called C / C++ code file, for example, at the location of a native function call.

[0170] The system displays the corresponding code location and the code in the C / C++ file corresponding to the called C / C++ function, making it easier for developers to quickly locate and fix cross-language program code issues, thus improving debugging efficiency.

[0171] Based on the above Figure 3b The debugging system shown below will be described in conjunction with Embodiment 2, which will illustrate another interaction method between the debugging service 310 running on the electronic device 100, the application being debugged 340, and the IDE 201 running on the electronic device 200 in the above-described debugging system.

[0172] Example 2

[0173] Compared with the above embodiment 1 Figure 4 The difference from the interaction flow shown is that, in this embodiment, the electronic device 100 running the debugged application 340 can execute the above-described process. Figure 4 The process of step 406 and steps 413 to 415 shown.

[0174] Specifically, such as Figure 8 As shown, the interaction process may include the following steps:

[0175] Figure 8 An interactive flow for implementing an application debugging method is shown in an embodiment of this application.

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

[0177] Specifically, the interaction process includes the following steps:

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

[0179] 802: JS debugging service 311 sets the mixed debugging switch.

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

[0181] 804: C / C++ debugging service 312 reports the properties of the loaded SO after the shared library (SO) that the application process depends on has been loaded.

[0182] 805: C / C++ debugging service 312 reports a load completion event to IDE 201.

[0183] The execution process of steps 801 to 805 is the same as that of steps 401 to 405 in Embodiment 1. For details, please refer to the relevant descriptions of steps 401 to 405 in Embodiment 1. They will not be repeated here.

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

[0185] For example, in response to a received load completion event, IDE 201 can determine the address range of the code segment corresponding to the shared library (i.e., user SO) loaded by C / C++ debugging service 312. In this embodiment, 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. Then, IDE 201 can send this first address range to JS debugging service 311 to perform step 814 below. For details, please refer to the relevant description in step 814 below; it will not be repeated here.

[0186] 807: IDE 201 detected a user action to step into debug mode.

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

[0188] 809: NAPI component 320 detected a native function call and generated a native function call event.

[0189] 810: NAPI component 320 reports local function call events to JS debugging service 311 through JS engine 330.

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

[0191] 812: JS debugging service 311 pauses thread execution.

[0192] The execution process of steps 807 to 812 is the same as that of steps 407 to 412 in embodiment 1. For details, please refer to the relevant descriptions of steps 407 to 412 in embodiment 1. They will not be repeated here.

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

[0194] For example, in this embodiment of the application, the IDE 201 can determine the detected C / C++ function address corresponding to the local function call event reported by the JS debugging service 311, 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 step 814 below.

[0195] 814: JS debugging service 311 determines whether the address of a C / C++ function is within the first address range. If the determination result is yes, that is, the address of the C / C++ function is within the first address range, then step 815 can be executed; if the determination result is no, that is, the address of the C / C++ function is not within the first address range, then step 817 can be executed.

[0196] For example, the JS debugging service 311 can compare the received C / C++ function address with the first address range determined during step 806 above to determine whether the C / C++ function address is within the first address range. Specific examples can be found in the relevant description in step 413 of embodiment 1 above, and will not be repeated here.

[0197] 815: JS debugging service 311 reports the address of local functions to IDE 201.

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

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

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

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

[0202] 817: JS debugging service 311 ignores received C / C++ function addresses.

[0203] For example, if the JS debugging service 311 determines in step 814 that the received C / C++ function address is not within the first address range, it can ignore the received C / C++ function address. At this time, the IDE 201 can continue to execute step 818 below, sending a command to the JS debugging service 311 to resume thread execution.

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

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

[0206] 819: JS debugging service 311 resumes thread execution.

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

[0208] 820: JS debugging service 311 reports a breakpoint hit message to IDE 201.

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

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

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

[0212] It is understandable, based on the above Figure 8 The execution process of the interactive flow shown in this application embodiment also enables the automatic setting of breakpoints for application code written in multiple languages ​​during the debugging process of application code using an IDE. This allows the IDE's debugging interface to automatically stop at the called C / C++ code file, for example, at the code location indicated by the local function call, and displays the code in the corresponding C / C++ file of the called C / C++ function. This facilitates developers in quickly locating and fixing cross-language program code issues, thereby improving debugging efficiency.

[0213] Figure 9A schematic diagram of the hardware structure of an electronic device 100 is shown according to an embodiment of this application.

[0214] Electronic device 100 may include processor 110, external memory interface 120, internal memory 121, universal serial bus (USB) interface 130, charging management module 140, power management module 141, battery 142, antenna 1, antenna 2, 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, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer 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.

[0215] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0216] In addition, it is understandable that the above Figure 3b The electronic device 200 in the debugging system shown can also have Figure 9 The hardware structure components shown, or those with more than Figure 9 This may include more or fewer components, or combinations of some components, or separate components, or different arrangements of components. No restrictions are imposed here.

[0217] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0218] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0219] In this embodiment, the processor 110 of the electronic device 100 can generate control signals through a controller to control the electronic device 100 provided in Embodiment 1 or Embodiment 2 to implement the various interactive steps of the code debugging method during the IDE interaction process between the electronic device 100 and the electronic device 200. For details, please refer to Embodiment 1 above. Figure 4 The interactive process shown or in the above embodiment 2 Figure 8 The relevant descriptions of the interactive process shown are not repeated here.

[0220] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the aforementioned memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0221] In some embodiments, the processor 110 may include one or more interfaces. Interfaces 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.

[0222] USB interface 130 is an interface that conforms to the USB standard specification, specifically it can be a Mini USB interface, Micro USB interface, USB Type C interface, etc. USB interface 130 can be used to connect a charger to charge electronic device 100, and it can also be used for data transfer between electronic device 100 and peripheral devices.

[0223] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0224] The charging management module 140 receives charging input from the charger. The power management module 141 connects to 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, internal memory 121, display 194, camera 193, and wireless communication module 160, etc.

[0225] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0226] 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 one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0227] Mobile communication module 150 can provide wireless communication solutions, including 2G / 3G / 4G / 5G, for use on electronic device 100. Wireless communication module 160 can provide wireless communication solutions, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies, for use on electronic device 100.

[0228] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling electronic device 100 to communicate with networks and other devices via wireless communication technology. The aforementioned 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 technologies, etc. The aforementioned 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 satellite-based augmentation systems (SBAS).

[0229] Electronic device 100 implements display functions through GPU, display screen 194, and application processor.

[0230] 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 one or N display screens 194, where N is a positive integer greater than 1.

[0231] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

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

[0233] The external storage 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 storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

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

[0235] In this embodiment, 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 application being debugged by running related instructions for debugging application code stored in the internal memory 121 or the memory set in the processor. These functions can be used to implement the code debugging method provided in this embodiment.

[0236] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0237] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 180A can be disposed on display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may include at least two parallel plates with conductive material. When force is applied to pressure sensor 180A, the capacitance between the electrodes changes. Electronic device 100 determines the pressure intensity based on the change in capacitance. When a touch operation is applied to display screen 194, electronic device 100 detects the intensity of the touch operation based on pressure sensor 180A. Electronic device 100 can also calculate the touch position based on the detection signal from pressure sensor 180A. In some embodiments, touch operations applied to the same touch position but with different touch operation intensities can correspond to different operation commands. For example: when a touch operation with an intensity less than a first pressure threshold is applied to the SMS application icon, a command to view an SMS is executed. When a touch operation with an intensity greater than or equal to the first pressure threshold is applied to the SMS application icon, a command to create a new SMS is executed.

[0238] The 180E accelerometer can detect the magnitude of acceleration of electronic device 100 in various directions (typically three axes). When electronic device 100 is stationary, it can detect the magnitude and direction of gravity. It can also be used to identify the posture of electronic devices and applied to applications such as screen orientation switching and pedometers.

[0239] The fingerprint sensor 180H is used to collect fingerprints. The electronic device 100 can utilize the characteristics of the collected fingerprints to achieve fingerprint unlocking, accessing application locks, taking photos with fingerprints, answering calls with fingerprints, etc.

[0240] Touch sensor 180K, also known as a "touch device," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit 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 display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of electronic device 100, in a different position than display screen 194.

[0241] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch-sensitive buttons. Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100.

[0242] Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback.

[0243] Indicator 192 can be an indicator light, used to indicate charging status, power changes, or to indicate messages, missed calls, notifications, etc.

[0244] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with or separate from the electronic device 100.

[0245] In this specification, the reference to "an embodiment" or "an embodiment" means that a specific feature, structure, or characteristic described in connection with the embodiment is included in at least one exemplary implementation or technology disclosed according to an embodiment of this application. The appearance of the phrase "in an embodiment" in various places in the specification does not necessarily refer to the same embodiment.

[0246] The disclosure of embodiments of this application also relates to means for performing operations in text. This means may be specifically constructed for the claimed purpose or may include a general-purpose computer selectively activated or reconfigured by a computer program stored in a computer. Such a computer program may be stored on a computer-readable medium, such as, but not limited to, any type of disk, including floppy disks, optical disks, CD-ROMs, magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, application-specific integrated circuits (ASICs), or any type of medium suitable for storing electronic instructions, and each may be coupled to a computer system bus. Furthermore, the computer mentioned in the specification may include a single processor or may employ an architecture involving multiple processors for increased computing power.

[0247] Furthermore, the language used in this specification has been primarily chosen for readability and instructional purposes and may not have been chosen to depict or limit the disclosed subject matter. Therefore, the embodiments disclosed herein are intended to illustrate, and not limit, the scope of the concepts discussed herein.

Claims

1. A code debugging method applied to an electronic device, wherein the program code to be debugged running on the electronic device includes a first code segment written in a first language, the first code segment including 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, the program code being debugged is executed; During the execution of the debugged program code, a triggering event was detected in which a function in the second code segment was called through the first function call statement; Based on the association between the first function call statement and the first function called in the second code segment, it is determined that the address of the first function satisfies the triggering condition of the breakpoint. Set a breakpoint at the address of the first function being called, wherein the association between the first function call statement and the first function being called in the second code segment is determined in the following way: In the second code segment, an exported object is defined, and a first property is defined and initialized for the exported object, wherein the first property corresponds to the first function call statement in the first code segment; Set the first function that is called as the callback function of the first attribute to establish the association between the first attribute and the first function that is called; The first property of the exported object is loaded in the first code segment to determine the association between the first function call statement and the first function being called.

2. The method according to claim 1, characterized in that, The triggering conditions for satisfying the breakpoint include: The address of the first function is determined to be within a predetermined address range of the second code segment, wherein the address range of the second code segment is determined based on the shared library-related attributes corresponding to the program code loaded by the electronic device.

3. The method according to claim 2, characterized in that, A debugging session is established between the electronic device and the integrated development environment (IDE). The debugging command is a command sent by the IDE to the electronic device through the debugging session in response to a user operation. The detected event of calling a function in the second code segment via a first function call statement includes: The electronic device reports the detected triggering event to the integrated development environment and suspends the execution of the thread used to run the program code.

4. The method according to claim 3, characterized in that, The integrated development environment (IDE) determines the address range of the second code segment based on the shared library-related attributes reported by the electronic device to the IDE via a load 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. The breakpoint setting command is used to instruct the electronic device to set a breakpoint at 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.

5. The method according to claim 4, characterized in that, 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 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.

6. The method according to any one of claims 3 to 5, characterized in that, After setting a breakpoint at the address of the first function, the method further includes; Received the command from the integrated development environment to resume thread execution; In response to the command to resume thread execution, the execution of the thread running the program code is resumed.

7. The method according to any one of claims 1 to 6, characterized in that, After resuming execution of the thread running the program code, the method further includes; If the thread is detected to have hit the breakpoint in the first function, the thread is controlled to stop at the function entry point of the first function in the second code segment.

8. An electronic device, characterized in that, include: One or more processors; One or more memories; the one or more memories storing one or more programs, which, when executed by the one or more processors, cause the electronic device to perform the code debugging method of any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The storage medium stores instructions that, when executed on a computer, cause the computer to perform the code debugging method according to any one of claims 1 to 7.

Images