Debugging method for eBPF processor

Abstract

The invention discloses a debugging method for an eBPF processor, which comprises the following steps: selecting a target instruction of a to-be-set breakpoint in an interactive interface of a debugging platform, and acquiring an address of the target instruction by the debugging platform; setting a breakpoint at the position of the target instruction through the debugging platform, fusing the address of a breakpoint setting command and the address of the target instruction into a breakpoint instruction through the debugging platform, and sending the breakpoint instruction to the eBPF processor through the debugging interface; after the debugging control module receives the breakpoint instructions, backing up an original instruction of a target address, storing a target instruction in the breakpoint instructions into an instruction storage module of the eBPF processor, and replacing the target instruction with a breakpoint entry instruction; and after the eBPF processor starts to run and stops executing at the breakpoint position, the debugging control module retrieves the target instruction from the instruction storage module and restores the replaced breakpoint entry instruction into the target instruction. According to the embodiment, the problem that the eBPF processor does not support operations such as interrupt debugging is solved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a debugging method for an eBPF processor. Background Art

[0002] Support for eBPF (extended Berkeley Packet Filter) programs is a key feature of the Linux kernel. eBPF defines a general-purpose RISC instruction set that has been widely adopted due to its simplicity and efficiency. While eBPF programs typically run within the Linux kernel, some developers also develop and run eBPF programs in user mode. Processor (CPU) chips have also been developed that can directly run eBPF instructions, known as eBPF CPUs or hBPF CPUs.

[0003] The eBPF CPU / processor has great technical potential and a wide range of application scenarios, and is attracting industry attention. However, currently, no eBPF CPU offers debugging capabilities similar to those found on ARM and RISC-V CPUs. This is because the eBPF instruction set architecture (ISA) lacks a mechanism for triggering the executor (CPU) to enter a debugging state. The eBPF ISA definition is simple, lacking pause instructions such as stall / pause, and even fewer dedicated debugging instructions. Furthermore, the eBPF specification does not support hardware interrupt execution. This poses challenges in designing debugging mechanisms and circuitry for eBPF CPUs, significantly complicating program development for eBPF CPUs and hindering the development, promotion, and application of eBPF CPUs. Summary of the Invention

[0004] In view of this, an embodiment of the present invention provides a debugging method for an eBPF processor to solve the problem of lack of a debugging mechanism for the eBPF processor in the prior art.

[0005] An embodiment of the present invention provides a debugging method for an eBPF processor, comprising: Download the program code to be debugged to the eBPF processor through the debugging platform; Select the target instruction for setting a breakpoint in the interactive interface of the debugging platform, and the debugging platform obtains the address of the target instruction; A breakpoint is set at the target instruction location through the debugging platform. The debugging platform merges the breakpoint setting command and the address of the target instruction into a breakpoint instruction, and sends the breakpoint instruction to the eBPF processor through the debugging interface. After receiving the breakpoint instruction, the debug control module of the eBPF processor first backs up the target instruction to obtain the original instruction, and then replaces the target instruction with the breakpoint entry instruction; After the eBPF processor starts running and stops at the breakpoint, the replaced breakpoint entry instruction is restored to the original instruction; During the design phase of the eBPF processor, communication relationships are established between the debug control module and the instruction fetch component, the instruction storage module, and the execution component. A new enumeration type is extended in the kernel module of the eBPF processor and defined as the debug program entry, namely the breakpoint entry instruction.

[0006] Optionally, it also includes: During the debugging process, the debugging platform converts the user's software operations into debugging instructions, which are then sent to the eBPF processor through the debugging interface to implement specific debugging steps. Among them, the debugging instruction functions include single-step execution, breakpoint continuation, pause, reading and writing internal registers, reading and writing instructions, and accessing the internal stack space of the eBPF processor; the debugging instructions are coordinated and supported by the software and hardware ends. The software end is responsible for generating instruction codes that can be recognized by the hardware end through the protocol converter according to user operations, and sending them to the hardware end through the debugging interface; the hardware end is responsible for receiving and decoding the instruction codes sent by the software end, and generating a request corresponding to the debugging instruction function and sending it to the execution component to complete access operations, and to the instruction fetch component to complete run operations.

[0007] Optionally, it also includes: Expand the bpf_prog_type enumeration in the eBPF processor kernel module to include BPF_PROG_TYPE_DEBUG as a new enumeration type. Synchronously define BPF_PROG_TYPE_DEBUG on the software program side as the debugging entry program.

[0008] Optionally, the debug control module is configured to: After receiving the breakpoint instruction from the debugging platform, a read operation command corresponding to the target instruction address is issued to the instruction storage component according to the breakpoint address carried by the breakpoint instruction, and the read target instruction is stored in the storage unit of the debugging control module as the original instruction; a write operation command is issued to the instruction storage module to write the breakpoint entry instruction to the target instruction location.

[0009] Optionally, the debug control module is configured to: After setting a breakpoint, when a run command is received from the debugging platform, if the eBPF processor stops because it reaches the breakpoint, it sends a write operation command to the instruction storage module to write the original instruction back to the target instruction location; after waiting for the user to send a run command to the eBPF processor through the software end, it notifies the instruction fetch module to continue fetching instructions, so that the eBPF processor continues to run.

[0010] Optionally, the debug control module is configured to: After setting the breakpoint and starting the operation, when the eBPF processor executes to the breakpoint position, the execution component decodes the current instruction and finds it to be a breakpoint instruction, and transfers it to the debug control module, which then sends a debug pause request to the instruction fetch component.

[0011] Optionally, it also includes: After receiving the debug pause request, the instruction fetch component stops fetching instructions at the appropriate execution location, causing the eBPF processor to stop executing. The judgment conditions for the appropriate execution location include: after the current instruction operation step is completed and before the next instruction operation step begins, and without affecting the correctness of the current instruction pipeline.

[0012] Optionally, it also includes: When the instruction fetch unit fetches the breakpoint entry instruction, the decoder of the eBPF processor interprets the breakpoint entry instruction as a jump instruction. Based on the address carried by the breakpoint entry instruction, it jumps to the address and executes the corresponding program. After the execution is completed, the subsequent program is continued through the return of c. The instruction fetch component also translates the breakpoint entry instruction into an instruction with a breakpoint function. After receiving the breakpoint entry instruction, the execution component sends a debug pause request to the debug control module. The debug control module is responsible for stopping subsequent instructions by sending a debug pause request to the instruction fetch component.

[0013] Optionally, the debugging control module communicates with the debugging platform via a JTAG interface.

[0014] Beneficial effects of the present invention: An embodiment of the present invention provides a debugging method for an eBPF processor. Without adding additional eBPF instructions or interrupt mechanisms, this method packages a hardware debugging module into an eBPF function and extends a debug entry instruction within the kernel module, enabling the eBPF core to enter debug mode upon executing this debug entry instruction. This addresses issues such as eBPF's lack of pause / stall instructions and interrupt support. These basic functions are fundamental to the design and development of debugging hardware and software for chips such as MCUs and DSPs. If the eBPF CPU supports debugging capabilities (primarily including receiving and decoding debug commands from the debug interface, and accessing and controlling the instruction fetch / execution / instruction storage modules), MCU debugging functions such as setting breakpoints, viewing registers, and memory can be implemented. Related technical solutions can be developed with reference to ARM and RISC-V architectures, ultimately enabling the further development and application of eBPF CPUs. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The features and advantages of the present invention will be more clearly understood by referring to the accompanying drawings, which are schematic and should not be construed as limiting the present invention in any way. In the accompanying drawings: Figure 1 A schematic diagram of the hardware structure used in a debugging method for an eBPF processor in an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0016] To make the purpose, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making any creative efforts shall fall within the scope of protection of the present invention.

[0017] like Figure 1 As shown, an embodiment of the present invention provides a debugging method for an eBPF processor, including: Step 1: Download the program code to be debugged to the eBPF processor through the debugging platform.

[0018] Step 2: Select the target instruction for setting a breakpoint in the interactive interface of the debugging platform, and the debugging platform obtains the address of the target instruction.

[0019] Step 3: Set a breakpoint at the target instruction location through the debugging platform. The debugging platform merges the breakpoint setting command and the address of the target instruction into a breakpoint instruction, and sends the above instruction to the eBPF processor through the debugging interface (such as JTAG).

[0020] Step 4: The debug control module of the eBPF processor receives and decodes the instruction, confirms it is a breakpoint instruction, and replaces the target instruction with the breakpoint entry instruction.

[0021] In step 5, after the eBPF processor starts running and stops at the breakpoint location, the replaced breakpoint entry instruction is restored to the target instruction.

[0022] During the design phase of the eBPF processor, communication relationships are established between the debug control module and the instruction fetch component, instruction storage module, and execution component. A breakpoint function decoding for a new enumeration type is added to the execution component of the eBPF processor. That is, when the instruction code corresponding to the enumeration type is decoded, a simulation pause request is sent to the debug control module, and the above enumeration type is defined as the debug program entry, that is, the breakpoint entry instruction.

[0023] During the hardware encapsulation process of the eBPF processor core, access paths are set between the debug control module and the instruction fetch unit, instruction memory, and execution unit.

[0024] As an optional implementation, it also includes: during the debugging process, the debugging platform converts the user's software operations into debugging instructions, and sends the above instructions to the eBPF processor through the debugging interface to implement specific debugging operation steps; wherein, the debugging commands issued by the debugging platform include single-step execution, reading and writing internal registers, reading and writing instructions, accessing the internal stack space of the eBPF processor, and continuing to run at breakpoints; the debugging instructions are coordinated and supported by the software / hardware end, and the software end is responsible for generating hardware-recognizable instruction codes based on user operations through a protocol converter (such as USB to JTAG), and sending them to the hardware end (eBPF processor) through the debugging interface; the hardware end is responsible for receiving and decoding the instruction codes sent by the software end, and generating requests corresponding to the above-mentioned debugging instruction functions and sending them to the execution component to complete read / write access operations, and to the instruction fetch component to complete single-step execution / continue running / pause and other running operations.

[0025] As an optional implementation, it also includes: Expand the bpf_prog_type enumeration in the eBPF processor kernel module to include BPF_PROG_TYPE_DEBUG as a new enumeration type. Synchronously define BPF_PROG_TYPE_DEBUG on the software program side as the debugging entry program.

[0026] In this embodiment, since bpf_prog_type is an enumeration variable, BPF_PROG_TYPE_DEBUG can be added directly as a new enumeration type. Adding this enumeration type requires simultaneously defining a BPF_PROG_TYPE_DEBUG entry point in the software. The advantage of adding this debug entry point is that after the program jumps to the debug entry point, a series of routines can be executed before returning to the original function. This routine can include checksums such as register matching, data matching, and memory access result matching, making it very flexible and easy to add as needed.

[0027] As an optional implementation, the debug control module is configured to: After receiving the breakpoint instruction from the debugging platform, a read operation command corresponding to the target instruction address is issued to the instruction storage component according to the breakpoint address carried by the breakpoint instruction, and the read target instruction is stored in the storage unit of the debugging control module; a write operation command is issued to the instruction storage module to write the breakpoint entry instruction to the target instruction location.

[0028] After setting a breakpoint, when a run command is received from the debugging platform, if the eBPF processor stops because it reaches the breakpoint, it sends a write operation command to the instruction storage module to write back the target original instruction to the target instruction location; after waiting for the user to send a run command to the eBPF processor through the software end, it notifies the instruction fetch module to continue fetching instructions so that the processor continues to run.

[0029] After setting the breakpoint, when a stop command is received from the debugging platform, a debug pause request is sent to the instruction fetch unit.

[0030] As an optional implementation, after the instruction fetch component receives a debug pause request, it stops fetching instructions at a suitable execution location, causing the eBPF processor to stop executing; wherein, the judgment conditions for the suitable execution location include: after the current instruction operation step is completed and before the next instruction operation step begins, and without affecting the correctness of the current instruction pipeline.

[0031] As an optional implementation, when the instruction fetch unit fetches a breakpoint entry instruction, the decoding unit of the eBPF processor interprets the breakpoint entry instruction as a jump instruction; based on the address carried by the breakpoint entry instruction, it jumps to the address and executes the corresponding program. After the execution is completed, the subsequent program is continued through the return of c; The instruction fetch component also translates the breakpoint entry instruction into an instruction that carries the breakpoint function. After receiving the breakpoint entry instruction, the execution component sends a debug pause request to the debug control module, and the debug control module is responsible for stopping subsequent instructions. The stopping method is to send a debug pause (i.e., stop instruction fetching) request to the instruction fetch component.

[0032] As an optional implementation, the debugging control module communicates with the debugging platform via a JTAG interface.

[0033] This embodiment designs a mechanism for entering a debug state for the eBPF processor. This mechanism enables the development of debugging software and hardware similar to those used for ARM / RISC-V CPUs, such as setting breakpoints on eBPF programs, single-stepping, and inspecting memory and register variables. Furthermore, C programs can be debugged in an IDE, similar to MCU development environments that typically support C / C++ language development.

[0034] When a breakpoint needs to be set, the debugging platform integrates a breakpoint command with the breakpoint address according to the breakpoint location set by the user, and sends it to the eBPF processor using a debugging interface (such as JTAG). The hardware debugging module in the eBPF processor receives and decodes the breakpoint command. After the hardware debugging module receives the breakpoint command, it first reads out the instruction containing the breakpoint address and then rewrites it into a BPF_SYSCALL BPF_PROG_DEBUG instruction. It then uses the BFP auxiliary function to extend the definition of a BPF_PROG_DEBUG entry.

[0035] The hardware debugging module monitors whether the execution component has decoded the breakpoint instruction and sends a debugging pause request to the debugging module. When it finds that the BPF_SYSCALLBPF_PROG_DEBUG instruction is executed, the debugging module controls the instruction fetch component to stop fetching instructions. At this time, the BPF processor core no longer performs instruction fetch operations and the BPF processor is in a paused state. This enables the debugging platform to issue access-class debugging commands according to user needs to view the register and memory information inside the eBPF processor core at this time.

[0036] In the breakpoint state, the debugging platform initiates a breakpoint continue command, and after it is received by the hardware debugging module, the hardware debugging module writes back the instructions at the original breakpoint, enables the instruction fetch component, and re-fetches instructions for execution from the breakpoint.

[0037] In the breakpoint state, the debugging platform initiates a single-step execution command, which is received by the hardware debugging module. The hardware debugging module writes back the instruction at the original breakpoint and initiates an instruction fetch request. The instruction fetch component fetches the instruction at the breakpoint and sends it to the subsequent platform and stops. Subsequently, whenever the eBPF processor core initiates a single-step execution command, the instruction fetch component fetches an instruction and executes it.

[0038] In the breakpoint state, if it is necessary to read or write the internal register, the debugging platform initiates the first read / write command, and after being received by the hardware debugging module, the hardware debugging control module initiates the first read / write command. The parameters carried in the first read / write command are the register number and the first data to be written; after receiving the first read / write command, the hardware debugging module reuses the BPF instruction set and the existing core path, encodes the first read / write command into a special register transfer instruction, and sends it to the execution component to read the required register or write data to the target register. If it is a read command, the read-back data must be sent back to the debugging platform through the debugging interface. At this time, the user can observe the reading result of the corresponding register in the debugging platform.

[0039] In the breakpoint state, if it is necessary to read or write the internal stack space of the eBPF processor, the debugging platform initiates a first read / write command, and after being received by the hardware debugging module, the hardware debugging module initiates a second read / write command. The parameters carried by the second read / write command are the memory access address and the second data to be written; after receiving the second read / write command, the hardware debugging module reuses the BPF instruction set and the existing core path, encodes the second read / write command into a special memory access instruction, and sends it to the execution component, initiating a memory access request to the eBPF core stack storage space, reading the required storage space data, or writing data to the target address. If it is a read command, the read-back data must be returned to the debugging platform through the debugging interface. At this time, the user can observe the reading result of the corresponding stack in the debugging platform.

[0040] The embodiment of the present invention provides a debugging function triggering method based on the eBPF CPU. Without adding additional eBPF instructions or interrupt mechanisms, by packaging the hardware debugging module into an eBPF function, the eBPF core can enter debugging mode when executing the instruction, thereby solving the problems of eBPF not having pause / stall instructions and not supporting interrupts. These basic functions are the basis for designing and developing debugging software and hardware for chips such as MCU / DSP. If the eBPF CPU has the ability to support debugging functions, MCU debugging functions such as setting breakpoints, viewing registers and memory can be realized. Related technical solutions can be developed with reference to ARM and RISCV, ultimately realizing the further development and promotion of the eBPF CPU.

[0041] The following is an explanation using examples at the software and hardware levels: Software level: BPF debug commands are extended through the eBPF system call interface, and debug functions are defined and packaged. For example, BPF_PROG_TYPE_DEEBUG is a newly extended command dedicated to debugging: enum bpf_prog_type { BPF_PROG_TYPE_UNSPEC, / * Reserve 0 as invalid program type * / BPF_PROG_TYPE_SOCKET_FILTER, BPF_PROG_TYPE_KPROBE, BPF_PROG_TYPE_SCHED_CLS, BPF_PROG_TYPE_SCHED_ACT, BPF_PROG_TYPE_TRACEPOINT, BPF_PROG_TYPE_XDP, BPF_PROG_TYPE_PERF_EVENT, BPF_PROG_TYPE_CGROUP_SKB, BPF_PROG_TYPE_CGROUP_SOCK, BPF_PROG_TYPE_LWT_IN, BPF_PROG_TYPE_LWT_OUT, BPF_PROG_TYPE_LWT_XMIT, BPF_PROG_TYPE_SOCK_OPS, BPF_PROG_TYPE_SK_SKB, BPF_PROG_TYPE_CGROUP_DEVICE, BPF_PROG_TYPE_SK_MSG, BPF_PROG_TYPE_RAW_TRACEPOINT, BPF_PROG_TYPE_CGROUP_SOCK_ADDR, BPF_PROG_TYPE_LWT_SEG6LOCAL, BPF_PROG_TYPE_LIRC_MODE2, BPF_PROG_TYPE_SK_REUSEPORT, BPF_PROG_TYPE_FLOW_DISSECTOR, BPF_PROG_TYPE_DEBUG / * See / usr / include / linux / bpf.h for the full list. * / }; The following describes the newly extended BPF system call debugging function: For the system call wrapper, __NR_bpf is the system call number corresponding to bpf. All BPF-related operations interact with the kernel through this system call: int bpf(enum bpf_cmd cmd, union bpf_attr *attr, unsigned int size) { return syscall(__NR_bpf, cmd, attr, size); } Initiate debugging to eBPF through system calls: int bpf_prog_debug(enum bpf_prog_type type, union bpf_attr *attr) { return bpf(BPF_PROG_DEBUG, &attr, sizeof(attr)); } The actual final call is: syscall(__NR_bpf, BPF_PROG_DEBUG, &attr, sizeof(attr)); Hardware level: A hardware debug control module is added to the eBPF processor core. The debug control module has an external interface of JTag and internal access to the instruction memory, instruction fetch unit, execution unit, etc., so that it can set breakpoints in the instruction memory, control the pause and operation of the instruction fetch unit, and set the PC, and read and write core registers and data memory through the execution unit.

[0042] The debugging control commands sent by the JTag interface to the eBPF core include stop execution, single-step execution, full-speed execution, and exit debugging. The stop execution command can control the eBPF core to enter debug mode, and the exit debugging command can control the eBPF core to exit debug mode. When single-stepping, the eBPF core executes one instruction at a time and then stops and waits. When executing at full speed, the eBPF core will continue to execute instructions until a breakpoint is encountered or a stop execution command is received again.

[0043] The debug execution commands sent by the JTag interface to the eBPF core include reading and writing instruction memory (changing instructions, setting breakpoints), reading and writing core registers (including control status registers and general registers, setting PC and initiating DMA), and reading and writing data memory.

[0044] When debugging is initiated to the eBPF core via the JTag interface, the debug control module controls the instruction fetch component to enter debug mode at an appropriate time (pausing instruction fetching and then waiting for the pipeline to be empty). At this point, the eBPF core is stopped at the current PC, and debug control commands or debug execution commands can be sent via the JTag interface to observe or control the running status of the eBPF core.

[0045] Although the embodiments of the present invention have been described with reference to the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention. Such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A debugging method for an eBPF processor, characterized in that: include: Download the program code to be debugged to the eBPF processor through the debugging platform; Selecting a target instruction for setting a breakpoint in an interactive interface of a debugging platform, and obtaining an address of the target instruction by the debugging platform; Setting a breakpoint at the target instruction location by the debugging platform, fusing a breakpoint setting command and the address of the target instruction into a breakpoint instruction by the debugging platform, and sending the breakpoint instruction to the eBPF processor through a debugging interface; After receiving the breakpoint instruction, the debugging control module of the eBPF processor first backs up the target instruction to obtain the original instruction, and then replaces the target instruction with the breakpoint entry instruction; After the eBPF processor starts running and stops at a breakpoint, restoring the replaced breakpoint entry instruction to the original instruction; During the design phase of the eBPF processor, communication relationships are established between the debug control module and the instruction fetch component, and between the instruction storage module and the execution component. A new enumeration type is extended in the kernel module of the eBPF processor and defined as the debug program entry, namely the breakpoint entry instruction.

2. The debugging method for the eBPF processor according to claim 1, characterized in that: Also includes: During the debugging process, the debugging platform converts the user's software operations into debugging instructions, and sends the debugging instructions to the eBPF processor through the debugging interface to implement specific debugging operation steps; The debugging command functions include single-step execution, breakpoint continuation, pause, reading and writing internal registers, reading and writing instructions, and accessing the internal stack space of the eBPF processor; the debugging commands are coordinated and supported by the software and hardware ends. The software end is responsible for generating instruction codes recognizable by the hardware end through the protocol converter based on user operations and sending them to the hardware end through the debugging interface; The hardware end is responsible for receiving and decoding the instruction code sent by the software end, and generating a request corresponding to the debug instruction function and sending it to the execution component to complete the access type operation, and sending it to the instruction fetch component to complete the run type operation.

3. The debugging method for the eBPF processor according to claim 1, characterized in that: Also includes: Expand the bpf_prog_type enumeration in the eBPF processor kernel module to include BPF_PROG_TYPE_DEBUG as a new enumeration type. Synchronously define BPF_PROG_TYPE_DEBUG on the software program side as the debugging entry program.

4. The debugging method for the eBPF processor according to claim 2, characterized in that: The debug control module is configured to: After receiving the breakpoint instruction from the debugging platform, a read operation command corresponding to the target instruction address is issued to the instruction storage component according to the breakpoint address carried by the breakpoint instruction, and the read-back target instruction is stored in the storage unit of the debugging control module as the original instruction; and a write operation command is issued to the instruction storage module to write the breakpoint entry instruction to the target instruction location.

5. The debugging method for the eBPF processor according to claim 4, characterized in that: The debug control module is configured to: After setting a breakpoint, when a run command is received from the debugging platform, if the eBPF processor stops because it reaches the breakpoint, a write operation command is issued to the instruction storage module to write back the original instruction to the target instruction location; after waiting for the user to issue a run command to the eBPF processor through the software end, the instruction fetch module is notified to continue fetching instructions, so that the eBPF processor continues to run.

6. The debugging method for the eBPF processor according to claim 5, characterized in that: The debug control module is configured to: After setting a breakpoint and starting the operation, when the eBPF processor executes to the breakpoint position, the execution component decodes the current instruction and finds that it is a breakpoint instruction, and transfers it to the debug control module, and the debug control module sends a debug pause request to the instruction fetch component.

7. The debugging method for an eBPF processor according to claim 6, wherein: Also includes: After the instruction fetch component receives the debug pause request, it stops fetching instructions at a suitable execution location, causing the eBPF processor to stop executing; wherein, the judgment conditions for the suitable execution location include: after the current instruction operation step is completed and before the next instruction operation step begins, and without affecting the correctness of the current instruction pipeline.

8. The debugging method for an eBPF processor according to claim 1, wherein: Also includes: When the instruction fetch component fetches the breakpoint entry instruction, the decoding component of the eBPF processor interprets the breakpoint entry instruction as a jump instruction; according to the address carried by the breakpoint entry instruction, it jumps to the address to execute the corresponding program, and after the execution is completed, continues to execute the subsequent program through the return of c; The instruction fetch component simultaneously interprets the breakpoint entry instruction as an instruction carrying a breakpoint function. After receiving the breakpoint entry instruction, the execution component sends a debug pause request to the debug control module, and the debug control module is responsible for stopping subsequent instructions. The stopping method is to send a debug pause request to the instruction fetch component.

9. The debugging method for an eBPF processor according to claim 1, wherein: The debugging control module is connected to the debugging platform via a JTAG interface.

Images