A trap management apparatus, processor, chip and electronic device

Abstract

The present disclosure relates to the technical field of computer, and particularly relates to a trap management device, a processor, a chip and an electronic device, which comprises: at least one processing core configured to execute a thread; a processor trap management unit coupled with the at least one processing core; and an interrupt reporting unit coupled with the processor trap management unit; wherein: the processing core suspends execution of the thread and reports a trap event to the processor trap management unit in response to the thread executed therein satisfying a trap condition; and the processor trap management unit performs coordinated management and triggers the interrupt reporting unit to report an interrupt to an external debugger in response to receiving the trap event. According to the embodiment of the present disclosure, the resource utilization efficiency of the processor in a debugging or monitoring scenario can be effectively improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to a trap management device, processor, chip, and electronic device. Background Technology

[0002] In processor design and debugging techniques, trap management is a crucial mechanism for enabling online debugging, program monitoring, and exception handling. Typically, during thread execution, the processor can trigger trap events through preset trap conditions (such as breakpoints, watchpoints, or specific instructions), thereby pausing the execution of the current thread so that the debugger can intervene to perform status checks, data modifications, or flow control.

[0003] In related technologies, a common trap management method relies on software implementation. Specifically, when a trap needs to be triggered, a jump instruction is inserted into the target code to redirect the execution flow to a pre-defined trap handler. This handler typically maintains a suspended state through methods such as looping or hibernation until the debugger issues a resume instruction, at which point it jumps back to the original execution point. This method completely controls the triggering, suspension, and resumption of traps through software instruction flow.

[0004] However, the aforementioned software-implemented trap management method typically involves the trap handler continuously consuming processor execution resources while waiting for the trap event to be processed. This includes front-end pipeline resources such as instruction fetch bandwidth, decoding resources, and issue queues, preventing the processor from fully releasing computing resources for other threads during the waiting phase. Because the processing core continuously occupies hardware resources without performing any actual effective tasks during the trap waiting period, resource utilization is low, and unnecessary power consumption is also incurred. Summary of the Invention

[0005] In view of this, this disclosure proposes a trap management technology solution.

[0006] According to one aspect of this disclosure, a trap management apparatus is provided, comprising: at least one processing core for executing threads; a processor trap management unit coupled to the at least one processing core; and an interrupt reporting unit coupled to the processor trap management unit; wherein:

[0007] The processing core, in response to a thread executing within it satisfying a trap condition, suspends the execution of that thread and reports the trap event to the processor trap management unit;

[0008] The processor trap management unit, in response to receiving the trap event, performs coordination management and triggers the interrupt reporting unit to report the interrupt to the external debugger.

[0009] In one possible implementation, the device further includes a plurality of trap control registers; the trap control registers are used to receive and store configuration information related to trap management.

[0010] In one possible implementation, the processing core includes:

[0011] Instruction unit, used to issue instructions to threads;

[0012] The core trap management unit is coupled to the instruction unit;

[0013] The core trap management unit is used to control the instruction unit to suspend issuing instructions to the corresponding thread and send a trap event to the processor trap management unit in response to the trap condition being met.

[0014] In one possible implementation, the processor trap management unit broadcasts the trap event to other processing cores if it determines, based on the type of the trap event, that the trap event needs to be broadcast to other processing cores.

[0015] In response to a trap event for the target process from the processor trap management unit, any core trap management unit in the device controls its coupled instruction unit to suspend issuing instructions to all threads belonging to the target process.

[0016] In one possible implementation, the core trap management unit, in response to the trap event targeting the target process, controls its coupled instruction unit to pause any newly arriving threads belonging to the target process before they begin executing their first instruction.

[0017] In one possible implementation, the trap control register includes a process trap control register for setting or clearing the trap state of the target process;

[0018] The processor trap management unit, in response to the target process information to be released configured in the process trap control register, performs a trap release operation for the target process. The trap release operation includes: clearing the relevant trap state and broadcasting a trap release signal to all processing cores.

[0019] In response to the trap release signal, any core trap management unit in the device controls the instruction unit to resume sending instructions to the thread belonging to the target process.

[0020] In one possible implementation, the trap control register includes: a thread trap control register for receiving commands to control thread execution or resumption; and a thread trap mask register for specifying the thread to which the commands in the thread trap control register apply.

[0021] The core trap management unit, in response to the thread recovery command configured in the thread trap control register, controls the instruction unit to resume sending instructions to the thread to be recovered according to the thread information to be recovered configured in the thread trap mask register.

[0022] In one possible implementation, the core trap management unit controls the instruction unit to continuously resume transmission, or automatically triggers a new trap to pause the thread again after resuming transmission of a specified number of instructions.

[0023] In one possible implementation, the apparatus further includes a process trap status register and / or a thread trap status register;

[0024] Upon receiving the trap event, the processor trap management unit records the event information in the process trap status register for reading by an external debugger; and / or,

[0025] The thread trap status register updates the state of the corresponding thread after the thread pauses execution and records the reason for the trap being triggered, so that it can be read by an external debugger.

[0026] According to another aspect of this disclosure, a processor is provided that includes any of the trap management devices described above.

[0027] According to another aspect of this disclosure, a chip is also provided, including any of the aforementioned trap management devices.

[0028] According to another aspect of this disclosure, an electronic device is also provided, including any of the aforementioned trap management devices.

[0029] In this embodiment, the processing core, in response to a thread executing within it satisfying a trap condition, suspends the execution of that thread and reports a trap event to the processor trap management unit. The processor trap management unit, in response to receiving the trap event, performs coordination and management, and triggers the interrupt reporting unit to report an interrupt to an external debugger. Thus, when a thread executes and triggers a trap condition, the processing core can promptly suspend the instruction issuance of that thread at the hardware level, preventing the thread from continuously occupying front-end pipeline resources such as fetch bandwidth, decoding resources, and issue queues while waiting for a debugger response. Simultaneously, through the coordination of the processor trap management unit and the hardware interrupt notification mechanism of the interrupt reporting unit, the external debugger can quickly learn of the trap event and process it. This process reduces the ineffective occupation of processor computing resources during the trap suspension phase, helping to improve the processor's resource utilization efficiency in debugging or monitoring scenarios.

[0030] Other features and aspects of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0031] The accompanying drawings, which are included in and form part of this specification, illustrate exemplary embodiments, features, and aspects of this disclosure together with the specification and serve to explain the principles of this disclosure.

[0032] Figure 1 A block diagram of a trap management device according to an embodiment of the present disclosure is shown.

[0033] Figure 2 A block diagram of another trap management device according to an embodiment of the present disclosure is shown.

[0034] Figure 3 A block diagram of another trap management device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0035] Various exemplary embodiments, features, and aspects of this disclosure will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0036] As used herein, the terms “comprising,” “including,” “having,” or variations thereof are open-ended and include one or more of the stated features, integrals, elements, steps, components, or functions, but do not exclude the presence or addition of one or more other features, integrals, elements, steps, components, functions, or groups thereof.

[0037] When an element is referred to as “connected,” “coupled,” “responding,” or a variation thereof relative to another element, it may be directly connected, coupled, or responding to another element, or there may be an intermediate element present.

[0038] Although the terms first, second, third, etc., may be used herein to describe various elements / operations, these elements / operations should not be limited by these terms. These terms are only used to distinguish one element / operation from another. Therefore, without departing from the teachings of the inventive concept, a first element / operation in some embodiments may be referred to as a second element / operation in other embodiments.

[0039] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0040] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

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

[0042] In processor design and debugging techniques, trap management is a crucial mechanism for online debugging, program monitoring, and exception handling. Typically, when a processor thread executes a function that meets preset trap conditions (such as breakpoints, watchpoints, or specific instructions), a trap event needs to be triggered to suspend the current thread, allowing an external debugger to perform status checks or process intervention. A common implementation in related technologies involves inserting jump instructions into the software to enter a specific trap handler. This handler often maintains the suspended state using methods such as loop waiting or hibernation until a resumption instruction is received. This approach relies entirely on software flow control for trap triggering and maintenance. During the trap waiting period, the processor's fetch bandwidth, decoding resources, and front-end pipeline resources such as the issue queue may be continuously occupied, preventing their use for other effective computational tasks and resulting in reduced hardware resource utilization.

[0043] Based on this, this disclosure provides a hardware-coordinated trap management scheme. By introducing a trap management unit at the processor level and a trap control unit at the processing core level, and interacting with an external debugger through interrupts and registers, the scheme can directly suspend the instruction issuance of the target thread at the hardware level after a trap is triggered. This reduces the occupation of processor computing resources during the trap suspension phase, thereby improving the overall resource utilization efficiency and energy efficiency of the processor when performing debugging or monitoring tasks.

[0044] Figure 1 A block diagram of a trap management device according to an embodiment of the present disclosure is shown. Figure 1 As shown, the device includes: at least one processing core 11 for executing threads; a processor trap management unit 12 coupled to the at least one processing core 11; and an interrupt reporting unit 13 coupled to the processor trap management unit 12; wherein:

[0045] The processing core 11, in response to a thread executing within it satisfying a trap condition, suspends the execution of that thread and reports the trap event to the processor trap management unit 12.

[0046] The processor trap management unit 12, in response to receiving the trap event, performs coordination management and triggers the interrupt reporting unit to report the interrupt to the external debugger.

[0047] The processing core can be the basic arithmetic unit in the processor that executes the instruction stream, used to run one or more software threads. The number of processing cores can be multiple, for example, N, where N is a positive integer.

[0048] A thread can be the smallest unit of program scheduling, such as an execution flow within a process allocated by the operating system. For example, a processing core can be a central processing unit (CPU) core, a graphics processing unit (GPU) core, or a dedicated acceleration core, which completes instruction fetching, parsing, computation, and result writing through internal pipelines such as instruction fetching units, decoding units, execution units, and write-back units.

[0049] A processor trap management unit (TMU) can be a hardware control module located at the processor level and connected to each processing core. It coordinates and manages trap-related events from different processing cores. This unit can receive and process trap signals and perform unified scheduling based on event type or the process to which it belongs. For example, the TMU may include a state machine, a configuration register set, and logic decision circuits to implement functions such as receiving, classifying, recording, or broadcasting trap events.

[0050] An interrupt reporting unit can be a hardware interface circuit connected to the processor trap management unit, used to send interrupt notifications to debuggers or other system components outside the processor. The interrupt reporting unit can convert internal events generated by the processor trap management unit into standard interrupt request signals so that external devices can detect and respond promptly. In one example, the interrupt reporting unit can conform to the Advanced Programmable Interrupt Controller (APIC) specification or a similar interrupt protocol, transmitting interrupt information via the system bus, a dedicated interrupt line, or Message Signaled Interrupt (MSI).

[0051] When a thread executing within a processing core meets a preset trap condition, the processing core can pause the execution of that thread. A trap condition can be a debug breakpoint, a memory access watchpoint, the execution of a specific instruction (such as a trap instruction or illegal opcode), or a custom performance event.

[0052] In one example, in a software debugging scenario, a trap condition can be configured to trigger when the program counter (PC) value equals a preset breakpoint address. Upon detecting that the trap condition is met, the processing core can immediately stop issuing subsequent instructions to the thread, thereby suspending the thread's execution at the hardware level while preserving its context state (such as general-purpose registers, program counter, status registers, etc.).

[0053] In another example, a trap condition can be triggered when a thread executes a specific instruction or class of instructions. For example, executing a special trap instruction or breakpoint instruction, or executing an instruction that is defined as illegal, reserved, or privileged.

[0054] Subsequently, the processing core generates a trap event signal, which can carry information such as the trap type, the identifier of the triggering thread, and the process identifier of the thread to which it belongs. This signal is then reported to the processor trap management unit via the internal bus, a dedicated event channel, or a register write operation.

[0055] Upon receiving a trap event, the processor trap management unit can perform corresponding coordination and management operations. Specifically, this includes: recording the event information in the internal process trap status register for later querying; or deciding whether to broadcast the event to other processing cores based on the type of trap event (e.g., process-level trap or thread-level trap) to achieve cross-core synchronous suspension.

[0056] Subsequently, the processor trap management unit can trigger the interrupt reporting unit, causing it to report a hardware interrupt to the external debugger. The interrupt reporting unit then generates an interrupt request signal, which can be received by the system interrupt controller and delivered to the debugger. Upon receiving the interrupt information, the debugger can read the status information recorded in the processor trap management unit or the processing core to understand the specific reason and context of the trap triggering, and then perform debugging operations such as viewing memory, modifying registers, or controlling program flow.

[0057] In this embodiment, the processing core, in response to a thread executing within it satisfying a trap condition, suspends the execution of that thread and reports a trap event to the processor trap management unit. The processor trap management unit, in response to receiving the trap event, performs coordination and management, and triggers the interrupt reporting unit to report an interrupt to an external debugger. Thus, when a thread executes and triggers a trap condition, the processing core can promptly suspend the instruction issuance of that thread at the hardware level, preventing the thread from continuously occupying front-end pipeline resources such as fetch bandwidth, decoding resources, and issue queues while waiting for a debugger response. Simultaneously, through the coordination of the processor trap management unit and the hardware interrupt notification mechanism of the interrupt reporting unit, the external debugger can quickly learn of the trap event and process it. This process reduces the ineffective occupation of processor computing resources during the trap suspension phase, helping to improve the processor's resource utilization efficiency in debugging or monitoring scenarios.

[0058] Figure 2 A block diagram of another trap management device according to an embodiment of the present disclosure is shown. Figure 2 As shown, the trap management device can support trap management at the thread level and trap management at the process level.

[0059] When the processing core receives a user thread trap command, its internal core trap management unit responds to the command, suspends instruction issuance for the corresponding thread, and updates the thread trap status register to record the trap state of that thread, thus achieving trap management at the thread level. Furthermore, the processor trap management unit can also receive and process user process trap commands, manage the trap state of the target process according to the command content, and record it in the process trap status register, thereby achieving trap management at the process level. For specific implementation details, please refer to the possible implementation methods provided in this disclosure; further elaboration is not provided here.

[0060] The processor trap management unit comprehensively monitors trap events and process commands from each processing core, and reports the corresponding trap interrupts to the external debugger through the interrupt reporting unit, thereby coordinating to complete the complete trap management process from the thread level to the process level.

[0061] In one possible implementation, the device further includes a plurality of trap control registers; the trap control registers are used to receive and store configuration information related to trap management.

[0062] Trap control registers are memory areas in the processor's address space that can be read and written by software (such as an external debugger). They are used to receive, store, and provide various configuration and control information related to trap management. These registers constitute the main interface between the software debugger and the hardware trap management mechanism.

[0063] Specifically, trap control registers can include various types, each used to handle different aspects of control in the trap management process. For example, they can include process trap control registers for controlling the overall trap state of a process, thread trap mask registers for filtering target threads, and thread trap control registers for sending execution control commands to specific threads.

[0064] In one example, the process trap control register can be one or more bit-wide registers, each bit or field of which can correspond to a process identifier (Process ID). The software requests the cleanup of the trap state of the process by writing a specific value to the corresponding bit.

[0065] In another example, the thread trap mask register can be a bitmap register, where each bit corresponds to a thread identifier (Thread ID) or a thread slot, indicating the specific set of threads to which subsequent thread control commands apply. The thread trap control register can receive command codes written by software, such as "continue execution" or "step through M instructions" (M being a positive integer). After parsing the command code, the hardware circuitry performs the corresponding operation on the thread specified by the mask register.

[0066] Software debuggers can achieve precise control over trap management processes by writing specific configuration information to these trap control registers. When a debugger needs to release a previously suspended process, it can write information about the target process to the process trap control register. The processor trap management unit polls or responds to this write operation and executes the trap release logic for that process based on the configuration information, such as clearing internal state and broadcasting a release signal to all processing cores.

[0067] When the debugger needs to resume the execution of one or more specific threads, it first sets the bitmap of the thread to be resumed in the thread trap mask register, and then writes a "continue" command to the thread trap control register. The core trap management unit within each processing core monitors the changes in these registers and executes the resumption instruction issuance operation for the thread whose mask matches. If the written command is "step through M steps", the core trap management unit will also start an internal counter to count the number of issued instructions while resuming the thread. After reaching M steps, the trap will be automatically triggered again, thereby achieving fine-grained single-step debugging functionality.

[0068] For details on the specific usage of the trap control register, please refer to the possible implementations provided in this disclosure; they will not be elaborated upon here.

[0069] In this embodiment, by setting multiple trap control registers for receiving and storing configuration information related to trap management, the software debugger can send commands to the hardware, such as cleaning up process states, filtering target threads, and controlling thread execution (e.g., continuing or single-stepping), by configuring process trap control registers, thread trap mask registers, and thread trap control registers. Consequently, the hardware management unit can respond to these register configurations and automatically execute corresponding fine-grained management operations. This eliminates the need for external debuggers to perform fine-grained control through complex memory mapping or frequent interrupts; instead, it enables differentiated trap management for different processes and thread combinations through simple register read / write operations. This achieves fine-grained thread-level trap control, reduces the implementation complexity of the software debugger, and provides more flexible and efficient thread-level debugging control capabilities.

[0070] Compared to pure software solutions, this disclosure uses a method that directly configures the registers in the hardware through registers, eliminating the need to insert additional jump instructions and wait loops into the target program. This avoids the implementation complexity introduced by modifying the program instruction flow and the potential interference with the normal execution flow of the original program, significantly improving the flexibility and reliability of trap management.

[0071] In one possible implementation, the processing core includes:

[0072] Instruction unit, used to issue instructions to threads;

[0073] The core trap management unit is coupled to the instruction unit;

[0074] The core trap management unit is used to control the instruction unit to suspend issuing instructions to the corresponding thread and send a trap event to the processor trap management unit in response to the trap condition being met.

[0075] Figure 3 A block diagram of another trap management device according to an embodiment of the present disclosure is shown. Figure 3 As shown, the processing core includes an instruction unit and a core trap management unit.

[0076] An instruction unit can be a hardware circuit module within the processing core responsible for the front-end operations of the instruction pipeline. It reads machine instructions from the instruction cache or system memory, parses the instructions to determine their opcodes and operands, and sends the parsed instructions to subsequent execution units (i.e., threads) for processing. For example, an instruction unit may include fetch logic, decode logic, and an issue scheduler. These circuits work together to maintain a continuous supply and dispatch of instructions.

[0077] The core trap management unit can be a dedicated control circuit located within the processing core and directly connected to the instruction unit. It monitors the occurrence of trap conditions and manages the instruction unit's instruction issuance behavior for specific threads. This unit can receive trigger signals from multiple monitoring points within the processing core (such as debug breakpoint comparators, memory access monitoring circuits, or performance event counters) and generate control commands for the instruction unit according to a preset strategy. In one example, the core trap management unit may include a finite state machine, event priority arbitration logic, and multiple configuration register interfaces to achieve rapid detection and response to different types of trap events.

[0078] When a thread executing within the processing core meets a preset trap condition, the core trap management unit can detect this event in real time. Subsequently, the core trap management unit can send a pause control signal to the instruction unit, instructing it to immediately stop issuing any subsequent instructions to the specific thread that triggered the trap. This control operation can take effect at or earlier in the instruction pipeline, causing the instruction flow of that thread to be rapidly interrupted at the hardware level, while the thread's current processor state (including the program counter, general-purpose registers, and status flags) is preserved as it was at the time the trap was triggered. Simultaneously, the core trap management unit can generate a structured trap event signal, which may contain information such as the trap type code, the triggering thread identifier, and the process identifier, and send it to the processor trap management unit via the internal event bus, dedicated register write, or message passing interface.

[0079] Through the coordination of the aforementioned hardware circuits, trap detection, thread suspension, and event reporting can be automatically completed by dedicated logic within the processing core, without waiting for software intervention. Upon receiving a pause-issue signal, the instruction unit can immediately cease supplying instructions to the target thread, ensuring that the thread does not consume fetch bandwidth, decoding resources, or issue queues during the entire period it awaits debugger processing. Simultaneously, the core trap management unit promptly reports trap events to the processor trap management unit, providing necessary information for subsequent cross-core coordination and sending interrupt notifications to external debuggers.

[0080] In this embodiment, the processing core includes: an instruction unit for issuing instructions to threads; and a core trap management unit coupled to the instruction unit. The core trap management unit, in response to the trap condition being met, controls the instruction unit to pause issuing instructions to the corresponding thread and sends a trap event to the processor trap management unit. Therefore, since the core trap management unit is a hardware circuit within the processing core, when a thread execution meets the trap condition, the dedicated hardware circuit within the processing core can directly control the front end of the instruction pipeline, immediately interrupting the issuance of instructions to the thread. This quickly suspends the thread at the hardware level and releases the front-end pipeline resources it occupies. Compared to a pure software solution, this reduces the invalid occupation of the processing core's front-end resources while waiting for a debugger response, helping to improve the overall resource utilization efficiency and real-time response of the processor in multi-threaded debugging scenarios. Simultaneously, by reporting the trap event to the processor trap management unit, unified coordination at the processor level and debugger notification are facilitated, making the thread suspension operation after the trap is triggered more efficient.

[0081] Compared to purely software solutions, this approach directly controls the front end of the instruction pipeline through the internal hardware circuitry of the core, suspending the target thread in hardware rather than inserting jump instructions into the target program to cause the thread to enter an infinite loop. This native hardware suspension mechanism does not modify the program's instruction flow and will not disrupt the original program's normal execution logic by inserting additional instructions. Therefore, it maintains non-intrusiveness to the original program's execution flow while implementing trap suspension, thus improving the reliability of the trap management solution.

[0082] In one possible implementation, the processor trap management unit, upon determining, based on the type of the trap event, that it needs to be broadcast to other processing cores, broadcasts the trap event to other processing cores; any core trap management unit in the device, in response to a trap event from the processor trap management unit targeting the target process, controls its coupled instruction unit to suspend issuing instructions to all threads belonging to the target process.

[0083] Trap events can be categorized based on their predefined scope of influence. For example, they can be divided into "thread-level traps" that only affect a single triggering thread and "process-level traps" that need to affect the entire process to which the triggering thread belongs.

[0084] The trap type configuration can be associated with a selection rule, which can be configured by the debugger in the process trap control register. This rule defines which threads within the same process should be suspended along with the triggering thread. This rule can be based on the thread identifier (Thread ID), the thread creation order, the hardware resource group to which the thread belongs, or other distinguishing attributes. For example, the rule could be expressed as "all threads with odd-numbered thread IDs," "the first k created threads" (where k is a positive integer), or "threads bound to a specific processor cluster."

[0085] In one example, the trap type can be configured as "first 50% of threads". The processor trap management unit or core trap management unit can use this rule to determine the type when parsing such trap events. For example, the processor might maintain a list of creation sequence numbers or IDs for each thread within a process. When a trap event marked as "first 50% of threads" is received, the management unit calculates half of the current total number of threads in the process and sends a suspension control signal only to the first 50% of threads (or the processing cores they reside in), while the remaining 50% of threads can continue execution.

[0086] The processor trap management unit can internally set judgment logic, such as by looking up a table or parsing a specific type field in the trap event signal, to determine whether the event needs to be broadcast. For example, taking a trap type as a process-level trap, when the trap event is triggered by a debugging condition configured as a "process breakpoint", its type can be marked as process-level, thereby triggering the broadcast process.

[0087] When broadcasting is deemed necessary, the processor trap management unit can send the trap event signal to all other processing cores via the processor's internal event distribution network. The broadcast signal can carry key information related to the trap type. For example, taking a process-level trap as an example, this key information could be the identifier of the target process, the trap event type code, etc.

[0088] In one example, the broadcast can be accomplished through a shared, multicast-enabled event bus, with the processor trap management unit acting as the master node sending event packets onto the bus, and all processing cores acting as slave nodes listening and receiving them.

[0089] Taking a process-level trap as an example, the core trap management unit within each processing core continuously listens to the broadcast channel from the processor trap management unit. When a trap event broadcast targeting a specific process is received, the core trap management unit performs local processing.

[0090] The core trap management unit parses the broadcast message to identify the target process's identifier. Then, it queries its internal or shared thread state table within the processing cores to determine all threads currently executing on that core that belong to the target process. Once these threads are identified, the core trap management unit sends a control command to its coupled instruction unit. Based on this command, the instruction unit suspends the issuance of subsequent instructions to all identified threads belonging to the target process. This process can be executed in parallel, allowing multiple threads belonging to the same process distributed across multiple processing cores to be suspended nearly simultaneously.

[0091] Through this mechanism, a trap event that might have been triggered by a single thread on a single processing core can now have its impact extended to the entire process. This allows the debugger to obtain a unified, process-level debug pause state, facilitating the observation and manipulation of the collaborative context of all threads within the process, without the need to manually set breakpoints or suspend operations for each thread individually.

[0092] In this embodiment, the processor trap management unit, based on the type of the trap event, determines that it needs to be broadcast to other processing cores, and then broadcasts the trap event to other processing cores. Any core trap management unit in the device, in response to a trap event for the target process from the processor trap management unit, controls its coupled instruction unit to suspend issuing instructions to all threads belonging to the target process. Thus, a specific type of trap (such as a process-level trap) triggered by a single thread can be quickly synchronized to all processing cores of the processor through a hardware broadcast mechanism, causing the threads of the target process on all cores to be suspended uniformly. Clearly, based on the type of trap event, the hardware trap management device of this disclosure can achieve differentiated trap control granularity: when the trap type is thread-level, only the single thread that triggered the trap is suspended, and other threads are unaffected, thereby achieving fine-grained thread-level trap control; when the trap type is process-level, the processor trap management unit distributes the trap event to all processing cores through a broadcast mechanism, causing all threads of the process on multiple cores to be suspended uniformly, thereby achieving larger-grained process-level trap control and improving the convenience and efficiency of debugging in a multi-core, multi-threaded environment.

[0093] This hardware mechanism, which flexibly selects control granularity based on trap event type, allows debuggers to perform precise trap management on a single thread or the entire process, depending on the needs of the debugging scenario. In contrast, pure software trap management schemes in related technologies can only affect the triggering and suspension of traps on the single thread currently executing the trap handler. They cannot detect whether other threads belonging to the same process are running on other processing cores, nor can they coordinate and manage them uniformly. Their control granularity is limited to the scope of a single thread. This disclosure, by associating trap types with hardware broadcast decisions, enables the trap management device to flexibly switch between single-thread granularity and multi-core process granularity (as well as the granularity of other trap types) as needed, effectively solving the problems of limited control granularity and inability to manage trap events across execution units in existing software solutions.

[0094] In one possible implementation, the core trap management unit, in response to the trap event targeting the target process, controls its coupled instruction unit to pause any newly arriving threads belonging to the target process before they begin executing their first instruction.

[0095] When the core trap management unit receives a trap event targeting a specific process (such as a process-level trap broadcast by the processor trap management unit), in addition to immediately suspending all threads currently executing on the core that belong to that target process, it also enters a continuous monitoring state. In this state, the core trap management unit coordinates with the processing core's thread scheduler or thread creation logic to detect in real time whether any new threads belonging to the same target process have been dispatched to the processing core for execution.

[0096] Newly arriving threads belonging to the target process can be other threads within the same process that were assigned to the processing core by the operating system scheduler after the trap event occurred, or they may include entirely new threads dynamically created by the process. For example, in a multi-threaded server program, after the main thread responsible for handling connection requests triggers a process-level trap and is suspended, the server program may create new worker threads to handle subsequent network connections; these newly created worker threads are considered "newly arriving" threads.

[0097] When a new thread is scheduled to a processing core, the monitoring logic of the core trap management unit intervenes before it officially begins executing its first machine instruction. The core trap management unit compares the process identifier of the new thread with the internally recorded target process identifier that is currently in a trap-suspended state. Once a match is found, the core trap management unit immediately sends a control signal to the instruction unit, which, based on this signal, places the new thread in a paused-issue state before its instruction stream enters the pipeline.

[0098] In this embodiment, the core trap management unit, in response to a trap event targeting the target process, controls its coupled instruction unit to suspend any newly arriving threads belonging to the target process before they begin executing their first instruction. Thus, after the target process is suspended due to a trap event, all its existing threads are suspended, and any new threads subsequently scheduled to the processing core are immediately intercepted and suspended before execution. This provides the trap suspension operation for the process with temporal continuity and completeness, ensuring that all execution entities of the process (including dynamically created threads) are in a controllable suspended state throughout the entire period of debugger inspection and manipulation of the process state. This provides the debugger with a completely static and consistent view of the process memory and registers, greatly improving the reliability and accuracy of debugging complex multithreaded programs.

[0099] In one possible implementation, the trap control register includes a process trap control register for setting or clearing the trap state of the target process;

[0100] The processor trap management unit, in response to the target process information to be released configured in the process trap control register, performs a trap release operation for the target process. The trap release operation includes: clearing the relevant trap state and broadcasting a trap release signal to all processing cores.

[0101] In response to the trap release signal, any core trap management unit in the device controls the instruction unit to resume sending instructions to the thread belonging to the target process.

[0102] Trap management devices may include dedicated registers for controlling trap release, such as process trap control registers. These registers can be written to by an external debugger to indicate which target process needs to be released (i.e., exit the trap suspension state). The process trap control register may store identification information of the target process, such as the process ID, and possible opcodes to indicate the "clean up and release" command.

[0103] When an external debugger completes debugging of the target process and wishes to resume its execution, it can write the corresponding configuration information to the process trap control register. The processor trap management unit monitors or responds to write events to this register. After parsing the configuration information, the processor trap management unit begins executing the trap release operation for that target process.

[0104] Specifically, the processor trap management unit performs a state cleanup operation, clearing the trap state records it maintains internally that are associated with the target process. For example, it clears the entry in the process trap state register corresponding to the process identifier to indicate that the process is no longer in a debugged and suspended state.

[0105] Then, a signal broadcast is executed. The processor trap management unit generates a trap release signal and sends it to all processing cores via the internal event network or broadcast bus. This signal also carries the identifier of the target process so that each core can identify it.

[0106] Each processing core's core trap management unit continuously listens for broadcast messages from the processor side. When a trap release signal is received, the core trap management unit parses the process identifier and queries the threads currently in a "paused issue" state within its core. For all threads belonging to the target process, the core trap management unit sends a resumption control signal to its coupled instruction unit. Upon receiving this signal, the instruction unit releases the instruction issue pause for these threads, allowing the instruction stream to re-enter the pipeline and begin execution. Simultaneously, the core trap management unit exits its continuous monitoring of the process; any newly arriving threads belonging to that process will not be intercepted and can begin execution normally.

[0107] Through this hardware-automated broadcast and resume mechanism triggered by register configuration, the debugger can very efficiently resume the execution of a suspended process on all processing cores without sending resume commands one core or one thread at a time.

[0108] In this embodiment, the trap control register includes a process trap control register for setting or clearing the trap state of the target process. The processor trap management unit, in response to the target process information configured in the process trap control register, performs a trap release operation for the target process, including clearing the relevant trap state and broadcasting a trap release signal to all processing cores. Any core trap management unit in the device, in response to the trap release signal, controls the instruction unit to resume issuing instructions to the threads belonging to the target process. Thus, the external debugger only needs to perform a single configuration write to the process trap control register to drive the processor trap management unit to automatically complete the clearing of the trap state and the global broadcast of the trap release signal, thereby triggering the core trap management units within each processing core to synchronously resume issuing instructions to all threads of the target process. This process simplifies the release operation on the debugger side to a single write to a single register, eliminating the need for the debugger to send recovery commands to each processing core individually. Simultaneously, the hardware broadcast and core-synchronized response mechanism ensures that threads across multiple processing cores can consistently exit the suspended state and resume execution, which is beneficial for improving the overall efficiency of the debugging process and the coordination of multi-threaded program execution.

[0109] Compared to a pure software solution, which requires the debugger to send recovery commands to each processing core or thread individually, making the operation cumbersome and difficult to guarantee synchronization, this solution simplifies the release operation to a single configuration of a single register through the unified cleanup and broadcast mechanism of the processor trap management unit. This eliminates the need to process each thread individually, resulting in a simpler and more efficient solution. Furthermore, the hardware broadcast ensures the synchronization of the recovery of each core thread.

[0110] In one possible implementation, the trap control register includes: a thread trap control register for receiving commands to control thread execution or resumption; and a thread trap mask register for specifying the thread to which the commands in the thread trap control register apply.

[0111] The core trap management unit, in response to the thread recovery command configured in the thread trap control register, controls the instruction unit to resume sending instructions to the thread to be recovered according to the thread information to be recovered configured in the thread trap mask register.

[0112] The thread trap control register is a command register that can be written to by an external debugger. It is specifically used to receive and control the execution or resumption of specific operation instructions of a thread. The thread trap mask register is a filter register used in conjunction with the thread trap control register to precisely specify one or more target threads to which the commands in the thread trap control register apply.

[0113] Specifically, the commands written to the thread trap control register can characterize different resumption strategies. For example, a command could be a simple "Go" command, instructing the thread to resume continuous execution; or it could be a "Step M" command, instructing the thread to automatically trigger the trap again after executing a specific number of instructions. The thread trap mask register typically exists as a bitmap, with each bit corresponding to a possible thread identifier or a thread slot. When a bit is set to "1", it indicates that the thread corresponding to that bit is selected and needs to respond to the commands in the thread trap control register; setting it to "0" indicates no response. This masking mechanism allows for the flexible specification of any combination of thread sets, such as resuming only threads 0 and 2, or resuming all odd-numbered threads within a process.

[0114] When an external debugger needs to resume a specific set of suspended threads, it determines which threads need to be resumed based on its debugging intent. Then, it writes the corresponding bitmap to the thread trap mask register, setting the bit corresponding to the thread to be resumed. Next, the debugger writes the specific resume command (such as "continue execution") to the thread trap control register. These two write operations together constitute a complete hardware control instruction with target filtering.

[0115] Each processing core's core trap management unit continuously monitors the state changes of these registers. When a new command is detected written to the thread trap control register, the core trap management unit simultaneously reads the current value of the thread trap mask register. Subsequently, within its processing core, the core trap management unit compares the mask bitmap with the currently paused threads. For each thread, if its corresponding mask bit is "1", the core trap management unit determines that the thread is a thread to be resumed. Then, the core trap management unit sends a resumption control signal for these threads to its coupled instruction unit. Upon receiving the signal, the instruction unit releases the instruction issue pause for these threads, allowing their instruction streams to re-inject into the pipeline, thereby resuming thread execution.

[0116] In this embodiment, the trap control register includes: a thread trap control register for receiving commands to control thread execution or resumption; a thread trap mask register for specifying the threads to which the commands in the thread trap control register apply; and a core trap management unit, responding to a thread resumption command configured in the thread trap control register, controlling the instruction unit to resume issuing commands to the threads to be resumed according to the thread information to be resumed configured in the thread trap mask register. Thus, an external debugger can achieve batch, synchronous resumption control of all selected threads by configuring arbitrary thread combination bitmaps in the thread trap mask register and issuing commands in the thread trap control register. This mask command mechanism improves the efficiency and flexibility of thread group operations, eliminating the need for the debugger to send commands individually to each thread, thereby significantly reducing the complexity and time overhead of debugging interactions, and supporting precise operations on specific subsets of threads in complex multithreaded scenarios.

[0117] In one possible implementation, the core trap management unit controls the instruction unit to continuously resume transmission, or automatically triggers a new trap to pause the thread again after resuming transmission of a specified number of instructions.

[0118] The core trap management unit supports two different recovery strategies when controlling thread resumption of execution. These two strategies can be distinguished by the command code in the thread trap control register. Different recovery strategies can be controlled by configuring the thread trap control register: one is to resume execution continuously without restriction, and the other is to resume execution of only a specified number of instructions.

[0119] Therefore, the core trap management unit can control the instruction unit to continuously resume issuing based on the configuration information of the thread trap control register, or automatically trigger a new trap to pause the thread again after resuming issuing a specified number of instructions.

[0120] When an external debugger wants a suspended thread to fully resume free execution, it can send a continue command to the thread trap control register. The core trap management unit responds to this command, releasing the target thread from its paused execution state and no longer imposing additional restrictions on instruction issuance by that thread. The instruction unit will then continue to fetch, decode, and issue instructions from that thread, just like a normal thread, until the thread terminates naturally or encounters another trap condition. This mode is suitable for scenarios where the debugger wants the program to continue running at full speed after completing a breakpoint check.

[0121] Another debugging requirement is single-step execution, which involves automatically pausing after executing one or a few instructions to observe subtle changes in the program's state. To support this, the debugger can send a "Step M" command to the thread trap control register, where M is the specified number of instructions; for example, M=1 means single-step execution. The core trap management unit, while parsing this command and resuming thread execution, starts an internal instruction counter. This counter can be a hardware counter, initially set to M.

[0122] The core trap management unit works in conjunction with the instruction issuance logic of the processing core to count the instructions issued by the target thread. Each time the instruction unit successfully issues an instruction for this thread, the counter is decremented. When the counter reaches zero, it indicates that the specified M instructions have been issued. At this point, the core trap management unit automatically triggers a new trap event.

[0123] This process is entirely handled by hardware logic. The core trap management unit regains control of the instruction unit, suspends issuing instructions to the thread again, and simultaneously reports a single-step completion or similar trap event to the processor trap management unit, notifying the debugger that it can be inspected again. In one example, when M=1, the thread automatically suspends after executing one instruction, achieving strict single-step debugging; when M is greater than 1, it achieves instruction block-level step-by-step debugging.

[0124] This hardware-based automatic triggering mechanism enables precise step control without requiring the debugger to manually send a pause command after each instruction is executed.

[0125] In this embodiment, the core trap management unit controls the instruction unit to continuously resume issuing commands, or automatically triggers a new trap to suspend the thread again after resuming issuing a specified number of commands. Thus, the hardware natively supports both "continue execution" and "single-step / multi-step execution" recovery modes. During single-step debugging, a hardware counter automatically monitors the number of commands issued and immediately re-suspends the thread and reports the event after each step, enabling the debugger to obtain precise, instruction-level program control. This greatly simplifies the software interaction required for single-step debugging, avoids the overhead of debugger polling or frequent command sending, thereby improving the efficiency and responsiveness of interactive debugging and providing developers with more refined and efficient program flow control.

[0126] Compared to a purely software approach, which typically requires inserting additional trap instructions or software interrupts after each target instruction to achieve single-step debugging, the pure software method is complex and can easily affect the normal execution flow of the program. In contrast, this solution integrates the step counting and automatic re-triggering trap functions into the hardware logic of the core trap management unit. Only the thread trap control register needs to be configured, and the hardware can autonomously complete the execution and re-suspend of the specified number of steps without repeatedly modifying the program instruction flow. This makes the implementation simpler and does not interfere with the execution logic of the original program.

[0127] In one possible implementation, the apparatus further includes a process trap status register and / or a thread trap status register;

[0128] Upon receiving the trap event, the processor trap management unit records the event information in the process trap status register for reading by an external debugger; and / or,

[0129] The thread trap status register updates the state of the corresponding thread after the thread pauses execution and records the reason for the trap being triggered, so that it can be read by an external debugger.

[0130] The processor may also include dedicated registers for recording trap state information, such as process trap state registers and thread trap state registers. These registers can serve as an observability interface for the hardware trap management mechanism, allowing external debuggers to read the state of suspended threads.

[0131] The process trap status register resides at the processor level and is associated with the processor trap management unit. This register stores trap information related to the entire process. When a trap event is reported to the processor trap management unit, in addition to coordination and broadcasting, the management unit archives key information about the event into the process trap status register. This information may include the process identifier that triggered the trap, the trap event type code, the trigger timestamp, or a unique event sequence number.

[0132] In one example, this register could be a table structure, with each entry corresponding to a process and recording a summary of the trap event it last reported. This allows the debugger, upon receiving an interrupt, to quickly understand which process triggered the trap event and the macroscopic type of the event by reading this register, thus determining the next direction for debugging.

[0133] The thread trap status register operates at the core level, with each processing core having its own register, which can be coupled to the core trap management unit. When a thread is suspended due to meeting a trap condition, the core trap management unit updates the entry in the thread trap status register corresponding to that thread. In one example, the updated content might include: the specific reason for triggering the trap (e.g., breakpoint address, watchpoint address, illegal opcode), the program counter value when the thread was suspended, and the machine status code when the trap was triggered.

[0134] The processor trap management unit and the core trap management unit can update the status registers in real time. For example, simultaneously with the trap triggering and suspension hardware actions, the status recording circuitry captures relevant information and writes it into the corresponding status registers. Throughout this process, the instruction flow of the suspended thread has stopped, so its state remains unchanged for a short period after being written to the register.

[0135] Once an external debugger learns of a trap occurrence via an interrupt, it can read these status registers through memory-mapped input / output ports or dedicated debug access ports. By reading the process trap status register, the debugger can identify the problematic process; by reading the thread trap status register (of one or more cores), the debugger can pinpoint exactly which thread, at which address, and for what reason the trap was triggered, as well as the complete context of the thread when it was suspended. This information serves as direct evidence for the debugger's decisions (such as examining variables, modifying memory, or resuming execution).

[0136] In this embodiment, the device further includes a process trap status register and / or a thread trap status register; the processor trap management unit, upon receiving the trap event, records the event information in the process trap status register; and / or, the thread trap status register, after the thread execution is suspended, updates the state of the corresponding thread and records the reason for the trap triggering. Thus, while automatically managing trap triggering and suspension, the hardware simultaneously records key process-level and thread-level trap context information in dedicated registers. This provides an external debugger with a clear, comprehensive, and instantly readable status window. The debugger does not need to infer the system state through complex software interactions or guesswork; it only needs to read these hardware registers to obtain accurate debugging information, thereby significantly improving the observability of the debugging process, reducing the time for status diagnosis, and making debugging decisions more accurate and efficient.

[0137] The following is a specific implementation example illustrating the detailed process of implementing a trap management device in an application scenario.

[0138] In this application scenario, assume a target process with multiple threads is running in a multi-core processor system. The processor contains at least two processing cores (hereinafter referred to as Core A and Core B), a processor trap management unit, an interrupt reporting unit, and multiple trap control registers. Each processing core contains an instruction unit and a core trap management unit.

[0139] Core A is currently executing thread T1 of the target process. The program execution flow of thread T1 satisfies a preset trap condition (e.g., its program counter hits a breakpoint address pre-set by the debugger). The core trap management unit inside core A detects the fulfillment of this condition in real time.

[0140] In response to the preset trap condition being triggered, the core trap management unit sends a control signal to the instruction unit coupled to it. Based on this signal, the instruction unit suspends issuing any subsequent instructions to thread T1, thereby suspending thread T1 at the hardware level. The context state of thread T1 (including registers, program counter, etc.) is frozen at the trigger point.

[0141] Subsequently, the core trap management unit of core A generates a trap event signal. This signal contains at least the trap type ("process-level trap" in this example) and the target process identifier (PID_X) to which thread T1 belongs. This signal is sent to the processor trap management unit.

[0142] The processor trap management unit receives a trap event signal from core A, and determines, based on the trap type ("process-level trap") in the signal, whether the target process (PID_X) needs to be notified of this event to all threads on all processing cores.

[0143] Next, the processor trap management unit performs two operations: First, it records the key information of this trap event (such as process PID_X and event type) in the process trap status register within the processor. Second, it sends a broadcast signal to all processing cores (including core A and core B) through the internal event broadcast network, carrying the target process identifier PID_X and a suspension instruction.

[0144] Simultaneously, the processor trap management unit triggers the interrupt reporting unit. The interrupt reporting unit sends a hardware interrupt to the outside of the processor, notifying the debugger that a trap event has occurred.

[0145] The core trap management unit of core B receives the broadcast signal, parses out the target process identifier PID_X, and checks all threads currently executing on core B.

[0146] Suppose that thread T2, belonging to the same target process (PID_X), and thread T3, belonging to another process, are executing on core B. The core trap management unit of core B identifies thread T2 as belonging to the target process and sends a control signal to the instruction unit, which then suspends issuing instructions to thread T2. Thread T3, which does not belong to the target process (PID_X), remains unaffected during execution.

[0147] In addition, the core trap management units of both core A and core B enter a continuous monitoring state. If a new thread belonging to process PID_X is scheduled to either core, the core trap management unit will control the instruction unit to suspend it before it begins executing its first instruction, thereby ensuring the integrity of the process suspension.

[0148] After receiving a hardware interrupt, the debugger reads the process trap status register and learns that process PID_X triggered the trap. To understand the details further, the debugger reads the thread trap status registers of each core. From the thread trap status register of core A, the debugger learns that thread T1 triggered a breakpoint at a specific address; from the thread trap status register of core B, it can be seen that thread T2 is also synchronously suspended.

[0149] Based on this information, the debugger analyzes the program state. After completing the check, the debugger resumes the execution of the entire target process. The debugger writes the target process information (PID_X) and a release command to the process trap control register within the processor. The processor trap management unit responds to this configuration by performing a trap release operation: clearing the record for PID_X in the process trap status register; and broadcasting a trap release signal for PID_X to all processing cores.

[0150] Upon receiving the release signal, the core trap management units of cores A and B control their respective instruction units to resume issuing instructions to all threads belonging to process PID_X (i.e., T1 in core A and T2 in core B). Simultaneously, the core trap management units exit continuous monitoring of PID_X. Threads T1 and T2 resume normal execution from their previous freeze points.

[0151] Consider another scenario: After inspection, the debugger does not want to resume the entire process, but only wants thread T1 to execute one instruction at a time. In this case, the debugger first writes a bitmap to the thread trap mask register, setting only the bit corresponding to thread T1. Then, the debugger writes the command "step forward 1 step" to the thread trap control register.

[0152] Core A's core trap management unit detects the configuration changes of these two registers, confirms the operation target is thread T1 based on the mask, and parses out the single-step command. Subsequently, it performs two actions: first, it controls the instruction unit to resume issuing instructions to thread T1; second, it starts an internal counter and sets its value to 1.

[0153] Thread T1 resumes execution, and its instruction unit issues its first instruction. This instruction issuance causes an internal counter to decrement to 0. The counter reaching zero event triggers the core trap management unit in core A to perform the following operations: it again controls the instruction unit to pause issuing instructions to thread T1 (i.e., resuspends it), and reports a new trap event to the processor trap management unit. The processor trap management unit then notifies the debugger again via the interrupt reporting unit. The debugger can then read the state again and observe the program changes after executing one instruction, thus achieving fine-grained single-step debugging.

[0154] In the above process, the trap management device, as a hardware module, works in conjunction with the software-configurable trap control register to achieve fully automated management from trap triggering, cross-core synchronous suspension, status visibility, to fine-grained recovery at the process or thread level. This process reduces software polling and complex interactions, improving resource utilization and debugging control efficiency.

[0155] According to another aspect of this disclosure, a processor is provided that includes any of the trap management devices described above.

[0156] According to another aspect of this disclosure, a chip is also provided, including any of the aforementioned trap management devices.

[0157] According to another aspect of this disclosure, an electronic device is also provided, including any of the aforementioned trap management devices.

[0158] Other configurations of the processor, chip, or electronic device in the above embodiments may employ various technical solutions now and in the future known to those skilled in the art, and will not be described in detail here.

[0159] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0160] In the description of this specification, it should be understood that the terms "center," "longitudinal," "transverse," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this disclosure and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this disclosure.

[0161] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this disclosure, "multiple" means two or more, unless otherwise explicitly specified.

[0162] In this disclosure, unless otherwise expressly specified and limited, the terms "installation," "connection," "linking," "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection, an electrical connection, or a communication connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this disclosure according to the specific circumstances.

[0163] In this disclosure, unless otherwise expressly specified and limited, "above" or "below" the second feature can include direct contact between the first and second features, or contact between the first and second features through another feature between them. Furthermore, "above," "over," and "on top" of the second feature includes the first feature being directly above or diagonally above the second feature, or simply indicates that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature includes the first feature being directly above or diagonally above the second feature, or simply indicates that the first feature is at a lower horizontal level than the second feature.

[0164] The foregoing disclosure provides many different implementations or examples for carrying out different structures of this disclosure. To simplify the disclosure, specific examples of components and arrangements have been described above. Of course, these are merely examples and are not intended to limit the scope of this disclosure. Furthermore, reference numerals and / or letters may be repeated in different examples; such repetition is for simplification and clarity and does not in itself indicate a relationship between the various implementations and / or arrangements discussed.

[0165] The above are merely specific embodiments of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope disclosed in this disclosure, and these should all be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A trap management device, characterized in that, include: At least one processing core is used to execute threads; A processor trap management unit is coupled to the at least one processing core; The interrupt reporting unit is coupled to the processor trap management unit; wherein: The processing core, in response to a thread executing within it satisfying a trap condition, suspends the execution of that thread and reports the trap event to the processor trap management unit; The processor trap management unit, in response to receiving the trap event, performs coordination management and triggers the interrupt reporting unit to report the interrupt to the external debugger.

2. The apparatus according to claim 1, characterized in that, The device also includes multiple trap control registers; the trap control registers are used to receive and store configuration information related to trap management.

3. The apparatus according to claim 2, characterized in that, The processing core includes: Instruction unit, used to issue instructions to threads; The core trap management unit is coupled to the instruction unit; The core trap management unit is used to control the instruction unit to suspend issuing instructions to the corresponding thread and send a trap event to the processor trap management unit in response to the trap condition being met.

4. The apparatus according to claim 3, characterized in that: The processor trap management unit, based on the type of the trap event, determines that it needs to be broadcast the trap event to other processing cores, and then broadcasts the trap event to other processing cores. In response to a trap event for the target process from the processor trap management unit, any core trap management unit in the device controls its coupled instruction unit to suspend issuing instructions to all threads belonging to the target process.

5. The apparatus according to claim 4, characterized in that: The core trap management unit, in response to the trap event targeting the target process, controls its coupled instruction unit to pause any newly arriving threads belonging to the target process before they begin executing their first instruction.

6. The apparatus according to claim 3, characterized in that, The trap control register includes a process trap control register, which is used to set or clear the trap state of the target process; The processor trap management unit, in response to the target process information to be released configured in the process trap control register, performs a trap release operation for the target process. The trap release operation includes: clearing the relevant trap state and broadcasting a trap release signal to all processing cores. In response to the trap release signal, any core trap management unit in the device controls the instruction unit to resume sending instructions to the thread belonging to the target process.

7. The apparatus according to claim 3, characterized in that, The trap control register includes: a thread trap control register, used to receive commands to control the execution or resumption of a thread; and a thread trap mask register, used to specify the thread to which the commands in the thread trap control register apply. The core trap management unit, in response to the thread recovery command configured in the thread trap control register, controls the instruction unit to resume sending instructions to the thread to be recovered according to the thread information to be recovered configured in the thread trap mask register.

8. The apparatus according to claim 7, characterized in that, The core trap management unit controls the instruction unit to continuously resume transmission, or automatically triggers a new trap to pause the thread again after resuming transmission of a specified number of instructions.

9. The apparatus according to claim 2, characterized in that, The device further includes a process trap status register and / or a thread trap status register; Upon receiving the trap event, the processor trap management unit records the event information in the process trap status register for reading by an external debugger; and / or, The thread trap status register updates the state of the corresponding thread after the thread pauses execution and records the reason for the trap being triggered, so that it can be read by an external debugger.

10. A processor, characterized in that, Includes the trap management device as described in any one of claims 1 to 9.

11. A chip, characterized in that, Includes the trap management device as described in any one of claims 1 to 9.

12. An electronic device, characterized in that, Includes the trap management device as described in any one of claims 1 to 9.

Images