Redundancy debugging method and device, electronic equipment and storage medium

Abstract

The invention relates to a redundancy debugging method and device, electronic equipment and a storage medium, and the method comprises the steps: connecting a debugged target machine through redundancy debugging sessions in an upper computer, suspending all the redundancy debugging sessions after determining that multiple redundancy debugging sessions are successfully connected, and executing redundancy debugging processing on an issued debugging request. Firstly, a debugging request issued by a current active debugging session is intercepted, when it is determined that all redundancy debugging sessions are in normal states, the debugging request is issued to all the redundancy debugging sessions, and then a response result of a target machine responding to the debugging request is obtained; under the condition that all response results are normal, redundancy debugging processing is executed on the next debugging request, synchronous control over multiple redundancy debugging sessions on the same debugging interface is kept, the debugging mode of redundancy debugging is kept consistent with that of common single debugging, the use threshold is lowered, and the debugging efficiency is improved. And development personnel can be helped to improve the redundancy debugging efficiency.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer software, and particularly relates to a redundancy debugging method and device, electronic equipment and a storage medium. BACKGROUND

[0002] In the current mainstream embedded integrated development environment, only a single debugging session is supported by default for independent operation. If multiple debugging sessions are to be supported for synchronous operation, secondary development needs to be performed on the existing integrated development environment. However, in the current secondary development redundancy debugging implementation mode based on a proxy interface and a front-end interface display, the source code cannot be directly interacted with during debugging, and all debugging commands must be input through the front-end interface and then sent to the debugger for execution, which results in an inconvenient operation mode and requires the user to be familiar with the debugging commands, thereby increasing the use threshold. SUMMARY

[0003] The present application provides a redundancy debugging method and device, electronic equipment and a storage medium to solve the technical problem of how to keep the debugging mode of redundancy debugging consistent with ordinary single debugging and reduce the use threshold.

[0004] In a first aspect, the present application provides a redundancy debugging method, which comprises the following steps. determining multiple connected redundancy debugging sessions; wherein each redundancy debugging session corresponds to a target machine to be debugged; suspending all the redundancy debugging sessions and performing redundancy debugging processing on a debugging request sent; The redundancy debugging processing comprises the following steps. intercepting the debugging request sent by a current active debugging session; wherein the current active debugging session is an active session in all the redundancy debugging sessions; in a case where all the redundancy debugging sessions are in a normal state, sending the debugging request to all the redundancy debugging sessions; obtaining a response result of the target machine in response to the debugging request; in a case where all the response results are normal, performing the redundancy debugging processing on a next debugging request.

[0005] Optionally, determining multiple connected redundancy debugging sessions comprises the following steps. determining a target machine in a normal scanning state; configuring to-be-debugged information and a debugging port of the target machine; downloading the to-be-debugged information to the target machine through the debugging port; start a corresponding margin debugging session of the target machine, and connect the target machine based on the margin debugging session in a case that the target machine starts the to-be-debugged information successfully; determine all the margin debugging sessions connected successfully with the corresponding target machine.

[0006] Optionally, after downloading the to-be-debugged information to the target machine through the debugging port, the method further comprises: obtaining download failure information, wherein the download failure information is used to indicate that the to-be-debugged information fails to be downloaded to the target machine; outputting the download failure information and exiting margin debugging; and / or, obtaining start failure information, wherein the start failure information is used to indicate that starting the corresponding margin debugging session of the target machine fails; outputting the start failure information and exiting margin debugging.

[0007] Optionally, intercepting the debugging request issued under the current active debugging session comprises: obtaining an operation instruction in the current active debugging session of the host computer debugging interface; generating the debugging request based on the operation instruction; intercepting the debugging request through an interceptor.

[0008] Optionally, intercepting the debugging request through an interceptor comprises: starting an asynchronous request lock; intercepting the debugging request through an interceptor in a process that the asynchronous request lock is opened, and judging whether there is an unprocessed response in the margin debugging session or not; if there is the unprocessed response in any of the margin debugging sessions, the margin debugging session without the unprocessed response enters a suspended waiting state until the margin debugging session with the unprocessed response processes the unprocessed response is completed; in a case that the margin debugging session processes the unprocessed response is completed, closing the asynchronous request lock.

[0009] Optionally, in a case that all the margin debugging sessions are in a normal state, issuing the debugging request to all the margin debugging sessions comprises: in a case that all the margin debugging sessions are in a normal state, issuing the debugging request to all the margin debugging sessions through broadcasting.

[0010] Optionally, in a case that all the response results are normal, performing the multiple margin debugging processing on a next debugging request comprises: determining whether the response results are normal; in the case that any of the response results is abnormal, ending all the redundancy debugging sessions; in the case that all the response results are normal, determining whether the to-be-debugged information of the target machine is executed completely; in the case that the to-be-debugged information is not executed completely, performing the multi-redundancy debugging processing on a next debugging request; in the case that the to-be-debugged information is executed completely, ending the redundancy debugging.

[0011] In a second aspect, the present application provides a multi-redundancy debugging device, the device comprising: a determining module, configured to determine a plurality of successfully connected redundancy debugging sessions; wherein each of the redundancy debugging sessions corresponds to a to-be-debugged target machine; a debugging processing module, configured to suspend all the redundancy debugging sessions and perform multi-redundancy debugging processing on a debugging request issued; wherein the multi-redundancy debugging processing comprises: intercepting the debugging request issued by a current active debugging session; wherein the current active debugging session is an active session in all the redundancy debugging sessions; in the case that all the redundancy debugging sessions are in normal state, issuing the debugging request to all the redundancy debugging sessions; obtaining response results of the target machine in response to the debugging request; in the case that all the response results are normal, performing the multi-redundancy debugging processing on a next debugging request.

[0012] In a third aspect, the present application provides an electronic device, comprising a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete communication with each other through the communication bus; the memory, configured to store a computer program; the processor, configured to execute the program stored on the memory, to realize the multi-redundancy debugging method of any one of the embodiments of the first aspect.

[0013] In a fourth aspect, the present application provides a computer readable storage medium, having a computer program stored thereon, wherein the computer program is executed by a processor to realize the multi-redundancy debugging method of any one of the embodiments of the first aspect.

[0014] Compared with the prior art, the technical solution provided by the embodiments of the present application has the following advantages: the method provided by the embodiments of the present application determines multiple successful connection margin debugging sessions; each margin debugging session corresponds to a target machine to be debugged; all margin debugging sessions are suspended, and multiple margin debugging processing is performed on the debugging request issued; the multiple margin debugging processing includes: intercepting the debugging request issued by the current active debugging session; the current active debugging session is an active session in all margin debugging sessions; in the case that all margin debugging sessions are in a normal state, the debugging request is issued to all margin debugging sessions; the response result of the target machine in response to the debugging request is obtained; in the case that all response results are normal, the next debugging request is subjected to multiple margin debugging processing. The method connects the target machine to be debugged through the margin debugging session in the host computer, each margin debugging session corresponds to a target machine to be debugged, and all margin debugging sessions are suspended after it is determined that multiple margin debugging sessions are successfully connected. The multiple margin debugging processing is performed on the debugging request issued. Specifically, during the multiple margin debugging processing, the debugging request issued by the current active debugging session is first intercepted to prevent the debugging request from being directly executed in the current active debugging session. When it is determined that all margin debugging sessions are in a normal state, the debugging request is issued to all margin debugging sessions, so that one debugging request is synchronously distributed to all margin debugging sessions. Next, the response result of the target machine in response to the debugging request is obtained. Since the responses among the multiple margin debugging sessions are different due to external factors such as network environment and hardware device, the next debugging request is subjected to multiple margin debugging processing in the case that all response results are normal. The synchronous control of the multiple margin debugging sessions in the same debugging interface is maintained, the debugging mode of the multiple margin debugging is consistent with the ordinary single debugging, the use threshold is reduced, and the development personnel can improve the multiple margin debugging efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0015] The accompanying drawings, which are incorporated into and form a part of the specification, illustrate preferred embodiments consistent with the present application and, together with the description, serve to explain the principles of the application.

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or the prior art description will be briefly introduced. Obviously, for those skilled in the art, other drawings can also be obtained without creative labor based on these drawings.

[0017] One or more embodiments are exemplarily illustrated by the pictures in the drawings corresponding thereto, and these exemplary illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, unless otherwise specified. The drawings in the drawings do not constitute a proportional limitation.

[0018] Figure 1 A system architecture diagram of a redundancy debugging method provided for an embodiment of the present application is provided. Figure 2 A flowchart of a redundancy debugging method provided for an embodiment of the present application is provided. Figure 3 A schematic diagram of a redundancy debugging connection establishment provided for an embodiment of the present application is provided. Figure 4 A flowchart of a redundancy debugging processing execution provided for an embodiment of the present application is provided. Figure 5 A structural schematic diagram of a redundancy debugging device provided for an embodiment of the present application is provided. Figure 6 A structural schematic diagram of an electronic device provided for an embodiment of the present application is provided. DETAILED DESCRIPTION

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described below in connection with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0020] The following disclosure provides many different embodiments, or examples, for implementing different structures of the present application. For the purpose of simplicity, the components and arrangements of the examples, which have been described find below, are shown in only one of the various implementations. Of course, they can be arranged in a different manner than depicted and parameters can be scaled differently, and the omission of specific

[0021] In the current mainstream embedded integrated development environments such as Eclipse and VS Code, only a single debugging session is supported by default for independent operation. If multiple debugging sessions are to be supported for synchronous operation, secondary development needs to be performed on the existing integrated development environment.

[0022] The current redundancy technology is mainly divided into three ways in architecture: physical isolation, logical isolation, and hybrid isolation. 1. Physical isolation: Independent deployment using different hardware, each redundancy algorithm corresponds to a set of independent physical hardware system. Commonly used in high security flight control system (such as civil aviation passenger plane, military fighter) preferred solution, even if a set of physical hardware system fails, other systems can work normally, can avoid hardware failure, but the deployment cost is higher.

[0023] 2. Logical isolation: Using the same hardware multi-core deployment, realizing redundancy through software logical isolation, running different redundancy algorithms in different cores of a single processor chip. Commonly used in low security level industrial drones, which are less expensive but cannot resist hardware failure.

[0024] 3. Hybrid isolation: Physical isolation + logical isolation mixed deployment, that is, each physical template contains multiple logical isolation, and each physical module uses dual-core design (logical level redundancy) internally, and the cores are synchronized through internal bus.

[0025] Redundancy is commonly used in high security scenarios and multi-decision systems, such as in the field of automotive electronic automatic driving, which can use redundancy architecture to ensure computing consistency and security. For example, in high security level automatic driving, a dual redundancy architecture can be used, which uses two systems to share radar, camera and other sensor data, where the main controller participates in the main calculation, and the standby controller participates in the operation in real time background, and the results of the two must be completely consistent before execution; And when the main controller fails, the standby controller can take over seamlessly in a short time, thereby improving its security performance.

[0026] However, in the current mainstream embedded integrated development environment for debugging multiple redundancies, only a single debugging session can be operated at the same time, which can be simply regarded as a one-to-one debugging operation. In some multiple redundancy debugging implementation methods based on proxy interface and front-end interface display, although a debugging interface is displayed on the host computer and can control the debugged program on multiple homogeneous target machines, all debugging commands must be input through the front-end interface and sent to the debugger for execution during debugging. It cannot be operated at the source code level, such as adding a breakpoint at a specified line in the integrated development environment, but needs to input the specified debugging command in the interface (such as break main: 10 command to break the point operation), which is not user-friendly, does not support assembly debugging, and uses text as the output format, which is not conducive to observing the difference between different debugging sessions, which makes the operation method extremely inconvenient and requires users to be familiar with debugging commands, with a high threshold.

[0027] To solve the technical problem of how to keep the debugging mode of the multiple-redundancy debugging consistent with the ordinary single debugging and reduce the use threshold in the prior art, the application provides a multiple-redundancy debugging method and device, an electronic device, and a storage medium, which can keep the synchronous control of multiple-redundancy debugging sessions in the same debugging interface, keep the debugging mode of the multiple-redundancy debugging consistent with the ordinary single debugging, reduce the use threshold, and help developers improve the multiple-redundancy debugging efficiency.

[0028] The first embodiment of the application provides a multiple-redundancy debugging method, which can be applied to a system architecture as shown in the figure. Figure 1 The system architecture includes at least a host computer 101 and a target computer 102, wherein the target computer 102 can be multiple, and the specific number is not limited. After the host computer 101 and the target computer 102 establish a communication connection, the host computer 101 can simultaneously perform multiple-redundancy debugging on multiple target computers 102.

[0029] The method can be applied to the host computer 101 in the system architecture. Next, based on the system architecture, the multiple-redundancy debugging method is described in detail as follows. Figure 2 The multiple-redundancy debugging method includes the following steps. Step 201: Determine multiple connected-redundancy debugging sessions; wherein each redundancy debugging session corresponds to a target computer to be debugged.

[0030] In the embedded or cross-platform development scenario, the host computer can be used for development, and the target computer can be used for running. In this scenario, the host computer is responsible for developing and compiling programs, and the programs usually need to run in a target environment. When debugging is needed, the GDB+GDBServer mode is usually used for remote debugging. GDB is a general C / C++ debugger, which is a bottom-level debugger for debugging C / C++ language and runs on the host computer, and is responsible for interacting with the remote GDBServer. GDBServer is a remote debugging auxiliary tool, which runs in the target computer and is used to cooperate with GDB to realize remote debugging. GDB connects the GDBServer in the target computer, and each GDB connection to the GDBServer in the target computer corresponds to a redundancy debugging session in the host computer. Subsequently, all operations can be sent by GDB, and GDBServer is responsible for executing the debugging command to generate a response result.

[0031] In the following embodiments of the application, the embedded integrated development environment is taken as an example of VS Code, and in the host computer, the Intewell Developer, the C++ development tool suite (cpp-tools), the machine interface engine (MI Engine), and GDB can be included. The Intewell Developer is based on the secondary development of VS Code and is a native integrated development environment that supports the development of the Intewell operating system throughout the entire process. The cpp-tools are C / C++ support plug-ins officially released by Microsoft, which include code intelligence, code refactoring, debugging, and many other functions. Here, the cpp-tools are mainly used as a debugger support. The MI Engine is a protocol implementation layer of the cpp-tools debugging adapter, which encapsulates the underlying interface of different debuggers (gdb, lldb) and provides a unified MI protocol debugging interface upward. In the target computer, the GDBServer and the debugging information to be debugged are configured, and the debugging information to be debugged can also be referred to as an application program to be debugged, which is a program running on the target computer after debugging is completed.

[0032] In one embodiment, the multiple connection-successful redundancy debugging sessions are determined, including: determining the target computer in a normal scanning state; configuring the debugging information to be debugged and the debugging port of the target computer; downloading the debugging information to be debugged to the target computer through the debugging port; starting the redundancy debugging session corresponding to the target computer in the case that the target computer starts the debugging information to be debugged successfully, and connecting the target computer based on the redundancy debugging session; and determining all redundancy debugging sessions connected to the corresponding target computer successfully.

[0033] In this embodiment, the Intewell Developer scans the target computer to determine the target computer in a normal scanning state, and then configures the redundancy, that is, configures the debugging information to be debugged (such as a program to be debugged) and the debugging interface of the target computer. After the configuration is completed, the debugging information to be debugged is downloaded to the target computer through the debugging interface. After the downloading is completed, the remote target computer starts the GDBServer to load the debugging information to be debugged. After the GDBServer successfully loads the debugging information to be debugged, a redundancy debugging session is started in the host computer to connect the target computer. It should be understood that after a plurality of GDBServers are successfully started, the same number of redundancy debugging sessions are started in the host computer. Next, the multiple redundancy debugging can be performed based on all redundancy debugging sessions connected to the corresponding target computer successfully.

[0034] To ensure that the multiple redundancy debugging is successfully performed, termination mechanisms can be designed for abnormal situations in the debugging process, such as redundancy debugging exit after a download failure and redundancy debugging exit after a start failure.

[0035] In one embodiment, after the to-be-debugged information is downloaded to the target machine through the debugging port, the method further comprises: obtaining download failure information; wherein the download failure information is used to indicate that the to-be-debugged information fails to be downloaded to the target machine; outputting the download failure information and exiting the redundancy debugging; and / or obtaining startup failure information; wherein the startup failure information is used to indicate that the redundancy debugging session corresponding to the target machine fails to be started; outputting the startup failure information and exiting the redundancy debugging.

[0036] In this embodiment, when the debugging information fails to be downloaded to the target machine, the download failure information can be generated, and the host computer can report an error based on the download failure information and exit the redundancy debugging. When the redundancy debugging session corresponding to the target machine fails to be started in the host computer, the startup failure information can be generated, and the host computer can report an error based on the startup failure information and exit the redundancy debugging. After the repair is adjusted, the redundancy debugging can be restarted.

[0037] In one specific embodiment, a schematic diagram of connection establishment of the redundancy debugging is as shown in Figure 3 , comprising: Step 301, starting; Step 302, scanning the target machine; Step 303, configuring redundancy; configuring the to-be-debugged program and the debugging interface to the target machine; Step 304, downloading the program to the corresponding target machine; downloading the to-be-debugged program to the corresponding target machine through the debugging interface; Step 305, judging whether the downloading is successful; if the downloading is successful, executing step 306, and if the downloading fails, executing step 310; Step 306, the target machine starting the GDBserver to load the to-be-debugged program; Step 307, judging whether the starting is successful; if the starting is successful, executing step 308, and if the starting fails, executing step 310; Step 308, the host computer starting a plurality of debugging session connections to the GDBserver; Step 309, successful connection, all debugging sessions are suspended; Step 310, ending.

[0038] In the stage of establishing connection in the multiple-redundancy debugging, first, the Intewell Developer scans the available target machine, configures the redundancy to the target machine, that is, configures the program to be debugged and the debugging interface, then downloads the program to be debugged to the corresponding target machine through the debugging interface, the host computer judges whether the downloading is successful, if the downloading is successful, the target machine starts the GDBserver to load the program to be debugged, if the downloading fails, an error is reported and the process is exited, after the multiple-redundancy GDBserver is successfully started, the host computer starts the same number of debugging sessions to establish connection, if the starting fails, an error is reported and the process is exited, after the connection is successful, all the multiple-redundancy debugging sessions are in a suspended state, waiting for the user operation.

[0039] In step 202, all the multiple-redundancy debugging sessions are suspended, and the multiple-redundancy debugging processing is performed on the debugging request issued. The multiple-redundancy debugging processing includes: intercepting the debugging request issued by the current active debugging session; the current active debugging session is an active session in all the multiple-redundancy debugging sessions; in the case that all the multiple-redundancy debugging sessions are in a normal state, issuing the debugging request to all the multiple-redundancy debugging sessions; obtaining the response result of the target machine in response to the debugging request; in the case that all the response results are normal, performing the multiple-redundancy debugging processing on the next debugging request.

[0040] The method connects the target machine to be debugged through the multiple-redundancy debugging sessions in the host computer, each of the multiple-redundancy debugging sessions corresponds to a target machine to be debugged, after it is determined that the multiple-redundancy debugging sessions are all successfully connected, all the multiple-redundancy debugging sessions are suspended, and the multiple-redundancy debugging processing is performed on the debugging request issued. Specifically, in the multiple-redundancy debugging processing, first, the debugging request issued by the current active debugging session is intercepted, to prevent the debugging request from being directly executed in the current active debugging session, in the case that all the multiple-redundancy debugging sessions are in a normal state, the debugging request is issued to all the multiple-redundancy debugging sessions, to realize that one debugging request is synchronously distributed to all the multiple-redundancy debugging sessions, then the response result of the target machine in response to the debugging request is obtained, since the responses between the multiple-redundancy debugging sessions are different due to the external factors such as network environment and hardware device, in the case that all the response results are normal, the multiple-redundancy debugging processing is performed on the next debugging request, to keep the synchronous control of the multiple-redundancy debugging sessions in the same debugging interface, to realize the debugging mode of the multiple-redundancy debugging, which is consistent with the ordinary single debugging, to reduce the use threshold, and to help the developer to improve the multiple-redundancy debugging efficiency.

[0041] In one embodiment, the intercepting the debugging request issued by the current active debugging session includes: obtaining an operation instruction in the current active debugging session in the debugging interface of the host computer; generating the debugging request based on the operation instruction; and intercepting the debugging request through an interceptor.

[0042] In the embodiment, when the cpp-tools starts multiple debugging sessions, only one of the multiple debugging sessions can be operated in the debugging view, and the operated debugging session can be referred to as a current active debugging session, and the other debugging sessions can be referred to as inactive debugging sessions. The user can manually perform a switching operation of the debugging sessions according to needs. An operation instruction of the user in the current active debugging session of the host debugging interface can be acquired, and a debugging request can be generated based on the operation instruction. In order to realize synchronous operation of the multiple debugging sessions, the operation of the current active debugging session should be synchronized to the other inactive debugging sessions. In order to prevent the debugging request from being directly executed in the current active debugging session, the debugging request can be intercepted by an interceptor.

[0043] In one embodiment, the debugging request is intercepted by the interceptor, including: starting an asynchronous request lock; in a process in which the asynchronous request lock is opened, the debugging request is intercepted by the interceptor, and it is judged whether there is an unprocessed response in the debugging session; if there is an unprocessed response in any debugging session, the debugging session in which there is no unprocessed response enters a suspended waiting state until the debugging session in which there is an unprocessed response processes the unprocessed response; and in the case where the debugging session processes the unprocessed response, the asynchronous request lock is closed.

[0044] In the embodiment, the responses of the multiple debugging sessions are limited by network environment, hardware devices and other factors, and the time of the responses is not synchronized. The responses of the debugging sessions can be uniformly processed based on the asynchronous request lock. In the process in which the asynchronous request lock is opened, the debugging request is intercepted by the interceptor, and it is judged whether there is an unprocessed response in the debugging session. If there is an unprocessed response in any debugging session, the other debugging session in which there is no unprocessed response enters a suspended waiting state until the debugging session in which there is an unprocessed response processes the unprocessed response. At this time, the asynchronous request lock is closed.

[0045] In one embodiment, in the case where all the debugging sessions are in a normal state, the debugging request is sent to all the debugging sessions, including: in the case where all the debugging sessions are in a normal state, the debugging request is sent to all the debugging sessions by broadcasting.

[0046] In the embodiment, the debugging request has been intercepted and processed in the interceptor. The intercepted debugging request can be distributed to all the debugging sessions by a request distributor. Specifically, in the case where all the debugging sessions are in a normal state, the debugging request can be distributed to all the debugging sessions by the request distributor in the form of broadcasting, so that synchronous control of the multiple debugging sessions in the same debugging interface is realized.

[0047] In one embodiment, when all response results are normal, the redundancy debugging process is performed on the next debugging request, including: judging whether the response results are normal; in the case that any response result is abnormal, ending all redundancy debugging sessions; in the case that all response results are normal, judging whether the to-be-debugged information of the target machine is executed; in the case that the to-be-debugged information is not executed, performing the redundancy debugging process on the next debugging request; and in the case that the to-be-debugged information is executed, ending the redundancy debugging.

[0048] In the embodiment, when the debugging request is issued through broadcasting, the asynchronous request lock can be opened, during which the response completed redundancy debugging session is suspended and waits, and during which other debugging requests are intercepted by the interceptor and cannot be normally issued, for example, a prompt of "current operation is waiting" can be given. When all debugging requests are normally responded, the asynchronous request lock is released, and the debugging operation can be normally performed. When the response result of one of the redundancy debugging sessions is abnormal, all redundancy debugging sessions are terminated. In this way, the synchronization in response processing can be realized. In the case that all response results are normal, whether the to-be-debugged information of the target machine is executed can be judged. If the to-be-debugged information is not executed, the redundancy debugging process is re-installed and performed on the next debugging request. After the to-be-debugged information is executed, the redundancy debugging is ended. Through the embodiment, the synchronous control of multiple redundancy debugging sessions in the same debugging interface can be realized. In the embodiment, the debugging mode of the redundancy debugging is consistent with the ordinary single debugging, the use threshold is reduced, and the efficiency of the redundancy debugging of the developer can be improved.

[0049] In one specific embodiment, a flowchart of performing the redundancy debugging process is as shown in Figure 4 , including: Step 401, debugging is suspended and waits; Step 402, the debugging interface performs an operation to generate a debugging request; Step 403, the debugging request is issued; Step 404, the debugging request is intercepted by the interceptor; Step 405, whether there is an unprocessed response; if yes, step 406 is performed, and if no, step 408 is performed; Step 406, response processing is suspended and waits; Step 407, whether all responses are normal is judged; if yes, step 402 is performed, and if no, step 412 is performed; Step 408, the debugging request is broadcasted to all redundancy debugging sessions; Step 409, response processing is performed; Step 410, whether all responses are normal is judged; if yes, step 411 is performed, and if no, step 412 is performed; Step 411, judge whether the program to be debugged is executed; if yes, execute step 412, if no, execute step 402; Step 412, end.

[0050] In the embodiment, in the state of suspending all debugging sessions, the user can perform operations in the debugging interface, such as next operation, continue operation, and the like, generate a debugging request based on the operation of the user, or the operation of the user itself is the debugging request, such as input instruction, and the like, the debugging request is issued by the background, the request interceptor intercepts the debugging request, and the debugging request is prohibited from being issued to the current active debugging session. Next, it is judged whether there is an unprocessed response, if there is a debugging session that has not responded, it is suspended and waits for the response result, otherwise the current debugging request is broadcasted and issued to all redundant debugging sessions. When all debugging response states are normal, the user can continue to perform the debugging operation; when one of the debugging sessions responds abnormally, all debugging sessions are ended. After the debugging request is issued to all remote debugging sessions by broadcasting, unified response processing is performed, and then it is judged whether all responses are normal, if there is an exception, all debugging sessions are directly ended, and if it is normal, the next step is judged, that is, whether the program to be debugged is executed, if yes, all debugging sessions are normally ended, otherwise the user continues to operate the debugging session.

[0051] In the above embodiments of the present application, by modifying the debugging plug-in in VS Code, that is, secondary development of cpp-tools and MI Engine, such as development of request interceptor, request distributor and unified response processing of multiple redundant debugging sessions, synchronous control of multiple redundant debugging sessions in the same debugging interface can be maintained, the debugging mode of multiple redundant debugging is consistent with the ordinary single debugging, source code level breakpoint is supported, the use threshold is reduced, and the efficiency of multiple redundant debugging of the developer is improved.

[0052] Based on the same technical concept, the second embodiment of the present application provides a multiple-redundancy debugging device, such as Figure 5 The device comprises: A determination module 501 is configured to determine multiple redundant debugging sessions that are successfully connected; wherein each redundant debugging session corresponds to a target machine to be debugged. The debugging processing module 502 is configured to suspend all the redundancy debugging sessions, and perform redundancy debugging processing on the debugging request issued; wherein, the redundancy debugging processing comprises: intercepting the debugging request issued by a current active debugging session; wherein, the current active debugging session is an active session in all the redundancy debugging sessions; in the case that all the redundancy debugging sessions are in a normal state, issuing the debugging request to all the redundancy debugging sessions; obtaining response results of the target machine in response to the debugging request; in the case that all the response results are normal, performing the redundancy debugging processing on a next debugging request.

[0053] The device connects the target machine to be debugged through the redundancy debugging sessions in the host computer, each redundancy debugging session corresponds to a target machine to be debugged, and determines that the multiple redundancy debugging sessions are successfully connected, and then suspends all the redundancy debugging sessions, and performs redundancy debugging processing on the debugging request issued. Specifically, during the redundancy debugging processing, the debugging request issued by the current active debugging session is first intercepted to prevent the debugging request from being directly executed in the current active debugging session, and when it is determined that all the redundancy debugging sessions are in a normal state, the debugging request is issued to all the redundancy debugging sessions, so that one debugging request is synchronously distributed to all the redundancy debugging sessions. Next, the response results of the target machine in response to the debugging request are obtained. Since the responses among the multiple redundancy debugging sessions are different due to external factors such as network environment and hardware device, the redundancy debugging processing is performed on the next debugging request in the case that all the response results are normal, so that the synchronous control of the multiple redundancy debugging sessions in the same debugging interface is maintained, the debugging mode of the redundancy debugging is consistent with the ordinary single debugging, the use threshold is reduced, and the development personnel can improve the redundancy debugging efficiency.

[0054] As shown in Figure 6 The embodiment of the present application provides an electronic device, which comprises a processor 111, a communication interface 112, a memory 113 and a communication bus 114, wherein the processor 111, the communication interface 112 and the memory 113 complete mutual communication through the communication bus 114, The memory 113 is configured to store a computer program. In an embodiment of the present application, the processor 111 is configured to execute the program stored in the memory 113, and implement the redundancy debugging method provided in any one of the preceding method embodiments.

[0055] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For the convenience of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or only one type of bus.

[0056] The communication interface is used for communication between the terminal and other devices.

[0057] The memory can include a Random Access Memory (RAM) and can also include a non-volatile memory, such as at least one disk memory. Optionally, the memory can also be at least one storage device located away from the processor.

[0058] The processor mentioned above can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; can also be a Digital Signal Processing (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component.

[0059] The embodiment of the present application further provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to realize the redundancy debugging method provided by any one of the foregoing method embodiments.

[0060] The apparatus embodiments described above are only schematic, wherein the units shown as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place or distributed on a plurality of network units. According to actual needs, some or all of the modules can be selected to achieve the purpose of the embodiment scheme.

[0061] Those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a general hardware platform, and of course can be implemented by hardware. Based on such an understanding, the technical solutions described above essentially or in other words make contributions to the related art, and can be embodied in a software product form, which can be stored in a computer readable storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, and the like, and includes a plurality of instructions to cause a computer device (which can be a personal computer, a server, or a network device, and the like) to execute the methods described in each embodiment or some parts of the embodiments.

[0062] It is to be understood that the terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises", "comprising", "includes", "including" and "has" are inclusive and therefore specify the presence of stated features, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order in which they are described, unless specifically identified as an order dependent step. It is also to be understood that additional or alternative steps can be employed.

[0063] It should be understood that the specific embodiments described herein are merely exemplary and do not limit the application. In the description, the suffixes "module", "part" or "unit" used for components are merely intended for facilitation of the description and are not intended to have specific meanings or functions. Therefore, "module", "part" or "unit" can be mixedly used.

[0064] The above descriptions are only specific embodiments of the application to enable a person skilled in the art to understand or implement the application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the application. Therefore, the application will not be limited to these embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A redundancy adjustment method, characterized in that, The method includes: Multiple successful redundancy debugging sessions are identified; each redundancy debugging session corresponds to a target machine being debugged. Suspend all redundancy debugging sessions and perform redundancy debugging processing on the issued debugging requests; The redundancy adjustment process includes: Intercept the debugging request issued by the currently active debugging session; wherein, the currently active debugging session is the active session among all the redundancy debugging sessions; If all the redundancy debugging sessions are in normal status, the debugging request will be sent to all the redundancy debugging sessions. Obtain the response result of the target machine in response to the debugging request; If all the responses are normal, perform the redundant debugging process on the next debugging request.

2. The method according to claim 1, characterized in that, Identify multiple successful redundancy debugging sessions, including: Identify the target machine that is in a normal scanning state; Configure the target machine's debugging information and debugging port; The information to be debugged is downloaded to the target machine through the debugging port; If the target machine successfully starts the information to be debugged, start the redundancy debugging session corresponding to the target machine, and connect to the target machine based on the redundancy debugging session; Identify all redundant debugging sessions that have successfully connected to the corresponding target machine.

3. The method according to claim 2, characterized in that, After downloading the information to be debugged to the target machine through the debugging port, the method further includes: Obtain download failure information; wherein, the download failure information is used to indicate that the information to be debugged failed to be downloaded to the target machine; Output the download failure message and exit redundancy debugging; And / or, Obtain startup failure information; wherein, the startup failure information is used to indicate that the startup of the redundancy debugging session corresponding to the target machine failed; Output the startup failure information and exit redundancy debugging.

4. The method according to claim 1, characterized in that, Intercepting the debugging request issued by the currently active debugging session, including: Retrieve operation commands from the currently active debugging session in the host computer debugging interface; The debugging request is generated based on the operation instructions; The debugging request is intercepted using an interceptor.

5. The method according to claim 4, characterized in that, The debugging request is intercepted using an interceptor, including: Initiate asynchronous request lock; During the process of unlocking the asynchronous request lock, the debugging request is intercepted by an interceptor, and it is determined whether there are any unprocessed responses in the redundancy debugging session; If any of the aforementioned redundancy debugging sessions contains an unprocessed response, the redundancy debugging sessions without the unprocessed response will enter a suspended waiting state until the redundancy debugging sessions with the unprocessed response have completed processing the unprocessed response. Once the unprocessed response has been processed in the redundancy debugging session, the asynchronous request lock is closed.

6. The method according to claim 1, characterized in that, If all the aforementioned redundancy debugging sessions are in normal status, the debugging request will be sent to all the aforementioned redundancy debugging sessions, including: If all the redundancy debugging sessions are in normal condition, the debugging request will be broadcast to all the redundancy debugging sessions.

7. The method according to claim 1, characterized in that, If all the aforementioned response results are normal, perform the aforementioned redundancy debugging processing on the next debugging request, including: Determine whether the response result is normal; If any of the above response results are abnormal, terminate all of the above redundancy debugging sessions; If all the response results are normal, determine whether the debugging information of the target machine has been completed; If the debugging information has not been fully processed, the redundant debugging process is performed on the next debugging request. Once the requested debugging information has been executed, the redundancy debugging will end.

8. A redundancy adjustment device, characterized in that, The device includes: A determination module is used to determine multiple successfully connected redundancy debugging sessions; wherein each redundancy debugging session corresponds to a target machine being debugged; A debugging processing module is used to suspend all redundant debugging sessions and perform redundant debugging processing on the issued debugging requests; wherein, the redundant debugging processing includes: intercepting the debugging request issued by the currently active debugging session; wherein, the currently active debugging session is the active session among all redundant debugging sessions; if the status of all redundant debugging sessions is normal, issuing the debugging request to all redundant debugging sessions; obtaining the response result of the target machine to the debugging request; if all the response results are normal, performing the redundant debugging processing on the next debugging request.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the redundancy debugging method according to any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the redundancy debugging method as described in any one of claims 1-7.

Images