GPU (Graphics Processing Unit) interrupt debugging method, device, equipment, medium and program product

Abstract

The invention relates to a GPU interrupt debugging method and device, equipment, a medium and a program product. The method comprises the steps that under the condition that a set breakpoint in a target GPU program is detected, an interrupt agent program corresponding to the breakpoint is generated, and the target GPU program is the currently executed target GPU program; replacing the original instruction located at the breakpoint position with a target instruction, and skipping to the interrupt agent program from the target GPU program under the condition that the target instruction is executed; executing the interrupt agent program, and storing program operation data corresponding to execution of the target GPU program; a debugging command of a debugger is received in the execution process of the interrupt agent program, and debugging is carried out based on the debugging command and the stored program operation data. The method is not limited by hardware.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a GPU interrupt debugging method, apparatus, device, medium, and program product. Background Technology

[0002] Traditional GPU interrupt debugging primarily utilizes hardware interrupt mechanisms. These mechanisms reserve debug commands and interrupt control logic during the GPU hardware design phase, allowing debuggers to pause GPU execution threads and read or modify register states under specific conditions. These mechanisms typically rely on internal GPU hardware debugging interfaces (such as trap instructions, halt signals, or single-step registers), configuring relevant registers or control bits to achieve debug control and breakpoint responses. This method offers high real-time performance and accuracy, representing a native hardware-level debugging support.

[0003] However, current hardware interrupt mechanisms are limited by hardware design and cannot be used universally with GPUs that do not support interrupts. Summary of the Invention

[0004] Therefore, it is necessary to provide a GPU interrupt debugging method, apparatus, device, medium, and program product that is not limited by hardware to address the above-mentioned technical problems.

[0005] Firstly, this application provides a GPU interrupt debugging method, the method comprising:

[0006] If a breakpoint is detected in the target GPU program, an interrupt proxy program corresponding to the breakpoint is generated, wherein the target GPU program is the target GPU program that is currently being executed.

[0007] Replace the original instruction at the breakpoint with the target instruction, and if the target instruction is executed, jump from the target GPU program to the interrupt proxy.

[0008] Execute the interrupt proxy program and save the execution data of each program corresponding to the target GPU program;

[0009] During the execution of the interrupt agent, the debugger receives debug commands and performs debugging based on the debug commands and the saved program execution data.

[0010] In some optional embodiments, executing the interrupt proxy includes:

[0011] Acquire the execution lock if no other interrupt agent is currently executing;

[0012] If other interrupt agents are currently executing, wait for them to complete before acquiring the execution lock;

[0013] If the execution lock is acquired, the step of executing the interrupt agent program continues.

[0014] In some optional embodiments, the interrupt proxy includes a loop-waiting subroutine; receiving debug commands from the debugger during the execution of the interrupt proxy includes:

[0015] During the execution of the loop waiting subroutine, debug commands from the debugger are received based on the shared memory mechanism between the GPU and CPU.

[0016] In some optional embodiments, the debugging command includes a single-step execution command; the debugging based on the debugging command and the saved program execution data includes:

[0017] Modify the single-step instruction corresponding to the single-step execution command to obtain the modified single-step instruction, wherein the single-step instruction is an instruction in the target GPU program;

[0018] The last instruction of the interrupt proxy is set as the first jump instruction, and the modified single-step instruction is stored in the interrupt proxy. The first jump instruction is used to jump to the next instruction of the single-step instruction.

[0019] Data recovery is performed based on the previously saved program execution data, and after the program execution data is recovered, the modified single-step instructions are executed.

[0020] After the modified single-step instruction is executed, the program execution data after the single-step instruction is executed is saved as the new program execution data, and the step of receiving the debugger's debugging command during the execution of the interrupt agent program continues.

[0021] In some optional embodiments, the debugging command includes a continue execution command; generating the interrupt proxy corresponding to the breakpoint includes:

[0022] Obtain a pre-compiled interrupt proxy template, set the last instruction of the interrupt proxy template as the second jump instruction, and obtain the interrupt proxy corresponding to the breakpoint. The second jump instruction is used to jump to the next instruction after the original instruction.

[0023] The debugging based on the debugging commands and the saved program execution data includes:

[0024] If the debugging command is a continue execution command, data recovery is performed based on the saved program execution data, and the second jump instruction is executed again after the program execution data is recovered.

[0025] In some optional embodiments, the generation of the interrupt proxy program corresponding to the breakpoint includes any of the following:

[0026] Obtain a pre-compiled interrupt proxy template, generate a third jump instruction, which is used to jump to the instruction following the original instruction. Replace the last instruction in the pre-compiled interrupt proxy template with the third jump instruction to obtain the interrupt proxy; or,

[0027] Obtain an uncompiled interrupt proxy template, generate a fourth jump instruction, which is used to jump to the instruction following the original instruction, replace the last instruction in the uncompiled interrupt proxy template with the fourth jump instruction, and compile the interrupt proxy template after variable replacement to obtain the interrupt proxy program.

[0028] Secondly, this application also provides a GPU interrupt debugging apparatus, the apparatus comprising:

[0029] A generation module is used to generate an interrupt proxy program corresponding to a breakpoint when a breakpoint is detected in the target GPU program, wherein the target GPU program is the target GPU program that is currently being executed.

[0030] A jump module is used to replace the original instruction at the breakpoint with the target instruction, and, if the target instruction is executed, jump from the target GPU program to the interrupt proxy program;

[0031] The storage module is used to execute the interrupt proxy program and save the running data of each program corresponding to the execution of the target GPU program;

[0032] The debugging module is used to receive debugging commands from the debugger during the execution of the interrupt agent program, and to perform debugging based on the debugging commands and the saved program execution data.

[0033] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method in any of the above embodiments.

[0034] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the methods in any of the above embodiments.

[0035] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method in any of the above embodiments.

[0036] The aforementioned GPU interrupt debugging method, apparatus, device, medium, and program product, upon detecting a breakpoint set in a target GPU program, generates an interrupt proxy program corresponding to the breakpoint. The target GPU program is a currently executing target GPU program. The original instructions are replaced with target instructions, and when the target instructions are executed, the program jumps to the interrupt proxy program. The interrupt proxy program is executed, and the execution data of each program corresponding to the target GPU program is saved. During the execution of the interrupt proxy program, debugging commands from a debugger are received, and debugging is performed based on the debugging commands and the saved execution data. Interrupt debugging can be achieved through a software interrupt proxy program, without hardware limitations. Attached Figure Description

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

[0038] Figure 1 This is a diagram illustrating the application environment of a GPU interrupt debugging method in one embodiment;

[0039] Figure 2 This is a flowchart illustrating a GPU interrupt debugging method in one embodiment;

[0040] Figure 3 This is a schematic diagram of an interrupt agent procedure in one embodiment;

[0041] Figure 4 This is a schematic diagram of breakpoint settings in one embodiment;

[0042] Figure 5 This is a schematic diagram of a single-step execution command in one embodiment;

[0043] Figure 6 This is a structural block diagram of a GPU interrupt debugging device in one embodiment;

[0044] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0046] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0047] The GPU interrupt debugging method provided in this application embodiment can be applied to, for example, Figure 1 The application environment shown illustrates this. The host computer communicates with the GPU. The host includes a debugger. During the execution of the target GPU program on the GPU, if a breakpoint is detected in the target GPU program, an interrupt proxy program corresponding to the breakpoint is generated. The target GPU program is the currently executing program. The original instruction at the breakpoint is replaced with the target instruction. When the target instruction is executed, the program jumps to the interrupt proxy program. The interrupt proxy program is executed, and the execution data of each program corresponding to the target GPU program is saved. During the execution of the interrupt proxy program, debug commands from the debugger are received, and debugging is performed based on the debug commands and the saved execution data. Thus, interrupt debugging can be achieved through a software interrupt proxy program, without hardware limitations.

[0048] In one exemplary embodiment, such as Figure 2 As shown, a GPU interrupt debugging method is provided, which can be applied to... Figure 1 Taking the GPU as an example, the explanation includes the following steps S202 to S208. Wherein:

[0049] S202: If a breakpoint is detected in the target GPU program, an interrupt proxy program corresponding to the breakpoint is generated, wherein the target GPU program is the currently executing target GPU program.

[0050] The target GPU program is the program being executed by the GPU. A breakpoint is a marker set within the target GPU program; it's an embedded marker used to notify the debugger that execution should be interrupted when the program reaches that instruction. Generally, in an integrated development environment (IDE), breakpoints are set to the side of the line number in the code.

[0051] An interrupt proxy corresponds to a breakpoint; that is, an interrupt is required at the breakpoint location, and the corresponding interrupt proxy is executed. Optionally, the interrupt proxy can be generated based on a pre-compiled binary program template or based on an uncompiled program template.

[0052] Among them, the combination Figure 3 As shown, the interrupt proxy includes a lock acquisition subroutine, a program execution data saving subroutine, a program execution data restoration subroutine, a loop wait subroutine, and a nop instruction. The lock acquisition subroutine ensures that only one thread can enter the interrupt at a time; the program execution data saving and program execution data restoration subroutines are mainly used to save and restore registers; the loop wait subroutine waits to receive commands from the debugger; and the nop instruction is used to replace the instruction to be executed after exiting the interrupt proxy.

[0053] In some optional embodiments, generating an interrupt proxy program corresponding to the breakpoint includes any of the following: obtaining a pre-compiled interrupt proxy program template, generating a third jump instruction, the third jump instruction being used to jump to the instruction following the original instruction, replacing the last instruction in the pre-compiled interrupt proxy program template with the third jump instruction to obtain the interrupt proxy program; or, obtaining an uncompiled interrupt proxy program template, generating a fourth jump instruction, the fourth jump instruction being used to jump to the instruction following the original instruction, replacing the last instruction in the uncompiled interrupt proxy program template with the fourth jump instruction, and compiling the interrupt proxy program template after variable replacement to obtain the interrupt proxy program.

[0054] The pre-compiled interrupt proxy template can be a binary file. This template can be deployed along with the GPU during loading. When an interrupt proxy needs to be generated, the last instruction in the template is modified to obtain the interrupt proxy. This modification includes altering the `nop` instructions, such as the third jump instruction. This third jump instruction is used to jump to the instruction following the original instruction at the breakpoint. It should be noted that the instruction following the original instruction is not necessarily a consecutive instruction. For example... Figure 4 In this context, the original instruction is instruction 2. If it is necessary to jump to instruction 4 after executing instruction 2, then the next instruction is instruction 4. If it is necessary to jump to instruction 3 after executing instruction 2, then the next instruction is instruction 3. The specific instruction to be executed depends on the actual situation.

[0055] An uncompiled interrupt proxy template can be an actual program. Based on the original instruction located at the breakpoint, the uncompiled interrupt proxy template is modified by replacing the nop instruction with the fourth jump instruction. The fourth jump instruction is used to jump to the instruction after the original instruction. Then, the modified interrupt proxy template is compiled to obtain the interrupt proxy. In this way, through just-in-time (JIT) compilation or dynamic code generation technology, the interrupt proxy is dynamically generated according to the current context when the breakpoint is set.

[0056] S204: Replace the original instruction at the breakpoint with the target instruction, and if the target instruction is executed, jump from the target GPU program to the interrupt agent.

[0057] The original instruction is the instruction located at the breakpoint, that is, the instruction carrying the identifier corresponding to the breakpoint. The target instruction is used to jump from the target GPU program to the interrupt proxy routine. In some optional embodiments, the type of the target instruction includes jump instructions or other abnormal instructions. Abnormal instructions include illegal instructions or special trap instructions. These instructions only need to be able to trigger an interrupt and enter the interrupt proxy routine after the instruction is executed, that is, to achieve the purpose of debugging.

[0058] Combination Figure 4 As shown, Figure 4 This is a schematic diagram of the breakpoint setting process in one embodiment. In this embodiment, instruction 2 is the instruction located at the breakpoint, i.e., the original instruction. When instruction 2 is executed, since instruction 2 carries the breakpoint identifier, the interrupt proxy routine corresponding to the breakpoint is first generated. Then, instruction 2 is replaced with the target instruction so that when the target instruction is executed, the program jumps from the target GPU program to the interrupt proxy routine.

[0059] S206: Execute the interrupt proxy and save the running data of each program corresponding to the target GPU program.

[0060] The interrupt proxy includes a program execution data saving subroutine. Therefore, before debugging, the program execution data saving subroutine needs to be executed to save the execution data of the target GPU program. The saved execution data includes data related to the execution of the target GPU program stored in registers and / or memory.

[0061] S208: Receives debug commands from the debugger during the execution of the interrupt agent and performs debugging based on the debug commands and the saved program execution data.

[0062] After saving the running data of each program, the interrupt agent program executes a loop waiting subroutine to receive debugging commands from the debugger.

[0063] Optionally, the debugging commands also include at least one of the following: register read / write commands, memory read / write commands, single-step execution commands, and continue execution commands. Register read / write commands and memory read / write commands are used to modify program execution data, etc. Single-step execution commands are used to execute any instruction in the target GPU program. Single-step execution commands can execute the original instruction that was replaced, or any instruction following the original instruction that was replaced, but the order of the instructions executed in the target GPU program must be explicitly specified. Continue execution commands are used to instruct the interrupt agent to execute the program execution data recovery subroutine to restore the context of the target GPU program and jump to the corresponding location in the target GPU program to continue execution.

[0064] The debugging process involves executing the single-step instructions corresponding to the single-step execution commands. Executing single-step instructions requires first restoring the saved program execution data, and then executing the single-step instructions based on this restored data. After execution, the debugging result can be determined based on the program execution data obtained from the single-step instructions. It should be noted that the GPU in this application can generate the debugging result based on the program execution data, or it can choose not to generate the result and allow the user to determine it. For example, the debugging result can be automatically generated by the GPU based on the program execution data obtained from the single-step instructions, or it can be determined by the user based on the execution results of the single-step instructions. There is no restriction on how the debugging result is obtained.

[0065] The aforementioned GPU interrupt debugging method, upon detecting a breakpoint set in the target GPU program, generates an interrupt proxy program corresponding to the breakpoint, replaces the original instructions with the target instructions, and jumps from the target GPU program to the interrupt proxy program when the target instructions are executed; executes the interrupt proxy program and saves the program execution data corresponding to the execution of the target GPU program; during the execution of the interrupt proxy program, it receives debugging commands from the debugger and performs debugging based on the debugging commands and the saved program execution data. Interrupt debugging can be achieved through the software interrupt proxy program, without hardware limitations.

[0066] In some optional embodiments, executing an interrupt proxy includes: acquiring an execution lock if no other interrupt proxy is currently executing; acquiring an execution lock after waiting for the other interrupt proxy to finish executing if other interrupt proxies are currently executing; and continuing to execute the steps of executing the interrupt proxy if the execution lock is acquired.

[0067] Among them, the combination Figure 2As shown, optionally, the interrupt proxy can include a lock acquisition subroutine, that is, maintain a lock-based mutual exclusion mechanism inside the interrupt proxy to ensure that in a multi-threaded concurrent scenario, only one thread is allowed to enter debug mode, while other thread threads are blocked.

[0068] Therefore, after jumping to the interrupt proxy, the lock acquisition subroutine is executed first. This lock acquisition subroutine is used to check whether there are other interrupt proxies being executed. If there are, it waits for the other interrupt proxies to finish executing before acquiring the lock. If there are no other interrupt proxies being executed, it directly acquires the lock and enters the interrupt.

[0069] In the above embodiments, a mutual exclusion control mechanism is introduced to prevent multiple thread warp from competing for access, thus preventing context chaos caused by multiple thread warp entering the breakpoint proxy area at the same time.

[0070] In some optional embodiments, the interrupt agent includes a loop wait subroutine; receiving debug commands from the debugger during the execution of the interrupt agent includes: receiving debug commands from the debugger based on the shared memory mechanism between the GPU and the host during the execution of the loop wait subroutine.

[0071] The interrupt proxy includes a loop-wait subroutine for receiving debug commands from the debugger. After executing the lock acquisition subroutine, the interrupt proxy executes the program execution data saving subroutine, and after saving the program execution data, it executes the loop-wait subroutine.

[0072] The debugger's debugging commands are transmitted based on the shared memory mechanism between the GPU and the host. This shared memory can be a segment of memory allocated and mapped after an interrupt agent is generated when a breakpoint is reached in the target GPU program, for communication between the interrupt agent in the host and the GPU.

[0073] In the above embodiments, a command loop and debugger interaction protocol are introduced to realize remote command control (step execution command, continue execution command, read command, write command, etc.).

[0074] In some optional embodiments, the debugging command includes a single-step execution command; debugging is performed based on the debugging command and the saved program execution data, including: modifying the single-step instruction corresponding to the single-step execution command to obtain the modified single-step instruction, wherein the single-step instruction is an instruction in the target GPU program; setting the last instruction of the interrupt proxy program as the first jump instruction, and storing the modified single-step instruction in the interrupt proxy program, wherein the first jump instruction is used to jump to the next instruction of the single-step instruction; performing data recovery based on the previously saved program execution data, and executing the modified single-step instruction after the program execution data is recovered; after the modified single-step instruction is executed, saving the program execution data after the single-step instruction is executed as new program execution data, and continuing to execute the steps of receiving the debugger's debugging command during the execution of the interrupt proxy program.

[0075] The single-step execution command is used to execute a single instruction in the target GPU program. This single instruction is called the single-step instruction. The single-step instruction can include the original instruction located at the breakpoint and any instruction that follows the original instruction. To ensure execution accuracy, since the program counter values ​​of the instructions in the interrupt proxy program and the instructions in the GPU may differ, it is necessary to modify the original instruction located at the breakpoint and any instruction that follows the original instruction to obtain the modified single-step instruction.

[0076] Among them, the combination Figure 5 As shown, when each single-step instruction is executed, the nop instruction needs to be set as the next instruction after the single-step instruction. That is, the last instruction of the interrupt proxy program is set as the first jump instruction. The single-step instruction is stored in the single-step execution instruction command body of the interrupt proxy program. This single-step execution instruction command body includes a program execution data recovery subroutine and a program execution data saving subroutine. That is, after storing the single-step instruction in the single-step execution instruction command body of the interrupt proxy program, the data is restored based on the previously saved program execution data. Then, the modified single-step instruction is executed. Finally, after the modified single-step instruction is executed, the program execution data after the single-step instruction is executed is saved as the new program execution data. This completes one debugging cycle. The loop waiting subroutine is then executed again.

[0077] If further single-step instructions are required, the debugger will continue to receive the next single-step execution command and debug according to the above logic.

[0078] In some optional embodiments, the debugging command includes a continue execution command; generating an interrupt proxy corresponding to the breakpoint, including: obtaining a pre-compiled interrupt proxy template, setting the last instruction of the interrupt proxy template as a second jump instruction, obtaining the interrupt proxy corresponding to the breakpoint, the second jump instruction being used to jump to the instruction following the original instruction; debugging based on the debugging command and the saved program execution data, including: when the debugging command is a continue execution command, performing data recovery based on the saved program execution data, and continuing to execute the second jump instruction after the program execution data is recovered.

[0079] When generating the interrupt proxy, the last instruction needs to be set, that is, the nop instruction is replaced with the second jump instruction, which is used to jump to the instruction after the original instruction located at the breakpoint. If no single-step execution command is received subsequently, the second jump instruction remains unchanged. If a single-step execution command is received, the corresponding second jump instruction is replaced with the instruction after the single-step instruction corresponding to the single-step execution command, that is, the first jump instruction.

[0080] The debugger then sends a continue execution command to the interrupt agent to end the current debugging session. Upon receiving the continue execution command, the interrupt agent restores the saved program execution data and, after the program execution data is restored, executes the second jump instruction to jump to the next instruction after the original instruction, thereby re-executing the GPU program and ending the current debugging session.

[0081] After the program runs and the data is restored, the lock needs to be released, and after the lock is released, the second jump instruction, which replaces the nop instruction, is executed.

[0082] For ease of understanding, a complete embodiment of this application is provided, including:

[0083] First, the target GPU program includes breakpoint markers. When the GPU executes the target GPU program and detects a breakpoint, an interrupt proxy is generated based on the original instruction at the breakpoint location. For example, the last instruction in the interrupt proxy, the nop instruction, is replaced with a second jump instruction. This second jump instruction points to the instruction following the original instruction at the breakpoint location in the target GPU program. Figure 3 Instruction 2 in the original instruction is the original instruction, and its next instruction can be instruction 3 or instruction 4 (when instruction 2 is a jump instruction).

[0084] Secondly, the original instructions at the breakpoints in the target GPU program are replaced with target instructions. These target instructions are used to jump from the target GPU program to the generated interrupt agent. Then, a memory segment is allocated and mapped for communication between the interrupt agent in the host and the GPU.

[0085] Third, after the replacement is completed, the target instruction is executed, and the process jumps to the lock acquisition subroutine of the interrupt agent. The lock acquisition subroutine checks whether there are other interrupt agents that are currently being executed. If there are, the process waits for the other interrupt agents to finish executing before acquiring the execution lock; otherwise, the lock is acquired directly.

[0086] Fourth, after the interrupt agent acquires the lock, it continues to execute the program execution data saving subroutine in the interrupt agent to save the data in each register and memory when the target GPU program is executed.

[0087] Fifth, after the program's execution data is saved, the loop wait subroutine in the interrupt agent program continues to execute. In this loop wait subroutine, debug commands sent by the debugger can be received, including register read / write commands, memory read / write commands, single-step execution commands, and continue execution commands.

[0088] Sixth, upon receiving a single-step execution command, the `nop` instruction needs to be set as the next instruction after the single-step instruction. This means setting the last instruction of the interrupt proxy to the first jump instruction. Note that the original `nop` instruction has been replaced with the second jump instruction; therefore, the second jump instruction is replaced with the first jump instruction. The modified single-step instruction (see above for details on the modification method) is then stored in the single-step execution command body of the interrupt proxy. This single-step execution command body includes a program execution data recovery subroutine and a program execution data saving subroutine. After storing the single-step instruction in the interrupt proxy's single-step execution command body, data recovery is performed based on the previously saved program execution data. Then, the modified single-step instruction is executed. Finally, after the modified single-step instruction completes its execution, the program execution data after the single-step instruction is executed is saved as the new program execution data. This completes one debugging cycle, and the loop waiting subroutine continues to execute.

[0089] Seventh, after receiving the continue execution command sent by the debugger, the interrupt agent restores the data based on the saved program execution data, and continues to execute the first jump instruction whose nop instruction was replaced after the program execution data is restored. This allows the interrupt agent to jump to the target GPU program to ensure the correct execution of subsequent steps.

[0090] The aforementioned GPU interrupt debugging methods include: a mechanism for implementing GPU interrupt response in pure software, including generating interrupt handlers (bphandler), instruction substitution, command loops, and locking mechanisms; an execution mechanism that uses jump instructions to simulate breakpoint behavior in the GPU program; a method for saving and restoring the GPU thread bundle execution context through software; the introduction of a command loop and debugger interaction protocol for remote command control (step, continue, read, write, etc.); and the introduction of a mutual exclusion control mechanism for multiple warps competing for access, preventing context chaos caused by multiple warps entering the breakpoint handler area simultaneously.

[0091] This application relies entirely on the GPU's general-purpose instruction set to implement interrupt control logic, without requiring modifications to the GPU hardware architecture or the addition of dedicated registers. Therefore, it allows for rapid migration between different GPU architectures, requiring only adaptation at the driver or debug layer, significantly reducing development and maintenance costs.

[0092] It can seamlessly integrate with existing CPU debugging frameworks (such as GDB) to achieve a unified debugging experience. It supports runtime command communication mechanisms and can flexibly expand functions such as instruction access, register operation, and thread control according to debugging needs.

[0093] Compared with traditional hardware interrupts, the interrupt response logic of this application is completely controlled by software, and the interrupt trigger point and recovery strategy can be dynamically adjusted according to different debugging states (single-step execution, conditional breakpoints, exception detection).

[0094] Traditional GPU debugging mechanisms rely on hardware debugging interfaces (such as JTAG and dedicated registers), while this application can achieve the same result simply through instruction substitution and control flow jumps. Therefore, even if the hardware debugging interface is restricted or not open, debugging interruption can still be implemented in user space.

[0095] The debugging interrupt logic is managed uniformly by the host software, which can strictly limit the interrupt triggering range and recovery conditions.

[0096] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0097] Based on the same inventive concept, this application also provides a GPU interrupt debugging apparatus for implementing the GPU interrupt debugging method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more GPU interrupt debugging apparatus embodiments provided below can be found in the limitations of the GPU interrupt debugging method described above, and will not be repeated here.

[0098] In one exemplary embodiment, such as Figure 6 As shown, a GPU interrupt debugging device is provided, including: a generation module 601, a jump module 602, a saving module 603, and a debugging module 604, wherein:

[0099] The generation module 601 is used to generate an interrupt proxy program corresponding to the breakpoint when a breakpoint is detected in the target GPU program, wherein the target GPU program is the target GPU program that is currently being executed.

[0100] The jump module 602 is used to replace the original instruction at the breakpoint with the target instruction, and, if the target instruction is executed, jump from the target GPU program to the interrupt agent.

[0101] The storage module 603 is used to execute the interrupt proxy program and save the running data of each program corresponding to the target GPU program.

[0102] The debugging module 604 is used to receive debugging commands from the debugger during the execution of the interrupt agent program, and to perform debugging based on the debugging commands and the saved program execution data.

[0103] In some optional embodiments, the aforementioned saving module 603 is further configured to acquire an execution lock if no other interrupt proxy is being executed; if other interrupt proxy is being executed, wait for the other interrupt proxy to finish executing before acquiring the execution lock; and if the execution lock is acquired, continue executing the steps of the interrupt proxy.

[0104] In some alternative embodiments, the interrupt agent includes a loop wait subroutine; the aforementioned debug module 604 is specifically used to receive debug commands from the debugger based on the shared memory mechanism of the GPU and CPU during the execution of the loop wait subroutine.

[0105] In some optional embodiments, the debugging command includes a single-step execution command; the debugging module 604 is specifically used to modify the single-step instruction corresponding to the single-step execution command to obtain the modified single-step instruction, which is an instruction in the target GPU program; set the last instruction of the interrupt proxy program as the first jump instruction, and store the modified single-step instruction in the interrupt proxy program, the first jump instruction being used to jump to the next instruction of the single-step instruction; perform data recovery based on the previously saved program running data, and execute the modified single-step instruction after the program running data is recovered; after the modified single-step instruction is executed, save the program running data after the single-step instruction is executed as new program running data, and continue to execute the step of receiving the debugger's debugging command during the execution of the interrupt proxy program.

[0106] In some optional embodiments, the debugging command includes a continue execution command; the generation module 601 is specifically used to obtain a pre-compiled interrupt proxy template, set the last instruction of the interrupt proxy template as a second jump instruction, obtain the interrupt proxy corresponding to the breakpoint, and the second jump instruction is used to jump to the next instruction after the original instruction; the debugging module 604 is specifically used to perform data recovery based on the saved program running data when the debugging command is a continue execution command, and continue to execute the second jump instruction after the program running data is recovered.

[0107] In some optional embodiments, the generation module 601 is specifically used to generate an interrupt proxy program by any of the following methods: obtaining a pre-compiled interrupt proxy program template, generating a third jump instruction, the third jump instruction being used to jump to the instruction following the original instruction, replacing the last instruction in the pre-compiled interrupt proxy program template with the third jump instruction to obtain the interrupt proxy program; or, obtaining an uncompiled interrupt proxy program template, generating a fourth jump instruction, the fourth jump instruction being used to jump to the instruction following the original instruction, replacing the last instruction in the uncompiled interrupt proxy program template with the fourth jump instruction, and compiling the interrupt proxy program template after variable replacement to obtain the interrupt proxy program.

[0108] Each module in the aforementioned GPU interrupt debugging device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0109] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 7 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a GPU interrupt debugging method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0110] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0111] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0112] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0113] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0114] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0115] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0116] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0117] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A GPU interrupt debugging method, characterized in that, The method includes: If a breakpoint is detected in the target GPU program, an interrupt proxy program corresponding to the breakpoint is generated, wherein the target GPU program is the target GPU program that is currently being executed. Replace the original instruction at the breakpoint with the target instruction, and if the target instruction is executed, jump from the target GPU program to the interrupt proxy. Execute the interrupt proxy program and save the execution data of each program corresponding to the target GPU program; During the execution of the interrupt agent, the debugger receives debug commands and performs debugging based on the debug commands and the saved program execution data.

2. The method according to claim 1, characterized in that, The execution of the interrupt proxy program includes: Acquire the execution lock if no other interrupt agent is currently executing; If other interrupt agents are in execution, wait for them to finish executing before acquiring the execution lock; If the execution lock is acquired, the step of executing the interrupt agent program continues.

3. The method according to claim 1, characterized in that, The interrupt proxy includes a loop waiting subroutine; receiving debug commands from the debugger during the execution of the interrupt proxy includes: During the execution of the loop waiting subroutine, debug commands from the debugger are received based on the shared memory mechanism between the GPU and CPU.

4. The method according to claim 1, characterized in that, The debugging commands include single-step execution commands; the debugging based on the debugging commands and the saved program execution data includes: Modify the single-step instruction corresponding to the single-step execution command to obtain the modified single-step instruction, wherein the single-step instruction is an instruction in the target GPU program; The last instruction of the interrupt proxy is set as the first jump instruction, and the modified single-step instruction is stored in the interrupt proxy. The first jump instruction is used to jump to the next instruction of the single-step instruction. Data recovery is performed based on the previously saved program execution data, and after the program execution data is recovered, the modified single-step instructions are executed. After the modified single-step instruction is executed, the program execution data after the single-step instruction is executed is saved as the new program execution data, and the step of receiving the debugger's debugging command during the execution of the interrupt agent program continues.

5. The method according to claim 1, characterized in that, The debugging commands include a continue execution command; the generation of the interrupt proxy program corresponding to the breakpoint includes: Obtain a pre-compiled interrupt proxy template, set the last instruction of the interrupt proxy template as the second jump instruction, and obtain the interrupt proxy corresponding to the breakpoint. The second jump instruction is used to jump to the next instruction after the original instruction. The debugging based on the debugging commands and the saved program execution data includes: If the debugging command is a continue execution command, data recovery is performed based on the saved program execution data, and the second jump instruction is executed again after the program execution data is recovered.

6. The method according to any one of claims 1 to 5, characterized in that, The generation of the interrupt proxy program corresponding to the breakpoint includes any one of the following: Obtain a pre-compiled interrupt proxy template, generate a third jump instruction, the third jump instruction is used to jump to the instruction after the original instruction, and replace the last instruction in the pre-compiled interrupt proxy template with the third jump instruction to obtain the interrupt proxy; or, Obtain an uncompiled interrupt proxy template, generate a fourth jump instruction, which is used to jump to the instruction following the original instruction, replace the last instruction in the uncompiled interrupt proxy template with the fourth jump instruction, and compile the interrupt proxy template after variable replacement to obtain the interrupt proxy program.

7. A GPU interrupt debugging device, characterized in that, The device includes: A generation module is used to generate an interrupt proxy program corresponding to a breakpoint when a breakpoint is detected in the target GPU program, wherein the target GPU program is the target GPU program that is currently being executed. A jump module is used to replace the original instruction at the breakpoint with the target instruction, and, if the target instruction is executed, jump from the target GPU program to the interrupt proxy program; The storage module is used to execute the interrupt proxy program and save the running data of each program corresponding to the execution of the target GPU program; The debugging module is used to receive debugging commands from the debugger during the execution of the interrupt agent program, and to perform debugging based on the debugging commands and the saved program execution data.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images