Software debugging method and device and computer program product
By adding stack instructions at the beginning of the function block, dynamically record the currently executed function or code block, and triggering breakpoints in specific cases, the problem of intervention of traditional debugging methods on real-time tasks is solved, and efficient and accurate real-time program debugging is achieved.
Patent Information
- Application Number
- CN202411821399.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-11
- Publication Date
- 2025-04-11
AI Technical Summary
Traditional software debugging methods can easily lead to task blockage and inconsistent scheduling during the periodic operation of real-time programs, affecting the execution of real-time tasks.
By adding stack instructions at the start of the function block, dynamically record the currently executed function or code block, determine whether the target breakpoint is triggered, and only trigger the breakpoint in specific situations, thereby reducing the debugger's intervention in real-time tasks.
It realizes reducing debugging intervention during real-time task execution, ensuring real-time tasks execution, and providing efficient debugging capabilities to ensure debugging accuracy and system real-time.
Smart Images

Figure CN119807009A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer software development, and in particular, to a software debugging method, device and computer program product. Background Art
[0002] Software debugging is a very important part of the software development process, and its purpose is to find and fix errors or abnormal behaviors in the program.
[0003] In current debugging methods, debugging usually relies on the instruction set and auxiliary registers provided by the CPU, and software debugging is performed through these hardware features. Based on this, the debugger interacts with the user in conjunction with the upper software to implement debugging functions such as breakpoint setting, single-step execution, and online assignment. These operations help developers locate and correct problems in the software by cooperating with the hardware interface.
[0004] However, the operation of real-time programs is periodic and there are priorities between tasks; therefore, traditional debugging methods will cause task blocking, resulting in different effects between the tasks being debugged and the actual running. Summary of the invention
[0005] The purpose of the embodiments of the present application is to provide a software debugging method, device and computer program product. The software debugging method checks whether there are breakpoints that need to be triggered during the periodic operation of the program, and only triggers the breakpoints under specific circumstances, thereby reducing the intervention of the debugger on real-time tasks and greatly reducing the impact of debugging on task scheduling.
[0006] In a first aspect, an embodiment of the present application provides a software debugging method, which includes: determining a current call stack corresponding to a currently executed function block based on a push instruction added at the start position of the function block; judging whether to trigger a target breakpoint based on the current call stack and target breakpoint information; wherein the target breakpoint is used to debug a software program; if the target breakpoint is triggered, running the software program according to the operating status of the target breakpoint.
[0007] In the above implementation process, the software debugging method provided by the embodiment of the present application can dynamically record the currently executed function or code block by adding a stack instruction at the starting position of the function block, ensuring that the debugger can accurately track the execution path of the program. In the periodic operation of the program, it is checked whether there is a breakpoint that needs to be triggered, and the breakpoint is triggered only under specific circumstances, thereby reducing the debugger's intervention in real-time tasks, greatly reducing the impact of debugging on task scheduling. The software debugging method provided by the embodiment of the present application can not only ensure the execution of real-time tasks, but also provide sufficient debugging capabilities.
[0008] Optionally, in an embodiment of the present application, the function block name corresponding to the function block is located at the end of the call stack; based on the push function added at the starting position of the function block, the current call stack corresponding to the currently executed function block is determined, including: based on the currently executed function block information and the function block name at the end of the call stack, the current call stack information of the current call stack is obtained; and the line number of the currently executed function block is used as the current line number of the current call stack.
[0009] In the above implementation process, the software debugging method provided by the embodiment of the present application can add the identification information (such as function name) of the current function block to the call stack and update the current line number information each time the program enters a function block through the design of the data structure of the real-time operation information; when the function block is executed, the identification information of the function block is deleted from the call stack and rolls back to the previous call stack. In this way, the current call stack of the program can be dynamically tracked and recorded, helping the debugger to locate the execution position of the program and the current execution context.
[0010] Optionally, in an embodiment of the present application, the target breakpoint information also includes breakpoint call stack information, the line number where the breakpoint is located, and the breakpoint status; based on the current call stack and the target breakpoint information, determine whether to trigger the target breakpoint, including: based on the breakpoint status, determine whether the target breakpoint is triggered; if it is determined that the target breakpoint is not triggered, determine whether to trigger the target breakpoint based on the breakpoint call stack information, the line number where the breakpoint is located, the current call stack information and the current line number.
[0011] In the above-mentioned implementation process, the software debugging method provided by the embodiment of the present application determines whether to enter the breakpoint state by judging the breakpoint state. When the state of the target breakpoint is true (trigger state), the debugger knows that the program has been suspended at the breakpoint, avoids multiple triggering, and ensures the accuracy of debugging. When the target breakpoint is not triggered, it is further judged whether the breakpoint can be triggered, and only in specific cases, the debugger will trigger the target breakpoint. Not only improve the efficiency in the debugging process, avoid the situation of false triggering breakpoints or leaking triggering breakpoints, it is also possible to keep efficient operation in the process of real-time task execution, ensuring that the program performs accurate debugging operations without interrupting execution.
[0012] Optionally, in an embodiment of the present application, the method further includes: if it is determined that the target breakpoint is triggered, jumping the execution of the software program to the target breakpoint according to the breakpoint call stack information and the current call stack information.
[0013] In the above implementation process, the software debugging method provided by the embodiment of the present application can efficiently and reliably trigger and restore to the specified breakpoint position in real-time program debugging, avoiding the debugging inconsistency caused by program blocking or scheduling problems in traditional debugging methods. At the same time, it can also maintain the real-time performance of the system and ensure that each debugging cycle accurately and stably enters the breakpoint position.
[0014] Optionally, in an embodiment of the present application, whether to trigger the target breakpoint is determined based on the breakpoint call stack information, the line number where the breakpoint is located, the current call stack information and the current line number, including: determining whether the breakpoint call stack information is consistent with the current call stack information; determining whether the line number where the breakpoint is located is consistent with the current line number; if it is determined that the breakpoint call stack information is consistent with the previous call stack information, and the line number where the breakpoint is located is consistent with the current line number information, then the target breakpoint is triggered.
[0015] In the above implementation process, the software debugging method provided in the embodiment of the present application ensures high accuracy and no misjudgment of breakpoint triggering, avoiding the program being mistakenly stopped when debugging is not required, and avoiding the situation where the breakpoint is missed during debugging.
[0016] Optionally, in an embodiment of the present application, the method also includes: if it is determined that the breakpoint call stack information is consistent with the previous call stack information, and the line number where the breakpoint is located is consistent with the current line number information, then based on the pop instruction added at the end position of the function block, execute the pop function.
[0017] In the above implementation process, by adding a pop instruction at the end position of the function block, when the program executes to the position where the breakpoint is triggered, it can ensure that the currently executed function block is correctly exited and the call stack can be restored to the previous state, thereby avoiding excessive nesting of the program or stack overflow problems.
[0018] Optionally, in an embodiment of the present application, the operating state includes a default running state and a target debugging state; running the software program according to the operating state of the target breakpoint includes: when the operating state of the target breakpoint is the default running state, the software program continues to run normally; when the operating state of the target breakpoint is the target debugging state, performing target debugging.
[0019] In the above implementation process, when the operation state of the target breakpoint is the default running state, the program will continue to execute according to the predetermined process, and the debugger will not interfere with the normal operation. This avoids unnecessary interruptions caused by debugging operations and maintains the real-time nature of the program. When the operation state of the target breakpoint is the target debugging state, such as single-step debugging; the debugger will enter the debugging mode and conduct a detailed inspection of the program execution process. This allows the debugger to accurately intervene in program execution when needed, helping developers analyze and fix problems.
[0020] Optionally, in an embodiment of the present application, after the target debugging is completed, the method also includes: changing the operating state from the target debugging state to the default running state; adding 1 to the last level of the array of the current line number to obtain an updated current line number, and returning the breakpoint position represented by the current call stack information.
[0021] In the above implementation process, by returning the breakpoint position represented by the current call stack information, the debugger can accurately restore to the debugging point, ensure that the program stays at the breakpoint, and avoid the deviation of the execution flow caused by debugging interrupts. Therefore, even if the debugging process spans multiple cycles, the program can ensure that it stays accurately at the predetermined breakpoint position.
[0022] In a second aspect, an embodiment of the present application provides a software debugging device, which includes an information determination module, a judgment module and an execution module. The information determination module is used to determine the current call stack corresponding to the currently executed function block based on the push instruction added at the start position of the function block; the judgment module is used to determine whether to trigger the target breakpoint based on the current call stack and the target breakpoint information; wherein the target breakpoint is used to debug the software program; the execution module is used to run the software program according to the operating status of the target breakpoint when the target breakpoint is triggered.
[0023] In a third aspect, an embodiment of the present application provides a computer program product, which includes a computer program / instructions, which, when executed by a processor, implement the steps of any one of the software debugging methods provided in the first aspect of the present application.
[0024] In a fourth aspect, an embodiment of the present application provides an electronic device, comprising a memory and a processor, wherein the memory stores program instructions, and when the processor reads and runs the program instructions, it executes the steps in any implementation of the software debugging method provided in the first aspect of the present application.
[0025] In a fifth aspect, an embodiment of the present application further provides a computer-readable storage medium, wherein the computer program instructions are stored in the computer-readable storage medium. When the computer program instructions are read and executed by a processor, the steps in any implementation of the software debugging method provided in the first aspect of the present application are executed. BRIEF DESCRIPTION OF THE DRAWINGS
[0026] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.
[0027] Figure 1A flowchart of a software debugging method provided in an embodiment of the present application;
[0028] Figure 2 A flowchart of breakpoint processing provided in an embodiment of the present application;
[0029] Figure 3 A schematic diagram of a module of a software debugging device provided in an embodiment of the present application;
[0030] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0031] The technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying drawings in the embodiments of the present application. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions and operations of the systems, methods and computer program products according to multiple embodiments of the present invention. In this regard, each box in the flowchart or block diagram may represent a module, a program segment or a part of a code, and the module, a program segment or a part of a code contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the box may also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they may sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or the flowchart, and the combination of boxes in the block diagram and / or the flowchart, can be implemented by a dedicated hardware-based system that performs a specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions. In addition, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist separately, or two or more modules can be integrated to form an independent part.
[0032] Software debugging is a very important part of the software development process. Its purpose is to find and fix errors or abnormal behaviors in the program. In traditional debugging methods, debugging usually relies on the instruction set and auxiliary registers provided by the CPU, and software debugging is performed through these hardware features. Based on this, the debugger interacts with the user in conjunction with the upper software to implement debugging functions such as breakpoint setting, single-step execution, and online assignment. These operations help developers locate and correct problems in the software by cooperating with the hardware interface.
[0033] On the one hand, the function of the debugger in the process of software debugging is to control the execution of the program. When a breakpoint is set or single-step debugging is performed, the program will pause or stop execution in order to check variables, call stack or other states; therefore, the periodic execution of real-time tasks will be disrupted, causing task blocking, priority inversion and other problems.
[0034] On the other hand, in real-time systems, tasks are usually triggered by hardware interrupts (such as timer interrupts, I / O device interrupts, etc.). During debugging, the debugger may suspend the execution of the program or even interrupt the execution of the system. The debugger itself may prohibit or affect the triggering of hardware interrupts, resulting in a mismatch between the task cycle during debugging and the cycle of the actual system. When the debugger stops at a breakpoint or is performing single-step debugging, the execution of the program is forcibly paused.
[0035] In addition, when the debugger pauses or single-steps a task, it may affect the normal priority scheduling, causing high-priority tasks to be "preempted" or delayed, thus affecting the real-time performance of the entire system. In addition, many real-time tasks are executed based on a fixed cycle (for example, refresh every 1ms). The debugger pause may cause these tasks to fail to execute on time, disrupting the time coordination between tasks. Even if debugging continues, the task cycle may be "misaligned" or "slipped", producing effects different from actual operation.
[0036] In general, since the debugger itself will occupy CPU resources, interfere with program execution, block task scheduling, and even change the response method of hardware interrupts; when debugging real-time programs, the current debugging methods will cause the program to pause execution or add unnecessary overhead, affecting the periodicity and task scheduling of real-time tasks.
[0037] Based on this, the present application proposes a software debugging method, device and computer program product.
[0038] Before introducing the specific content of the present application, the components used in the present solution are explained first. The software debugging method provided in the embodiment of the present application is based on a complete component including a debugger and a real-time program embedded support part, wherein the debugger is responsible for setting breakpoints and controlling single-step debugging, while the embedded support part is responsible for checking the triggered breakpoints during operation and responding to the control of the debugger.
[0039] Please see Figure 1 , Figure 1 A flowchart of a software debugging method provided in an embodiment of the present application; The present application provides a software debugging method, which can be Figure 4 The software debugging method comprises the following steps:
[0040] Step S100: Based on the push instruction added at the beginning of the function block, determine the current call stack corresponding to the currently executed function block.
[0041] In the above step S100, when the software program is executed, the program starts from a functional block (such as a function or method) and enters the code area of the functional block. In order to track the execution flow of the program, it is necessary to record the stack information of the program call, which is the call stack.
[0042] First, a push instruction needs to be added at the beginning of each function block, so that the function block identification information can be added to the current call stack, and the current call stack in the real-time running information of the current function block can be updated.
[0043] That is to say, by adding a push instruction at the beginning of each function block, the current call stack of the program can be dynamically tracked and recorded, helping the debugger to locate the execution position of the program and the current execution context.
[0044] Step S200: judging whether to trigger the target breakpoint according to the current call stack and the target breakpoint information.
[0045] In the above step S200, during the software debugging process, the debugger often needs to set a breakpoint at a specific code line, a specific function entry, or inside a function, that is, the program is paused when it executes to a certain position, so that the developer can check variable values, execution status, etc. In the above implementation process, according to the target breakpoint information of the target breakpoint of the current call stack for debugging the software program, it is determined whether to trigger the target breakpoint.
[0046] Step S300: If the target breakpoint is triggered, the software program is run according to the operating state of the target breakpoint.
[0047] In the above step S300, when a breakpoint is triggered, the debugger controls the execution mode of the program according to the operating state, supports different debugging operations (such as single-step debugging, resume execution, etc.), and makes the debugging process more flexible and accurate.
[0048] pass Figure 1 It can be seen that the software debugging method provided by the embodiment of the present application can dynamically record the currently executed function or code block by adding a stack instruction at the starting position of the function block, ensuring that the debugger can accurately track the execution path of the program. In the periodic operation of the program, it is checked whether there is a breakpoint that needs to be triggered, and the breakpoint is triggered under specific circumstances, thereby reducing the debugger's intervention in real-time tasks, greatly reducing the impact of debugging on task scheduling. The software debugging method provided by the embodiment of the present application can not only ensure the execution of real-time tasks, but also provide sufficient debugging capabilities.
[0049] In an optional embodiment, the function block name corresponding to the function block is located at the end of the call stack. The above step S100 determines the current call stack corresponding to the currently executed function block based on the push instruction added at the beginning of the function block, which can be implemented in the following way:
[0050] Based on the information of the currently executed function block and the name of the function block at the end of the call stack, the current call stack information of the current call stack is obtained; and the line number of the currently executed function block is used as the current line number of the current call stack.
[0051] In the embodiment of the present application, the call stack is a data structure that records the program execution path, records the current execution function and the function call chain. Through the call stack, you can know where the program is currently executed, which functions are called, and how the calling order is.
[0052] For example, when executing the beginning of main, #main is added to the call stack. After A1Func is called, the call stack becomes #main#A1Func, and the line number array information of the current call stack is dynamically updated.
[0053] For example, the call stack information and current line number of the current call stack are (#main#A1func,{1,3}), which means that the current statement is the first line 1 in the call stack main that calls A1func and executes to the third line of A1func.
[0054] In the embodiment of the present application, as described above, while adding a push instruction at the beginning of each function block, a pop instruction is added at the end of each function block to delete the identification information of the function block from the running call stack.
[0055] For example, after executing A1Func, jump out of A1Func and continue to execute the program in main, the call stack rolls back to #main, and the line number array is dynamically updated.
[0056] It can be seen that the software debugging method provided by the embodiment of the present application can add the identification information (such as the function name) of the current function block to the call stack and update the current line number information each time the program enters a function block through the design of the data structure of the real-time operation information; when the function block is executed, the identification information of the function block is deleted from the call stack and rolls back to the previous call stack. In this way, the current call stack of the program can be dynamically tracked and recorded, helping the debugger to locate the execution position of the program and the current execution context.
[0057] Please see Figure 2 , Figure 2A flowchart of breakpoint processing provided in an embodiment of the present application; in an optional embodiment, the target breakpoint information also includes the breakpoint call stack information, the line number where the breakpoint is located, and the breakpoint status. In the above step S200, judging whether to trigger the target breakpoint according to the current call stack and the target breakpoint information can be achieved by the following steps:
[0058] The target breakpoint information in the embodiment of the present application includes the breakpoint call stack information, the line number where the breakpoint is located, the breakpoint status and the operation status.
[0059] The breakpoint call stack is of string type, and the line number where the breakpoint is located is an integer array. The breakpoint call stack information and the line number where the breakpoint is located can be used to confirm the location of the real-time program where the user wants to breakpoint.
[0060] The breakpoint status is of Boolean type and may include a default status and a trigger status, such as false for the default status and true for the trigger status. The operation status information is of integer type, and the operation status may include a default run status, a target debugging status, and a resume run exit status. For example, 0 represents the default run, 1 represents single-step execution, and 2 represents resume run exit. The breakpoint status and operation status are used for status setting and feedback of the debugger for operations such as single-step debugging and exit debugging.
[0061] Step S210: judging whether the target breakpoint is triggered according to the breakpoint status.
[0062] In the above step S210, it is assumed that a breakpoint is set at the first line (the line number where the breakpoint is located) in #main#A1Func (breakpoint call stack). When the program executes each line normally, it will be determined whether the target breakpoint of the currently executed function block has been triggered.
[0063] If the breakpoint status of the target breakpoint is true (trigger status), then the current state is breakpoint status.
[0064] Step S220: If it is determined that the target breakpoint is not triggered, determine whether to trigger the target breakpoint based on the breakpoint call stack information, the line number where the breakpoint is located, the current call stack information and the current line number.
[0065] In the above step S220, if the breakpoint state of the target breakpoint is false (default state), the target breakpoint is not triggered. In the case where the target breakpoint is not triggered, it is determined whether to trigger the target breakpoint based on the breakpoint call stack information, the line number where the breakpoint is located, the current call stack information and the current line number. The target breakpoint is triggered only when the triggering condition is met.
[0066] It can be seen from this that the software debugging method provided by the embodiment of the present application determines whether to enter the breakpoint state by judging the breakpoint state. When the state of the target breakpoint is true (trigger state), the debugger knows that the program has been suspended at the breakpoint, avoids multiple triggering, and ensures the accuracy of debugging. When the target breakpoint is not triggered, it is further judged whether the breakpoint can be triggered, and only in specific cases, the debugger will trigger the target breakpoint. Not only improve the efficiency in the debugging process, avoid the situation of false triggering breakpoints or leaking triggering breakpoints, it is also possible to keep efficient operation in the process of real-time task execution, ensuring that the program performs accurate debugging operations without interrupting execution.
[0067] In an optional embodiment, please continue to see Figure 2 In the above step S220, the target breakpoint is not triggered. It is determined whether to trigger the target breakpoint according to the breakpoint call stack information, the line number where the breakpoint is located, the current call stack information and the current line number. This can be achieved in the following way:
[0068] Step S221: Determine whether the breakpoint call stack information is consistent with the current call stack information.
[0069] Step S222: Determine whether the line number where the breakpoint is located is consistent with the current line number.
[0070] Step S223: If it is determined that the breakpoint call stack information is consistent with the previous call stack information, and the line number where the breakpoint is located is consistent with the current line number information, then the target breakpoint is triggered.
[0071] In the above steps S221 to S223, by respectively judging the consistency between the breakpoint call stack information and the current call stack information, and the consistency between the line number where the breakpoint is located and the current line number information, it is ensured that the breakpoint is triggered only when the program executes to the breakpoint position.
[0072] In an optional implementation, if it is determined that the breakpoint call stack information is consistent with the previous call stack information, and the line number where the breakpoint is located is consistent with the current line number information, the pop function is executed based on the pop instruction added at the end position of the function block. By adding the pop instruction at the end position of the function block, when the program executes to the position where the breakpoint is triggered, it can ensure that the currently executed function block is correctly exited and the call stack can be restored to the previous state, thereby avoiding excessive nesting of the program or stack overflow problems.
[0073] It can be seen that the software debugging method provided in the embodiment of the present application ensures high accuracy and no misjudgment of breakpoint triggering, avoiding the program being mistakenly stopped when debugging is not needed, and avoiding the situation where breakpoints are missed during debugging.
[0074] In an optional embodiment, if the above step S210 determines that the currently executed function block has a breakpoint that has been triggered, the following steps are performed:
[0075] Step S230: If it is determined that the target breakpoint is triggered, the execution of the software program is jumped to the target breakpoint according to the breakpoint call stack information and the current call stack information.
[0076] When the target breakpoint is triggered, the debugger compares the call stack in the real-time running information with the breakpoint call stack information to determine whether the level of the current call stack is consistent with the breakpoint call stack. Through this hierarchical comparison, the debugger can gradually restore the execution state of the program to ensure that each cycle can accurately jump to the breakpoint position. For example, if the running stack is #main and the breakpoint call stack is #main#A1Func, the first level is consistent.
[0077] The mechanism of periodic refresh and step-by-step jump ensures that the debugger can accurately restore the program to the breakpoint position even during the execution of the program. This jump method not only avoids the interruption of real-time task scheduling, but also ensures that the program debugging can be carried out accurately according to the predetermined breakpoint position.
[0078] It can be seen that the software debugging method provided by the embodiment of the present application can efficiently and reliably trigger and restore to the specified breakpoint position in real-time program debugging, avoiding the debugging inconsistency caused by program blocking or scheduling problems in traditional debugging methods. At the same time, it can also maintain the real-time performance of the system and ensure that each debugging cycle accurately and stably enters the breakpoint position.
[0079] In an optional embodiment, when the operating state of the target breakpoint is the default running state, the software program continues to run normally; when the operating state of the target breakpoint is the target debugging state, target debugging is performed.
[0080] When the target breakpoint is in the default running state, the program will continue to execute according to the predetermined process, and the debugger will not interfere with normal operation. This avoids unnecessary interruptions caused by debugging operations and maintains the real-time nature of the program.
[0081] When the target breakpoint's operation state is the target debugging state, such as single-step debugging, the debugger will enter the debugging mode and conduct a detailed inspection of the program execution process. This allows the debugger to accurately intervene in program execution when necessary, helping developers analyze and fix problems.
[0082] In an optional embodiment, after the target debugging is completed, the method further includes:
[0083] Change the operation state from the target debugging state to the default running state; add 1 to the last level of the array of the line number where the breakpoint is located to obtain the updated line number where the breakpoint is located, and return the breakpoint position represented by the breakpoint call stack information.
[0084] In the above implementation process, after the target debugging is completed, the program can resume normal execution by switching the operation state from the target debugging state back to the default running state, ensuring that the program will not be subject to any additional interference after the debugging is completed and can continue to execute according to the original logic.
[0085] At the same time, by updating the array of line numbers where the breakpoints are located (ie, adding 1 to the last level of the array of line numbers where the breakpoints are located), the debugger can accurately record the execution position after debugging and provide accurate status information for the next debugging or program running.
[0086] By returning to the breakpoint position represented by the breakpoint call stack information, the debugger can accurately restore to the debugging point, ensuring that the program stays at the breakpoint and avoiding deviations in the execution flow caused by debugging interrupts. Therefore, even if the debugging process spans multiple cycles, the program can ensure that it stays accurately at the predetermined breakpoint position.
[0087] For example, the call stack information and the current line number of the current call stack are (#main#A1func,{1,3}), and the set breakpoint call stack information and the line number of the breakpoint are (#main#A1func,{4}), that is, a breakpoint is set at the 4th line of #main#A1func.
[0088] When the 4th line of #main#A1func is executed, the stack information (current call stack information and breakpoint call stack information) will be compared first to determine whether they are consistent. Then the last level of the array of the current line number (that is, the line number of the function block currently being executed) will be compared with the last level of the array of the line number where the breakpoint is located. After they are the same, the debugging state (breakpoint state) will be entered.
[0089] Assume that when the program is executed in #main#A1func, the position of the breakpoint needs to be updated according to the dynamic changes during the execution process. When the program is executed to the 4th line of #main#A1func, the breakpoint is triggered. Since the breakpoint data structure is dynamically managed, when the breakpoint is triggered, its state is updated to (#main#A1func,{1,4}), indicating that the program has entered the main function and executed to the 1st line, and then jumps to the 4th line of A1func.
[0090] During single-step execution, when the program executes from line 4 to line 5 of #main#A1func, the breakpoint data structure will be updated to (#main#A1func,{1,5}), which means that it has jumped from line 4 to line 5.
[0091] If you continue to execute single-step and eventually reach the last line of A1func, A1func will end, the breakpoint management will enter the previous level, and the data structure will be updated to (#main,{2}), that is, the breakpoint has exited A1func and returned to the second line of the main function.
[0092] In addition, during the entire debugging process, the breakpoint initially set at line 4 of #main#A1func will gradually become invalid as the single-step execution progresses and will be overwritten by the new breakpoint data. For example, when the breakpoint data structure becomes (#main#A1func,{1,5}), the initially set #main#A1func,{4} is no longer valid, and the original breakpoint information is overwritten.
[0093] Therefore, in the software debugging method provided in the embodiment of the present application, in order to ensure that the breakpoint history record is not lost, an additional data structure can be retained to save the initial breakpoint position, such as (#main#A1func,{4}), so that the breakpoint information initially set can be saved.
[0094] In an optional embodiment, after completing the target debugging, the jump out opcode is set to the operation state variable, that is, the recovery operation jump out state. During operation, each time the correct position of the breakpoint is jumped to, the operation state will be judged. When the operation state variable is the recovery operation jump out state, the breakpoint call stack information and the breakpoint line number information will be deleted (the breakpoint call stack is set to empty, and the line number array is set to []), the breakpoint state variable (set to false by default) and the operation state variable (set to the default operation 0) are cleared, and normal execution is resumed.
[0095] In the above implementation process, by restoring the run exit state, the long-term interference of debugging operations on real-time tasks and program performance can be avoided. In addition, clearing the breakpoint information and operation status can ensure that the program continues to run without being affected, thus achieving a balance between debugging and real-time tasks.
[0096] Optionally, the real-time program in the embodiment of the present application is created using templates and is divided into a code area and a data area. The data area is set as a shared memory data block (through the API for creating shared memory provided by Linux, and providing a shared memory ID, a large structure is created, and all variables that need to be debugged are written to the structure. The function operates the variables in the shared structure through a global pointer, for example, global_p->globalVarA=123 is executed in the program, and the value therein can be printed out through the shared memory global_p->globalVarA). This allows the debugger to display and edit the contents of the shared memory data block through the shared memory.
[0097] Optionally, the software debugging method provided in the embodiment of the present application can also detect and feedback the breakpoint position. Detect the breakpoint state, and when it is a true trigger state, display the breakpoint position according to the breakpoint call stack information (e.g., #main#A1Func) and the breakpoint line number information (e.g., 3).
[0098] The software debugging method provided in the embodiment of the present application can automatically add operations such as push and pop internally when executing compilation; add the jump logic in the above text at the beginning of each function block, and add the judgment and processing logic of the call stack and breakpoint call stack on each line of the text code, so that the user can use the software debugging method provided in the embodiment of the present application to debug the real-time program in a single step without feeling. After sending and running, connect the lower computer debugger service on the upper computer editing software to set breakpoints, single-step execution and resume operation, so as to control the breakpoints of the real-time program.
[0099] Optionally, the software debugging method provided in real time by the present application is not only applicable to real-time programs that are executed periodically, but also to ordinary software programs that are executed non-periodically. For ordinary software applications, when the program is executed to the breakpoint position, the debugger will pause the program and enter the breakpoint state. In this state, a loop (while loop or similar mechanism) can be used to detect whether there is a new debugging command or operation update.
[0100] Optionally, for real-time patch programs in a Linux environment (such as kernel patches, real-time task scheduling, etc.), the debugging method provided in the embodiments of the present application can also provide debugging functions to ensure dynamic debugging during the execution of real-time programs without affecting task scheduling and system real-time performance.
[0101] Optionally, for pure software debugging, pure software debugging usually involves code-level debugging of the application, such as viewing variables, tracing function calls, checking memory and execution flow, etc. In this scenario, the debugger helps developers deeply analyze the execution of the program through methods such as breakpoint setting, single-step execution, and stack tracing.
[0102] Please see Figure 3 , Figure 3 A module diagram of a software debugging device provided in an embodiment of the present application; An embodiment of the present application provides a software debugging device, and the software debugging device 100 includes an information determination module 110, a judgment module 120 and an execution module 130.
[0103] The information determination module 110 is used to determine a current call stack corresponding to a currently executed function block based on a push instruction added at the beginning of the function block.
[0104] The determination module 120 is used to determine whether to trigger a target breakpoint based on the current call stack and target breakpoint information; wherein the target breakpoint is used to debug a software program.
[0105] The execution module 130 is used to run the software program according to the operation status of the target breakpoint when the target breakpoint is triggered.
[0106] In an optional embodiment, the function block name corresponding to the function block is located at the end of the call stack; in the process of determining the current call stack corresponding to the currently executed function block based on the push function added at the starting position of the function block, the information determination module 110 is specifically used to: obtain the current call stack information of the current call stack based on the currently executed function block information and the function block name at the end of the call stack; use the line number of the currently executed function block as the current line number of the current call stack.
[0107] In an optional embodiment, the target breakpoint information also includes breakpoint call stack information, the line number where the breakpoint is located, and the breakpoint status; in the process of judging whether to trigger the target breakpoint based on the current call stack and the target breakpoint information, the judgment module 120 is specifically used to: judge whether the target breakpoint is triggered based on the breakpoint status; if it is determined that the target breakpoint is not triggered, judge whether to trigger the target breakpoint based on the breakpoint call stack information, the line number where the breakpoint is located, the current call stack information and the current line number.
[0108] In an optional embodiment, the software debugging device 100 is further used to: when it is determined that the target breakpoint is triggered, jump the execution of the software program to the target breakpoint according to the breakpoint call stack information and the current call stack information.
[0109] In an optional embodiment, in the process of determining whether to trigger a target breakpoint based on the breakpoint call stack information, the line number where the breakpoint is located, the current call stack information and the current line number, the determination module 120 is specifically used to: determine whether the breakpoint call stack information is consistent with the current call stack information; determine whether the line number where the breakpoint is located is consistent with the current line number; if it is determined that the breakpoint call stack information is consistent with the previous call stack information, and the line number where the breakpoint is located is consistent with the current line number information, then the target breakpoint is triggered.
[0110] In an optional embodiment, the software debugging device 100 is also used to execute a pop function based on a pop instruction added at the end position of the function block when it is determined that the breakpoint call stack information is consistent with the previous call stack information and the line number where the breakpoint is located is consistent with the current line number information.
[0111] In an optional embodiment, wherein the operating state includes a default running state and a target debugging state; in the process of running the software program according to the operating state of the target breakpoint, the execution module 130 is specifically used to: when the operating state of the target breakpoint is the default running state, the software program continues to run normally; when the operating state of the target breakpoint is the target debugging state, target debugging is performed.
[0112] In an optional embodiment, after the target debugging is completed, the software debugging device 100 is also used to: change the operating state from the target debugging state to the default running state; add 1 to the last level of the array of the current line number to obtain an updated current line number, and return the breakpoint position represented by the current call stack information.
[0113] See also Figure 4 , Figure 4 The electronic device 200 provided in the embodiment of the present application includes: a processor 201 and a memory 202, wherein the memory 202 stores machine-readable instructions executable by the processor 201, and when the machine-readable instructions are executed by the processor 201, the above method is executed.
[0114] Based on the same inventive concept, an embodiment of the present application also provides a computer program product, which includes a computer program / instructions. When the computer program / instructions are executed by a processor, the steps of any one of the software debugging methods provided in the first aspect of the present application are implemented.
[0115] Based on the same inventive concept, an embodiment of the present application also provides a computer-readable storage medium, in which computer program instructions are stored. When the computer program instructions are read and run by a processor, the steps in any implementation method of the software debugging method provided in the first aspect of the present application are executed.
[0116] The computer-readable storage medium may be a random access memory (RAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or any other medium that can store program code.
[0117] In this article, relational terms such as first and second, etc. are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the statement "include..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.
[0118] The above description is only an embodiment of the present application and is not intended to limit the protection scope of the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.
Claims
1. A software debugging method, characterized in that: The software debugging method comprises: Determine a current call stack corresponding to a currently executed function block based on a push instruction added at the beginning of the function block; Determine whether to trigger a target breakpoint according to the current call stack and target breakpoint information; wherein the target breakpoint is used to debug a software program; If the target breakpoint is triggered, the software program is run according to the operation state of the target breakpoint.
2. The method according to claim 1, characterized in that in, The function block name corresponding to the function block is located at the end of the call stack; the step of determining the current call stack corresponding to the currently executed function block based on the push function added at the beginning of the function block includes: Based on the currently executed function block information and the function block name at the end of the call stack, obtaining current call stack information of the current call stack; The line number of the currently executed function block is used as the current line number of the current call stack.
3. The method according to claim 2, characterized in that in, The target breakpoint information also includes breakpoint call stack information, the line number of the breakpoint, and the breakpoint status; judging whether to trigger the target breakpoint according to the current call stack and the target breakpoint information includes: According to the breakpoint status, determining whether the target breakpoint is triggered; If it is determined that the target breakpoint is not triggered, whether to trigger the target breakpoint is determined based on the breakpoint call stack information, the line number where the breakpoint is located, the current call stack information and the current line number.
4. The method according to claim 3, characterized in that The method further comprises: If it is determined that the target breakpoint is triggered, the execution of the software program is jumped to the target breakpoint according to the breakpoint call stack information and the current call stack information.
5. The method according to claim 3, characterized in that: The determining whether to trigger the target breakpoint according to the breakpoint call stack information, the line number where the breakpoint is located, the current call stack information and the current line number includes: Determine whether the breakpoint call stack information is consistent with the current call stack information; Determine whether the line number where the breakpoint is located is consistent with the current line number; If it is determined that the breakpoint call stack information is consistent with the previous call stack information, and the line number where the breakpoint is located is consistent with the current line number information, the target breakpoint is triggered.
6. The method according to claim 5, characterized in that The method further comprises: If it is determined that the breakpoint call stack information is consistent with the previous call stack information, and the line number where the breakpoint is located is consistent with the current line number information, the pop function is executed based on the pop instruction added at the end position of the function block.
7. The method according to claim 1, characterized in that in, The operating state includes a default running state and a target debugging state; and running the software program according to the operating state of the target breakpoint includes: In the case where the operation state of the target breakpoint is a default operation state, the software program continues to operate normally; When the operation state of the target breakpoint is a target debugging state, target debugging is performed.
8. The method according to claim 7, characterized in that After the target debugging is completed, the method further includes: Modifying the slave operation state from the target debugging state to the default operation state; The last level of the array of the line number where the breakpoint is located is increased by 1 to obtain the updated line number where the breakpoint is located, and the breakpoint position represented by the breakpoint call stack information is returned.
9. A software debugging device, characterized in that: The software debugging device includes an information determination module, a judgment module and an execution module The information determination module is used to determine the current call stack corresponding to the currently executed function block based on the push instruction added at the start position of the function block; The judgment module is used to judge whether to trigger a target breakpoint according to the current call stack and the target breakpoint information; wherein the target breakpoint is used to debug a software program; The execution module is used to run the software program according to the operation state of the target breakpoint when the target breakpoint is triggered.
10. A computer program product, characterized in that The computer program product comprises a computer program / instruction, which implements the steps of the method according to any one of claims 1 to 8 when executed by a processor.