CN114691483A

CN114691483A - Software debugging method, electronic equipment and debugging system

Info

Publication number: CN114691483A
Application number: CN202011631714.4A
Authority: CN
Inventors: 杨建伟; 金琦森
Original assignee: Huawei Device Co Ltd
Current assignee: Huawei Device Co Ltd
Priority date: 2020-12-30
Filing date: 2020-12-30
Publication date: 2022-07-01
Also published as: WO2022143108A1

Abstract

The application discloses a software debugging method, electronic equipment and a debugging system, which can realize the cooperative debugging of the equipment. The method can achieve collaborative debugging of one or more devices in a distributed scenario. For example, a client device (e.g., a second device) in a debugging cluster composed of multiple debugging devices (e.g., a first device and a second device) may forward a debugging command triggered by a user to a debugged device through a server device (e.g., a first device) connected to a master device (e.g., a third device) in the distributed device cluster, so as to implement cooperative debugging of a debugged process by the multiple debugging devices in the debugging system.

Description

Software debugging method, electronic equipment and debugging system

Technical Field

The embodiment of the application relates to the technical field of software development, in particular to a software debugging method, electronic equipment and a debugging system.

Background

With the development of communication technology and the diversified development of electronic devices, more and more electronic devices (such as smart phones, televisions, wireless headsets, smart speakers, smart home devices, and the like) can provide intelligent life or work experience for users based on the communication technology. For example, a user may perform cooperative work between devices based on a distributed device cluster architecture formed by multiple devices as shown in fig. 1, for example, control a smart home device through a smart phone.

Generally, the implementation of the functions of the electronic device requires a software system for implementing the related functions, which is developed based on a software developer. The development of the software system needs to be continuously debugged by software developers to realize stable functional performance. In a scenario of cooperative work among multiple devices, cooperative debugging of the multiple devices is often required.

However, in the conventional software system debugging technology, only one debugger can be supported for monitoring and debugging a single device application process.

Disclosure of Invention

The embodiment of the application provides a software debugging method, electronic equipment and a debugging system, which can realize the cooperative debugging of the equipment.

In order to achieve the above purpose, the embodiment of the present application adopts the following technical solutions:

in a first aspect, a software debugging method is provided, and the method includes: the method comprises the steps that first equipment receives a first debugging command corresponding to a first process in third equipment from second equipment, wherein the first debugging command carries an identifier of the third equipment and an identifier of the first process; the first equipment sends a first debugging command to the third equipment; the method comprises the steps that first equipment receives first debugging data from third equipment, wherein the first debugging data are obtained after the third equipment executes a first debugging command on a first process, and the first debugging data carry an identifier of the third equipment and an identifier of the first process; the first device sends the first debug data to the second device.

In the technical solution provided in the first aspect, a client device (e.g., a second device) in a debugging cluster composed of multiple debugging devices (e.g., a first device and a second device) may forward a debugging command triggered by a user to a debugged device through a server device (e.g., a first device) connected to a master device (e.g., a third device) in a distributed device cluster, so as to implement cooperative debugging of a debugged process by the multiple debugging devices in a debugging system.

In a possible implementation manner, the method further includes: responding to a debugging event triggered by a user, the first equipment acquires a second debugging command corresponding to a second process in the fourth equipment, wherein the second debugging command carries an identifier of the fourth equipment and an identifier of the second process; the first equipment sends a second debugging command to the third equipment; the first device receives second debugging data from the third device, wherein the second debugging data is obtained after the fourth device executes a second debugging command on the second process; the second debugging data is sent to the third device after the fourth device executes the second debugging command to the second process, and the second debugging data carries the identifier of the fourth device and the identifier of the second process. In some embodiments of the present application, a server device (e.g., a first device) and a client device (e.g., a second device) in a commissioning cluster may cooperate to cooperatively commission a plurality of processes (e.g., a first process and a second process) having an association relationship among a plurality of devices (e.g., a third device and a fourth device) in a distributed device cluster.

In a possible implementation manner, the method further includes: the first equipment receives a third debugging command from the second equipment, wherein the third debugging command corresponds to a third process in the fourth equipment, and the third debugging command carries an identifier of the fourth equipment and an identifier of the third process; the first equipment sends a third debugging command to the third equipment; the first device receives third debugging data from the third device, wherein the third debugging data is obtained after the fourth device executes a third debugging command on the third process, the third debugging data is sent to the third device after the fourth device executes the third debugging command on the third process, and the third debugging data carries an identifier of the fourth device and an identifier of the third process; and the first equipment sends the third debugging data to the second equipment. In some embodiments of the present application, a client device (e.g., a second device) in a commissioning cluster may collaboratively commission a plurality of processes (e.g., a first process and a third process) having an association relationship among a plurality of devices (e.g., a third device and a fourth device) in a distributed device cluster.

In a possible implementation manner, the method further includes: the first device receiving a viewing request from the second device; in response to the viewing request, the first device sends second commissioning data to the second device. In some embodiments of the present application, the server device (e.g., the first device) may further receive a viewing request of the client device (e.g., the second device), and send second debugging data corresponding to the second debugging command to the client device (e.g., the second device) so that the client device (e.g., the second device) can display the second debugging data on the UI interface.

In a possible implementation manner, after the first device receives the second debugging data from the third device, the method further includes: the first device displays the second debugging data through a User Interface (UI). In some embodiments of the present application, the server device (e.g., the first device) may directly display the second debugging data corresponding to the second debugging command on a UI interface of the server device (e.g., the first device).

In a possible implementation manner, the method further includes: the first device displays the first debugging data through the UI interface. In some embodiments of the present application, the server device (e.g., the first device) may further display first debug data corresponding to the first debug command on a UI interface of the server device (e.g., the first device).

In one possible implementation, a first device is communicatively coupled to a second device; the first device is in communication connection with a third device, which is in communication connection with a fourth device. The cooperative debugging of the plurality of debugging devices to one debugged device in the distributed device cluster, the cross-device cooperative debugging of one debugging device to the plurality of debugged devices, the cross-device cooperative debugging of the plurality of debugging devices to the plurality of debugged devices, and the like can be realized based on the established debugging cluster comprising the debugging server and the debugging client.

In a possible implementation manner, the sending, by the first device, the first debug data to the second device includes: and the first device sends the first debugging data to the second device according to the identifier of the third device and the identifier of the first process carried in the first debugging data. In the solution provided by the present application, a server device (such as a first device) may perform unified management and distribution of debug commands.

In a possible implementation manner, before the first device receives the first debug command from the second device, the method further includes: the first equipment sends a command for discovering the debuggable process to the third equipment, and the command is used for discovering the debuggable process; the first device receives debuggable process information from the third device, wherein the debuggable process information comprises information of debuggable processes discovered by the third device and the fourth device. In the solution provided by the present application, the first device may be configured to perform unified reporting on all debuggable processes in the distributed device cluster, so that a user determines a debuggable device and a debuggable process.

In a possible implementation manner, the debuggable process includes information of the first process, information of the second process, and information of the third process.

In a possible implementation manner, the first debug command includes a breakpoint command and/or a time-light debug command. The second debugging command comprises a breakpoint command and/or a time-light debugging command. For example, in the solution provided by the present application, the debugging device may implement cooperative debugging on one or more debugged processes through a breakpoint command and/or a time-light debugging command.

In a possible implementation manner, the breakpoint command includes one or more of the following: a data breakpoint command, a synchronization breakpoint command, or a conditional breakpoint command. For example, in the scheme provided by the present application, the debugging device may implement cooperative debugging of one or more debugged processes through a data breakpoint command, a synchronization breakpoint command, a conditional breakpoint command, or other breakpoint commands.

In a second aspect, a software debugging method is provided, which includes: the third equipment receives a first debugging command corresponding to a first process in the third equipment from the first equipment, wherein the first debugging command carries an identifier of the third equipment and an identifier of the first process; the third device executes the first debugging command on the first process according to the identifier of the third device and the identifier of the first process carried in the first debugging command, and obtains first debugging data, wherein the identifier of the third device and the identifier of the first process are carried in the first debugging data; the third device sends the first commissioning data to the first device.

In the technical solution provided in the second aspect, a client device (e.g., a second device) in a debugging cluster composed of multiple debugging devices (e.g., a first device and a second device) may forward a debugging command triggered by a user to a debugged device through a server device (e.g., a first device) connected to a master device (e.g., a third device) in a distributed device cluster, so that the debugged device (e.g., the third device) performs a debugging operation on a debugged process (e.g., a first process) according to the debugging command, and returns debugging data (e.g., first debugging data).

In a possible implementation manner, the method further includes: the third equipment receives a second debugging command corresponding to a second process in the fourth equipment from the first equipment, wherein the second process is associated with the first process, and the second debugging command carries an identifier of the fourth equipment and an identifier of the second process; the third equipment sends the second debugging command to the fourth equipment according to the identifier of the fourth equipment carried in the second debugging command; the third device receives second debugging data from the fourth device, wherein the second debugging data is obtained after the fourth device executes a second debugging command on the second process, and the second debugging data carries an identifier of the fourth device and an identifier of the second process; the third device sends the second commissioning data to the first device. In some embodiments of the present application, a server device (e.g., a first device) and a client device (e.g., a second device) in a commissioning cluster may cooperate to cooperatively commission a plurality of processes (e.g., a first process and a second process) having an association relationship among a plurality of devices (e.g., a third device and a fourth device) in a distributed device cluster.

In a possible implementation manner, the method further includes: the third device receives a third debugging command from the first device, wherein the third debugging command corresponds to a third process in the fourth device, and the third debugging command carries an identifier of the fourth device and an identifier of the third process; the third equipment sends the third debugging command to the fourth equipment according to the identifier of the fourth equipment carried in the third debugging command; the third device receives third debugging data from the fourth device, wherein the third debugging data is obtained after the fourth device executes a third debugging command on a third process, and the third debugging data carries an identifier of the fourth device and an identifier of the third process; the third device sends third commissioning data to the first device. In some embodiments of the present application, a client device (e.g., a second device) in a commissioning cluster may perform collaborative commissioning for a plurality of processes (e.g., a first process and a third process) having an association relationship among a plurality of devices (e.g., a third device and a fourth device) in a distributed device cluster.

In a possible implementation manner, before the third device receives the first debug command from the first device, the method further includes: the third device discovers the device and establishes communication connection with the fourth device after discovering the fourth device; the third device is communicatively coupled to the first device. The cooperative debugging of the multiple debugging devices to one debugged device in the distributed device cluster, the cross-device cooperative debugging of the one debugging device to the multiple debugged devices, the cross-device cooperative debugging of the multiple debugging devices to the multiple debugged devices, and the like provided by the application can be realized based on the established distributed device cluster including the master device (such as the third device) and the slave device (such as the fourth device).

In a possible implementation manner, after the distributed device cluster is established, the method further includes: the third device receiving a command to discover a debuggable process from the first device; the third device sends a command for discovering a debuggable process to the fourth device; the third equipment discovers a first debuggable process, wherein the first debuggable process comprises a first process; the third device receives information of a second debuggable process discovered by the fourth device from the fourth device, wherein the second debuggable process comprises a second process and a third process; the third equipment sends the information of the debuggable process to the first equipment; the information of the debuggable process includes information of a first debuggable process and information of a second debuggable process. In the solution provided by the present application, the first device may be configured to perform unified reporting on all debuggable processes in the distributed device cluster, so that a user determines a debuggable device and a debuggable process.

In a possible implementation manner, the first debug command includes a breakpoint command and/or a time-light debug command. For example, in the solution provided by the present application, the debugging device may implement cooperative debugging on one or more debuggee processes through a breakpoint command and/or a time-light debugging command.

In a possible implementation manner, the breakpoint command includes one or more of the following: a data breakpoint command, a synchronization breakpoint command, or a conditional breakpoint command.

In a third aspect, a software debugging method is provided, which includes: the method comprises the steps that first equipment receives a first debugging command corresponding to a first process in third equipment from second equipment, wherein the first debugging command carries an identifier of the third equipment and an identifier of the first process; the first equipment sends a first debugging command to the third equipment; the third device executes the first debugging command on the first process according to the identifier of the third device and the identifier of the first process carried in the first debugging command, and obtains first debugging data, wherein the identifier of the third device and the identifier of the first process are carried in the first debugging data; the third equipment sends first debugging data to the first equipment; the first equipment transmits the first debugging data to the second equipment; the second device displays the first debugging data through the UI interface.

In the technical solution provided by the third aspect, a client device (e.g., a second device) in a debugging cluster composed of multiple debugging devices (e.g., a first device and a second device) may forward a debugging command triggered by a user to a debugged device through a server device (e.g., a first device) connected to a master device (e.g., a third device) in a distributed device cluster, so as to implement cooperative debugging of a debugged process by the multiple debugging devices in a debugging system.

In a possible implementation manner, the method further includes: responding to a debugging event triggered by a user, the first equipment acquires a second debugging command corresponding to a second process in the fourth equipment, wherein the second debugging command carries an identifier of the fourth equipment and an identifier of the second process; the first equipment sends a second debugging command to the third equipment; the third equipment sends the second debugging command to the fourth equipment according to the identifier of the fourth equipment carried in the second debugging command; the fourth device executes debugging operation on the second process according to the identifier of the second process carried in the second debugging command to obtain second debugging data, wherein the second debugging data carries the identifier of the fourth device and the identifier of the second process; the fourth device sends second debugging data to the third device; the third equipment sends second debugging data to the first equipment; the first device displays the second debugging data through the UI interface. In some embodiments of the present application, a server device (e.g., a first device) and a client device (e.g., a second device) in a commissioning cluster may collaboratively commission a plurality of processes (e.g., a first process and a second process) having an association relationship among a plurality of devices (e.g., a third device and a fourth device) in a distributed device cluster.

In a possible implementation manner, the method further includes: the first equipment receives a third debugging command from the second equipment, wherein the third debugging command corresponds to a third process in the fourth equipment, and the third debugging command carries an identifier of the fourth equipment and an identifier of the third process; the first equipment sends a third debugging command to the third equipment; the third equipment sends the third debugging command to the fourth equipment according to the identifier of the fourth equipment carried in the third debugging command; the fourth device executes debugging operation on the third process according to the identifier of the third process carried in the third debugging command to obtain third debugging data, wherein the third debugging data carries the identifier of the fourth device and the identifier of the third process; the fourth device sends third debugging data to the third device; the first equipment sends the third debugging data to the second equipment; and the second equipment displays the third debugging data through the UI interface. In some embodiments of the present application, a client device (e.g., a second device) in a commissioning cluster may collaboratively commission a plurality of processes (e.g., a first process and a third process) having an association relationship among a plurality of devices (e.g., a third device and a fourth device) in a distributed device cluster.

In a fourth aspect, there is provided a first device comprising: the second debugging module is used for receiving a first debugging command corresponding to a first process in the third equipment from the second equipment and sending the first debugging command to the third equipment; receiving first debug data from a third device; and sending the first debug data to the second device; the first debugging command carries an identifier of the third device and an identifier of the first process; the first debugging data is obtained after the third device executes the first debugging command on the first process, and the first debugging data carries an identifier of the third device and an identifier of the first process.

In the technical solution provided in the fourth aspect, a client device (e.g., a second device) in a debugging cluster composed of multiple debugging devices (e.g., a first device and a second device) may forward a debugging command triggered by a user to a debugged device through a server device (e.g., a first device) connected to a master device (e.g., a third device) in a distributed device cluster, so as to implement cooperative debugging of a debugged process by the multiple debugging devices in a debugging system.

In a possible implementation manner, the first device further includes: the framework layer is used for responding to a debugging event triggered by a user and acquiring a second debugging command; and sending a second debug command for a second process in the fourth device to the second debug module; the second process is associated with the first process, and the second debugging command carries an identifier of the fourth device and an identifier of the second process; the second debugging module is also used for sending a second debugging command to the third equipment; receiving second debugging data from the third equipment, wherein the second debugging data is obtained after the fourth equipment executes a second debugging command on the second process; the second debugging data is sent to the third device after the fourth device executes the second debugging command to the second process, and the second debugging data carries the identifier of the fourth device and the identifier of the second process. In some embodiments of the present application, a server device (e.g., a first device) and a client device (e.g., a second device) in a commissioning cluster may cooperate to cooperatively commission a plurality of processes (e.g., a first process and a second process) having an association relationship among a plurality of devices (e.g., a third device and a fourth device) in a distributed device cluster.

In a possible implementation manner, the second debugging module is further configured to receive a third debugging command from the second device, and send the third debugging command to the third device; receiving third debugging data from the third device and sending the third debugging data to the second device; the third debugging command corresponds to a third process in the fourth device, and the third debugging command carries an identifier of the fourth device and an identifier of the third process; the third debugging data is obtained after the fourth device executes the third debugging command on the third process, the third debugging data is sent to the third device after the fourth device executes the third debugging command on the third process, and the third debugging data carries the identifier of the fourth device and the identifier of the third process. In some embodiments of the present application, a client device (e.g., a second device) in a commissioning cluster may collaboratively commission a plurality of processes (e.g., a first process and a third process) having an association relationship among a plurality of devices (e.g., a third device and a fourth device) in a distributed device cluster.

In a possible implementation manner, the second debugging module is further configured to receive a viewing request from a second device; in response to the viewing request, second commissioning data is sent to the second device. In some embodiments of the present application, the server device (e.g., the first device) may further receive a viewing request of the client device (e.g., the second device), and send second debugging data corresponding to the second debugging command to the client device (e.g., the second device) so that the client device (e.g., the second device) can display the second debugging data on the UI interface.

In a possible implementation manner, the second debugging module is further configured to send second debugging data to the framework layer, so that the framework layer displays the second debugging data through the UI interface. In some embodiments of the present application, the server device (e.g., the first device) may directly display the second debugging data corresponding to the second debugging command on the UI interface of the server device (e.g., the first device).

In a possible implementation manner, the second debugging module is further configured to send the first debugging data to the framework layer, so that the framework layer displays the first debugging data through the UI interface. In some embodiments of the present application, the server device (e.g., the first device) may further display first debugging data corresponding to the first debugging command on a UI interface of the server device (e.g., the first device).

In a possible implementation manner, the second debugging module is further configured to establish a communication connection with a second device, and the first device is in communication connection with a third device. The cooperative debugging of the plurality of debugging devices to one debugged device in the distributed device cluster, the cross-device cooperative debugging of one debugging device to the plurality of debugged devices, the cross-device cooperative debugging of the plurality of debugging devices to the plurality of debugged devices, and the like can be realized based on the established debugging cluster comprising the debugging server and the debugging client.

In a possible implementation manner, the second debugging module is specifically configured to send the first debugging data to the second device according to an identifier of the third device and an identifier of the first process, which are carried in the first debugging data. In the solution provided by the present application, a server device (e.g., a first device) may perform unified management and distribution of debug commands.

In a possible implementation manner, the second debugging module is further configured to send a command for discovering a debuggable process to a third device, where the command is used to discover the debuggable process; and receiving debuggable process information from the third device, wherein the debuggable process information comprises information of debuggable processes discovered by the third device and the fourth device. In the solution provided by the present application, the first device may be configured to perform unified reporting on all debuggable processes in the distributed device cluster, so that a user determines a debuggable device and a debuggable process.

In a fifth aspect, a third apparatus is provided, the third apparatus comprising: a distributed debug assistant to receive a first debug command from a first device; calling a debugging tool in the third equipment according to the identifier of the third equipment and the identifier of the first process carried in the first debugging command, executing the first debugging command on the first process, and acquiring first debugging data; and sending the first debug data to the first device; the first debugging command corresponds to a first process in the third equipment, and the first debugging command carries an identifier of the third equipment and an identifier of the first process; the first debugging data carries an identifier of the third device and an identifier of the first process.

In the technical solution provided in the fifth aspect, a client device (e.g., a second device) in a debugging cluster composed of multiple debugging devices (e.g., a first device and a second device) may forward a debugging command triggered by a user to a debugged device through a server device (e.g., a first device) connected to a master device (e.g., a third device) in a distributed device cluster, so that the debugged device (e.g., the third device) performs a debugging operation on a debugged process (e.g., a first process) according to the debugging command, and returns debugging data (e.g., first debugging data).

In a possible implementation manner, the distributed debug assistant is further configured to receive a second debug command from the first device; sending the second debugging command to the fourth equipment according to the identifier of the fourth equipment carried in the second debugging command; receiving second debug data from a fourth device; and sending the second debug data to the first device; the second debugging command corresponds to a second process in the fourth device, the second process is associated with the first process, and the second debugging command carries an identifier of the fourth device and an identifier of the second process; the second debug data carries an identifier of the fourth device and an identifier of the second process. In some embodiments of the present application, a server device (e.g., a first device) and a client device (e.g., a second device) in a commissioning cluster may cooperate to cooperatively commission a plurality of processes (e.g., a first process and a second process) having an association relationship among a plurality of devices (e.g., a third device and a fourth device) in a distributed device cluster.

In a possible implementation manner, the distributed debugging assistant is further configured to receive a third debugging command from the first device, and send the third debugging command to the fourth device according to an identifier of the fourth device carried in the third debugging command; receiving third debug data from the fourth device, and sending the third debug data to the first device; the third debugging command corresponds to a third process in the fourth device, and the third debugging command carries an identifier of the fourth device and an identifier of the third process; the third debugging data is obtained after the fourth device executes a third debugging command on the third process, and the third debugging data carries an identifier of the fourth device and an identifier of the third process. In some embodiments of the present application, a client device (e.g., a second device) in a commissioning cluster may perform collaborative commissioning of a plurality of processes (e.g., a first process and a third process) having an association relationship among a plurality of devices (e.g., a third device and a fourth device) in a distributed device cluster.

In a possible implementation manner, the distributed debug assistant is further configured to perform device discovery, and establish a communication connection with a fourth device after the fourth device is discovered; the third device is communicatively coupled to the first device. The cooperative debugging of the multiple debugging devices to one debugged device in the distributed device cluster, the cross-device cooperative debugging of the one debugging device to the multiple debugged devices, the cross-device cooperative debugging of the multiple debugging devices to the multiple debugged devices, and the like provided by the application can be realized based on the established distributed device cluster including the master device (such as the third device) and the slave device (such as the fourth device).

In a possible implementation manner, the distributed debugging assistant is further configured to receive a command for discovering a debuggable process from the first device; sending a command for discovering a debuggable process to the fourth device; discovering a first debuggable process; receiving, from the fourth device, information of a second debuggable process discovered by the fourth device; and sending information of the debuggable process to the first device; wherein the first debuggable process comprises a first process; the second debuggable process comprises a second process and a third process; the information of the debuggable process includes information of a first debuggable process and information of a second debuggable process. In the solution provided by the present application, the first device may be configured to perform unified reporting on all debuggable processes in the distributed device cluster, so that a user determines a debuggable device and a debuggable process.

In a sixth aspect, there is provided a first device comprising: a memory for storing a computer program; a transceiver for performing transmission and reception of radio signals; a processor for executing the computer program, such that the first device receives a first debug command corresponding to a first process in the third device from the second device through the transceiver, and sends the first debug command to the third device; receiving first commissioning data from a third device; and sending the first debug data to the second device; the first debugging command carries an identifier of the third device and an identifier of the first process; the first debugging data is obtained after the third device executes the first debugging command on the first process, and the first debugging data carries an identifier of the third device and an identifier of the first process.

In the technical solution provided in the sixth aspect, a client device (e.g., a second device) in a debugging cluster composed of multiple debugging devices (e.g., a first device and a second device) may forward a debugging command triggered by a user to a debugged device through a server device (e.g., a first device) connected to a master device (e.g., a third device) in a distributed device cluster, so as to implement cooperative debugging of a debugged process by the multiple debugging devices in a debugging system.

In a possible implementation manner, the processor is further configured to execute the computer program, so that the first device obtains a second debug command in response to a debug event triggered by a user; and sending, by the transceiver, a second debug command for a second process in the fourth device to the second debug module; sending a second debugging command to the third equipment; receiving second debugging data from the third equipment, wherein the second debugging data is obtained after the fourth equipment executes a second debugging command on the second process; the second debugging data is sent to the third device after the fourth device executes a second debugging command on the second process, the second debugging data carries an identifier of the fourth device and an identifier of the second process, the second process is associated with the first process, and the second debugging command carries the identifier of the fourth device and the identifier of the second process. In some embodiments of the present application, a server device (e.g., a first device) and a client device (e.g., a second device) in a commissioning cluster may cooperate to cooperatively commission a plurality of processes (e.g., a first process and a second process) having an association relationship among a plurality of devices (e.g., a third device and a fourth device) in a distributed device cluster.

In a possible implementation manner, the transceiver is further configured to receive a third debug command from the second device, and send the third debug command to the third device; receiving third debugging data from the third device and sending the third debugging data to the second device; the third debugging command corresponds to a third process in the fourth device, and the third debugging command carries an identifier of the fourth device and an identifier of the third process; the third debugging data is obtained after the fourth device executes the third debugging command on the third process, the third debugging data is sent to the third device after the fourth device executes the third debugging command on the third process, and the third debugging data carries the identifier of the fourth device and the identifier of the third process. In some embodiments of the present application, a client device (e.g., a second device) in a commissioning cluster may collaboratively commission a plurality of processes (e.g., a first process and a third process) having an association relationship among a plurality of devices (e.g., a third device and a fourth device) in a distributed device cluster.

In a possible implementation manner, the transceiver is further configured to receive a viewing request from the second device; in response to the viewing request, second commissioning data is sent to the second device. In some embodiments of the present application, the server device (e.g., the first device) may further receive a viewing request of the client device (e.g., the second device), and send second debugging data corresponding to the second debugging command to the client device (e.g., the second device) so that the client device (e.g., the second device) can display the second debugging data on the UI interface.

In a possible implementation manner, the transceiver is further configured to send the second debugging data to the framework layer, so that the framework layer displays the second debugging data through the UI interface. In some embodiments of the present application, the server device (e.g., the first device) may directly display the second debugging data corresponding to the second debugging command on the UI interface of the server device (e.g., the first device).

In a possible implementation manner, the processor is further configured to send the first debugging data to the framework layer, so that the framework layer displays the first debugging data through the UI interface. In some embodiments of the present application, the server device (e.g., the first device) may further display first debug data corresponding to the first debug command on a UI interface of the server device (e.g., the first device).

In a possible implementation manner, the processor is further configured to establish a communication connection with a second device; the first device is communicatively coupled to a third device. The cooperative debugging of the plurality of debugging devices to one debugged device in the distributed device cluster, the cross-device cooperative debugging of one debugging device to the plurality of debugged devices, the cross-device cooperative debugging of the plurality of debugging devices to the plurality of debugged devices, and the like can be realized based on the established debugging cluster comprising the debugging server and the debugging client.

In a possible implementation manner, the processor is configured to send the first debugging data to the second device through the transceiver according to an identifier of the third device and an identifier of the first process, which are carried in the first debugging data. In the solution provided by the present application, a server device (e.g., a first device) may perform unified management and distribution of debug commands.

In a possible implementation manner, the transceiver is further configured to send a command for discovering an debuggable procedure to a third device, where the command is used to discover the debuggable procedure; and receiving debuggable process information from the third device, wherein the debuggable process information comprises information of debuggable processes discovered by the third device and the fourth device. In the solution provided by the present application, the first device may be configured to perform unified reporting on all debuggable processes in the distributed device cluster, so that a user determines a debuggable device and a debuggable process.

In a seventh aspect, a third device is provided, which includes: a memory for storing a computer program; a transceiver for performing transmission and reception of radio signals; a processor for executing the computer program such that the third device performs receiving a first debug command from the first device through the transceiver; calling a debugging tool in the third equipment according to the identifier of the third equipment and the identifier of the first process carried in the first debugging command, executing the first debugging command on the first process, and acquiring first debugging data; and sending, by the transceiver, the first commissioning data to the first device; the first debugging command corresponds to a first process in the third equipment, and the first debugging command carries an identifier of the third equipment and an identifier of the first process; the first debugging data carries an identifier of the third device and an identifier of the first process.

In the technical solution provided by the seventh aspect, a client device (e.g., a second device) in a debugging cluster composed of multiple debugging devices (e.g., a first device and a second device) may forward a debugging command triggered by a user to a debugged device through a server device (e.g., a first device) connected to a master device (e.g., a third device) in a distributed device cluster, so that the debugged device (e.g., the third device) performs a debugging operation on a debugged process (e.g., the first process) according to the debugging command, and returns debugging data (e.g., the first debugging data).

In a possible implementation manner, the transceiver is further configured to receive a second debug command from the first device; sending the second debugging command to the fourth equipment according to the identifier of the fourth equipment carried in the second debugging command; receiving second debug data from a fourth device; and sending the second debug data to the first device; the second debugging command corresponds to a second process in the fourth device, the second process is associated with the first process, and the second debugging command carries an identifier of the fourth device and an identifier of the second process; the second debug data carries an identifier of the fourth device and an identifier of the second process. In some embodiments of the present application, a server device (e.g., a first device) and a client device (e.g., a second device) in a commissioning cluster may cooperate to cooperatively commission a plurality of processes (e.g., a first process and a second process) having an association relationship among a plurality of devices (e.g., a third device and a fourth device) in a distributed device cluster.

In a possible implementation manner, the transceiver is further configured to receive a third debug command from the first device, and send the third debug command to the fourth device according to an identifier of the fourth device carried in the third debug command; receiving third debug data from the fourth device, and sending the third debug data to the first device; the third debugging command corresponds to a third process in the fourth device, and the third debugging command carries an identifier of the fourth device and an identifier of the third process; the third debugging data is obtained after the fourth device executes a third debugging command on the third process, and the third debugging data carries an identifier of the fourth device and an identifier of the third process. In some embodiments of the present application, a client device (e.g., a second device) in a commissioning cluster may perform collaborative commissioning for a plurality of processes (e.g., a first process and a third process) having an association relationship among a plurality of devices (e.g., a third device and a fourth device) in a distributed device cluster.

In a possible implementation manner, the processor is further configured to perform device discovery, and establish a communication connection with a fourth device after the fourth device is discovered; the third device is communicatively coupled to the first device. The cooperative debugging of the multiple debugging devices to one debugged device in the distributed device cluster, the cross-device cooperative debugging of the one debugging device to the multiple debugged devices, the cross-device cooperative debugging of the multiple debugging devices to the multiple debugged devices, and the like provided by the application can be realized based on the established distributed device cluster including the master device (such as the third device) and the slave device (such as the fourth device).

In a possible implementation manner, the transceiver is further configured to receive a command for discovering a debuggable process from the first device; sending a command for discovering a debuggable process to the fourth device; receiving, from the fourth device, information of a second debuggable process discovered by the fourth device; and sending information of the debuggable process to the first device; the processor is further configured to discover a first debuggable process therein; the first debuggable process comprises a first process; the second debuggable process comprises a second process and a third process; the information of the debuggable process includes information of a first debuggable process and information of a second debuggable process. In the solution provided by the present application, the first device may be configured to perform unified reporting on all debuggable processes in the distributed device cluster, so that a user determines a debuggable device and a debuggable process.

In an eighth aspect, a debugging system is provided, comprising: the first apparatus as in any one of the possible implementations of the fourth aspect or the sixth aspect, and the third apparatus as in any one of the possible implementations of the fifth aspect or the seventh aspect. The commissioning system is for implementing a method as in any one of the possible implementations of the third aspect.

A ninth aspect provides a computer readable storage medium having computer program code stored thereon, the computer program code implementing a method as in any one of the possible implementations of the first or second aspect when executed by a processor.

In a tenth aspect, a chip system is provided, where the chip system includes a processor and a memory, and the memory stores computer program codes; the computer program code realizes the method according to any one of the possible implementations of the first aspect or the second aspect when executed by the processor. The chip system may be formed by a chip, and may also include a chip and other discrete devices.

In an eleventh aspect, a computer program product is provided which, when run on a computer, causes the implementation of a method as in any one of the possible implementations of the first or second aspect.

Drawings

FIG. 1 is an exemplary diagram of a distributed device cluster architecture;

fig. 2 is a schematic diagram of a hardware structure of an electronic device according to an embodiment of the present disclosure;

FIG. 3A is a diagram illustrating an exemplary debugging system framework according to an embodiment of the present disclosure;

FIG. 3B is a diagram of another exemplary debugging system framework provided in an embodiment of the present application;

FIG. 4 is a diagram illustrating an exemplary debugging system framework according to an embodiment of the present application;

fig. 5 is a diagram illustrating a structure of a debugging system according to an embodiment of the present application;

fig. 6A is a structural diagram of a debugging device according to an embodiment of the present application;

fig. 6B is a schematic workflow diagram of a second debugging module according to an embodiment of the present application;

fig. 7 is a block diagram of another debugging device provided in the embodiment of the present application;

fig. 8 is a diagram illustrating a procedure of a connection establishment phase and a debuggable procedure determination phase according to an embodiment of the present application;

fig. 9 is an exemplary diagram of a network topology UI interface provided in an embodiment of the present application;

FIG. 10A is a diagram illustrating an example of a UI interface for a debuggable process according to an embodiment of the application;

fig. 10B is an exemplary diagram of a hardware state interface of a debuggee device according to an embodiment of the present application;

fig. 11 is a flowchart of a method for debugging multiple devices by multiple devices according to an embodiment of the present application;

fig. 12 is a flowchart of another method for debugging multiple devices by multiple devices according to an embodiment of the present application;

fig. 13 is a flowchart of a method for debugging multiple devices by a single device according to an embodiment of the present application;

fig. 14 is a flowchart of a method for debugging a single device by multiple devices according to an embodiment of the present application;

fig. 15 is a block diagram of an electronic device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. In the description of the embodiments herein, "/" means "or" unless otherwise specified, for example, a/B may mean a or B; "and/or" herein is merely an association describing an associated object, and means that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of the present application, "a plurality" means two or more than two.

In the following, the terms "first", "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the present embodiment, "a plurality" means two or more unless otherwise specified.

Embodiments of the present application provide a software debugging method, where the method is used in a debugging process of a developer using one or more debugging devices to an application process running in one or more debugged devices, for example, in a debugging process of a developer using one or more debugging devices to an application process running in one or more devices in a distributed device cluster.

For example, the distributed device cluster may include a smart phone, a television, a wireless headset, a smart watch, a speaker, a Personal Computer (PC), a tablet PC, an Augmented Reality (AR)/Virtual Reality (VR) device, and an internet of things (IOT) device (e.g., smart home device) shown in fig. 1. The IOT is an important component of future information technology development, and is mainly technically characterized in that objects are connected with a network through a communication technology, so that an intelligent network with man-machine interconnection and object-object interconnection is realized. The IOT technology can realize mass connection, deep coverage, terminal power saving and the like.

As another example, a "1 +8+ N" end product may be included in a distributed cluster of devices. The '1 +8+ N' terminal product is used for creating future fifth-generation mobile communication technology (5G) full-scene intelligent life. Exemplarily, "1" refers to a smart phone, i.e., an entrance to a future smart life; "8" refers to a tablet, a PC, a wearable device, a high-definition (HD) device, an Artificial Intelligence (AI) speaker, an earphone, an AR/VR device, and a car device; "N" refers broadly to IOT devices, such as smart home devices.

Among them, a Process (Process) is a running activity of a program in a computer on a certain data set, is a basic unit for a system to perform resource allocation and scheduling, and is the basis of an operating system structure. In early process-oriented designs of computer architecture, processes were the basic execution entities of programs. In contemporary thread-oriented computer architectures, processes are containers for threads. A program is a description of instructions, data, and their organization, and a process is an entity of a program.

In the embodiment of the present application, the debugged device may be, for example, a desktop device, a laptop device, a handheld device, a wearable device, a smart home device, a computing device, or a vehicle-mounted device. For example, the debugged device may be a smart phone, a television, a wireless headset, a smart watch, a sound box, a PC, a tablet computer, an AR/VR device, an IOT device, as well as a netbook, an ultra-mobile personal computer (UMPC), a smart camera, a Personal Digital Assistant (PDA), a Portable Multimedia Player (PMP), an onboard device on an aircraft, an onboard device on a robot, a control device in industrial control, a wireless device in telemedicine, an intelligent device in a smart grid, an intelligent device in a smart city (smart city), an intelligent device in a smart home (smart home), and the like, as shown in fig. 1.

The debuggee device may also be an access terminal, subscriber unit, subscriber station, mobile station, relay station, remote terminal, mobile device, user terminal (UE), terminal (terminal), wireless communication device, user agent, or user equipment. The terminal device may also be a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a handheld device with wireless communication functionality, a computing device or other processing device connected to a wireless modem, a terminal device in a future 5G network or a terminal device in a future evolved PLMN or a terminal device in a future car networking, etc.

In addition, the debugged device may also be a terminal device in the IOT system, and the specific type, structure, and the like of the debugged device are not limited in this application.

In the embodiment of the present application, the debugging device generally has a display screen for displaying the debugging UI interface to the developer. For example, the debugging device may be a PC, a UMPC, a tablet computer, a netbook, or the like, and the embodiments of the present application are not limited.

Referring to fig. 2, fig. 2 is a schematic diagram illustrating a hardware structure of an electronic device according to an embodiment of the present disclosure. The electronic device may be a debuggable device or a debugging device. As shown in fig. 2, the electronic device may specifically include: the mobile phone comprises a processor 210, a memory 220, a USB interface 230, a charging management module 240, a power management module 241, a battery 242, an antenna 1, an antenna 2, a mobile communication module 250, a wireless communication module 260, an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, an earphone interface 270D, a button 280, a motor 291, an indicator 292, a camera 293, a display 294, and the like.

It is to be understood that the illustrated structure of the embodiment of the present invention does not limit the electronic device. In other embodiments of the present application, an electronic device may include more or fewer components than shown, or some components may be combined, some components may be split, or a different arrangement of components may be used. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Processor 210 may include one or more processing units. For example: the processor 210 may include an Application Processor (AP), a modem processor, a Graphics Processing Unit (GPU), an Image Signal Processor (ISP), a flight controller, a video codec, a Digital Signal Processor (DSP), a baseband processor, and/or a neural-Network Processing Unit (NPU), among others. The different processing units may be separate devices or may be integrated into one or more processors.

A memory may also be provided in processor 210 for storing instructions and data. In some embodiments, the memory in the processor 210 is a cache memory. The memory may hold instructions or data that have just been used or recycled by processor 210. If the processor 210 needs to use the instruction or data again, it can be called directly from the memory. Avoiding repeated accesses reduces the latency of the processor 210, thereby increasing the efficiency of the system.

In some embodiments, processor 210 may include one or more interfaces. The interface may include an integrated circuit (I2C) interface, an integrated circuit built-in audio (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 USB interface, etc. In the embodiment of the present application, the USB interface of the debugging device may be used for Client/Server (C/S) networking. In some embodiments, the USB interface of the commissioning device may also be used to establish a communication connection with a device in the distributed device cluster.

The wireless communication function of the electronic device may be implemented by the antenna 1, the antenna 2, the mobile communication module 250, the wireless communication module 260, the modem processor, the baseband processor, and the like.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in an electronic device may be used to cover a single or multiple communications bands. Different antennas can also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed as a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 250 may provide a solution including 2G/3G/4G/5G wireless communication applied on the electronic device. The mobile communication module 250 may include at least one filter, a switch, a power amplifier, a Low Noise Amplifier (LNA), and the like. The mobile communication module 250 may receive the electromagnetic wave from the antenna 1, filter, amplify, etc. the received electromagnetic wave, and transmit the electromagnetic wave to the modem processor for demodulation. The mobile communication module 250 may also amplify the signal modulated by the modem processor, and convert the signal into electromagnetic wave through the antenna 1 to radiate the electromagnetic wave. In some embodiments, at least some of the functional modules of the mobile communication module 250 may be disposed in the processor 210. In some embodiments, at least some of the functional modules of the mobile communication module 250 may be disposed in the same device as at least some of the modules of the processor 210.

The modem processor may include a modulator and a demodulator. The modulator is used for modulating a low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used for demodulating the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then passes the demodulated low frequency baseband signal to a baseband processor for processing. The low frequency baseband signal is processed by the baseband processor and then transferred to the application processor. The application processor outputs sound signals through an audio device (not limited to the speaker 270A, the receiver 270B, etc.) or displays images or video through the display screen 294. In some embodiments, the modem processor may be a stand-alone device. In other embodiments, the modem processor may be separate from the processor 210, and may be disposed in the same device as the mobile communication module 250 or other functional modules.

The wireless communication module 360 may provide solutions for wireless communication applied to electronic devices, including Wireless Local Area Networks (WLANs), such as Wi-Fi networks, bluetooth BT, Global Navigation Satellite System (GNSS), Frequency Modulation (FM), Near Field Communication (NFC), Infrared (IR), and the like. The wireless communication module 260 may be one or more devices integrating at least one communication processing module. The wireless communication module 260 receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering processing on electromagnetic wave signals, and transmits the processed signals to the processor 210. The wireless communication module 260 may also receive a signal to be transmitted from the processor 210, frequency-modulate and amplify the signal, and convert the signal into electromagnetic waves via the antenna 2 to radiate the electromagnetic waves. In this embodiment, the wireless communication module 260 of the commissioning device may be used for client/server (C/S) networking. In some embodiments, the wireless communication module 260 of the commissioning device may also be used to establish a communication connection with a device in the distributed device cluster.

In some embodiments, antenna 1 of the electronic device is coupled to the mobile communication module 250 and antenna 2 is coupled to the wireless communication module 360 so that the electronic device can communicate with the network and other devices through wireless communication techniques. The wireless communication technology may include global system for mobile communications (GSM), General Packet Radio Service (GPRS), code division multiple access (code division multiple access, CDMA), Wideband Code Division Multiple Access (WCDMA), time-division code division multiple access (time-division code division multiple access, TD-SCDMA), Long Term Evolution (LTE), LTE, BT, GNSS, WLAN, NFC, FM, and/or IR technologies, etc. The GNSS may include a Global Positioning System (GPS), a global navigation satellite system (GLONASS), a beidou satellite navigation system (BDS), a quasi-zenith satellite system (QZSS), and/or a Satellite Based Augmentation System (SBAS).

The electronic device implements display functions via the GPU, the display screen 294, and the application processor. The GPU is a microprocessor for image processing, and is connected to the display screen 294 and an application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. For example, in embodiments of the present application, processor 210 may include one or more GPUs that execute program instructions to generate or alter display information. In this embodiment, the debugging device may implement display of the UI interface through the GPU, the display screen 294, the application processor, and the like. The debugged device may implement display of an application interface corresponding to the process through the GPU, the display screen 294, the application processor, and the like.

The display screen 294 is used to display images, video, and the like. The display screen 294 includes a display panel. The display panel may adopt a Liquid Crystal Display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (active-matrix organic light-emitting diode, AMOLED), a flexible light-emitting diode (FLED), a miniature, a Micro-oeld, a quantum dot light-emitting diode (QLED), and the like. In some embodiments, the electronic device may include 1 or N display screens 294, N being a positive integer greater than 1. In the embodiment of the present application, the debugging device may display the UI interface through 1 or N display screens 294. The debuggee device may display the application interface corresponding to the process through 1 or N display screens 294.

Memory 220 may be used to store computer-executable program code, which includes instructions. The memory 220 may include a program storage area and a data storage area. The storage program area may store an operating system, an application program (such as a sound playing function, an image playing function, etc.) required by at least one function, and the like. The data storage area can store data (such as audio data, phone book and the like) created in the using process of the electronic equipment. Further, the memory 220 may include a high-speed random access memory, and may further include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (UFS), and the like. The processor 210 executes various functional applications of the electronic device and data processing by executing instructions stored in the memory 220 and/or instructions stored in a memory provided in the processor.

It should be noted that the hardware modules included in the electronic device shown in fig. 2 are only described by way of example, and do not limit the specific structure of the electronic device. For example, the electronic device may further include other hardware modules having an interactive relationship with the hardware modules illustrated in the drawings, and is not limited herein.

In this embodiment of the present application, the application process running in one or more devices may be implemented based on a programming language, for example, based on C/C + +, Java, JavaScript (JS), Python, hypertext markup language (HTML), or a server-side programming language (PHP), and the present application is not limited in this embodiment.

Typically, a developer can debug an application process based on a debugger, e.g., a setInto an Integrated Development Environment (IDE). Illustratively, the IDE may be the Deveco Studio development platform,

Intellij IDEA developed by companies based on Intellij open source framework,

Android Studio developed based on Intellij open source framework,

Visual Studio of the company or

Eclipse developed by the company,

NetBeans, developed by Inc.

Among them, the DevEco Studio development platform aims to help developers to use the open capability of the operating system quickly, conveniently and efficiently. For example, the method is used for helping developers to support application development of '1 +8+ N' full-scene pan-terminal, and cross-terminal ecological sharing is achieved. Illustratively, the DevEco Studio development platform can be specifically used for remote real-time testing, cloud testing capability, and help developers to comprehensively improve application quality and experience. In general, an IDE may also be referred to as a compiler, debugger, or programming software.

Referring to fig. 3A, fig. 3A is a diagram illustrating an example debugging system framework, taking Intellij as an example of an open source framework. As shown in fig. 3A, the debugging system includes a debugging device and a debuggee device. A Framework (Framework) layer and a first debugging module are integrated in the debugging equipment. For example, the first debug module may include a debug plug-in (debug plug-in). A debugged device is integrated with a debugging tool (debug tool) and runs one or more debuggeable processes (processes) (fig. 3A only takes as an example that a debuggeable process (process) runs in a debugged device).

On the debugging device shown in fig. 3A, a Framework (Framework) layer may generate a debugging command for a debugging event of a debugged process according to a detected debugging event triggered by a developer (for example, triggered by the developer on a User Interface (UI) (hereinafter, abbreviated as UI interface)), and send the debugging command to a first debugging module. The first debugging module may convert a debugging command from a Framework (Framework) layer into a debugging command corresponding to a specific debugging tool (debug tool) protocol. And the first debugging module may send the converted debugging command to a debugging tool (debug tool) of the debugged device through a communication connection (such as a wired connection or a wireless connection) with the debugged device. By way of example, debug commands may include, but are not limited to, breakpoint commands, jump commands, read and write commands, and the like. The breakpoint command refers to a debug command that suspends a current task (i.e., a program), executes another task (i.e., an interrupt service program), and returns to the original task to continue execution after execution.

For example, the wired connection may be a connection through a Universal Serial Bus (USB), a network cable connection, or the like; the wireless connection may be a wireless fidelity (Wi-Fi) connection or the like. The method and the device do not limit a specific network connection mode between the debugging device and the debugged device.

By way of example, the debugging tool (debug tool) may be a debugging tool JDB for Java language, a debugging tool GDB or LLDB for C + + language, or a debugging tool V8 for JS debugging, and the embodiments of the present application are not limited thereto.

The debug tool (debug tool) of the debugged device parses the received debug command from the debug device to obtain the instruction and data corresponding to the debug command. And debugging interruption is carried out on the debuggable process (process) by a debugging tool (debug tool) according to the instruction and the data obtained by analysis, and specified debugging information (such as variable values and/or stack information and the like) after interruption is obtained and fed back to the debugging plug-in (debug plug-in). The debugging plug-in (debug plug in) is used for analyzing debugging information from a debugging tool (debug tool) and calling a Framework interface according to a data model required by a Framework (Framework) layer to be displayed to a developer on a UI interface. The data model may include, but is not limited to, a file path line of a breakpoint or a line on which a breakpoint resides, among others.

It should be noted that, based on a debugging system framework similar to that shown in fig. 3A, debugging of a debuggeable process (process) on a debugged device by a debugging device may be implemented. However, based on a debugging system framework like that shown in fig. 3A, the debugging device cannot perform cross-process debugging. The cross-process debugging refers to the cooperative debugging of a plurality of application processes which are mutually associated.

In addition, based on a debugging system framework like that shown in fig. 3A, collaborative debugging across devices/processes in a distributed scenario cannot be achieved. For example, in a scenario where a smart watch controls a large-screen device (such as a television), synchronization problems such as communication, connection, and control between the smart watch and the large-screen device need to be cooperatively debugged. On the basis of a debugging system framework similar to that shown in fig. 3A, cross-device cooperative debugging of the smart watch and the large-screen device cannot be realized.

In order to solve the foregoing problem, embodiments of the present application provide a software debugging method, which can implement cooperative debugging of one or more devices in a distributed scenario. For example, the method may implement, in a debugging system, cooperative debugging of one debugged device in a distributed device cluster by a plurality of debugging devices, cross-device cooperative debugging of a plurality of debugged devices by one debugging device, cross-device cooperative debugging of a plurality of debugged devices by a plurality of debugging devices, and the like.

The software debugging method provided in the embodiment of the present application may be implemented based on the debugging system framework shown in fig. 3B, and as shown in fig. 3B, the debugging system provided in the embodiment of the present application may include a debugging device and a debugged device. Wherein, a Framework (Framework) layer and a second debugging module are integrated in the debugging equipment. For example, the second debug module may include a debug tool distribution (debug) layer. The debugged device is integrated with a distributed debug assistant and a debug tool (debug tool), and the debugged device runs one or more debuggeable processes (processes) (where fig. 3B only takes as an example that one debuggeable process (process) runs in the debugged device). A distributed debug assistant and a debug tool (debug tool) are integrated in the debuggee device, and one or more debuggeable processes (processes) run in the debuggee device (fig. 3B only takes as an example that one debuggeable process (process) runs in the debuggee device).

On the debugging device shown in fig. 3B, a Framework (Framework) layer may generate a debugging command according to a detected debugging event for the debugged process triggered by the developer (for example, triggered by the developer on the UI interface), and send the debugging command to the second debugging module.

The second debugging module can be used for networking among the multiple debugging devices. Through the networking among the multiple debugging devices, a developer can realize the cooperative debugging of the multiple debugging devices on one or more debugged devices.

The second debugging module can also be used for shielding debugging protocol differences among different language debugging devices. For example, a unified protocol, such as a defined protocol (e.g., DAP protocol) or a custom protocol, is used to interface data models (e.g., java objects, C + + objects, etc.) in different languages at the framework layer.

In some embodiments, the second debugging module may convert the debugging command from the Framework (Framework) layer shown in fig. 3B into a debugging command corresponding to a specific debugging tool (debug tool) protocol. Further, the second debugging module may further send the converted debugging command to second debugging modules of other debugging devices (where fig. 3B does not show other debugging devices), so that the second debugging modules of other debugging devices forward the debugging command to the corresponding debugged device. The debugging command received by the second debugging module carries the identifier of the debugged equipment and the identifier of the debugged process.

In other embodiments, the second debugging module may also receive debugging commands from second debugging modules of other debugging devices (where fig. 3B does not show other debugging devices). And forwarding the debugging commands from the second debugging modules of other debugging devices to the corresponding debugged devices.

The second debugging module is further configured to establish a direct connection relationship with the debugged device, or establish an indirect connection relationship with the debugged device through other electronic devices. The second debugging module establishes an indirect connection relationship with the debugged device through other electronic devices, which means that: the second debugging module establishes a direct connection relationship through other electronic equipment so as to establish an indirect connection relationship with debugged equipment connected with the equipment through the equipment. This will be described in detail below.

The distributed debug assistant in the debuggee device is configured to receive debug commands from the second debug module.

In some embodiments, when the debugged device shown in fig. 3B establishes a direct connection relationship with the second debugging module shown in fig. 3B, the distributed debugging assistant shown in fig. 3B may be configured to distribute a debugging command to the debugging command or execute the debugging command according to the debugging command from the second debugging module, where the debugging command carries the identifier of the debugged device.

For example, when a debug command is directed to a process in the debuggee device shown in fig. 3B, the distributed debug assistant shown in fig. 3B may convert the debug command into a debug command in a corresponding thread language, and call a specific debug tool (e.g., a debug tool such as LLDB-MI or JDB) installed in the debuggee device to send the debug command to the debuggee process, and receive debug information of the debuggee process in the debuggee device returned by the debug tool.

For another example, when the debug command is for another debuggee device (where fig. 3B does not show another debug device), the distributed debug assistant shown in fig. 3B may distribute the debug command to the distributed debug assistant of the corresponding debuggee device according to the debug command from the second debug module, which carries the identifier of the debuggee device. And receiving debugging information of the debuggee process returned by other debuggee equipment.

Further, when the debugged device shown in fig. 3B establishes a direct connection relationship with the second debugging module shown in fig. 3B, the distributed debugging assistant shown in fig. 3B may also be configured to feed back the obtained debugging information to the second debugging module of the debugging device, so that the second debugging module converts the debugging information into the data format and the data model of the corresponding language. And calling an interface of the framework layer to trigger the display of the debugging operation result on the UI interface of the debugging equipment, so that the debugging operation result is fed back to the developer through the UI interface.

In other embodiments, when the debuggee device shown in fig. 3B establishes an indirect connection with the debuggee device shown in fig. 3B through another electronic device (where fig. 3B does not show another debug device), the distributed debug assistant shown in fig. 3B may be configured to receive the debug command forwarded by the distributed debug assistant of the another electronic device. The debugging command is converted into a debugging command of a corresponding thread language, a specific debugging tool (such as a debugging tool like LLDB-MI or JDB) installed in the debugged device is called to send the debugging command to the debugged process, and the debugging information of the debugged process in the debugged device returned by the debugging tool is acquired. And forwarding the acquired debugging information to a second debugging module of the debugging device through the distributed debugging assistant of the other electronic device, so that the second debugging module converts the debugging information into a data format and a data model of the corresponding language. And calling an interface of the framework layer to trigger the display of the result of the debugging operation on the UI interface of the debugging equipment, so that the result of the debugging operation is fed back to the developer through the UI interface.

Based on the debugging device integrated with the second debugging module and the debugged device integrated with the distributed debugging assistant shown in fig. 3B, a developer may perform cooperative debugging on a plurality of application processes associated with each other in a plurality of debugged devices according to actual needs.

Referring to fig. 4, fig. 4 is a diagram illustrating an example of a debugging system framework according to an embodiment of the present application. The software debugging method provided by the embodiment of the application can be realized based on a debugging system framework similar to that shown in fig. 4.

As shown in fig. 4, the debugging system provided in the embodiment of the present application may include a debugging server 41 and a distributed device cluster 42. The distributed device cluster 42 includes one or more electronic devices, for example, fig. 4 is an example in which the distributed device cluster 42 includes a plurality of electronic devices having the structure shown in fig. 1, and is used for implementing the same or different functions.

In some embodiments, the debugging system may also include one or more debugging clients. Fig. 4 exemplifies that the debugging system includes two debugging clients (a debugging client a43 and a debugging client B44). When the debugging system includes a plurality of debugging devices, for example, a debugging server and one or more debugging clients, the debugging server and the one or more debugging clients may form a debugging cluster (also referred to as IDE cluster). For example, debug server 41, debug client a43, and debug client B44 shown in fig. 4 may form a debug cluster.

In the debugging system framework shown in fig. 4, the debugging server 41 is mainly used for establishing a communication connection with a host of the distributed device cluster 42 (for example, establishing a communication connection through USB or Wi-Fi), networking the distributed device cluster, implementing breakpoint and authority division management of multiple debuggers, performing cross-process debugging command combination, issuing and managing debugging commands, distributing and managing debugging information, monitoring the registration capability of the debugging system, and the like.

The host of the distributed device cluster 42 is mainly used for performing debuggable device discovery, debuggable process discovery, communication connection with the debug server 41, forwarding of debug commands in the distributed device cluster 42, forwarding of debug information in the distributed device cluster 42, and the like in the distributed device cluster. Illustratively, in the framework of the commissioning system shown in fig. 4, the smartphone is a host (hereinafter referred to as a master) of the distributed device cluster 42. The slave device corresponds to the master device, and the television, the wireless headset, the smart watch, the sound box, the PC, the tablet PC, the AR/VR device, and the IOT device shown in fig. 4 are all slave devices.

It is to be understood that a master device is a device in the distributed device cluster that establishes a direct communication connection with a commissioning device in the commissioning cluster. The slave device is a device in a distributed device cluster, and establishes indirect communication connection with the debugging device in the debugging cluster through communication connection with the master device.

In addition, the debugging server 41, the debugging client a43, and the debugging client B44 may be electronic devices (such as PCs) of the same structure, and the electronic devices may be defined and set by developers as servers or clients in a debugging cluster. For example, if the electronic device 1 (e.g., the debugging server 41 shown in fig. 4) is directly connected to the master device (e.g., the smart phone shown in fig. 4) in the distributed device cluster, the electronic device 1 may be understood as a server in the debugging cluster. For another example, if the electronic device 2 (the debugging client a43 and the debugging client B44 shown in fig. 4) establishes an indirect connection relationship with a master device (a smartphone shown in fig. 4) in the distributed device cluster through a communication connection with the electronic device 1 (the debugging server 41 shown in fig. 4), the electronic device 2 may be understood as a client in the debugging cluster.

As shown in FIG. 4, after debug client A43 and debug client B44 have C/S networked with debug server 41, debug client A43 and debug client B44 may communicate with devices in distributed device cluster 42 via debug server 41. Specifically, as shown in fig. 4, the debug client a43 and the debug client B44 may communicate with a smart phone (i.e., a master device) or other slave devices (e.g., the tv, the wireless headset, the smart watch, the speaker, the PC, the tablet, the AR/VR device, and the IOT device shown in fig. 4 are all slave devices) in the distributed device cluster 42 through the debug server 41.

In the embodiment of the present application, the debug client a43, the debug client B44, and the debug server 41 may implement the following functions: checking and managing a distributed database, checking and managing equipment registration capability in a distributed equipment cluster, commanding unauthorized detection, breakpoint and authority distribution management and the like. The distributed database is used for providing storage of debugging equipment, debugging commands, debugged equipment, debugged processes, debugging data and the like in the debugging system. The distributed database can acquire larger storage capacity and higher concurrent access amount by dispersedly storing data on a plurality of data storage nodes connected through communication.

Further, debug client a43 and debug client B44 may also implement aggregation of debug commands to the server side (i.e., debug server 41). Debug server 41 may also implement debug command coordination.

In some embodiments, debug client A43, debug client B44, and debug server 41 may implement one or more of the functions described above in terms of modules or units having debug features. In the embodiment of the present application, devices in a distributed device cluster may communicate with each other. However, it should be noted that the embodiments of the present application are not limited to the modules or units on which the above functions are implemented.

In the embodiment of the present application, the master device and the slave device in the distributed device cluster 42 may implement the following functions: the method comprises the steps of device discovery, distributed device cluster owner selection in a Master-Slave mode (Master/Slave), distributed device cluster networking, distributed database checking and the like. The device discovery is used for discovering electronic devices, for example, discovering electronic devices connected to the same local area network. The distributed device cluster owner is used for determining a Master device (Master) and one or more Slave devices (Slave) in a debugging system. The distributed device cluster networking is used for establishing communication connection among devices in the distributed device cluster. The distributed database check is used for acquiring data such as debugging equipment, debugging commands, debugged equipment, debugged processes and the like in the debugging system by checking the distributed database.

In some embodiments, the master and slave devices may implement one or more of the functions described above in terms of modules or units having distributed characteristics. However, it should be noted that the embodiments of the present application are not limited to the specific modules or units for realizing the above functions. Further, the master device in the distributed device cluster 42 may also establish a communication connection (e.g., a communication connection established through USB or Wi-Fi, etc.) with the debug server 41 and the slave devices in the distributed device cluster 42. In some embodiments, if the debugged device is a slave device in the distributed device cluster, the master device in the distributed device cluster may also issue a debug command to one or more slave devices, receive debug data (also referred to as debug information) fed back by the one or more slave devices, and forward the debug information to the debug server.

It should be noted that the present application does not limit the specific networking manner of the debugging system. For example, the method provided by the embodiment of the application can also be applied to a micro-service debugging system and the like.

Based on the debugging system framework shown in fig. 4, a developer can realize debugging under any one of the following scenarios:

1. the multi-device debugs the multi-device.

For example, the developer uses the debugging client a43 and/or the debugging client B44 to cooperatively debug the master device and one or more slave devices or debuggee processes in one or more slave devices in the distributed device cluster 42 through the debugging server 41. As another example, a developer uses the debugging server 41, and the debugging client a43 and/or the debugging client B44 to cooperatively debug a master device and one or more slave devices, or debuggee processes in one or more slave devices, in the distributed device cluster 42.

2. And debugging multiple devices by using a single device.

For example, a developer uses the debugging server 41 to perform cooperative debugging on a master device in the distributed device cluster 42 and a debuggee process in one or more devices. Alternatively, the developer uses the debug server 41 to cooperatively debug a debuggable process in one or more slave devices in the distributed device cluster 42.

3. And debugging the single device by the multiple devices.

For example, the developer uses the debugging client a43 and/or the debugging client B44 to perform the cooperative debugging on the debuggee process in the master device in the distributed device cluster 42 through the debugging server 41. As another example, the developer uses the debugging server 41, and the debugging client a43 and/or the debugging client B44 to perform cooperative debugging on the debuggee process in the master device in the distributed device cluster 42.

4. And debugging the single device by the single device.

For example, a developer uses the debug server 41 to debug a debuggee process in a master device in the distributed device cluster 42.

It should be noted that, although the conventional debugging technology may also implement debugging of a single device on a single device, in the conventional debugging technology, a debugging device is a debugged process directly connected to a debuggee device through a debugging tool (e.g., JDB, GDB, etc.). In the solution provided in the embodiment of the present application, the single device to single device debugging may be implemented by relying on a debugging system framework similar to that shown in fig. 4. Specifically, in the single device debugging device provided in the embodiment of the present application, the debugging device (e.g., the debugging server 41) serves as its own server, and the debugged device (e.g., the smart phone) serves as its own master device, so that the debugging device debugs the debugged process in the debugged device. The implementation details of the two are substantially different, and based on the software debugging method provided by the embodiment of the application, software debugging under multiple scenes (such as multiple-device debugging multiple-device scenes, single-device debugging multiple-device scenes, multiple-device debugging single-device scenes or single-device debugging single devices) can be flexibly realized.

It should be noted that the present application does not limit the specific networking manner of the debugging system. For example, the method provided by the embodiment of the present application may be applied to a debugging system such as a hong meng distributed debugging system or a micro-service distributed debugging system. The debugging system has the capability of acquiring the following information no matter what networking mode is adopted: a path of a class of the registered interface, a function name of the registered function, a code line of the function, and the like. For example, for the hongmeng distributed debugging system, the information may be obtained from a debugging server; for a microservice distributed debugging system, the above information may be obtained from configuration items of code.

Referring to fig. 5, fig. 5 shows an exemplary diagram of a debugging system structure provided in an embodiment of the present application, where a debugging cluster includes a debugging server 41, a debugging client a43, and a debugging client B44, a distributed device cluster includes a smart phone, a sound box, and a television, and the smart phone is a master device, and the television and the sound box are slave devices.

As shown in fig. 5, the debug server 41, the debug client a43, and the debug client B44 include a Framework (Framework) layer and a second debug module. The specific functions of the second debugging module are different when the electronic device (such as a PC) is used as a debugging server and is used as a debugging client. For ease of understanding, fig. 5 represents the second debugging module of the debugging Server 41 by the second debugging module (Server), and represents the second debugging modules of the debugging Client a43 and the debugging Client B44 by the second debugging module (Client). The smart phone, the speaker and the television set comprise a distributed debugging assistant, a debugging tool and debuggee processes (such as a first process, a second process and a third process shown in fig. 5). For ease of understanding, fig. 5 shows a distributed debugging assistant for a Master device (i.e., a smartphone) as a distributed debugging assistant (Master) and a distributed debugging assistant for a Slave device as a distributed debugging assistant (Slave).

The second debugging module (including a second debugging module (Server) and a second debugging module (Client)) is used for networking among the multiple IDE.

Further, in this embodiment of the present application, the second debugging module (including the second debugging module (Server) and the second debugging module (Client)) may also be configured to shield a difference of debugging protocols between different language debugging devices, and interface data models of different languages of the framework layer using a unified debugging protocol. For example, a defined protocol (e.g., DAP protocol) or a custom protocol may be used to interface data models (e.g., java objects, C + + objects, etc.) in different languages at the framework level.

The second debugging module (Server) may also be configured to establish a communication connection (e.g., a communication connection is established through USB or Wi-Fi) with a master device (e.g., a smartphone shown in fig. 5) in the distributed device cluster, and issue a debugging command to a debuggee device in the distributed device cluster, where the debugging command is sent by the debugging Client a43 or the debugging Client B44 to the second debugging module (Server) through the second debugging module (Client), or the debugging command from the framework layer of the debugging Server 41 is issued to the debuggee device in the distributed device cluster.

When the second debugging module (Server) issues a debugging command, the second debugging module (Server) first sends the debugging command to a distributed debugging assistant (Master) of a Master device (such as a smart phone shown in fig. 5) in the distributed device cluster, and the distributed debugging assistant (Master) further completes subsequent debugging command distribution work. In addition, the second debugging module (Server) may be further configured to receive a returned result (i.e., debugging information) for the debugging command from the debuggee device after sending the debugging command to a distributed debugging assistant (Master) of the Master device (e.g., the smart phone shown in fig. 5), and convert the returned result (i.e., the debugging information) into the data format and the data model of the corresponding language. And calling an interface of the framework layer to trigger the display of a debugging operation result on a UI (user interface) of the debugging equipment, and feeding the debugging operation result back to the developer.

The distributed debugging assistants (including a distributed debugging assistant (Master) and a distributed debugging assistant (Slave)) of the debugged device may be used to receive a debugging command for a debugged process in the debugged device, implement device discovery, and perform distributed device cluster selection, distributed device cluster networking, and the like after the device is discovered.

Furthermore, the distributed debugging assistant is also used for discovering the debuggable process and reporting the information of the debuggable process.

Further, the distributed debugging assistant of the Master device (Master) is further configured to establish a communication connection (for example, a communication connection is established through USB or Wi-Fi) with the debugging server and the Slave device (Slave) in the distributed device cluster, receive a debugging command issued by the debugging server or the debugging client, perform distribution of the debugging command in the distributed device cluster, and the like.

Further, the distributed debug assistant of the debugged device is further configured to, after receiving the debug command, convert the debug command into a debug command in a corresponding thread language, and call a specific debug tool (e.g., a debug tool such as LLDB-MI or JDB) installed in the debugged device to send the debug command to the debugged process, and receive debug information of the debugged process in the debugged device returned by the debug tool. For example, the commissioning tool may include any of the following: LLDB-MI, JDB, GDB, LLDB, V8, or PDB.

In this embodiment of the present application, the debugged device may be a master device in a distributed device cluster (e.g., a smartphone shown in fig. 5), may also be one or more slave devices in the distributed device cluster (e.g., one or more of a television, a wireless headset, a smart watch, a sound box, a PC, a tablet computer, an AR/VR device, and an IOT device shown in fig. 5), and may also include both the master device in the distributed device cluster and one or more slave devices in the distributed device cluster, which is not limited in this application.

When the debugged device is a Master device (e.g., a smartphone shown in fig. 5) in the distributed device cluster, a distributed debug assistant (Master) of the Master device (e.g., the smartphone shown in fig. 5) may directly send debug information for the debug command to the second debug module (Server), so that the second debug module (Server) performs subsequent debug information distribution. When the debugged device is a Slave device (such as a television or a sound box shown in fig. 5) in the distributed device cluster, the distributed debugging assistant (Master) of the Master device (such as a smartphone shown in fig. 5) may receive debugging information for a debugging command from the distributed debugging assistant (Slave) of the Slave device (such as a television or a sound box shown in fig. 5), and send the received debugging information to the second debugging module (Server), so that the second debugging module (Server) performs subsequent debugging information distribution.

It should be noted that fig. 5 only takes as an example that only one debuggable process (such as the first process, the second process, and the third process shown in fig. 5) is run by the master device and the slave device in the distributed device cluster, and the application does not limit the number of debuggable processes run in the debuggable device. In addition, the embodiment of the present application does not limit the correspondence between the debugged process and the debugging tool. For example, the first process, the second process, and the third process shown in FIG. 5 may be debugged by any of debugging tools such as LLDB-MI, JDB, GDB, LLDB, V8, or PDB.

More specifically, referring to fig. 6A, fig. 6A shows a possible structure of the second debug module. As shown in fig. 6A, the second debug module (including the second debug module (Server) and the second debug module (Client)) may include a connection manager (connectirmanager), a device manager (devices manager), a breakpoint manager (breakpoints manager), a command manager (command manager), a debug information manager (debug info manager), and a distributed capability manager (distributedability manager).

In this embodiment, the connection manager may be specifically configured to provide a networking capability (e.g., a C/S networking capability) between the debug client and the debug server.

It should be noted that, in the scenario of debugging a single device or debugging multiple devices by a single device in the embodiment of the present application, the connection manager (connectiormanager) does not need to participate.

The device manager may be specifically configured to connect a master device in the distributed device cluster, so that the debug server may obtain device information of each device in the distributed device cluster through the master device. The device manager may also be used to view capabilities, data, etc. of the debuggee device.

The breakpoint manager may be specifically configured to provide breakpoint delegation management between the debug client and the debug server. And breakpoint information between the debugging client and the debugging server is mutually visible. For example, the breakpoint information newly added by the debugging client a is visible to the debugging client B; and newly added breakpoint information of the debugging client B is visible to the debugging client A. In the same process, breakpoints can be newly added to the debugging client or the debugging server. However, the debugging client or the debugging server can only modify or delete the newly added breakpoints; between different processes, the debugging client or the debugging server can only modify, delete or newly add breakpoints in the own process.

The command manager may be specifically configured to perform cross-process debug command combination, debug command issue management, provide debug command queue management, combine debug command management between different IDEs, and debug command management for distributed registration capabilities. Wherein, the management of combined debugging commands among different IDE is mainly used for realizing cross-process debugging capability; debug command management for distributed registration capabilities is mainly used to support cross-process conditional breakpoint capabilities.

The debug information manager may be specifically configured for debug information reception, debug information distribution management, providing distribution of debug information in the IDE cluster, distribution of common data in the IDE cluster, and distribution of thread information in the IDE cluster. It should be noted that, in a single device debugging scenario in the embodiment of the present application, for example, in a single device debugging scenario or a single device debugging scenario for multiple devices, distribution of the debugging information, the common data, and the thread information in the IDE cluster is not involved, and the debugging information, the common data, and the thread information are all returned to the single debugging device.

The distributed capability manager may be specifically configured to monitor registration capabilities of the debug system and provide tracking of the registered capabilities of each device in the distributed device cluster. For example, in a hong meng distributed debugging system that relies on a distributed soft bus, a distributed capability manager may be used to query the distributed soft bus; and inquiring the registration capability of the equipment in the distributed equipment cluster through the distributed soft bus, inquiring the characteristics of the Hongmon distributed debugging system and the like. As another example, in a micro-service distributed debugging system, a distributed capability manager may be used to query interfaces and the like registered by each micro-service.

It should be noted that, in the embodiment of the present application, the second debugging module may not include the above-mentioned distributed capability manager. The function of querying registration capability of devices in the distributed device cluster or querying tracking capability of each device registration in the distributed device cluster, such as characteristics of the distributed debugging system, may be implemented by relying on other modules or units, and the present application is not limited thereto.

Referring to fig. 6B, fig. 6B shows a schematic working flow diagram of a second debugging module provided in the embodiment of the present application, taking a debugging server as an example. As shown in fig. 6B, the connection manager of the second debugging module is mainly used for networking the debugging client and the debugging server to obtain the debugging cluster.

After the connection manager completes networking and the debugging cluster is established. The device manager of the second commissioning module (more specifically, the device manager in the second commissioning module of the commissioning server) may connect the master devices in the distributed device cluster. For example, a device manager in a second debug module of the debug server may establish a communication connection with a master device in the distributed device cluster in response to a developer establishing a communication connection between the debug server and the master device. Since the master device and the slave device in the distributed device cluster have already established connection, the debugging system is established up to this point.

For example, the operation of the developer establishing the communication connection between the debugging server 41 and the host device may be an operation of the developer connecting the debugging server 41 and the host device through a wired connection manner such as a USB, a network cable, or the like, or an operation of the developer inputting an IP address of the host device on the debugging server 41 to establish the communication connection, an operation of the developer inputting an IP address of the debugging server 41 on the host device to establish the communication connection, or the like, and the embodiment of the present application is not limited.

Further, the distributed capability manager of the second debugging module (more specifically, the distributed capability manager in the second debugging module of the debugging server) may continuously track the registration capability of the debugging system and the registration capability of the devices in the cluster in the distributed device, so as to ensure that the capability of the debugging system for supporting the collaborative debugging is normal.

Further, the command manager of the second debug module may perform cross-process debug command combination, debug command management, debug command queue management, and the like on the debug command from the debug server and/or the debug client. And the command manager can carry out debugging command issuing management, and issues debugging commands from the debugging server and/or the debugging client to the main equipment so as to facilitate the main equipment to carry out subsequent debugging command distribution.

For example, if the debug command is a breakpoint command, the breakpoint manager of the second debug module may provide breakpoint delegation management between the debug client and the debug server. For example, only debugging devices bound to the debuggee process are allowed to debug the debuggee process at the same time.

Further, after the debugged device completes the debugging operation according to the debugging command, the debugging information manager of the second debugging module may receive the debugging information from the debugged device, and perform debugging information distribution management, debugging information distribution, public data distribution, thread information distribution, and the like, so as to feed back the debugging information to the developer in time.

It should be noted that the structures of the debugging client and the debugging server in fig. 5 and fig. 6A are only examples. In some embodiments, as shown in fig. 7, the debug client and the debug server may further include a Debug Adapter Protocol (DAP) layer. The debug protocol adaptation layer may be used to implement part of the functionality of the second debug module shown in fig. 5 or fig. 6A described above.

For example, the debugging protocol adaptation layer may be used to shield the debugging protocol adaptation layer, which is mainly used to shield the differences of the debugging protocols between different language debugging devices, and use a unified debugging protocol to interface data models of different languages in the framework layer. For example, a defined protocol (e.g., DAP protocol) or a custom protocol may be used to interface data models (e.g., java objects, C + + objects, etc.) in different languages at the framework level.

In addition, the second debugging module can also be used for converting the IDE debugging event triggered by the operation of the developer into a debugging command. Further, in this embodiment of the application, the second debugging module may be further configured to convert a return result (i.e., debugging information) of the debugging command returned by the debuggee device into a data format and a data model of the corresponding language. And calling an interface of the framework layer to trigger the display of the result of the debugging operation on the UI interface so as to feed the result of the debugging operation back to the developer through the UI interface.

As described above, in the embodiment of the present application, software debugging in any one of the following scenarios in a distributed architecture can be implemented: the method comprises the steps of debugging multiple devices by multiple devices, debugging multiple devices by single device, debugging single device by multiple devices and debugging single device by single device.

Wherein the multi-device commissioning of the multi-device may include: the method comprises the steps that one or more debugging clients and a debugging server are used for cooperatively debugging processes in a master device and one or more slave devices, one or more debugging clients and the debugging server are used for cooperatively debugging processes in a plurality of slave devices connected with the master device, one debugging client is used for debugging processes in one or more slave devices connected with the master device through the debugging server, and a plurality of debugging clients are used for debugging processes in one or more slave devices connected with the master device through the debugging server. For example, in the debugging system framework shown in fig. 4, the debugging client a43 or the debugging client B44 debugs one slave device connected to a smartphone, i.e., a multi-device debugging multi-device scenario, through the debugging server 41. For another example, a scenario in which a plurality of slave devices in the debug client a43, the debug client B44, and the debug server 41 cooperatively debug and connect with a smartphone is a multi-device debug multi-device scenario.

The single device commissioning of multiple devices may include: the debugging server debugs processes in the master device and the one or more slave devices, and the debugging server debugs processes in the one or more slave devices connected with the master device. For example, in the debugging system framework shown in fig. 4, a scenario in which the debugging server 41 debugs one slave device connected to a smartphone is a single-device debugging multi-device scenario.

The multi-device commissioning single device may include: the debugging client debugs the process in the main equipment through the debugging server, the debugging clients debugs the process in the main equipment through the debugging server, and one or more debugging clients and the debugging server are used for cooperatively debugging the process in the main equipment. For example, in the debugging system framework shown in fig. 4, a scenario in which the debugging client a43 and/or the debugging client B44 debugs a process in a smartphone through the debugging server 41 is a single device multi-device debugging scenario.

The single device commissioning single device may include: the debug server debugs a process in the host device.

The software debugging method provided by the embodiment of the application can comprise the following stages: the method comprises a debugging command generating stage (namely a first stage), a debugging command issuing stage (namely a second stage), a debugging stage (namely a third stage), a debugging information returning stage (namely a fourth stage) and a debugging information displaying stage (namely a fifth stage).

Typically, before the first phase, a connection establishment phase and a debuggable progress determination phase are also included. The connection establishing stage is used for establishing a distributed equipment cluster and a debugging cluster. The debuggable process determination phase is used for a developer to acquire the information of the debuggable process.

Illustratively, in some embodiments, as shown in fig. 8, the connection establishment phase may include the following steps S801 to S803:

s801, performing distributed device cluster networking on a plurality of electronic devices (such as a first device, a second device, a third device, and a fourth device) to obtain a distributed device cluster 42.

Fig. 8 illustrates an example in which the first device is a smart phone, the second device is a television, the third device is a sound box, and the fourth device is the wireless headset, the smart watch, the sound box, the PC, the tablet PC, the AR/VR device, and the IOT device shown in fig. 4.

For example, in some embodiments of the present application, a plurality of electronic devices (e.g., the first device, the second device, the third device, and the fourth device) may be discovered through the devices, and after discovering the devices, perform distributed device cluster owner selection, and perform distributed device cluster networking to obtain the distributed device cluster 42.

For example, in a hongmeng distributed debugging system relying on a distributed soft bus, a plurality of electronic devices can discover and network each other through the distributed soft bus. The distributed equipment cluster networking of the electronic equipment can be completed by establishing USB connection or Wi-Fi connection between the equipment and the like.

In some embodiments of the present application, multiple electronic devices may prompt a developer to set up a master device and a slave device. For example, the electronic device may remind a developer to set the main device and the auxiliary device by setting up a connection relationship between multiple electronic devices through a pop-up setting box, a voice prompt, and the like, so as to obtain the distributed device cluster 42, which is not limited in the embodiment of the present application. For example, the electronic device may prompt a developer to establish a connection relationship between the plurality of electronic devices in a wired connection manner such as a USB or a network cable, or establish a connection relationship between the plurality of electronic devices in a wireless connection manner such as inputting an IP address or establishing a Wi-Fi connection.

In other embodiments of the present application, multiple electronic devices may also be selected according to the performance of the device, the connection condition of the device, and the like, which is not limited in the present application. For example, the electronic devices may preferentially select a device configured first as a master device and other devices as slave devices. For example, the first configured device may include an electronic device or the like in which the most discovered device automatically establishes a wireless connection.

As another example, the first configured device may include the electronic device that first discovered the device. For this case, the electronic device that first discovers a device may remind the developer of the identity of the device discovered by the device, and remind the developer to obtain the distributed device cluster 42 by establishing a connection relationship between multiple electronic devices.

For a specific method and an operation process in which a developer obtains a distributed device cluster by establishing a connection relationship between a plurality of electronic devices, reference may be made to descriptions in the conventional technology, and details are not described in the embodiments of the present application.

In some embodiments of the present application, more specifically, multiple electronic devices may perform device discovery by a distributed debug assistant, and perform distributed device cluster selection and distributed device cluster networking after discovering devices. Wherein the distributed device cluster owner is configured to determine a master device (e.g., a smart phone as shown in fig. 4) and one or more slave devices (e.g., a television, a wireless headset, a smart watch, a speaker, a PC, a tablet, an AR/VR device, and an IOT device as shown in fig. 4). The distributed device cluster networking is used for establishing a distributed device cluster.

S802, the debugging server 41, the debugging client A43 and the debugging client B44 are networked to obtain a debugging cluster.

It is understood that the debugging server 41, the debugging client a43 and the debugging client B44 may be debugging devices (such as PCs) of the same structure, and whether the debugging devices are servers or clients in a debugging cluster, may be defined and set by developers.

For example, a developer may set a connection relationship between multiple debugging devices on a setting interface to set a server and a client, so as to obtain a debugging cluster, which is not limited in the embodiment of the present application. Further, the developer establishes a connection relationship between the plurality of debugging devices through a wired connection manner such as a USB or a network cable, or establishes a connection relationship between the plurality of debugging devices through a wireless connection manner such as inputting an IP address or establishing a Wi-Fi connection.

If the debugging device 1 and the debugging device 2 are both in direct communication connection with the debugging device 3, the electronic device 2 can be understood as a server in a debugging cluster, and the debugging device 1 and the debugging device 2 can be understood as a client in the debugging cluster.

It should be noted that, in the embodiment of the present application, the specific execution of the above steps S801 and S802 is not limited to be smooth. For example, S801 and then S802 may be executed first, S802 and then S801 may be executed first, and S801 and S802 may also be executed simultaneously, which is not limited in this application.

S803, the debug server 41 establishes a communication connection with the master device.

For example, the debug server 41 may establish a communication connection with the host device in response to an operation of the developer to establish a communication connection between the debug server 41 and the host device. For example, the operation of the developer establishing the communication connection between the debugging server 41 and the host device may be an operation of the developer connecting the debugging server 41 and the host device through a wired connection manner such as a USB, a network cable, or the like, or an operation of the developer inputting an IP address of the host device on the debugging server 41 to establish the communication connection, an operation of the developer inputting an IP address of the debugging server 41 on the host device to establish the communication connection, or the like, and the embodiment of the present application is not limited.

Illustratively, the distributed debug assistant of the master device may map its port identification (port ID, PID) to a port designated by debug server 41 through which debug server 41 may establish a communication connection with the distributed debug assistant of the master device.

After the debug server 41 establishes a communication connection with the master device, for example, the debug server 41 may directly obtain device information of the master device from the master device through the device manager, or may obtain device information of one or more slave devices in the distributed device cluster 42 through the master device.

Further, after the debug server 41 establishes a communication connection with the master device, the debug server 41 may debug a debuggable process in the master device, and may also debug one or more slave devices in the distributed device cluster 42 through the master device.

Further, as shown in fig. 8, the debuggable process determining stage may include the following steps S804 to S807:

s804, the debugging server 41 sends a command for finding a debuggable process to the smartphone.

For example, the device manager of the debug server 41 may send the above-mentioned command to discover the debuggable process to the distributed debug assistant of the master device (e.g., the smart phone shown in fig. 4) through the communication connection between the debug server 41 and the master device (e.g., the smart phone shown in fig. 4) in the distributed device cluster.

After the distributed debug assistant of the master device (e.g., the smart phone shown in fig. 4) receives the command to discover the debuggable process, the distributed debug assistant of the master device (e.g., the smart phone shown in fig. 4) may forward the command to discover the debuggable process to each slave device in the distributed device cluster. Thereafter, the master device (i.e. the first device, the smartphone) and the slave devices (i.e. the second device, the third device, and the fourth device) in the distributed device cluster perform the following step S805:

s805, the first device, the second device, the third device, and the fourth device discover a debuggable process running on the current device.

For example, the first device, the second device, the third device, and the fourth device may discover the debuggable process running on the current device through respective distributed debug assistants. For example, the distributed debug assistant may discover processes that are currently running and that may be debugged, i.e., debuggable processes.

S806, the first device, the second device, the third device, and the fourth device send the discovered information of the debuggable process to the debug server 41.

For example, the distributed debug assistants of the first device, the second device, the third device, and the fourth device report the information of the discovered debuggable processes to the device manager of the debug server 41.

The distributed debugging assistant of the master device may directly report the information of the debuggable process of the master device to the device manager of the debugging server 41, and the slave device may report the information of the debuggable process of the slave device to the device manager of the debugging server 41 through the master device.

It can be understood that, since the purpose of sending the information of the debuggable process to the debugging server 41 by the cluster device (such as the first device, the second device, the third device, and the fourth device) is to provide the developer with knowledge and further selection of the debuggable device and the debuggable process, in this embodiment of the present application, the information of the debuggable process may include device information, such as a device ID, of the debuggable device corresponding to the debuggable process. S807, the debugging server 41, the debugging client a43, and the debugging client B44 perform display of information of the debuggable process.

For example, the device manager of the debug server 41 presents the acquired information of the debuggable processes to the developer through the UI interface, so that the developer to which the debug server 41 belongs can select a debuggable process in a debuggable device. And the debugging server 41 may send the information of the debuggable process to the debugging client a43 and the debugging client B44, so that the device managers of the debugging client a43 and the debugging client B44 display the acquired information of the debuggable process to developers through UI interfaces, so that the corresponding developers may select the debuggable process in the specific debuggable device.

Referring to fig. 9, fig. 9 is a diagram illustrating an example of a UI interface of a network topology according to an embodiment of the present application. As shown in fig. 9, a master device (such as the smart phone shown in fig. 9) and a slave device (such as the television, the sound box, the smart watch, the wireless headset, the PC, the tablet computer, the IOT device, and the AR/VR device shown in fig. 9) in the distributed device cluster, and a connection relationship between the master device and the slave device may be displayed on the UI interface. The debug server 41, the debug client a43, or the debug client B44 may display the debuggable process UI interface shown in fig. 10A in response to receiving a selection operation of a certain device by a developer. For example, in response to the operation of the developer selecting a smartphone on the network topology UI interface of the debugging server 41, the debugging server 41 may display a debuggable process UI interface shown in fig. 10A for the developer to further select a debuggable process.

Assuming that a debugging system framework in the embodiment of the present application is shown in fig. 4, structures of a debugging client a43, a debugging client B44, and a debugging server 41, and structures of a master device (i.e., a smartphone shown in fig. 4) and a slave device (i.e., a television, a wireless headset, a smart watch, a sound box, a PC, a tablet computer, an AR/VR device, and an IOT device shown in fig. 4) in a distributed device cluster 42 are shown in fig. 5, where structures of a second debugging module in the debugging client a43, the debugging client B44, and the debugging server 41 are shown in fig. 6A, and a software debugging method provided in the embodiment of the present application will be specifically described below with reference to a specific embodiment and the accompanying drawings.

Example 1: the multi-device debugs the multi-device.

In a scenario of multi-device debugging in embodiment 1 of the present application, a developer may perform collaborative debugging on processes in one or more slave devices in the distributed device cluster 42 through a debugging device. Wherein the commissioning device may include at least two of the commissioning server 41, the commissioning client a43, or the commissioning client B44, or the commissioning device may include the commissioning client a43 or the commissioning client B44. The debuggee device may include a master device and one or more slave devices, or the debuggee device may include a plurality of slave devices, or the debuggee device may include one slave device.

If the debugging device includes at least one of the debugging client a43 and the debugging client B44, the debugging client a43 or the debugging client B44 specifically needs to connect the debugging server 41 to implement the above-described cooperative debugging of multiple processes in multiple devices.

The following describes a specific process of multi-device commissioning of a multi-device according to embodiment 1 of the present application with example 1 and example 2, respectively.

Example 1, a developer debugs a first process (e.g., a control process) in a smart phone, a second process (e.g., a video playback process) in a television, and a third process (e.g., an audio playback process) in an audio box in a distributed device cluster 42 cooperatively through a debugging server 41, a debugging client a43, and a debugging client B44 shown in fig. 5.

For example, the scene of example 1 may be a screen projection scene of a smart phone, specifically, the smart phone plays a video through a television, and plays an audio through a sound box. As shown in fig. 11, the first phase (i.e., the debug command generation phase) of example 1 of the present application may include the following steps s1.1.1 to s 1.2.1:

s1.1.1, in response to receiving the selection operation of the developer on the debuggable process, the debugging server 41, the debugging client A43 and the debugging client B44 determine the corresponding debuggable process.

For example, assume that in response to receiving a selection operation of developer a on the UI interface of the debugging server 41 for a first process (e.g., a control process) in a smartphone, in response to receiving a selection operation of developer B on the UI interface of the debugging client a43 for a second process (e.g., a video playback process) in a television, and in response to receiving a selection operation of developer C on the UI interface of the debugging client B44 for a third process (e.g., an audio playback process) in a soundbox, the debugging server 41, the debugging client a43, and the debugging client B44 respectively determine that the first process, the second process, and the third process are debugged processes.

For example, the debugging devices (e.g., the debugging server 41, the debugging client a43, and the debugging client B44) may determine the debuggee process in response to a selection operation of a certain debuggee process by a developer on a debuggee process UI interface similar to that shown in fig. 10A.

Further, after the debugging device (such as the debugging server 41, the debugging client a43 and the debugging client B44) responds to the selection operation of the debugged process by the developer on the debugged process UI interface similar to that shown in fig. 10A, the debugging device may also display the hardware device status in the debugged device, including the list and details of the hardware device, and the like. In this embodiment of the present application, hardware devices in debuggee devices may all be called by the debug process. As shown in fig. 10B, assuming that the smartphone is a debugged device, one or more hardware devices of GPS, sensor, vibrator, NFC, FM, security chip, etc. may be included in the smartphone. The debugging device (e.g., the debugging server 41, the debugging client a43, or the debugging client B44) can view details of the hardware device in response to receiving a selection operation of the hardware device by the developer in the left selection box 10-1 on the UI interface as shown in fig. 10B. After the developer selects the debuggee process, as shown in fig. 10B, a hardware detail box 10-2 on the UI interface may display specific hardware device details. Fig. 10B illustrates an example where the debuggee process calls GPS.

S1.2.1, the debugging server 41, the debugging client A43 and the debugging client B44 respectively generate debugging commands according to the detected debugging events triggered by the developers.

For example, assume that in response to receiving a first debug event that developer a triggers (e.g., inputs a code or clicks a debug button) a first process (e.g., a control process) in a smartphone on the UI interface of debug server 41, in response to receiving a second debug event that developer B triggers (e.g., inputs) a second process (e.g., a video playback process) in a television on the UI interface of debug client a43, and in response to receiving a third debug event that developer C triggers (e.g., inputs) a third process (e.g., an audio playback process) in a sound box on the UI interface of debug client B44, debug server 41, debug client a43, and debug client B44 generate a first debug command, a second debug command, and a third debug command, respectively.

In the embodiment of the present application, the debug command is mainly used to obtain information such as the operation details of the debugged process by instructing the debugged process to step in, step out, step over, run, or the like at the corresponding program instruction according to the debug command. For example, a debugging device (e.g., the debugging server 41, the debugging client a43, or the debugging client B44) may generate debugging commands (e.g., a first debugging command, a second debugging command, and a third debugging command) according to breakpoints set by a developer in a debugged process (e.g., a first process, a second process, or a third process).

It should be noted that, for debugging commands such as step-in, step-out, and step-out, in the embodiment of the present application, only the debugging device bound to the debugged process is allowed to debug the debugged process at the same time. The binding relationship between the debugged process and the debugging device may be determined according to a correspondence between an identifier (e.g., ID) of the debugged process and an identifier (e.g., ID) of the debugging device.

For example, if a process (e.g., the second process) is occupied by a debugging device (e.g., the debugging client a43), that is, the second process is bound to the debugging client a43, the debugging server 41 records the binding information of the debugging client a43 and the second process (e.g., the binding relationship between the ID of the debugging client a43 and the ID of the second process) in the command manager. When the command manager receives a new debugging command of a certain debugging device (such as debugging device a) to the second process at a certain time, the command manager can judge whether the ID of the debugging device a initiating the new command is consistent with the ID of the debugging client a43 bound by the current second process by looking at the recorded binding information. If the command is consistent with the command, the debugging server 41 allows the new command to be issued to the second process; if not, the debug server 41 does not allow the new command to be issued to the second process.

Through the control of the debugging commands such as stepping-in, stepping-out and stepping-through by the debugging server, the mutual interference caused by different debugging of a plurality of developers on the same process through a plurality of debugging devices at the same moment can be avoided, and the smooth progress of the debugging process and the accuracy of debugging data are influenced.

It should be noted that, in the embodiment of the present application, the debug command (such as the first debug command, the second debug command, or the third debug command) may be a breakpoint command. In the embodiment of the present application, the breakpoint may include, but is not limited to, any of the following: data breakpoints, synchronization breakpoints, or conditional breakpoints.

Among them, the data breakpoints may include the following two types:

type 1: common data breakpoints across processes.

For common data, such as the control instruction data, the audio playing progress data, and the video playing progress data in example 1 above, the debug server 41 may send a query command to the master device to acquire common data of multiple processes from multiple debuggee devices. For example, if the first debug command is a data breakpoint command, the master device may periodically call the soft bus interface to obtain common data of multiple debugged devices (such as a smart phone and a television), and report the common data to the debug server 41. The debug server 41 may record the change of the common data over time and distribute the time flow record of the common data to the debug client a43 and the debug client B44, so that the debug client a43 and the debug client B44 are exposed on the UI interface, which facilitates the monitoring and comparison of the change of the common data of the plurality of processes (such as the first process and the second process) by the developer.

Type 2: private data breakpoints across processes.

For the process private data, such as the local variables in the process of acquiring the video stream parsing key frame by the television adapter player in example 1, the local variables in the process of acquiring the audio stream parsing key frame by the sound box adapter player, and the like, the debugging server 41 may send the data breakpoints set by the multiple debugging devices (such as the debugging server 41, the debugging client a43, and the debugging client B44) to the corresponding debugged devices. For example, in example 1 described above, the debugging device may issue a data breakpoint command to listen to the packet ID to the television, and the television may distribute the command to the debugging tool corresponding to the video playing. If the debugging tool obtains the relevant process private data, the relevant process private data is returned to the debugging server 41 through the main device (such as a smart phone). The debug server 41 synchronizes the private data to each debug device (i.e., the debug server 41, the debug client a43, and the debug client B44) in the debug cluster so that each debug client can expose the data breakpoints of the debug client on the UI interface. For example, corresponding data breakpoints may be exposed based on different debug client pages.

The synchronization breakpoint refers to a synchronization breakpoint agreed by a plurality of processes at a certain system time. For example, after a debugging device (e.g., the debugging client a43) issues a synchronization breakpoint command of multiple processes (e.g., a first process and a second process), the command manager of the debugging server 41 may issue the debugging command to a master device (e.g., a smart phone shown in fig. 5). The master device (e.g., the smart phone shown in fig. 5) forwards the debugging command to the corresponding debugged device (e.g., the television) according to the process number corresponding to the debugging command, so as to stipulate that the corresponding process is synchronously paused at a certain system time with the television, and after the corresponding process is paused, the debugging data (including thread information, stack information, variable data, and the like) is reported to the breakpoint manager of the debugging server 41 through the master device (e.g., the smart phone shown in fig. 5). The breakpoint manager of the debugging server 41 broadcasts the debugging data to each debugging client (such as the debugging client a43 and the debugging client B44) so that each debugging client performs UI interface exhibition, which facilitates the time slice monitoring of the debugging data of multiple processes (such as the first process and the second process) by the developer. For example, each debugging client can display the debugging data in a different process comparison mode, so that developers can conveniently perform further cross-process cooperative debugging.

Conditional breakpoints refer to breakpoints that control one or more processes of a device in a distributed cluster of devices by setting a condition. For example, if a variable (e.g., a device state) of a device in the distributed device cluster satisfies a certain condition, a process in the device is suspended, and meanwhile, another device in the distributed device cluster may obtain debugging data (e.g., including stack information) of the suspended process.

For example, in this embodiment of the present application, the debugging server 41 may analyze the debugging command into a newly added conditional breakpoint according to the debugging command of the cross-process conditional breakpoint triggered by the developer, which is acquired by the command manager, and monitor whether the corresponding device in the distributed device cluster meets the corresponding condition. If the corresponding equipment in the distributed equipment cluster meets the corresponding conditions, the command management module issues an interrupt command to the equipment so as to interrupt the corresponding process.

For example, in the screen projection scene of the smart phone shown in example 1, in order to solve the situation of audio and video asynchronism, when the playing progress reaches 2 minutes and 30 seconds in the playing control process of the smart phone, the video playing process of the television may be interrupted, whether the acquired data packet information in the video decoder is healthy or not may be checked, and meanwhile, debugging data (for example, data such as the playing process, stack information, and the like) adapted to the video playing process of the television may be acquired. Specifically, the conditional breakpoint command may be sent to a debugger of the play control process of the smart phone through a command manager of the debug server 41. When the playing progress reaches 2 minutes and 30 seconds (namely, the condition breakpoint is triggered) in the playing control process of the smart phone, the debugger may pause the playing progress and return an interrupt message to the command manager of the debug server 41. After receiving the interrupt message from the smart phone, the command manager of the debugging server 41 sends a playing process interrupt command to the television through the smart phone to control the television to interrupt the video playing process. After the television interrupts the video playing process, the command manager of the debugging server 41 acquires the current stack information of the smartphone from the smartphone and the current stack information of the television forwarded by the television through the smartphone. After that, the debug server 41 distributes the acquired stack information to the corresponding debug apparatus. For example, the debug server 41 distributes the current stack information of the television set to the debug client a43 which debugs the device.

Further, in some embodiments, when the playing progress reaches 2 minutes and 30 seconds in the smart phone playing control process, the conditional breakpoint command is disassembled into a command for pausing the video playing process of the television. Then, when the debugging server receives the debugging data which is forwarded by the smart phone and acquired after the television executes the command for pausing the video playing process, the debugging data is only distributed to the debugging device (such as the debugging client a43 in example 1) which initiates the conditional breakpoint.

In some embodiments, the debugging device (e.g., debugging client a43 in example 1) that initiated the conditional breakpoint may not expose the debugging data corresponding to the conditional breakpoint on the UI interface, but rather act as a trigger condition for the next debugging command.

Further, as shown in fig. 11, the second phase (i.e., the debug command issuing phase) of example 1 of the present application may include the following steps S2.1.1-S2.2.1:

s2.1.1, debug server 41, debug client A43, and debug client B44 send debug commands to the smartphone.

In some embodiments, if the debug command (such as the second debug command and the third debug command described above) is generated by debug client a43 or debug client B44 according to the detected developer-triggered debug event, debug client a43 or debug client B44 may specifically send the debug command to the smartphone (i.e., the master device) through debug server 41.

In other embodiments, if a debug command (such as the first debug command described above) is generated by the debug server 41 according to a detected debug event triggered by the developer, the debug server 41 sends the debug command directly to the smartphone (i.e., the master device).

The debugging server 41 may specifically send a debugging command to the smartphone (i.e., the master device) through a communication connection between the debugging server 41 and the smartphone.

It can be understood that the debug command from the debug device generally corresponds to a certain debugged process in a certain debugged device, and therefore, in this embodiment of the application, the first debug command, the second debug command, and the third debug command carry a target address corresponding to the debug command or a device identifier (such as a device ID) and a process identifier (such as a process number) corresponding to the debug command, so that when the debug server 41 and the master device perform subsequent debug command distribution, the debug command is accurately and unmistakably forwarded to the debugged device according to the target address/device identifier carried in the debug command. And when the subsequent debugged equipment receives the debugging command, the debugged process can be determined accurately and correctly.

S2.2.1, the smart phone distributes the received debugging command to the debuggee device.

For example, after receiving the first debug command, the second debug command, and the third debug command from the debug server 41, the smart phone may forward the debug command to the corresponding device according to the target address/device identifier corresponding to the debug command carried by the smart phone. For example, in example 1 shown in fig. 11, since the first debug command corresponds to a process in the smartphone, the first debug command usually carries a device address or a device ID of the smartphone, and in this case, the smartphone knows that the first debug command corresponds to itself, and does not forward the first debug command. Since the second debug command corresponds to a process in the television, the second debug command usually carries a device address or a device ID of the television, and in this case, the smart phone forwards the second debug command to the television. Since the third debug command corresponds to a process in the sound box, the third debug command usually carries an equipment address or an equipment ID of the sound box, and in this case, the smart phone forwards the third debug command to the sound box.

It should be noted that, if the first debug command, the second debug command, or the third debug command is a conditional breakpoint command, for example, if the second debug command and the third debug command are conditional that the first debug command is successfully executed, S2.1.1 specifically includes: the debugging server 41 sends a first debugging command to the smart phone, and after the debugging server 41 receives information that the first debugging command from the smart phone is successfully executed, a second trying command and a third debugging command are sent to the smart phone. Correspondingly, the S2.2.1 specifically includes: and the smart phone distributes the received second debugging command to the television and distributes the received third debugging command to the sound box.

For example, if the first debug command is used to instruct the smart phone to halt the first process at a certain system time, and the conditions of the second debug command and the third debug command are that the first debug command is successfully executed, the smart phone halts the first process when the system time is reached, and meanwhile, sends information that the first debug command is successfully executed to the debug server 41. The debug server 41, after receiving the information that the first debug command was successfully executed, triggers the instructions to the television and the audio box to execute the second debug command and the third debug command, respectively.

Further, as shown in fig. 11, the third phase (i.e., the debugging phase) of the present application example 1 may include the following steps S3.1.1-S3.3.1:

s3.1.1, the smart phone executes debugging operation on the first process according to the received first debugging command, and obtains first debugging data.

For example, the distributed debugging assistant of the smartphone may invoke a corresponding debugging tool to perform a debugging operation on a first process (e.g., a control process) indicated by the process identifier according to the process identifier (e.g., the process number) carried in the received first debugging command, so as to obtain first debugging data. For example, in the embodiment of the present application, the debugging operation may include one or more of the following: step-in, step-out, step-through, run, etc.

S3.2.1, the television executes debugging operation to the second process according to the received second debugging command, and acquires second debugging data.

For example, the distributed debugging assistant of the television may invoke a corresponding debugging tool to perform a debugging operation on a second process (e.g., a video playing process) indicated by the process identifier according to the process identifier (e.g., the process number) carried in the received second debugging command, so as to obtain second debugging data.

S3.3.1, the sound box executes debugging operation on the third process according to the received third debugging command, and obtains third debugging data.

For example, the distributed debugging assistant of the sound box may invoke a corresponding debugging tool to perform a debugging operation on a third process (e.g., an audio playing process) indicated by the process identifier according to the process identifier (e.g., the process number) carried in the received third debugging command, so as to obtain third debugging data.

For example, if the first debug command, the second debug command, and the third debug command are synchronization breakpoint commands, the smart phone, the television, and the audio box synchronously suspend corresponding processes at a specified system time according to the debug commands, and acquire respective debug data (including thread information, stack information, variable data, and the like).

For another example, if the first debug command, the second debug command, or the third debug command is a conditional breakpoint command, for example, if the first debug command is successfully executed, the television and the audio box respectively execute the second debug command and the third debug command when the smart phone successfully executes the first debug command, and acquire respective debug data (for example, data such as a playing process and stack information may be included).

For another example, if the first debug command, the second debug command, and the third debug command are data breakpoint commands, such as cross-process public data breakpoints or process private data, the mobile phone, the television, and the audio box obtain public or private data of the corresponding process.

Further, as shown in fig. 11, the fourth phase (i.e., the debug information return phase) of example 1 of the present application may include the following steps s4.1.1 to S4.2.1:

s4.1.1, the television sends second debugging data to the smart phone; and the sound box sends third debugging data to the smart phone.

For example, the television and the audio box may send the second debug data and the third debug data to the smartphone through respective distributed debug assistants.

S4.2.1, the smart phone sends the first debug data, the second debug data and the third debug data to the debug server 41.

For example, the smartphone may send the first debug data, the second debug data, and the third debug data to the debug information manager of the debug server 41 through the distributed debug assistant. The first debug data, the second debug data, and the third debug data carry a device identifier (e.g., a device ID) of the debugged device and a process identifier (e.g., a process number) of the debugged process.

For example, the first debug data, the second debug data, and the third debug data may be debug data of the debuggee process based on a synchronization breakpoint command, a conditional breakpoint command, a data breakpoint command, or the like. For example, the debug data may include thread information after a process pause, stack information, frames, variable data, play process data, public or private data across processes, and the like. In some embodiments, the debug data may further include call information. For example, the call information may include data such as a process call procedure record (e.g., a Remote Procedure Call (RPC) mode function call, a web mode network call, a hong meng distributed debugging system distributed soft bus registration capability call, etc.), a function call time, a function call order, a debuggee device name or a debuggee device type. The debugged device may send the debug data to a debug information manager of the debug server via the distributed debug assistant. Further, as shown in fig. 11, the fifth stage (i.e. the debugging information display stage) of the present application example 1 may include the following steps s5.1.1 and s 5.2.1:

s5.1.1, the debugging server 41 distributes the first debugging data, the second debugging data and the third debugging data.

In this embodiment of the application, after receiving the first debug data, the second debug data, and the third debug data sent by the smartphone, the debug server 41 may determine the debug device corresponding to the debug data according to the device identifier and the process identifier carried in the first debug data, the second debug data, and the third debug data.

In some embodiments, if the debugging server 41 determines that a certain piece of debugging data is a debugging command corresponding to the debugging server 41 according to the device identifier and the process identifier carried in the debugging data, step s5.1.1 may include: the debugging server 41 presents the debugging data to the developer through the UI interface. For example, in example 1 shown in fig. 11, the debugging server 41 determines that the first debugging data corresponds to the first debugging command of the debugging server 41 according to the device identifier of the smartphone and the process identifier of the first process, which are carried in the first debugging data.

In other embodiments, if the debugging server 41 determines that a certain piece of debugging data is a debugging command corresponding to the debugging client according to the device identifier and the process identifier carried in the debugging data, the debugging server 41 distributes the debugging data to the debugging client, and the debugging client displays corresponding debugging information on the UI interface.

For example, in example 1 shown in fig. 11, the debug server 41 determines that the second debug data corresponds to the second debug command of the debug client a43 from the device identifier of the television and the process identifier of the second process, which are carried in the second debug data, and determines that the third debug data corresponds to the third debug command of the debug client B44 from the device identifier of the audio enclosure and the process identifier of the third process, which are carried in the third debug data, then the debug server 41 distributes the second debug data to the debug client a43 and the third debug data to the debug client B44.

And S5.2.1, the debugging client A43 and the debugging client B44 are used for debugging information display.

For example, in example 1 shown in fig. 11, the debug server 41 presents the first debug data to the developer through the UI interface. The debugging client a43 presents the second debugging data to the developer through the UI interface. And the debugging client B44 shows the third debugging data to the developer through the UI interface.

In some embodiments, after the debugged device (e.g., the smart phone, the television, and the sound box) feeds back the debugging data (e.g., the first debugging data, the second debugging data, and the third debugging data) to the debugging information manager of the debugging server 41, the debugging information manager of the debugging server 41 may save the breakpoint data, the stack information of the interrupted process, and the like in the debugging data locally.

Further, in some embodiments, the debugging server 41 may also send data such as breakpoint data and stack information of an interrupt process in the local debugging data to each debugging device participating in the cooperative debugging.

For example, the debugging information manager of the debugging server 41 may simultaneously send data such as breakpoint data and stack information of an interrupted process in the local debugging data to each debugging device participating in the cooperative debugging in the debugging cluster, so that each cooperative debugging device may display a relevant debugging result to the developer at any time by newly adding a tab page on the UI interface when there is a viewing demand.

For another example, when a debugging client (e.g., the debugging client a43) of the cooperative debugging, the debugging information manager of the debugging server 41 may receive a request from a debugging device of the cooperative debugging, and send data such as breakpoint data and stack information of a break process stored in the local debugging data to the debugging client. For example, breakpoint data, stack information of an interrupt process, and the like in the first debug data from the smartphone and the second debug data from the television are sent to the debug client a44, so that the debug client a44 can present a relevant debug result to the developer by adding a tab page on the UI interface.

In addition, the debug information manager of the debug server 41 may distribute data corresponding to debug operations such as step-in, step-out, step-through, run, pause, and the like in the debug data to the debug device that issued the corresponding debug command. For other debugging devices, data corresponding to the debugging operations such as step-in, step-out, step-over, running, suspending and the like are not allowed to be acquired.

It should be noted that, the debugging client for collaborative debugging may obtain the debugging data by sending a check request to the debugging server when the debugged process is not running, so as to achieve the capability of locating a problem without reproducing a program execution scenario. The above debugging means is generally called time-light debugging. The principle of time-light debugging is to record calling information in the debugging process so as to locate problems (such as difficult-to-reproduce problems) in process execution without reproducing program execution scenes.

After the on-time optical debugging, the debugged device may issue a non-blocking function breakpoint for a function (e.g., a function corresponding to the capability of the distributed soft bus registration in the hong Meng distributed debugging system) by using a distributed debugging assistant, and send the non-blocking line breakpoint to the debugging device. For example, in the screen-casting scenario of the smartphone of example 1, when a pause button of a play control interface of the smartphone is triggered, the play control process of the smartphone calls a play pause distributed interface of the television according to the non-blocking function breakpoint, and call information (for example, called capability information, a function call sequence, a called parameter, a call initiation time point, a call termination time point, and the like in a debugged device) may be fed back to the debug server through the smartphone. For example, in the scenario of example 1, the above-mentioned call information helps to locate the problems of smartphone pause, slow or no tv playback response, slow or no sound box playback response, or asynchronous sound box and tv playback without reproducing the program execution scenario. Illustratively, according to the time difference between the time point when the television pause interface is called and the time point when the smartphone initiates the call, whether the distributed soft bus has a problem can be determined. Specifically, if the time difference is too long, i.e., the video stream takes too much time to be transmitted from the smartphone to the television, it may be important to see if there is a problem with the distributed soft bus. If the time difference is short, the specific problem of the television can be located by repeatedly calling the pause interface of the television.

In the embodiment of the present application, the debug server 41 may perform breakpoint delegation management on the debug device. The breakpoint authorization management of the debugging equipment refers to managing and controlling operations of the debugging equipment such as modification or deletion of breakpoints and the like according to authorization.

For example, when there is a new breakpoint, the debug server 41 may record the code line where the breakpoint is located, identification information of the new breakpoint (including identification information of the debug device of the new breakpoint), and the like in the breakpoint manager. When the debug server 41 receives a modification or deletion event for a breakpoint (e.g., breakpoint a of the first process) from a certain debug device (e.g., debug client a43), the breakpoint manager of the debug server 41 can check whether the ID of the debug device a initiating the modification or deletion event is consistent with the ID of the debug client a43 to which the breakpoint a is newly added by looking at the recorded identification information of the debug device to which the breakpoint a is newly added. If the breakpoint a is consistent with the breakpoint a, the debugging server 41 allows the debugging device a to modify or delete the breakpoint a; and if the breakpoint A is inconsistent with the breakpoint A, the debugging equipment A is not allowed to modify or delete the breakpoint A.

It should be noted that, in the embodiment of the present application, any debugging device (such as the debugging server 41, the debugging client a43, and the debugging client B44 in example 1) may add a breakpoint to the first process (i.e., the control process) code in the smart phone, the second process (i.e., the video playing process) code in the television, and the third process (i.e., the audio playing) code in the sound box. Wherein, the information related to the new breakpoint operation is recorded in the breakpoint manager of the debug server 41. For example, the debugging device identification of the newly added breakpoint, the breakpoint type, the code file where the breakpoint is located, the code line where the breakpoint is located, and the like.

Further, the breakpoint of each debuggee process is visible to the debugging devices in the debugging cluster. When a breakpoint is captured (i.e., a process is halted when it executes to a specified breakpoint), the stack information of the halted process is visible to the debugging devices in the debugging cluster.

Example 2: the developer debugs the fourth process (such as a video playing process) in the tv set and the fifth process (such as an audio playing process) in the audio box in the distributed device cluster 42 cooperatively through the debugging server 41 and the debugging client a 43.

For example, the scene of example 2 may be a scene played by a sound box in cooperation with a television, wherein the sound box is used for playing audio and the television is used for playing video. Example 2 may be used to solve the problem of a television set not being synchronized with the sound drawing of a sound box, for example. Similar to example 1 shown in fig. 11, as shown in fig. 12, the first stage (i.e., the debug command generation stage) of example 2 of the present application mainly includes that the debug device determines a debugged process, and the debug device generates a debug command according to a debug event triggered by a developer. Taking as an example that the debugging devices are a debugging server 41 and a debugging client a43, the debugging server 41 cooperatively debugs a fourth process (such as a video playing process) in the television in the distributed device cluster 42 according to a debugging event triggered by a developer, and the debugging client a43 cooperatively debugs a fifth process (such as an audio playing process) in the audio box in the distributed device cluster 42 according to the debugging event triggered by the developer, as shown in fig. 12, the first stage (i.e., the debugging command generation stage) may include the following steps S1.1.2 to S1.2.2:

s1.1.2, in response to receiving a developer selection operation for a debuggable process, debug server 41 and debug client A43 determine a corresponding debuggable process.

S1.2.2, debug server 41 and debug client A43 generate debug commands based on detected developer-triggered debug events, respectively.

Further, the second phase (i.e., the debug command issuing phase) of example 2 of the present application mainly includes sending the debug command from the debug device to the master device, and distributing the debug command from the master device to the slave device. As shown in fig. 12, the second phase (i.e., the debug command issuing phase) of example 2 of the present application may include the following steps S2.1.2-S2.2.2:

s2.1.2, debug server 41, and debug client A43 send debug commands to the smartphone.

S2.2.2, the smart phone distributes the received debugging command to the debuggee device.

For example, in example 2 shown in fig. 12, since the fourth debug command corresponds to a process in the television, the fourth debug command usually carries a device address or a device ID of the television, and in this case, the smartphone forwards the fourth debug command to the television. Since the fifth debug command corresponds to a process in the sound box, the fifth debug command usually carries an equipment address or an equipment ID of the sound box, and in this case, the smart phone forwards the fifth debug command to the sound box.

Further, the third phase (i.e., the debugging phase) of example 2 of this application mainly includes the debugged device performing the debugging operation and obtaining the debugging data. As shown in fig. 12, the third phase (i.e., the debugging phase) of example 2 of the present application may include the following steps S3.1.2-S3.2.2:

s3.1.2, the television executes the debugging operation on the fourth process according to the received fourth debugging command, and acquires fourth debugging data.

S3.2.2, the sound box executes debugging operation on the fifth process according to the received fifth debugging command, and fifth debugging data is obtained.

Further, the fourth phase (i.e., the debugging information returning phase) of example 2 of the present application mainly includes sending the debugging data from the slave device to the master device, and forwarding the debugging data from the master device to the debugging server. As shown in fig. 12, the fourth phase (i.e., the debug information return phase) of the present application example 2 may include the following steps S4.1.2-S4.2.2:

s4.1.2, the television sends fourth debugging data to the smart phone; and the sound box sends fifth debugging data to the smart phone.

S4.2.2, the smart phone sends the fourth debugging data and the fifth debugging data to the debugging server 41.

Further, the fifth stage (i.e., the debugging information presentation stage) of example 2 of the present application mainly includes distribution of debugging data and presentation of debugging information. As shown in fig. 12, the fifth phase (i.e., the debugging information presentation phase) of the present application example 2 may include the following steps S5.1.2 and S5.2.2:

s5.1.2, the debug server 41 distributes the fourth debug data and the fifth debug data.

S5.2.2, debug server 41, and debug client A43 perform the debugging information exposure.

For example, in example 2 shown in fig. 12, the debug server 41 and the debug client a43 may expose the fourth debug data and the fifth debug data, respectively, to the developer through the UI interface. For the specific step execution process of example 2 shown in fig. 12, reference may be made to the description and the explanation of the specific step of example 1 shown in fig. 11, which are not described herein again.

In the embodiment of the present application, each of the above examples 1 and 2 is an example in which a plurality of debug clients and a debug server cooperate to debug a process in two or more devices. The software debugging method provided by the embodiment of the application is suitable for software debugging across multiple processes.

It should be noted that, the above example 1 is an example of a process in which a plurality of debugging clients and a debugging server cooperatively debug a master device and one slave device, and the above example 2 is an example of a process in which a plurality of debugging clients and a debugging server cooperatively debug two slave devices connected to a master device. For other scenarios in which multiple devices are debugged, reference may be made to the software debugging method shown in example 1 or example 2, and details are not described in this embodiment. It should be noted that in a scenario where one debugging client debugs a process in one slave device connected to a master device through a debugging server, or a scenario where a plurality of debugging clients debugs a process in one slave device connected to a master device through a debugging server, the master device only distributes and coordinates as one command, and debugs a data forwarding apparatus.

In addition, the above-described examples 1 and 2 are exemplified by a multi-process in which multi-device debugging is associated with each other. For independent functions without relevance among different processes, single-step debugging can be independently carried out according to a conventional method. For example, the command manager of the debug server may issue the debug command to the master device, and the master device distributes the debug command to the corresponding debugged device according to the target address or the device ID corresponding to the debug command carried in the debug command. And the debugged equipment carries out debugging operation on the corresponding process according to the process number corresponding to the debugging command carried in the debugging command, and acquires debugging data. And finally, the debugged equipment feeds the acquired debugging data back to a debugging information manager of the debugging server through the main equipment, and the debugging information manager distributes the debugging data to the corresponding debugging equipment.

By using a software debugging method similar to that shown in example 1 or example 2 in embodiment 1, cross-device cooperative debugging of multiple debugged devices in a distributed device cluster can be achieved. For example, in a distributed scenario like that shown in fig. 1, cross-process collaborative debugging may be performed on multiple devices that work in concert. In addition, a plurality of developers can perform cross-process cooperative debugging on a plurality of devices which cooperate in a distributed scene similar to that shown in fig. 1 through a plurality of debugging devices. By the debugging method, the efficiency and the quality of a developer in process debugging are greatly improved.

Example 2: and debugging multiple devices by using a single device.

In the scenario of single device debugging multiple devices in embodiment 2 of the present application, a developer may debug a process in one or more devices in the distributed device cluster 42 through the debugging server 41. The debuggee device may include a master device and one or more slave devices, or the debuggee device may include a plurality of slave devices, or the debuggee device may include one slave device.

A specific procedure for debugging multiple devices by a single device in embodiment 2 of the present application is described below with reference to example 3.

Example 3, the developer performs cooperative debugging on a sixth process (e.g., a control process) in the smart phone) in the distributed device cluster 42 and a seventh process (e.g., a video playing process) in the television through the debugging server 41.

For example, the scenario of example 1 may be a scenario in which a smartphone is projecting a screen to a television. Example 2 may be used to solve the problem of a smartphone not being synchronized with a television control, for example. Similar to example 1 shown in fig. 11, as shown in fig. 13, the first stage (i.e., the debug command generation stage) of example 3 of the present application mainly includes that the debug device determines a debugged process, and the debug device generates a debug command according to a debug event triggered by a developer. Taking the debugging device as the debugging server 41, and the debugging server 41 cooperatively debugs the sixth process (e.g., control process) in the smart phone and the seventh process (e.g., video playing process) in the television in the distributed device cluster 42 according to the debugging event triggered by the developer, as shown in fig. 13, the first stage (i.e., the debugging command generating stage) may include the following steps S1.1.3 to S1.2.3:

s1.1.3, in response to receiving a developer selection operation for a debuggable process, debug server 41 determines a debuggable process.

S1.2.3, the debug server 41 generates debug commands based on detected developer-triggered debug events.

Further, the second phase (i.e., the debug command issuing phase) of example 3 of the present application mainly includes sending the debug command from the debug device to the master device, and distributing the debug command from the master device to the slave device. As shown in fig. 13, the second phase (i.e., the debug command issuing phase) of example 3 of the present application may include the following steps S2.1.3-S2.2.3:

s2.1.3, the debug server 41 sends debug commands to the smartphone.

S2.2.3, the smart phone distributes the received debugging command to the debuggee device.

For example, in example 3 shown in fig. 13, since the sixth debug command corresponds to a process in the smartphone, the sixth debug command generally carries a device address or a device ID of the smartphone, and in this case, the smartphone does not forward the sixth debug command. Since the seventh debug command corresponds to a process in the television, the seventh debug command usually carries an equipment address or an equipment ID of the television, and in this case, the smartphone forwards the seventh debug command to the television.

Further, the third phase (i.e., the debugging phase) of example 3 of the present application mainly includes the debugged device performing the debugging operation and obtaining the debugging data. As shown in fig. 13, the third phase (i.e., the commissioning phase) of example 3 of the present application may include the following steps S3.1.3-S3.2.3:

s3.1.3, the smart phone executes the debugging operation on the sixth process according to the received sixth debugging command, and acquires sixth debugging data.

S3.2.3, the television executes debugging operation on the seventh process according to the received seventh debugging command, and acquires seventh debugging data.

Further, the fourth phase (i.e., the debugging information returning phase) of example 3 of the present application mainly includes sending the debugging data from the slave device to the master device, and forwarding the debugging data from the master device to the debugging server. As shown in fig. 13, the fourth phase (i.e., the debug information return phase) of example 3 of the present application may include the following steps S4.1.3-S4.2.3:

s4.1.3, the television sends the seventh debugging data to the smart phone.

S4.2.3, the smart phone sends the sixth debug data and the seventh debug data to the debug server 41.

Further, the fifth stage (i.e., the debugging information presentation stage) of example 3 of the present application mainly includes presentation of debugging information. As shown in fig. 13, the fifth stage (i.e., the debugging information presentation stage) of example 3 of the present application may include the following step S5.1.3:

s5.1.3, the debugging server 41 displays the debugging information.

For example, in example 3 shown in fig. 13, the debugging server 41 displays debugging information corresponding to the sixth debugging data and the seventh debugging data to the developer through the UI interface.

For the specific step execution process of example 3 shown in fig. 13, reference may be made to the description and the explanation of the specific step of example 1 shown in fig. 11, which is not described herein again.

It should be noted that example 3 above is an example of a process in which a debugging server debugs a master device and a slave device. For other scenarios in which a single device debugs multiple devices, reference may be made to the software debugging method shown in example 3, which is not described in detail in this embodiment. It should be noted that in a scenario where the debug server debugs a process in one slave device connected to the master device, or in a scenario where the debug server debugs processes in a plurality of slave devices connected to the master device, the master device only distributes and coordinates as one command, and debugs the data forwarding apparatus.

In addition, the above example 3 is exemplified by a single device debugging of multiple processes associated with each other. For independent functions without relevance among different processes, single-step debugging can be independently carried out according to a conventional method. For example, the command manager of the debug server may issue the debug command to the master device, and the master device distributes the debug command to the corresponding debugged device according to the target address or the device ID corresponding to the debug command carried in the debug command. And the debugged equipment carries out debugging operation on the corresponding process according to the process number corresponding to the debugging command carried in the debugging command, and acquires debugging data. And finally, the debugged equipment feeds the acquired debugging data back to a debugging information manager of the debugging server through the main equipment, and the debugging information manager distributes the debugging data to the corresponding debugging equipment.

By using a software debugging method similar to that shown in example 3 in embodiment 2, cross-device cooperative debugging of a plurality of debugged devices in a distributed device cluster by a debugging device can be realized. For example, in a distributed scenario like that shown in fig. 1, cross-process co-debugging may be performed on multiple devices working in cooperation. By the debugging method, the efficiency and the quality of a developer in process debugging are greatly improved.

Example 3: and debugging the single device by the multiple devices.

In a scenario where a single device is debugged by multiple devices in embodiment 3 of the present application, a developer may perform coordinated debugging on a process in one device in the distributed device cluster 42 through a debugging device. Wherein the commissioning device may include at least two of the commissioning server 41, the commissioning client a43, or the commissioning client B44, or the commissioning device may include the commissioning client a43 or the commissioning client B44. The debuggee device comprises a master device.

If the debugging device includes at least one of the debugging client a43 and the debugging client B44, the debugging client a43 or the debugging client B44 specifically needs to connect the debugging server 41 to implement the above-described cooperative debugging of the process in the master device.

A specific procedure for debugging a single device by multiple devices in embodiment 3 of the present application is described below with reference to example 4.

Example 4, the developer performs collaborative debugging on an eighth process (such as a control process, a video playing process, an audio playing process, a navigation process, an instant messaging process, and the like) in a smart phone (i.e., a master device) in the distributed device cluster 42 through the debugging server 41, the debugging client a43, and the debugging client B44.

For example, the scenario of example 4 may be a scenario in which multiple developers debug different execution processes in one process in a smartphone. Similar to example 1 shown in fig. 11, as shown in fig. 14, the first stage (i.e., the debugged process determining stage) of example 4 of the present application mainly includes that the debugging device determines the debugged process, and the debugging device generates a debugging command according to a debugging event triggered by a developer. Taking as an example that the debugging devices are a debugging server 41, a debugging client a43, and a debugging client B44, and the debugging server 41, the debugging client a43, and the debugging client B44 respectively debug different execution processes in an eighth process in the smart phone in the distributed device cluster 42 according to debugging events triggered by developers, as shown in fig. 14, the first stage (i.e., the debugging command generation stage) may include the following steps S1.1.4 to S1.2.4:

s1.1.4, in response to receiving a developer selection operation for a debuggable process, debug server 41, debug client A43, and debug client B44 determine a corresponding debuggable process.

S1.2.4, debug server 41, debug client A43, and debug client B44 each generate debug commands based on detected developer-triggered debug events.

Further, the second stage (i.e. the debug command issuing stage) of example 4 of the present application mainly includes sending a debug command from the debug apparatus to the master apparatus. As shown in fig. 14, the second phase (i.e., the debug command issuing phase) of example 4 of the present application may include the following step S2.1.4:

s2.1.4, debug server 41, debug client A43, and debug client B44 send debug commands to the smartphone.

Further, the third phase (i.e., the debugging phase) of example 4 of this application mainly includes the debugged device performing the debugging operation and obtaining the debugging data. As shown in fig. 14, the third phase (i.e., the debugging phase) of example 4 of the present application may include the following step S3.1.4:

s3.1.4, the smart phone executes corresponding debugging operations on the eighth process according to the received eighth debugging command, the ninth debugging command and the tenth debugging command, and respectively acquires eighth debugging data, ninth debugging data and tenth debugging data.

Further, the fourth stage (i.e. the debugging information returning stage) of example 4 of the present application mainly includes forwarding of debugging data from the master device to the debugging server. As shown in fig. 14, the fourth phase (i.e., the debug information return phase) of example 4 of the present application may include the following step S4.1.4:

s4.1.4, the smart phone sends the eighth debug data, the ninth debug data and the tenth debug data to the debug server 41.

Further, the fifth stage (i.e., the debugging information presentation stage) of example 4 of the present application mainly includes distribution of debugging data and presentation of debugging information. As shown in fig. 14, the fifth phase (i.e., the debugging information presentation phase) of the present application example 4 may include the following steps S5.1.4 and S5.2.4:

s5.1.4, the debug server 41 distributes the eighth debug data, the ninth debug data, and the tenth debug data.

S5.2.4, debug server 41, debug client A43, and debug client B44 perform the debugging information exposure.

For example, in example 4 shown in fig. 14, the debug server 41, the debug client a43, and the debug client B44 respectively present the eighth debug data, the ninth debug data, and the tenth debug data to the developer through UI interfaces.

For a specific step execution process of example 4 shown in fig. 14, reference may be made to the description and the explanation of the specific step of example 1 shown in fig. 11, and details are not repeated here.

It should be noted that, the above example 4 is an example in which a plurality of debugging clients and a debugging server cooperate to debug a process in a host device. For other scenarios in which multiple devices debug a single device, reference may be made to the software debugging method shown in example 4, which is not described in detail in this embodiment of the present application.

By the software debugging method similar to that shown in example 4 in embodiment 3, it is possible to implement cooperative debugging of a process in a certain device in a distributed device cluster by a plurality of debugging devices. By the debugging method, the efficiency and the quality of a developer in process debugging are greatly improved.

In some embodiments, a developer may also implement flexible debugging of software in other scenarios based on the debugging system framework provided in the embodiments of the present application, for example, debugging of a single device by a single device, that is, implementing debugging of a process in a master device by a debugging server. For example, in a scenario of debugging a single device, a software debugging method provided in an embodiment of the present application may include the following steps:

step 1: in response to receiving a developer's selection operation of a debuggable process, debug server 41 determines a debuggable process.

Step 2: the debug server 41 generates debug commands based on debug events triggered by the developer.

And step 3: the debugging server 41 sends a debugging command to the smartphone according to the detected debugging event of the developer.

And 4, step 4: and the smart phone executes corresponding debugging operation according to the received debugging command to acquire debugging data.

And 5: the smartphone transmits the acquired debug data to the debug server 41.

Step 6: the debugging server 41 performs debugging information presentation.

For the above steps, reference may be made to the above description of example 1, example 2, example 3, and example 4, which are not repeated herein.

It should be understood that the various aspects of the embodiments of the present application can be reasonably combined and explained, and the explanation or explanation of the various terms appearing in the embodiments can be mutually referred to or explained in the various embodiments, which is not limited.

It should also be understood that, in the various embodiments of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

It is to be understood that the electronic device (such as the first device, the second device, the third device or the fourth device) includes a corresponding hardware structure and/or software module for performing the functions of any of the above embodiments. Those of skill in the art would readily appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is performed in hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiment of the present application, functional modules of electronic devices (such as a first device, a second device, a third device, or a fourth device) may be divided, for example, each functional module may be divided corresponding to each function, or two or more functions may be integrated into one processing module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. It should be noted that, in the embodiment of the present application, the division of the module is schematic, and is only one logic function division, and another division manner may be available in actual implementation.

For example, in a case where each functional module is divided in an integrated manner, as shown in fig. 15, the functional module is a block diagram of an electronic device provided in an embodiment of the present application. The electronic device may be the first device, the second device, the third device, or the fourth device. As shown in fig. 15, the electronic device may include a processing unit 1510 and a transceiving unit 1520.

Further, in a possible structure, as shown in fig. 15, the electronic device may further include a storage unit 1530.

When the electronic device is a first device, the transceiving unit 1520 is configured to receive a first debug command corresponding to a first process in a third device from the second device, and send the first debug command to the third device; receiving first debug data from a third device; and sending the first debugging data to the second device; and/or other processes for the techniques described herein. The first debugging command carries an identifier of the third equipment and an identifier of the first process; the first debugging data is obtained by the third equipment executing the first debugging command to the first process; the first debugging data carries an identifier of the third device and an identifier of the first process. The processing unit 1510 is configured to determine to send the first debug data to the second device through the transceiving unit 1520 according to the identifier of the third device and the identifier of the first process, which are carried in the first debug data; and/or other processes for the techniques described herein.

Further, in some embodiments, the transceiving unit 1520 is further configured to send, to the second debugging module, a second debugging command, which is triggered by the developer through the first device and corresponds to a second process in the fourth device; sending a second debugging command to the third equipment; and receiving second commissioning data from the third device; and/or other processes for the techniques described herein. The second process is associated with the first process, and the second debugging command carries an identifier of the fourth device and an identifier of the second process; the second debugging data is obtained by executing a second debugging command on the second process by the fourth device; the second debug data carries an identifier of the fourth device and an identifier of the second process. The processing unit 1510 is further configured to determine, according to the identifier of the fourth device and the identifier of the second process, that the second debugging data is displayed to the developer by the first device.

When the electronic device is a third device, the transceiving unit 1520 is configured to receive a first debug command from the first device; sending first debugging data to first equipment; and/or other processes for the techniques described herein. The processing unit 1510 is configured to invoke a debugging tool in the third device according to the identifier of the third device and the identifier of the first process, which are carried in the first debugging command, to execute the first debugging command on the first process, and obtain first debugging data; and/or other processes for the techniques described herein.

Further, in some embodiments, the transceiving unit 1520 is further configured to receive a second debug command from the first device; sending second debugging data to the first equipment; receiving second debug data from a fourth device; and/or other processes for the techniques described herein. The processing unit 1510 is configured to send the second debug command to the fourth device according to the identifier of the fourth device carried in the second debug command; and/or other processes for the techniques described herein.

When the electronic device is a second device, the processing unit 1510 is configured to generate a debug command according to a debug operation triggered by a developer, perform debug cluster networking with the first device, and/or other processes for the techniques described herein. The transceiving unit 1520 is to send the first/second debug commands to the first device, receive the first/second debug data from the first device, and/or other processes for the techniques described herein.

When the electronic device is a fourth device, the transceiving unit 1520 is to receive the first/second debug command from the third device, send the first/second debug data to the third device, send information of the debuggable process to the third device, and/or other processes for the techniques described herein.

It should be noted that the transceiver unit 1520 may include a radio frequency circuit. Specifically, the electronic device may receive and transmit wireless signals through the radio frequency circuit. Typically, the radio frequency circuitry includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier, a duplexer, and the like. In addition, the radio frequency circuitry may also communicate with other devices via wireless communication. The wireless communication may use any communication standard or protocol including, but not limited to, global system for mobile communications, general packet radio service, code division multiple access, wideband code division multiple access, long term evolution, email, short message service, and the like.

In an alternative, when the data transfer is implemented using software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are implemented in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied in hardware or may be embodied in software instructions executed by a processor. The software instructions may consist of corresponding software modules that may be stored in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. Of course, the storage medium may also be integral to the processor. The processor and the storage medium may reside in an ASIC. Additionally, the ASIC may reside in an electronic device. Of course, the processor and the storage medium may reside as discrete components in an electronic device.

Through the description of the foregoing embodiments, it will be clear to those skilled in the art that, for convenience and simplicity of description, only the division of the functional modules is illustrated, and in practical applications, the above function distribution may be completed by different functional modules as needed, that is, the internal structure of the apparatus may be divided into different functional modules to complete all or part of the above described functions.

In a selectable manner, the present application provides a debugging system, where the debugging system includes a first device, a second device, a third device, and a fourth device, and the first device, the second device, the third device, and the fourth device are configured to implement the method in any one of the possible implementation manners provided by the present application.

In an alternative aspect, the present application provides a chip system, where the chip system includes a processor and a memory, where instructions are stored in the memory; when executed by a processor, implement the method of any one of the possible implementations provided herein. The chip system may be formed by a chip, and may also include a chip and other discrete devices.

In the several embodiments provided in the present application, it should be understood that the disclosed electronic device and method may be implemented in other ways. For example, the above-described device embodiments are merely illustrative, and for example, the division of the modules or units is only one logical functional division, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be integrated into another device, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may be one physical unit or a plurality of physical units, that is, may be located in one place, or may be distributed in a plurality of different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application, or portions of the technical solutions that substantially contribute to the prior art, or all or portions of the technical solutions may be embodied in the form of a software product, where the software product is stored in a storage medium and includes several instructions to enable a device (which may be a single chip, a chip, or the like) or a processor (processor) to execute all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above description is only an embodiment of the present application, but the scope of the present application is not limited thereto, and any changes or substitutions within the technical scope of the present disclosure should be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method for debugging software, the method comprising:

the method comprises the steps that first equipment receives a first debugging command from second equipment, wherein the first debugging command corresponds to a first process in third equipment, and the first debugging command carries an identifier of the third equipment and an identifier of the first process;

the first device sends the first debugging command to the third device;

the first device receives first debugging data from the third device, where the first debugging data is obtained after the third device executes the first debugging command on the first process, and the first debugging data carries an identifier of the third device and an identifier of the first process;

and the first equipment sends the first debugging data to the second equipment.

2. The method of claim 1, further comprising:

responding to a debugging event triggered by a user, and acquiring a second debugging command by the first equipment; the second debugging command corresponds to a second process in fourth equipment, the second process is associated with the first process, and the second debugging command carries an identifier of the fourth equipment and an identifier of the second process;

the first device sends the second debugging command to the third device;

the first device receives second debugging data from the third device, where the second debugging data is obtained after the fourth device executes the second debugging command on the second process, the second debugging data is sent to the third device after the fourth device executes the second debugging command on the second process, and the second debugging data carries an identifier of the fourth device and an identifier of the second process.

3. The method of claim 1, further comprising:

the first device receives a third debugging command from the second device, wherein the third debugging command corresponds to a third process in a fourth device, and the third debugging command carries an identifier of the fourth device and an identifier of the third process;

the first device sends the third debugging command to the third device;

the first device receives third debugging data from the third device, where the third debugging data is obtained after the fourth device executes the third debugging command on the third process, the third debugging data is sent to the third device after the fourth device executes the third debugging command on the third process, and the third debugging data carries an identifier of the fourth device and an identifier of the third process; and the first equipment sends the third debugging data to the second equipment.

4. The method of claim 2, further comprising:

the first device receiving a viewing request from the second device;

in response to the viewing request, the first device sends the second commissioning data to the second device.

5. The method of claim 2 or 4, wherein after the first device receives second commissioning data from the third device, the method further comprises:

and the first equipment displays the second debugging data through a User Interface (UI).

6. The method according to any one of claims 1-5, further comprising:

and the first equipment displays the first debugging data through a User Interface (UI).

7. The method according to any one of claims 2 to 6,

the first device is in communication connection with the second device; the first device is in communication connection with the third device, and the third device is in communication connection with the fourth device.

8. The method of any of claims 1-7, wherein the first device sending the first commissioning data to the second device comprises:

and the first device sends the first debugging data to the second device according to the identifier of the third device and the identifier of the first process carried in the first debugging data.

9. The method of any of claims 2-8, wherein prior to the first device receiving the first debug command from the second device, the method further comprises:

the first device sends a command for discovering a debuggable process to the third device, wherein the command for discovering the debuggable process is used for discovering the debuggable process;

the first device receives debuggable process information from the third device, wherein the debuggable process information comprises information of debuggable processes discovered by the third device and the fourth device.

10. The method of claim 9, wherein the information about the debuggable process comprises information about the first process, information about the second process, and information about the third process.

11. The method of any of claims 1-10, wherein the first debug command comprises a breakpoint command and/or a time-light debug command.

12. The method of claim 11, wherein the breakpoint command comprises one or more of: a data breakpoint command, a synchronization breakpoint command, or a conditional breakpoint command.

13. A method for debugging software, the method comprising:

the method comprises the steps that a third device receives a first debugging command from a first device, wherein the first debugging command corresponds to a first process in the third device, and the first debugging command carries an identifier of the third device and an identifier of the first process;

the third device executes the first debugging command on the first process according to the identifier of the third device and the identifier of the first process carried in the first debugging command, and obtains first debugging data, wherein the identifier of the third device and the identifier of the first process are carried in the first debugging data;

the third device sends the first commissioning data to the first device.

14. The method of claim 13, further comprising:

the third device receives a second debugging command from the first device, wherein the second debugging command corresponds to a second process in a fourth device, the second process is associated with the first process, and the second debugging command carries an identifier of the fourth device and an identifier of the second process;

the third equipment sends the second debugging command to the fourth equipment according to the identifier of the fourth equipment carried in the second debugging command;

the third device receives second debugging data from the fourth device, where the second debugging data is obtained after the fourth device executes the second debugging command on the second process, and the second debugging data carries an identifier of the fourth device and an identifier of the second process;

the third device sends the second commissioning data to the first device.

15. The method of claim 13, further comprising:

a third device receives a third debugging command from a first device, wherein the third debugging command corresponds to a third process in a fourth device, and the third debugging command carries an identifier of the fourth device and an identifier of the third process;

the third equipment sends the third debugging command to the fourth equipment according to the identifier of the fourth equipment carried in the third debugging command;

the third device receives third debugging data from the fourth device, where the third debugging data is obtained after the fourth device executes the third debugging command on the third process, and the third debugging data carries an identifier of the fourth device and an identifier of the third process;

the third device sends the third commissioning data to the first device.

16. The method of claim 14 or 15, wherein prior to the third device receiving the first debug command from the first device, the method further comprises:

the third device conducts device discovery, and after a fourth device is discovered, a communication connection is established with the fourth device; the third device is in communicative connection with the first device.

17. The method of claim 16, wherein after establishing the communication connection with the fourth device, the method further comprises:

the third device receiving a command to discover a debuggable process from the first device;

the third device sends a command of the discovery debuggable process to the fourth device;

the third device discovering a first debuggable process, the first debuggable process comprising the first process;

the third device receiving, from the fourth device, information of a second debuggable process discovered by the fourth device, the second debuggable process including the second process and the third process;

the third equipment sends information of a debuggable process to the first equipment; the information of the debuggable process includes information of the first debuggable process and information of the second debuggable process.

18. The method of any of claims 13-17, wherein the first debug command comprises a breakpoint command and/or a time-light debug command.

19. The method of claim 18, wherein the breakpoint command comprises one or more of: a data breakpoint command, a synchronization breakpoint command, or a conditional breakpoint command.

20. A first device, characterized in that the first device comprises:

the second debugging module is used for receiving a first debugging command from the second equipment;

sending the first debugging command to a third device;

receiving first commissioning data from the third device; and the number of the first and second groups,

sending the first debugging data to the second device;

the first debugging command corresponds to a first process in third equipment, and the first debugging command carries an identifier of the third equipment and an identifier of the first process; the first debugging data is obtained after the third device executes the first debugging command on the first process, and the first debugging data carries an identifier of the third device and an identifier of the first process.

21. The first device of claim 20, wherein the first device further comprises:

the framework layer is used for responding to a debugging event triggered by a user and acquiring a second debugging command; and sending the second debug command to the second debug module; the second debugging command corresponds to a second process in fourth equipment, the second process is associated with the first process, and the second debugging command carries an identifier of the fourth equipment and an identifier of the second process;

the second debugging module is further configured to send the second debugging command to the third device; and receiving second debugging data from the third device, where the second debugging data is obtained by the fourth device after executing the second debugging command on the second process, and the second debugging data carries an identifier of the fourth device and an identifier of the second process.

22. The first apparatus of claim 21,

the second debugging module is further configured to send the first debugging data to the framework layer, so that the framework layer displays the first debugging data through a user interface UI interface.

23. The first apparatus according to claim 21 or 22,

the second debugging module is further configured to receive a viewing request from the second device, and send the second debugging data to the second device.

24. The first apparatus of claim 20,

the second debugging module is further configured to receive a third debugging command from the second device; the third debugging command corresponds to a third process in fourth equipment, the third process is associated with the first process, and the third debugging command carries an identifier of the fourth equipment and an identifier of the third process; and the number of the first and second groups,

sending the third debug command to the third device; and receiving third commissioning data from the third device; the third debugging data is obtained after the fourth device executes the third debugging command on the third process, and the third debugging data carries an identifier of the fourth device and an identifier of the third process.

25. The first apparatus of claim 24,

the second debugging module is further configured to send the third debugging data to the framework layer, so that the framework layer displays the third debugging data through a user interface UI interface.

26. The first device of any of claims 21-25, wherein the second debugging module is further configured to,

and establishing communication connection with the second equipment, and performing communication connection with the third equipment through the first equipment.

27. The first device according to any of claims 20-26, wherein the second debugging module is specifically configured to,

and sending the first debugging data to the second equipment according to the identifier of the third equipment and the identifier of the first process carried in the first debugging data.

28. The first device of any of claims 20-27, wherein the second debugging module is further configured to,

sending a command for discovering an debuggable process to the third device, wherein the command is used for discovering the debuggable process; and the number of the first and second groups,

and receiving debuggable process information from the third device, wherein the debuggable process information comprises information of debuggable processes discovered by the third device and the fourth device.

29. A third device, characterized in that the third device comprises:

a distributed debug assistant to receive a first debug command from a first device; calling a debugging tool in the third equipment according to the identifier of the third equipment and the identifier of the first process carried in the first debugging command, executing the first debugging command on the first process, and acquiring first debugging data; and sending the first debug data to the first device;

the first debugging command corresponds to a first process in third equipment, and the first debugging data carries an identifier of the third equipment and an identifier of the first process.

30. The third apparatus of claim 29,

the distributed debug assistant is further to receive a second debug command from the first device; sending the second debugging command to fourth equipment according to an identifier of the fourth equipment carried in the second debugging command; receiving second commissioning data from the fourth device; and sending the second commissioning data to the first device;

the second debugging command corresponds to a second process in fourth equipment, the second process is associated with the first process, and the second debugging command carries an identifier of the second process; the second debug data carries an identifier of the fourth device and an identifier of the second process.

31. The third apparatus of claim 29,

the distributed debug assistant is further to receive a third debug command from the first device; sending the third debugging command to fourth equipment according to an identifier of the fourth equipment carried in the third debugging command; receiving third commissioning data from the fourth device; and sending the third commissioning data to the first device;

the third debugging command corresponds to a third process in fourth equipment, the third process is associated with the first process, and the third debugging command carries an identifier of the third process; the third debug data carries an identifier of the fourth device and an identifier of the third process.

32. The third apparatus according to claim 30 or 31,

the distributed debug assistant is further configured to perform device discovery and establish a communication connection with the one or more fourth devices after discovering the fourth device; the third device is in communicative connection with the first device.

33. The third apparatus of claim 32,

the distributed debug assistant is further to receive a command to discover a debuggable process from the first device; sending a command to the one or more fourth devices to discover the debuggable process; discovering a first debuggable process; receiving, from the fourth device, information of a second debuggable process discovered by the fourth device; and sending information of the debuggable process to the first device;

wherein the first debuggable process comprises the first process; the second debuggable process comprises the second process and the third process; the information of the debuggable process includes information of the first debuggable process and information of the second debuggable process.

34. A debugging system, characterized in that the debugging system comprises:

a first device as claimed in any one of claims 20 to 28; and

the third apparatus of any of claims 29-33.

35. An electronic device, characterized in that the electronic device comprises:

a memory for storing a computer program;

a processor for executing the computer program such that the electronic device implements the method of any of claims 1-12 or 13-19.

36. A computer-readable storage medium, having computer program code stored thereon, which, when executed by a processing circuit, implements the method of any of claims 1-12 or 13-19.

37. A chip system, comprising a processing circuit, a storage medium having computer program code stored therein; the computer program code realizing the method of any of claims 1-12 or 13-19 when executed by the processing circuit.

38. A computer program product for running on a computer to implement the method of any one of claims 1-12 or 13-19.