Data processing method, debugger system and computer readable storage medium

Abstract

The invention discloses a data processing method, a debugger system and a computer readable storage medium, and belongs to the technical field of chip debugging, and the method comprises the steps: obtaining a debugging conflict tree, a debugging request and a target debugging task corresponding to the debugging request, the debugging conflict tree is a tree structure established based on a hierarchical relationship of each device in a hardware device set and a preset rule between debugging tasks corresponding to each device, and each node except a root node in the debugging conflict tree is associated with at least one debugging task; the preset rule is used for representing that the debugging tasks are allowed to be executed at the same time or are not allowed to be executed at the same time in the preset debugging scene, and the target debugging task belongs to the preset debugging scene; and determining whether the target debugging task is allowed to be executed or not based on the target debugging task and the working state of each debugging task corresponding to each node associated with the target node corresponding to the target debugging task in the debugging conflict tree. The calculation complexity is reduced, and the processing efficiency of the debugging request is improved.

Description

Technical Field

[0001] This application relates to the field of chip debugging technology, and more specifically, to a data processing method, a debugger system, and a computer-readable storage medium. Background Technology

[0002] In debugger system design, the client is a higher-level computer device that plays a role in human-computer interaction, debugging task scheduling, and arbitration. On the one hand, it is responsible for efficiently and reliably receiving and parsing diverse debugging requests from the user interface or automated scripts. On the other hand, as a coordinator, it ensures that these requests maintain a strict order during execution, avoiding race conditions or logical conflicts.

[0003] Currently, the client-side design lacks a systematic debugging request conflict management mechanism. When a new debugging request arrives, because there is no clear retrieval rule to determine its feasibility, it is necessary to traverse all currently executing debugging tasks and perform feasibility checks to determine whether the new request conflicts logically or in terms of resources with any ongoing debugging tasks. Client programs implemented based on this method are complex, with a time complexity of O(N), and frequent traversal operations can become a performance bottleneck under high concurrency. Furthermore, from a development perspective, adding a new debugging operation requires defining its relationship with all existing debugging operations, which involves global modifications to the feasibility traversal and judgment functions, easily introducing errors and resulting in poor extensibility. Summary of the Invention

[0004] This application proposes a data processing method, a debugger system, and a computer-readable storage medium to improve the above-mentioned deficiencies.

[0005] In a first aspect, this application provides a data processing method applied to a client of a debugger system, the debugger system further comprising a set of hardware devices connected to the client, the method comprising: acquiring a debug conflict tree, a debug request, and a target debug task corresponding to the debug request, wherein the debug conflict tree is a tree structure established based on the hierarchical relationship of each device in the hardware device set and preset rules between each debug task corresponding to each device, each node in the debug conflict tree except the root node is associated with at least one debug task, the preset rules are used to characterize whether each debug task is allowed to be executed simultaneously or not allowed to be executed simultaneously under a preset debug scenario, and the target debug task belongs to the preset debug scenario; determining whether the target debug task is allowed to be executed or not allowed to be executed based on the target debug task and the working status of each debug task corresponding to each node associated with the target node of the target debug task in the debug conflict tree, wherein the working status of the debug task includes being executed or not being executed.

[0006] Optionally, in one possible implementation, any two debugging tasks associated with each node other than the root node in the debugging conflict tree are not allowed to be executed simultaneously and have no dependency relationship under a preset debugging scenario. Each debugging task associated with a child node in the debugging conflict tree depends on at least one debugging task associated with the parent node of that child node. Any debugging task associated with a child node in the debugging conflict tree and any debugging task associated with the parent node of that child node are not allowed to be executed simultaneously under a preset debugging scenario. Any debugging task associated with any two sibling nodes in the debugging conflict tree is allowed to be executed simultaneously under a preset debugging scenario.

[0007] Optionally, in one possible implementation, determining whether the target debugging task is allowed or not allowed to be executed based on the target debugging task and the working status of each debugging task associated with each node corresponding to the target node in the debugging conflict tree includes: determining each path including the target node selected from each path formed by traversing from the root node to the leaf node as the target path; and determining whether the target debugging task is allowed or not allowed to be executed based on the working status of each debugging task associated with each node on the target path.

[0008] Optionally, in one possible implementation, determining whether the target debugging task is allowed or not allowed to be executed based on the working status of each debugging task associated with each node on the target path includes: if at least one node on the target path has a debugging task associated with it being executed, then the status of the target debugging task is determined to be not allowed to be executed; if none of the debugging tasks associated with each node on the target path are being executed, then the status of the target debugging task is determined to be allowed to be executed.

[0009] Optionally, in one possible implementation, determining whether the target debugging task is allowed or not allowed to be executed based on the working status of each debugging task associated with each node on the target path includes: determining whether there is a debugging task being executed among the debugging tasks associated with the target node; if there is a debugging task being executed among the debugging tasks associated with the target node, then determining that the status of the target debugging task is not allowed to be executed.

[0010] Optionally, in one possible implementation, the method further includes: if none of the debugging tasks associated with the target node are executed, then determining the ancestor node of the target node based on the target path; determining whether there is a debugging task being executed among the debugging tasks associated with the ancestor node; if there is a debugging task being executed among the debugging tasks associated with the ancestor node, then determining that the state of the target debugging task is not allowed to be executed.

[0011] Optionally, in one possible implementation, the method further includes: if none of the debugging tasks associated with the ancestor node have been executed, then determining whether the target node contains descendant nodes based on the target path; if the target node does not contain descendant nodes, then determining that the state of the target debugging task is allowed to be executed.

[0012] Optionally, in one possible implementation, the method further includes: if the target node contains descendant nodes, determining whether there is a currently executing debugging task among the debugging tasks associated with the descendant nodes of the target node; if there is a currently executing debugging task among the debugging tasks associated with the descendant nodes of the target node, determining that the state of the target debugging task is not allowed to be executed; if none of the debugging tasks associated with the descendant nodes of the target node are executed, determining that the state of the target debugging task is allowed to be executed.

[0013] Optionally, in one possible implementation, each node in the debug conflict tree other than the root node is associated with an identifier, which is used to indicate the debug task being executed among the multiple debug tasks associated with the corresponding node. Before determining whether the target debug task is allowed or not allowed to be executed based on the working status of each debug task associated with each node on the target path, the method further includes: determining the working status of each debug task associated with each node on the target path based on the identifier associated with each node on the target path.

[0014] Optionally, in one possible implementation, after determining whether the target debugging task is allowed or not allowed to be executed based on the working status of each debugging task corresponding to each node associated with the target node in the debugging conflict tree, the method further includes: if the status of the target debugging task is allowed to be executed, determining the idle target channel corresponding to the debugging request; sending the debugging request to the server through the target channel, triggering the server to execute the target debugging task based on the debugging request, and returning target data to the corresponding target channel upon completion of the target debugging task.

[0015] Optionally, in one possible implementation, after sending the debugging request to the server through the target channel, the method further includes: determining whether the target channel has received the target data corresponding to the debugging request; if the target channel has received the target data corresponding to the debugging request, then outputting and displaying the target data corresponding to the debugging request; if the target channel has not received the target data corresponding to the debugging request, returning to the execution of determining whether the target channel has received the target data corresponding to the debugging request and subsequent steps.

[0016] Optionally, in one possible implementation, after sending the debug request to the server through the target channel, the method further includes: determining whether the target channel has received the target data corresponding to the debug request; if the target channel has received the target data corresponding to the debug request, then outputting and displaying the target data corresponding to the debug request; if the target channel has not received the target data corresponding to the debug request, then determining whether a new debug request has been received; if a new debug request has been received, then returning to the execution of obtaining the debug conflict tree, the debug request, and the target debug task corresponding to the debug request, as well as subsequent operations.

[0017] Secondly, this application also provides a debugger system, including: a client, a server, and a set of hardware devices; the server is connected to the client and the set of hardware devices respectively; the client includes a processor and a memory; the memory stores one or more applications, the one or more applications being configured to be executed by the processor, and the one or more applications being configured to perform the methods as described above.

[0018] Thirdly, this application also provides a computer-readable medium storing processor-executable program code, which, when executed by the processor, causes the processor to perform the above-described method.

[0019] The solution provided in this application firstly obtains a debug conflict tree, a debug request, and the target debug task corresponding to the debug request. The debug conflict tree is a tree structure established based on the hierarchical relationship of each device in the hardware device set and the preset rules between the debug tasks corresponding to each device. Each node in the debug conflict tree, except for the root node, is associated with at least one debug task. The preset rules are used to characterize whether the debug tasks are allowed to be executed simultaneously or not under a preset debug scenario. The target debug task belongs to the preset debug scenario. Secondly, based on the target debug task and the working status of the debug tasks corresponding to each node associated with the target node in the debug conflict tree, it is determined whether the target debug task is allowed to be executed or not. The working status of the debug task includes being executed or not being executed.

[0020] Compared to the approach of sequentially determining whether a debug request conflicts with each currently executing debug task, which has high time complexity, the debug conflict tree in this application is a tree structure built based on the hierarchical relationship of each device in the hardware device set and the preset rules between each debug task corresponding to each device. The preset rules characterize whether debug tasks are allowed to be executed simultaneously or not under a preset debug scenario. Therefore, the execution status of the target debug task is determined based on the target debug task and the working status of each debug task associated with the target node in the debug conflict tree. This can, to some extent, avoid determining whether a debug request conflicts with each currently executing debug task, reducing computational complexity and improving the processing efficiency of debug requests.

[0021] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A flowchart of the data processing method provided in an embodiment of this application is shown; Figure 2 A structural block diagram of the debugger system provided in an embodiment of this application is shown; Figure 3 This paper shows a structural block diagram of the hardware device set provided in an embodiment of this application; Figure 4 This paper shows a structural block diagram of the debugging conflict tree provided in an embodiment of this application; Figure 5 A flowchart of a data processing method according to another embodiment of this application is shown; Figure 6 A flowchart of a data processing method according to another embodiment of this application is shown; Figure 7 A flowchart of a data processing method according to another embodiment of this application is shown; Figure 8 A flowchart illustrating the workflow of the debugger system provided in an embodiment of this application is shown. Figure 9A flowchart of the debugger system provided in another embodiment of this application is shown; Figure 10 A flowchart of the debugger system provided in another embodiment of this application is shown; Figure 11 This illustration shows a structural block diagram of a debug conflict tree provided in yet another embodiment of this application; Figure 12 A structural block diagram of a debugger system provided in yet another embodiment of this application is shown; Figure 13 A structural block diagram of a computer-readable storage medium provided in an embodiment of this application is shown. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all of them. The components of the embodiments of the present application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of the present application. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without inventive effort are within the scope of protection of the present application.

[0025] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0026] In debugger system design, the client is a higher-level computer device that plays a role in human-computer interaction, debugging task scheduling, and arbitration. On the one hand, it is responsible for efficiently and reliably receiving and parsing diverse debugging requests from the user interface or automated scripts. On the other hand, as a coordinator, it ensures that these requests maintain a strict order during execution, avoiding race conditions or logical conflicts.

[0027] Currently, the client-side design lacks a systematic debugging request conflict management mechanism. When a new debugging request arrives, because there is no clear retrieval rule to determine its feasibility, it is necessary to traverse all currently executing debugging tasks and perform feasibility checks to determine whether the new request conflicts logically or in terms of resources with any ongoing debugging tasks. Client programs implemented based on this method are complex, with a time complexity of O(N), and frequent traversal operations can become a performance bottleneck under high concurrency. Furthermore, from a development perspective, adding a new debugging operation requires defining its relationship with all existing debugging operations, which involves global modifications to the feasibility traversal and judgment functions, easily introducing errors and resulting in poor extensibility.

[0028] In the field of debuggers, a debug request is a request sent by a user to the debugger to control or monitor the execution of a program.

[0029] Debug target: This refers to the target of a debug request or debug operation. It can be a real physical object, a program running in the chip, or a chip module responsible for performing the debug operation.

[0030] Single-threaded concurrency: This means that multiple tasks are processed alternately through task switching and scheduling when there is only one execution thread.

[0031] Dependency: This indicates that a change in the object being depended on will cause a change in the dependent object. For example, a chip reset will cause a change in the program on the chip, and the program debugging object depends on the chip reset debugging object.

[0032] Debugging task: This refers to a series of tasks that the debugger needs to complete in order to process a debug request.

[0033] Debugging operation: refers to the operation process that needs to be performed to achieve a certain debugging function.

[0034] Sequentiality: This means that for two requests with a clear time sequence, the returned results also have a sequential order.

[0035] Race condition: This refers to the situation where multiple debugging requests access the same resource asynchronously. Due to the lack of synchronization management, the result is uncertain and may even lead to hardware system abnormalities.

[0036] Feasibility traversal judgment function: It traverses all currently executing debugging tasks and determines whether a newly arrived debugging request is executable based on its relationship with these debugging tasks.

[0037] Channel: Represents a transmission channel responsible for data exchange between the client and the server, such as a socket session. It has the function of registering to receive callback functions and can only transmit one command at a time. After sending request data through the channel, when the channel receives the return result from the server, the callback function triggers the return result processing event.

[0038] It should be noted that the tree structure includes node names such as root node, child node, parent node, leaf node, ancestor node, and descendant node.

[0039] The root node is the topmost node in the tree structure; it is a node without a parent node.

[0040] Parent node: The node directly above the current node. Child node: The node directly connected to the parent node. A node can have multiple child nodes, but a node has only one parent node. A parent node can have multiple child nodes.

[0041] Leaf nodes: These are nodes that have no child nodes and are located at the bottom level of the tree structure.

[0042] Ancestor nodes: represent all nodes on the path from the root node to the current node, including parent nodes, grandparent nodes, etc. The root node is the ancestor node of all nodes.

[0043] Descendant nodes: represent all nodes at all levels under the current node, including child nodes, grandchild nodes, etc.

[0044] In this application embodiment, a data processing method, a debugger system, and a computer-readable storage medium are provided to solve or partially solve the above-mentioned problems.

[0045] Please see Figure 1 The diagram illustrates a data processing method provided in an embodiment of this application. The method is applied to a client of a debugger system, which further includes a set of hardware devices connected to the client. Specifically, it includes steps S101 to S102.

[0046] It should be noted that the structure of the debugger system is as follows: Figure 2As shown, the system includes a client (i.e., the host computer), a server (i.e., the slave computer), and a set of hardware devices connected to the server. The connection between the client and the server is called a channel. The channel is responsible for data transmission between the client and the server and has the function of registering and receiving callback functions. The client's commands are sent to the server through the channel. There can be multiple channels between the client and the server or only one channel. A channel can only transmit one piece of data at a time. After sending data to the server, the channel cannot be used to send other data to the server until it receives a feedback signal from the server. After receiving the data sent by the client, the server parses it into instructions to drive the set of hardware devices.

[0047] Step S101: Obtain the debug conflict tree, the debug request, and the target debug task corresponding to the debug request. The debug conflict tree is a tree structure established based on the hierarchical relationship of each device in the hardware device set and the preset rules between each debug task corresponding to each device. Each node in the debug conflict tree other than the root node is associated with at least one debug task. The preset rules are used to characterize whether each debug task is allowed to be executed simultaneously or not allowed to be executed simultaneously in a preset debug scenario. The target debug task belongs to the preset debug scenario.

[0048] In one alternative embodiment, a debug conflict tree can be obtained from a pre-stored database. Debug requests can be obtained based on information entered by the user on the interface, or they can be obtained through an automated script. Then, the target debug task corresponding to the debug request can be obtained based on the debug request. The target debug task represents the debug task corresponding to the debug request.

[0049] Understandably, the debug conflict tree is a tree structure built upon the hierarchical relationship between each device in the hardware device set and the preset rules between the debug tasks corresponding to each device. For example, a hardware device set... Figure 3 As shown, the preset debugging scenario is a scenario where the debugging chip is in a normal state.

[0050] Step S102: Based on the target debugging task and the working status of each debugging task associated with each node corresponding to the target node in the debugging conflict tree, determine whether the target debugging task is allowed to be executed or not allowed to be executed. The working status of the debugging task includes being executed or not being executed.

[0051] It should be noted that, since the debug conflict tree includes preset rules between each debug task, these preset rules characterize whether each debug task is allowed to be executed simultaneously or not under a preset debug scenario. Therefore, the execution of a target debug task can be determined based on the debug conflict tree and the target debug task. Specifically, the execution of the target debug task is determined based on the working status of each debug task corresponding to the target node associated with the target debug task in the debug conflict tree.

[0052] For example, if the working status of debugging task A is being executed, and the debugging tasks of each node associated with the target node of the target debugging task include debugging task A, then it is determined that the target debugging task will not be run.

[0053] For example, if the working status of each debugging task corresponding to each node associated with the target node corresponding to the target debugging task has not been executed, then it is determined that the target debugging task has been run and executed.

[0054] In this embodiment, firstly, a debug conflict tree, a debug request, and a target debug task corresponding to the debug request are obtained. The debug conflict tree is a tree structure established based on the hierarchical relationship of each device in the hardware device set and preset rules between each debug task corresponding to each device. Each node in the debug conflict tree, except for the root node, is associated with at least one debug task. The preset rules are used to characterize whether each debug task is allowed to be executed simultaneously or not allowed to be executed simultaneously under a preset debug scenario. The target debug task belongs to the preset debug scenario. Secondly, based on the target debug task and the working status of each debug task corresponding to each node associated with the target node of the target debug task in the debug conflict tree, it is determined whether the target debug task is allowed to be executed or not. The working status of the debug task includes being executed or not being executed.

[0055] Compared to the approach of sequentially determining whether a debug request conflicts with each currently executing debug task, which has high time complexity, the debug conflict tree in this application is a tree structure built based on the hierarchical relationship of each device in the hardware device set and the preset rules between each debug task corresponding to each device. The preset rules characterize whether debug tasks are allowed to be executed simultaneously or not under a preset debug scenario. Therefore, the execution status of the target debug task is determined based on the target debug task and the working status of each debug task associated with the target node in the debug conflict tree. This can, to some extent, avoid determining whether a debug request conflicts with each currently executing debug task, reducing computational complexity and improving the processing efficiency of debug requests.

[0056] In one alternative embodiment, the structure of the debug conflict tree is as follows: Figure 4 As shown, Figure 4 The debug conflict tree shown is Figure 3 The hardware device set corresponds to the following: in the debug conflict tree, any two debug tasks associated with each node other than the root node are not allowed to be executed simultaneously and have no dependency relationship under the preset debug scenario; each debug task associated with a child node in the debug conflict tree depends on at least one debug task associated with the parent node of that child node; any debug task associated with a child node in the debug conflict tree and any debug task associated with the parent node of that child node are not allowed to be executed simultaneously under the preset debug scenario; and any debug task associated with any two sibling nodes in the debug conflict tree is allowed to be executed simultaneously under the preset debug scenario.

[0057] Therefore, the execution status of a target debugging task can be determined based on the target debugging task and the working status of each debugging task associated with each node corresponding to the target node in the debugging conflict tree. The number of leaf nodes in the debugging conflict tree is the maximum number of parallel debugging tasks supported by the system.

[0058] Please see Figure 5 The document illustrates a flowchart of a data processing method provided in an embodiment of this application. The method is applied to a client of a debugger system, which further includes a set of hardware devices connected to the client. Specifically, it includes steps S501 to S503.

[0059] Step S501: Obtain the debug conflict tree, the debug request, and the target debug task corresponding to the debug request. The debug conflict tree is a tree structure established based on the hierarchical relationship of each device in the hardware device set and the preset rules between each debug task corresponding to each device. Each node in the debug conflict tree other than the root node is associated with at least one debug task. The preset rules are used to characterize whether each debug task is allowed to be executed simultaneously or not allowed to be executed simultaneously in a preset debug scenario. The target debug task belongs to the preset debug scenario.

[0060] It should be noted that, in the debugging conflict tree, any two debugging tasks associated with each node other than the root node are not allowed to be executed simultaneously and have no dependency relationship under the preset debugging scenario. Each debugging task associated with a child node in the debugging conflict tree depends on at least one debugging task associated with the parent node of that child node. Any debugging task associated with a child node in the debugging conflict tree and any debugging task associated with the parent node of that child node are not allowed to be executed simultaneously under the preset debugging scenario. Any debugging task associated with any two sibling nodes in the debugging conflict tree is allowed to be executed simultaneously under the preset debugging scenario. This will not be elaborated further here.

[0061] Step S502: Determine each path that includes the target node from each path formed by traversing from the root node to the leaf node as the target path.

[0062] It is understandable that there are multiple paths that can be formed by traversing from the root node to the leaf node. Each path that includes the target node is taken as the target path. In other words, each node on the target path represents a node associated with the target node.

[0063] Step S503: Determine whether the target debugging task is allowed to be executed or not based on the working status of each debugging task associated with each node on the target path.

[0064] It is understandable that each node on the target path represents a node associated with the target node. Therefore, it is only necessary to determine whether the target debugging task is allowed or not allowed to execute based on the working status of each debugging task corresponding to each node associated with the target node. The worst-case time complexity is O(N). Under normal circumstances, it is not necessary to judge based on the working status of each debugging task associated with each node in the debugging conflict tree, which greatly reduces the amount of computation. The embodiments of this application determine whether the target debugging task is allowed or not allowed to execute through the debugging conflict tree, which not only ensures the independence of debugging tasks in concurrent scenarios, but also provides a modular foundation for expanding debugging functions.

[0065] In one alternative embodiment, if at least one node on the target path has a debugging task associated with it that is being executed, then the target debugging task is determined to be in a state where execution is not allowed.

[0066] If none of the debugging tasks associated with each node on the target path have been executed, then the status of the target debugging task is determined to be allowed to execute.

[0067] Please see Figure 6 The document illustrates a flowchart of a data processing method provided in an embodiment of this application. The method is applied to a client of a debugger system, which further includes a set of hardware devices connected to the client. Specifically, it includes steps S601 to S6012.

[0068] Step S601: Obtain the debug conflict tree, the debug request, and the target debug task corresponding to the debug request. The debug conflict tree is a tree structure established based on the hierarchical relationship of each device in the hardware device set and the preset rules between each debug task corresponding to each device. Each node in the debug conflict tree other than the root node is associated with at least one debug task. The preset rules are used to characterize whether each debug task is allowed to be executed simultaneously or not allowed to be executed simultaneously in a preset debug scenario. The target debug task belongs to the preset debug scenario.

[0069] Step S602: Determine each path that includes the target node from each path formed by traversing from the root node to the leaf node as the target path.

[0070] Step S603: Determine whether there is a debugging task being executed among the debugging tasks associated with the target node.

[0071] It is understandable that the node associated with the target debugging task is the target node. However, in the debugging conflict tree, any two debugging tasks associated with a node are not allowed to be executed simultaneously and have no dependency relationship under the preset debugging scenario. Therefore, it is possible to determine whether the target debugging task is being run by checking whether there are any debugging tasks being executed among the debugging tasks associated with the target node.

[0072] Step S604: If there is a debugging task being executed among the debugging tasks associated with the target node, then the status of the target debugging task is determined to be not allowed to be executed.

[0073] If there are debugging tasks being executed among the debugging tasks associated with the target node, then the status of the target debugging task is determined to be "not allowed to execute".

[0074] Step S605: If none of the debugging tasks associated with the target node have been executed, then the ancestor node of the target node is determined based on the target path.

[0075] If none of the debug tasks associated with the target node have been executed, the ancestor node of the target node is determined based on the target path. For example, ... Figure 4 As shown, if the target node is "FPGA1 Bitstream Configuration", then the ancestor node corresponding to the target node is the root node "Root". If the target node is "Bitstream Readback", then the ancestor node corresponding to the target node is both the node "FPGA1 Bitstream Configuration" and the root node "Root".

[0076] Step S606: Determine whether there is a debugging task being executed among the debugging tasks associated with the ancestor node.

[0077] Since any debugging task associated with a child node in the debugging conflict tree and any debugging task associated with the parent node of that child node are not allowed to be executed simultaneously under the preset debugging scenario, it is necessary to further determine whether there are any debugging tasks being executed among the debugging tasks associated with the ancestor nodes of the target node.

[0078] Step S607: If there is a debugging task being executed among the debugging tasks associated with the ancestor node, then the state of the target debugging task is determined to be not allowed to be executed.

[0079] If there is a debugging task being executed among the debugging tasks associated with the ancestor node, then the state of the target debugging task is determined to be not allowed to be executed.

[0080] Step S608: If none of the debugging tasks associated with the ancestor node have been executed, determine whether the target node contains descendant nodes based on the target path.

[0081] If none of the debug tasks associated with the ancestor node have been executed, then it is determined whether the target node contains descendant nodes based on the target path. For example, ... Figure 4 As shown, if the target node is "FPGA1 bitstream configuration", then the descendant nodes corresponding to the target node include nodes "DebugcCore1", "DebugcCore2" and "bitstream readback".

[0082] Step S609: If the target node does not contain descendant nodes, then determine that the status of the target debugging task is allowed to be executed.

[0083] If the target node does not contain descendant nodes, it means that none of the debugging tasks associated with each node on the target path have been executed, and the status of the target debugging task is determined to be allowed to execute.

[0084] Step S610: If the target node contains descendant nodes, determine whether there is a debugging task being executed among the debugging tasks associated with the descendant nodes of the target node.

[0085] Since any debugging task associated with a child node in the debugging conflict tree and any debugging task associated with the parent node of that child node are not allowed to be executed simultaneously under the preset debugging scenario, if the target node contains descendant nodes, it is necessary to determine whether there is a debugging task being executed among the debugging tasks associated with the descendant nodes of the target node.

[0086] Step S6011: If there is a debugging task being executed among the debugging tasks associated with the descendant nodes of the target node, then the status of the target debugging task is determined to be not allowed to be executed.

[0087] If there is a debugging task being executed among the debugging tasks associated with the descendant nodes of the target node, then the state of the target debugging task is determined to be not allowed to be executed.

[0088] Step S6012: If none of the debugging tasks associated with the descendant nodes of the target node have been executed, then the status of the target debugging task is determined to be allowed to be executed.

[0089] If none of the debugging tasks associated with the descendant nodes of the target node have been executed, it means that none of the debugging tasks associated with each node on the target path have been executed, and the status of the target debugging task is determined to be allowed to be executed.

[0090] In one optional embodiment, each node in the debug conflict tree other than the root node is associated with an identifier, which is used to indicate the debug task being executed among the multiple debug tasks associated with the corresponding node. Before determining whether the target debug task is allowed or not allowed to be executed based on the working status of each debug task associated with each node on the target path, the method further includes: The working status of each debugging task associated with each node on the target path is determined based on the identifier associated with each node on the target path.

[0091] It is understandable that the debug conflict tree includes both preset rules that allow or disallow simultaneous execution of each debug task and the working status of each debug task. Therefore, the working status of each debug task associated with each node on the target path can be determined based on the identifier associated with each node on the target path, and then the target debug task can be determined to be allowed or disallowed to be executed based on the working status of each debug task associated with each node on the target path.

[0092] It should be noted that each time the client sends a target debugging task to the server, it needs to update the identifier associated with the target node in the debugging conflict tree. Each time the client receives a signal from the server indicating that the debugging task has been completed, it also needs to update the identifier associated with the corresponding node in the debugging conflict tree to ensure that the identifier information in the debugging conflict tree is accurate.

[0093] Please see Figure 7 The document illustrates a flowchart of a data processing method provided in an embodiment of this application. The method is applied to a client of a debugger system. The debugger system also includes a set of hardware devices connected to the client and a server. The server is connected to both the client and the set of hardware devices. The method specifically includes steps S701 to S704.

[0094] Step S701: Obtain the debug conflict tree, the debug request, and the target debug task corresponding to the debug request. The debug conflict tree is a tree structure established based on the hierarchical relationship of each device in the hardware device set and the preset rules between each debug task corresponding to each device. Each node in the debug conflict tree other than the root node is associated with at least one debug task. The preset rules are used to characterize whether each debug task is allowed to be executed simultaneously or not allowed to be executed simultaneously in a preset debug scenario. The target debug task belongs to the preset debug scenario.

[0095] Step S702: Based on the target debugging task and the working status of each debugging task associated with the target node in the debugging conflict tree, determine whether the target debugging task is allowed to be executed or not allowed to be executed. The working status of the debugging task includes being executed or not being executed.

[0096] Step S703: If the status of the target debugging task is "allowed to execute", determine the idle target channel corresponding to the debugging request.

[0097] If the target debugging task is in the state of being allowed to execute, determine the available target channel corresponding to the debugging request, which is used to transmit the debugging request to the server.

[0098] In one alternative embodiment, an idle target channel corresponding to the debugging request is selected from the idle channels.

[0099] In one alternative embodiment, each leaf node in the debug conflict tree is associated with a channel. If the target debug task is in a state of being allowed to execute, an idle channel is found from the leaf nodes of the target node's subtree as the idle target channel corresponding to the debug request.

[0100] Step S704: Send the debugging request to the server through the target channel, triggering the server to execute the target debugging task based on the debugging request and return the target data to the corresponding target channel after the target debugging task is completed.

[0101] In an optional embodiment, after step S704, steps S7041A to S7043A are further included: Step S7041A: Determine whether the target channel has received the target data corresponding to the debugging request.

[0102] It should be noted that the client is configured to send data to the server in a blocking manner, and the system checks whether the target channel has received the target data corresponding to the debugging request.

[0103] Step S7042A: If the target channel receives the target data corresponding to the debugging request, then the target data corresponding to the debugging request will be output and displayed.

[0104] If the target channel receives the target data corresponding to the debug request, it indicates that the target debug task has been completed, and the target data corresponding to the debug request will be output and displayed. This data can be displayed on the user interface.

[0105] Step S7043A: If the target channel does not receive the target data corresponding to the debugging request, return to the execution of determining whether the target channel has received the target data corresponding to the debugging request and subsequent steps.

[0106] If the target channel does not receive the target data corresponding to the debugging request, return to the execution of determining whether the target channel has received the target data corresponding to the debugging request and subsequent steps, that is, continue to wait to receive the target data corresponding to the debugging request.

[0107] In one optional embodiment, after step S704, steps S7041B to S7044B are further included: Step S7041B: Determine whether the target channel has received the target data corresponding to the debugging request.

[0108] It should be noted that the client is configured to send data to the server in a non-blocking manner, and the system determines whether the target channel has received the target data corresponding to the debugging request.

[0109] Step S7042B: If the target channel receives the target data corresponding to the debugging request, then the target data corresponding to the debugging request will be output and displayed.

[0110] If the target channel receives the target data corresponding to the debug request, it indicates that the target debug task has been completed, and the target data corresponding to the debug request will be output and displayed. This data can be displayed on the user interface.

[0111] Step S7043B: If the target channel does not receive the target data corresponding to the debugging request, then determine whether a new debugging request has been received.

[0112] If the target channel does not receive the target data corresponding to the debug request, it is not necessary to wait indefinitely to receive the target data corresponding to the debug request and to determine whether a new debug request has been received.

[0113] Step S7044B: If a new debugging request is received, return to the step of obtaining the debugging conflict tree, the debugging request, the target debugging task corresponding to the debugging request, and subsequent operations.

[0114] If a new debug request is received, return to the execution state to obtain the debug conflict tree, the debug request, the target debug task corresponding to the debug request, and subsequent operations.

[0115] Non-blocking execution mode allows multiple debug requests to be sent consecutively without waiting for the previous debug task to complete. Client user requests do not need to be processed in a blocking manner. As long as the server can respond, multiple consecutive requests from the user on the client can be executed, which can support the goal of full concurrency.

[0116] In one optional embodiment, before obtaining the debug conflict tree, the debug request, and the target debug task corresponding to the debug request, the method further includes: Obtain a set of hardware devices, which includes multiple devices distributed hierarchically, and each device corresponds to at least one debugging task.

[0117] Based on the device hierarchy, each debugging task corresponding to each device is traversed sequentially from high to low to determine the multiple debugging tasks corresponding to the hardware device set in a sequential order.

[0118] A debugging conflict tree is established based on multiple sequentially arranged debugging tasks corresponding to the set of hardware devices and preset rules between each debugging task. The preset rules are used to characterize whether each debugging task is allowed to be executed simultaneously or not under a preset debugging scenario.

[0119] In one optional embodiment, establishing a debugging conflict tree based on the sequentially arranged multiple debugging tasks corresponding to the hardware device set and the preset rules between each debugging task includes: Create the root node of the tree structure.

[0120] The tree structure is modified based on the current debugging task and the preset rules between each debugging task to obtain the target tree structure.

[0121] The next debugging task of the current debugging task is taken as the new current debugging task, and the target tree structure is taken as the new tree structure. The process returns to modify the tree structure based on the current debugging task and the preset rules between each debugging task to obtain the target tree structure and subsequent operations. This process continues until the tree structure is modified based on the last debugging task and the preset rules between each debugging task to obtain the target tree structure. The target tree structure is then determined as the debugging conflict tree.

[0122] In one optional embodiment, modifying the tree structure based on the current debugging task and preset rules between debugging tasks to obtain the target tree structure includes: Traverse from the root node to the leaf node of the tree structure.

[0123] If the current debugging task and the debugging tasks associated with the current node are not allowed to be executed simultaneously and have no dependencies, then the current debugging task is associated with the current node to obtain the target tree structure.

[0124] If the current debugging task and at least one debugging task associated with the current node are not allowed to be executed simultaneously and have a dependency relationship, then determine whether the current node contains child nodes.

[0125] If the current node does not contain child nodes, a first node is created as a child node of the current node, and the current debugging task is associated with the first node to obtain the target tree structure.

[0126] If the current node contains child nodes, then determine whether the current debugging task and each debugging task associated with the child nodes of the current node are allowed to be executed simultaneously.

[0127] If the current debugging task and the debugging tasks associated with the child nodes of the current node are allowed to be executed simultaneously, then a second node is created as a child node of the current node, and the current debugging task is associated with the second node to obtain the target tree structure.

[0128] If the current debugging task and a debugging task associated with a child node of the current node are not allowed to be executed simultaneously, then the child node associated with the debugging task that is not allowed to be executed simultaneously with the current debugging task is taken as the third node, and the current debugging task is associated with the third node to obtain the target tree structure.

[0129] If the current debugging task and the debugging tasks associated with each node in the tree structure are allowed to be executed simultaneously, a fourth node is created as a child node of the root node, and the current debugging task is associated with the fourth node to obtain the target tree structure.

[0130] This method can be used to establish a debugging conflict tree based on the hierarchical relationship of each device in the hardware device cluster and the preset rules between each debugging task corresponding to each device.

[0131] An example, a hardware device set such as Figure 3 As shown, the hardware device set includes download cables (Cable1 and Cable2), field-programmable gate arrays (FPGA1 and FPGA2), central processing units (CPU1 and CPU2), and DebugCore1 and DebugCore2. The download cables support download frequency setting debugging; the FPGAs support four debugging functions: bitstream download, bitstream readback, system reset, and status register reading; the DebugCore is a soft core for FPGA debugging, supporting waveform capture debugging, and is only present in FPGAs running DebugCore bitstreams.

[0132] based on Figure 3 The debug conflict tree, established by the preset rules between the set of hardware devices and the debug tasks corresponding to each device, is shown below. Figure 4 As shown. Figure 4Each node, except the root node, is named according to its associated debugging task. Since parallel execution of FPGA bitstream download and system reset can cause conflicts, it exists as an FPGA bitstream configuration node (equivalent to an FPGA bitstream configuration node being associated with two debugging tasks: bitstream download and system reset). Figure 4 (The debug tasks associated with each node are not shown in the diagram.) DebugCore depends on the FPGA's bitstream; therefore, the DebugCore node is a child node of the FPGA bitstream configuration node (equivalent to the DebugCore node being associated with the waveform capture debug task). Bitstream readback depends on the FPGA's bitstream, and the bitstream readback node is a child node of the FPGA bitstream configuration node (equivalent to the bitstream readback node being associated with the bitstream readback debug task). The FPGA status register read node, FPGA bitstream configuration node, CPU node, and download cable node are all child nodes of the root node.

[0133] For an example, please refer to Figure 8 This illustrates the workflow of a debugger system, including steps S801 to S804.

[0134] Step S801: Sweep the chain to construct and debug the conflict tree.

[0135] Specifically, the hardware device set is scanned to obtain the hierarchical relationship of the hardware device set. Based on the hierarchical relationship of each device in the hardware device set and the preset rules between each debugging task corresponding to each device, a debugging conflict tree is established. For details, please refer to the aforementioned embodiments, which will not be repeated here.

[0136] Step S802: Interface presentation.

[0137] Client-side interface.

[0138] Step S803: Is there an event?

[0139] If an event occurs, it is handled; otherwise, the user interface is returned. This can be understood as the event representing a debug request. The system checks if a debug request exists; if so, it is handled; otherwise, the client interface is displayed.

[0140] Step S801: Handle the event.

[0141] The event handling process includes handling debug request processing and server-returned data processing. If a debug request is requested, it is processed. The client executes the aforementioned data processing methods based on the debug request. If the debug request is allowed, it is transmitted to the server. The server executes the target debug task based on the debug request and returns the target data to the corresponding target channel upon completion of the target debug task. After the event processing is complete, the event exits, indicating that the event processing is finished, and the processing result (i.e., the target data) is presented to the client interface. If the debug request is not allowed, the processing result (feedback information indicating that the debug request could not be executed) is presented to the client interface.

[0142] The debugger system features a simple workflow, requiring only a single event loop and having low deployment environment requirements. It can be implemented on various operating systems and even in single-core embedded hardware environments with only interrupt capabilities. The processing flow employs a data and interface separation design philosophy and front-end / back-end separation technology to better facilitate user interface presentation and user operation processing. This ensures that user actions are quickly responded to by the hardware device, and that the hardware device status is promptly displayed on the interface, achieving a complete and clear data flow.

[0143] This application uses a single-threaded event loop to respond to concurrent debugging requests, which reduces logical complexity and simplifies the deployment of debugger clients while ensuring functionality.

[0144] For an example, please refer to Figure 9 It illustrates the workflow of a debugger system, including steps S901 to S911.

[0145] Step S901: Sweep the chain to construct and debug the conflict tree.

[0146] Step S902: Present the interface.

[0147] Step S903: Obtain a debug request.

[0148] Debug requests are obtained based on user-input data or automated scripts.

[0149] Step S904: Locate the target node.

[0150] Based on the debugging request, the target debugging task corresponding to the debugging request is determined, and the node associated with the target debugging task in the debugging conflict tree is taken as the target node.

[0151] Step S905: Traverse the target node and its ancestor nodes, and check for debug events.

[0152] Iterate through the target node and all debugging tasks associated with its ancestor nodes, and determine whether there is a debugging task currently being executed among the target node and its ancestor nodes. If there is a debugging task currently being executed, then the target debugging task is determined to be not allowed to be executed. If there is no debugging task currently being executed, proceed to the next step.

[0153] Step S906: Traverse the subtree, check for debug events, and return to the idle channel.

[0154] Iterate through all the debugging tasks associated with the descendant nodes of the target node, and determine whether there is a debugging task being executed among the debugging tasks associated with the descendant nodes of the target node. If there is a debugging task being executed, the target debugging task is determined to be not allowed to be executed. If there is no debugging task being executed, the target debugging task is determined to be allowed to be executed, return to the idle channel, and proceed to the next step.

[0155] Step S907: Register a callback function for the channel.

[0156] Register a callback function for the channel. Each time the callback function receives the target data returned by the server, it will update the data in the debug conflict tree based on the target data.

[0157] Step S908: Send request data to the server through the idle channel.

[0158] Step S909: Check if the returned data has been received.

[0159] Step S910: Receive the returned data.

[0160] Step S911: Update the interface.

[0161] The returned data is the target data. If the target data returned by the server is received, the target data will be updated on the interface. The debugger system operates on a blocking execution mode. The client will wait until the server returns a result before exiting the task processing context. The blocking execution mode is suitable for application scenarios where the client's debugging operations involve a series of subtasks that need to be executed sequentially or script-based debugging operations.

[0162] One example is registering a callback function with a channel, sending a debug request through the channel, and continuously polling for callback function events. If a callback function event occurs, the target data corresponding to the debug request is output and displayed; otherwise, the polling continues to check for callback function events.

[0163] For an example, please refer to Figure 10 This illustrates the workflow of a debugger system, including steps S1001 to S1008.

[0164] Step S1001: Sweep the chain to construct and debug the conflict tree.

[0165] Step S1002: Present the interface.

[0166] Step S1003: Obtain a debug request.

[0167] Debug requests are obtained based on user-input data or automated scripts.

[0168] Step S1004: Locate the target node.

[0169] Based on the debugging request, the target debugging task corresponding to the debugging request is determined, and the node associated with the target debugging task in the debugging conflict tree is taken as the target node.

[0170] Step S1005: Traverse the target node and its ancestor nodes, and check for any debug events.

[0171] Iterate through the target node and all debugging tasks associated with its ancestor nodes, and determine whether there is a debugging task currently being executed among the target node and its ancestor nodes. If there is a debugging task currently being executed, then the target debugging task is determined to be not allowed to be executed. If there is no debugging task currently being executed, proceed to the next step.

[0172] Step S1006: Traverse the subtree, check for debug events, and return to the idle channel.

[0173] Iterate through all the debugging tasks associated with the descendant nodes of the target node, and determine whether there is a debugging task being executed among the debugging tasks associated with the descendant nodes of the target node. If there is a debugging task being executed, the target debugging task is determined to be not allowed to be executed. If there is no debugging task being executed, the target debugging task is determined to be allowed to be executed, return to the idle channel, and proceed to the next step.

[0174] Step S1007: Register a callback function for the channel.

[0175] Register a callback function for the channel. Each time the callback function receives data, it will also update the data in the debug operation tree.

[0176] Step S1008: Send request data to the server through the idle channel.

[0177] It should be noted that if the target data is not received from the server, the interface will be returned to its previous state. If the target data is received, it will be updated on the interface. The debugger system operates on a non-blocking execution mode, which allows multiple requests to be sent consecutively. The client does not need to wait for the previous debugging task to complete, and user requests from the client do not require blocking processing. As long as the server can respond, multiple consecutive requests from the user on the client can be executed, supporting fully concurrent debugging scenarios.

[0178] One example is registering a callback function with a channel, sending a debug request through the channel, and continuing the interface presentation and event processing flow. When the channel receives the return data from the server, the callback function triggers the return result processing event. In the event processing flow, the client receives the return data and updates the backend and the interface.

[0179] This application proposes a tree-structured debug conflict tree to improve the efficiency of debug request processing, supports both blocking and non-blocking execution modes, meets diverse scenario requirements, and enhances the applicability of debugger clients.

[0180] An example, a debug conflict tree, such as Figure 4 As shown, each leaf node of the debug conflict tree is associated with a channel. The user needs to simultaneously acquire waveforms from DebugCore1 and DebugCore2 of FPGA1. The client constructs non-blocking waveform acquisition and debugging tasks, namely target debug task 1 (acquiring waveforms from DebugCore1 of FPGA1) and target debug task 2 (acquiring waveforms from DebugCore2 of FPGA1). First, target node 1 is determined based on target debug task 1 and the debug conflict tree. Based on target node 1, it is first determined whether there is a task being executed at the current node. Then, the ancestor and descendant nodes of target node 1 are traversed to check if there is a task being executed. If there are no conflicting tasks, an empty channel is found from the leaf node of the subtree as target channel 1. After registering a callback function for target channel 1, a command is sent to the server using target channel 1. Similarly, based on target debugging task 2, target node 2 is determined. Based on target node 2, it is first determined whether there is a task being executed on the current node. Then, the ancestor nodes and descendant nodes of target node 2 are traversed to check whether there is a task being executed. If there are no conflicting tasks, an empty channel is found from the leaf node of the subtree as target channel 2. After registering a callback function for target channel 2, a command is sent to the server using target channel 2. Because it is non-blocking execution, the two debugging tasks can be executed in parallel.

[0181] An example, a debug conflict tree, such as Figure 4As shown, each leaf node of the debug conflict tree is associated with a channel. A user wants to execute a script that first downloads a bitstream containing DebugCore1 and DebugCore2 to FPGA1, and then acquires waveforms from DebugCore1. For this sequential execution operation, the client first constructs the target debug task 1 (downloading the bitstream) in a blocking manner. Based on the target debug task 1, it determines the target node 1. Based on the target node 1, it first checks if there is a task currently being executed on the current node. Then, it traverses the ancestor and descendant nodes of the target node 1 to check if there are any tasks currently being executed. If there are no conflicting tasks, it finds an empty channel from the leaf nodes of the subtree as the target channel 1. After registering a callback function for the target channel 1, it uses the target channel 1 to send commands to the server. Because it is a blocking execution, the client waits for the server's result at the request context. After the target debugging task 1 is completed, the blocking execution target debugging task 2 (to acquire waveforms from DebugCore1) is constructed. Based on the target debugging task 2, the target node 2 is determined. Based on the target node 2, it is first determined whether there is a task being executed on the current node. Then, the ancestor and descendant nodes of the target node 2 are traversed to check if there is a task being executed. If there are no conflicting tasks, an empty channel is found from the leaf node of the subtree as the target channel 2. After registering a callback function for the target channel 2, the target channel 2 is used to send commands to the server. After the target channel 2 is completed, the script execution is finished.

[0182] An example, a debug conflict tree, such as Figure 4As shown, each leaf node of the debug conflict tree is associated with a channel. The user wants to perform waveform acquisition and debugging on FPGA1's DebugCore1, and simultaneously download a bit stream from FPGA1. The client constructs target debug task 1 (waveform acquisition on FPGA1's DebugCore1) and target debug task 2 (bit stream download from FPGA1). First, target node 1 is determined based on target debug task 1. Based on target node 1, it is first checked whether there is an ongoing task. Then, the ancestor and descendant nodes of target node 1 are traversed to check if there are any ongoing tasks. If there are no conflicting tasks, an empty channel is found from the leaf nodes of the subtree as target channel 1. After registering a callback function for target channel 1, commands are sent to the server using target channel 1. Based on target debugging task 2, target node 2 is determined. Based on target node 2, it is first determined whether there is a task being executed on the current node. Then, the ancestor nodes and descendant nodes of target node 2 are traversed to check whether there is a task being executed. If a conflict is detected between target debugging task 2 (FPGA1 bit stream download) and the currently executing target debugging task 1 (waveform acquisition of FPGA1's DebugCore1), then target debugging task 2 is refused to be executed. The client reports an error to the user indicating the reason for the conflict (because FPGA1 bit stream download and the currently executing waveform acquisition of FPGA1's DebugCore1 are not allowed to be executed simultaneously), thus preventing debugging conflicts.

[0183] An example, a debug conflict tree, such as Figure 4 As shown, the user needs to add a debug task for reading DebugCore information and a debug task for dynamic bitstream reconfiguration. Reading DebugCore information depends on downloading a bitstream containing the DebugCore. Reading DebugCore information and acquiring waveforms with DebugCore do not conflict and can be done in parallel; therefore, a sibling node for reading DebugCore information is added to all DebugCore nodes. Dynamic bitstream reconfiguration is a bitstream modification operation, so this debug task is associated with the FPGA bitstream configuration node. The updated debug conflict tree is shown in Figure 11. A new associated debug task (FPGA1 bitstream dynamic reconfiguration) is added to the FPGA1 bitstream configuration node. Figure 11 (The debugging tasks associated with each node are not shown in the figure). Two new sub-nodes have been added to the FPGA1 bitstream configuration node: “DebugCore1 Information Reading” and “DebugCore2 Information Reading”.

[0184] Therefore, in this embodiment of the application, if a new debugging task needs to be added, the position of the new debugging task in the debugging conflict tree is defined according to the dependency relationship between the debugging target of the newly added debugging task and other debugging operation targets. Only a local modification will be made to the debugging conflict tree, and the overall impact is small.

[0185] This invention proposes a single-threaded parallel debugging mechanism based on an event loop, which supports blocking and non-blocking execution to meet different event triggering scenarios and greatly enhance the role of the debugging conflict tree.

[0186] Please refer to Figure 12 This document illustrates a structural block diagram of a debugger system 1200 provided in an embodiment of this application. The debugger system 1200 may include one or more components: a client 1211, a server 1212, and a hardware device set 1213. The server 1212 is connected to both the client 1211 and the hardware device set 1213. The client 1211 includes a processor 12111 and a memory 12112. The memory 12112 stores one or more application programs configured to be executed by the processor 12111. These application programs are configured to perform the methods described in the foregoing method embodiments.

[0187] The processor 12111 may include one or more processing cores. The processor 12111 connects to various parts of the debugger system 1200 using various interfaces and lines, and performs various functions and processes data of the debugger system 1200 by running or executing instructions, programs, code sets, or instruction sets stored in the processor 12111, and by calling data stored in the processor 12111. Optionally, the processor 12111 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 12111 may integrate one or more of the following: a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and computer programs; the GPU is responsible for rendering and drawing the displayed content; and the modem is used for wireless communication. It is understood that the aforementioned modem may not be integrated into the processor 12111, but may be implemented using a separate communication chip. Specifically, the method described in the foregoing embodiments may be executed by one or more processors 12111.

[0188] In some implementations, processor 12111 may include random access memory (RAM) or read-only memory (ROM). Processor 12111 can be used to store instructions, programs, code, code sets, or instruction sets. Processor 12111 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for implementing at least one function, instructions for implementing the various method embodiments described below, etc. The data storage area may also store data created by the debugger system 1200 during use.

[0189] Please refer to Figure 13 This diagram illustrates a structural block diagram of a computer-readable medium provided in an embodiment of this application. The computer-readable medium 1300 stores program code that can be called by a processor to execute the methods described in the above method embodiments.

[0190] Computer-readable medium 1300 may be an electronic storage device such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, computer-readable medium 1300 includes non-transitory computer-readable storage medium. Computer-readable medium 1300 has storage space for program code 1310 that performs any of the method steps described above. This program code can be read from or written to one or more computer program products. Program code 1310 may be compressed, for example, in a suitable form.

[0191] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A data processing method, characterized in that, A client-side application for a debugger system, the debugger system further comprising a set of hardware devices connected to the client, the method comprising: Obtain the debug conflict tree, debug request, and target debug task corresponding to the debug request. The debug conflict tree is a tree structure established based on the hierarchical relationship of each device in the hardware device set and the preset rules between each debug task corresponding to each device. Each node in the debug conflict tree other than the root node is associated with at least one debug task. The preset rules are used to characterize whether each debug task is allowed to be executed simultaneously or not allowed to be executed simultaneously in a preset debug scenario. The target debug task belongs to the preset debug scenario. Based on the target debugging task and the working status of each debugging task associated with each node corresponding to the target node in the debugging conflict tree, it is determined whether the target debugging task is allowed to be executed or not. The working status of the debugging task includes being executed or not being executed.

2. The method according to claim 1, characterized in that, In the debugging conflict tree, any two debugging tasks associated with each node other than the root node are not allowed to be executed simultaneously and have no dependency relationship under the preset debugging scenario. Each debugging task associated with a child node in the debugging conflict tree depends on at least one debugging task associated with the parent node of that child node. Any debugging task associated with a child node in the debugging conflict tree and any debugging task associated with the parent node of that child node are not allowed to be executed simultaneously under the preset debugging scenario. Any debugging task associated with any two sibling nodes in the debugging conflict tree is allowed to be executed simultaneously under the preset debugging scenario.

3. The method according to claim 2, characterized in that, The process of determining whether the target debugging task is allowed or not allowed to be executed based on the target debugging task and the working status of each debugging task corresponding to each node associated with the target node in the debugging conflict tree includes: Each path that includes the target node is selected from each path formed by traversing from the root node to the leaf node and is then identified as the target path. The target debugging task is determined to be allowed or not allowed to be executed based on the working status of each debugging task associated with each node on the target path.

4. The method according to claim 3, characterized in that, The process of determining whether a target debugging task is allowed or not to be executed based on the working status of each debugging task associated with each node on the target path includes: If at least one of the nodes on the target path has a debugging task associated with it that is being executed, then the status of the target debugging task is determined to be not allowed to be executed. If none of the debugging tasks associated with each node on the target path have been executed, then the status of the target debugging task is determined to be allowed to execute.

5. The method according to claim 3, characterized in that, The process of determining whether a target debugging task is allowed or not to be executed based on the working status of each debugging task associated with each node on the target path includes: Determine whether there is a currently executing debugging task among the debugging tasks associated with the target node; If there is a debugging task being executed among the debugging tasks associated with the target node, then the status of the target debugging task is determined to be "not allowed to execute".

6. The method according to claim 5, characterized in that, Also includes: If none of the debugging tasks associated with the target node are executed, then the ancestor node of the target node is determined based on the target path; Determine whether there is a currently executing debugging task among the debugging tasks associated with the ancestor node; If there is a debugging task being executed among the debugging tasks associated with the ancestor node, then the state of the target debugging task is determined to be not allowed to be executed.

7. The method according to claim 6, characterized in that, Also includes: If none of the debugging tasks associated with the ancestor node are executed, then it is determined whether the target node contains descendant nodes based on the target path. If the target node does not contain descendant nodes, then the status of the target debugging task is determined to be allowed to execute.

8. The method according to claim 7, characterized in that, Also includes: If the target node contains descendant nodes, then determine whether there is a currently executing debug task among the debug tasks associated with the descendant nodes of the target node; If there is a debugging task being executed among the debugging tasks associated with the descendant nodes of the target node, then the status of the target debugging task is determined to be not allowed to be executed. If none of the debugging tasks associated with the descendant nodes of the target node have been executed, then the status of the target debugging task is determined to be allowed to be executed.

9. The method according to any one of claims 3-8, characterized in that, In the debug conflict tree, each node other than the root node is associated with an identifier, which indicates the debug task currently being executed among the multiple debug tasks associated with the corresponding node. Before determining whether the target debug task is allowed or not allowed to execute based on the working status of each debug task associated with each node on the target path, the method further includes: The working status of each debugging task associated with each node on the target path is determined based on the identifier associated with each node on the target path.

10. The method according to claim 1, characterized in that, The debugger system also includes a server, which is connected to both the client and the hardware device set. After determining whether the target debugging task is allowed or not allowed to execute based on the target debugging task and the working status of each debugging task corresponding to each node associated with the target node in the debugging conflict tree, the system further includes: If the target debugging task is in the state of being allowed to execute, determine the available target channel corresponding to the debugging request; The debugging request is sent to the server through the target channel, triggering the server to execute the target debugging task based on the debugging request and return the target data to the corresponding target channel upon completion of the target debugging task.

11. The method according to claim 10, characterized in that, After sending the debugging request to the server through the target channel, the process further includes: Determine whether the target channel has received the target data corresponding to the debugging request; If the target channel receives the target data corresponding to the debugging request, then the target data corresponding to the debugging request will be output and displayed. If the target channel does not receive the target data corresponding to the debugging request, return to the execution of determining whether the target channel has received the target data corresponding to the debugging request and subsequent steps.

12. The method according to claim 10, characterized in that, After sending the debugging request to the server through the target channel, the process further includes: Determine whether the target channel has received the target data corresponding to the debugging request; If the target channel receives the target data corresponding to the debugging request, then the target data corresponding to the debugging request will be output and displayed. If the target channel does not receive the target data corresponding to the debugging request, then determine whether a new debugging request has been received; If a new debugging request is received, the process returns to retrieve the debugging conflict tree, the debugging request, the target debugging task corresponding to the debugging request, and subsequent operations.

13. A debugger system, characterized in that, include: Client, server, and hardware device set; The server is connected to both the client and the set of hardware devices. The client includes a processor and a memory; The memory stores one or more applications configured to be executed by the processor, the one or more applications configured to perform the method as described in any one of claims 1-12.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains program code that can be invoked by a processor to execute the method as described in any one of claims 1-12.

Images