Efficient replacement of software breakpoint instructions in processor-based device

Abstract

Efficient replacement of software breakpoint instructions in a processor-based device is disclosed. In regard to this, in one exemplary embodiment, a processor-based device is provided. The processor-based device includes a system memory and a processor. The processor includes a breakpoint slip register (BSR) configured to store instructions of a software process that are replaced in system memory by a software breakpoint instruction, and the processor further includes a breakpoint slip enable (BSE) indicator. The processor is configured to execute the software breakpoint instruction during execution of a software process. The processor is further configured to, in response to executing the software breakpoint instruction, transfer program control to the debugger. The processor is further configured to determine that the BSE indicator is set after the program control is returned from the debugger. Further, the processor is configured to, in response to determining that the BSE indicator is set, execute the instructions stored in the BSR.

Description

Technical Field

[0001] The techniques of this disclosure relate to debugging in processor-based devices, and more particularly to the handling of software breakpoint instructions during debugging. Background Art

[0002] The instruction set architecture (ISA) on which traditional processor-based devices are based provides software breakpoint instructions that can be used during software process debugging. In order to debug a software process, a developer tool called a debugger is attached to a target software process in system memory and provides functionality for controlling program flow and inspecting the internal state of the target software process. The debugger can use software breakpoint instructions to pause the execution of the target software process at a specified point (i.e., at a given program counter (PC) within the target software process). To achieve this during a debugging session, the debugger replaces the instruction at the specified point in the system memory with a software breakpoint instruction. When the processor executes the software breakpoint instruction, an exception is raised, which pauses the execution of the target software process and causes program control to be transferred to the debugger.

[0003] The debugger can then resume execution of the target software process at the point where execution was suspended by the software breakpoint instruction. This requires the debugger to perform a series of operations to replace the software breakpoint instruction in system memory with the original instruction and perform cache maintenance and synchronization operations to ensure that the original instruction is correctly observed by all caches and processor cores within the processor-based device. The debugger can also configure the processor to re-enter debugging at the next instruction following the software breakpoint instruction, which requires replacing the next instruction with another software breakpoint instruction and performing further cache maintenance and synchronization operations to ensure that the newly inserted software breakpoint instruction is correctly observed by all caches and processor cores within the processor-based device. Finally, the debugger executes ISA-specific instructions to return program control to the software process and execute the original instruction.

[0004] However, this traditional approach to handling software breakpoint instructions has several drawbacks. The cache maintenance and synchronization operations described above each time an instruction in system memory is replaced by a software breakpoint instruction (or vice versa) can incur significant delays, negatively impacting processor performance. Furthermore, there is a risk that while the debugger is performing these operations, another processor thread executing on the processor-based device may not observe the software breakpoint instruction. To mitigate this risk, the debugger may pause all execution threads while performing the operation, further degrading processor performance.

[0005] Therefore, a more efficient mechanism for handling software breakpoint instructions during debugging is desirable. Summary of the Invention

[0006] Example embodiments disclosed herein include efficiently replacing software breakpoint instructions in a processor-based device. In this regard, in one example embodiment, a processor of the processor-based device includes a breakpoint slip register (BSR) that can store instructions that are replaced by software breakpoint instructions in system memory by a debugger. The processor also includes a breakpoint slip enable (BSE) indicator, which is a status bit that signals the processor to execute instructions stored in the BSR rather than the instruction at the location where program control returns from the debugger (e.g., the program counter (PC) of the software breakpoint instruction). In example operation, the processor executes the software breakpoint instruction while executing a software process in system memory, causing the processor to transfer program control to the debugger. After program control returns from the debugger, the processor determines that the processor's BSE indicator is set. In response, the processor executes the instructions stored in the BSR rather than the instruction at the PC where program control returned from the debugger. Some embodiments may provide that the processor provides multiple BSRs storing instructions corresponding to multiple instructions. In such embodiments, the processor may be configured to execute the multiple instructions stored in the multiple BSRs before executing the next instruction following the software breakpoint instruction in system memory.

[0007] According to some embodiments, when program control is transferred to a debugger, the debugger stores the instructions of the software process (i.e., the original instructions replaced by the software breakpoint instruction) in the processor's BSR. The debugger then sets a BSE indicator and, after the debugging task is complete, returns program control to the PC of the software breakpoint instruction (e.g., by executing an instruction set architecture (ISA)-specific instruction). According to some embodiments, the processor may clear the BSE indicator after executing the instruction stored in the BSR (or, in embodiments where multiple BSRs are provided, after executing the instruction stored in the final BSR). Some embodiments may provide that the processor determines that an exception was caused by executing the instruction stored in the BSR. In response to determining that an exception was caused, the processor sets the BSR exception indicator and transfers program control to an exception handler.

[0008] The exception handler determines whether the BSR exception indicator is set, obtains an instruction from the BSR, and then performs exception handling for the exception based on the instruction. In embodiments where multiple BSRs are provided, provision may be made for the exception handler to use a BSR pointer (which points to the BSR and is advanced as each instruction stored in each BSR is executed) to obtain the instruction, as the BSR pointer indicates which BSR stores the instruction that caused the exception. In some embodiments, after executing the instruction stored in the BSR, the processor may continue executing the software process at the next instruction following the software breakpoint instruction in system memory. In another exemplary embodiment, a processor-based device is provided. The processor-based device includes a system memory and a processor. The processor includes a BSR configured to store the instruction of the software process in the system memory that is replaced by the software breakpoint instruction, and the processor also includes a BSE indicator. The processor is configured to execute the software breakpoint instruction during execution of the software process. The processor is further configured to transfer program control to a debugger in response to executing the software breakpoint instruction. The processor is further configured to determine whether the BSE indicator is set after program control returns from the debugger. The processor is further configured to, in response to determining that the BSE indicator is set, execute instructions stored in the BSR.

[0009] In another exemplary embodiment, a method for efficiently replacing a software breakpoint instruction in a processor-based device is provided. The method includes executing the software breakpoint instruction by a processor of the processor-based device during execution of a software process in system memory. The method also includes transferring program control to a debugger by the processor in response to executing the software breakpoint instruction. The method also includes determining, by the processor, that a Backsplitting Error (BSE) indicator is set after program control returns from the debugger. The method also includes executing, by the processor, instructions stored in a Backsplitting Error (BSE) sequence number (BSR) of the processor in response to determining that the BSE indicator is set, wherein the instructions include instructions of the software process in system memory that is replaced by the software breakpoint instruction.

[0010] In another exemplary embodiment, a non-transitory computer-readable medium having stored thereon a program of instructions, the program of instructions comprising a plurality of computer-executable instructions for execution by a processor of a processor-based device is provided. The computer-executable instructions, when executed by the processor, cause the processor to: execute a software breakpoint instruction during execution of a software process in system memory. The computer-executable instructions further cause the processor to: transfer program control to a debugger in response to executing the software breakpoint instruction. The computer-executable instructions further cause the processor to: determine, after program control returns from the debugger, that a BSE indicator of the processor is set. Furthermore, the computer-executable instructions further cause the processor to: execute instructions stored in a BSR of the processor in response to determining that the BSE indicator is set, wherein the instructions include instructions of the software process in system memory that is replaced by the software breakpoint instruction.

[0011] Those skilled in the art will understand the scope of the present disclosure and implement additional embodiments thereof after reading the following detailed description of the preferred embodiments in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate several embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0013] Figure 1 is a block diagram of an exemplary processor-based device including a processor for efficiently replacing software breakpoint instructions, according to some exemplary embodiments;

[0014] Figure 2A-2C is a flow chart illustrating the Figure 1 Example operations of a processor-based device to efficiently replace software breakpoint instructions; and

[0015] Figure 3 is an exemplary processor-based device (such as Figure 1 A block diagram of a processor-based device configured to efficiently replace software breakpoint instructions. DETAILED DESCRIPTION

[0016] Example embodiments disclosed herein include efficiently replacing software breakpoint instructions in a processor-based device. To this end, in one example embodiment, a processor of the processor-based device includes a breakpoint slip register (BSR) in which instructions can be stored to be replaced by software breakpoint instructions in system memory by a debugger. The processor also includes a breakpoint slip enable (BSE) indicator, which is a status bit that instructs the processor to execute instructions stored in the BSR rather than the instruction at the location where program control returns from the debugger (e.g., the program counter (PC) of the software breakpoint instruction). In example operation, the processor executes the software breakpoint instruction while executing a software process in system memory, which causes the processor to transfer program control to the debugger. After program control returns from the debugger, the processor determines that the processor's BSE indicator is set. In response, the processor executes the instructions stored in the BSR rather than the instruction at the PC where program control returned from the debugger. Some embodiments may provide that the processor provides multiple BSRs storing multiple instructions. In these embodiments, the processor may be configured to execute the multiple instructions stored in the multiple BSRs before executing the next instruction following the software breakpoint instruction in system memory.

[0017] According to some embodiments, when program control is transferred to a debugger, the debugger stores the instructions of the software process (i.e., the original instructions replaced by the software breakpoint instructions) in the processor's breakpoint sequence number (BSR). The debugger then sets a BSE indicator and, after completing the debugging task, returns program control to the PC of the software breakpoint instruction (e.g., by executing an instruction set architecture (ISA)-specific instruction). According to some embodiments, the processor may clear the BSE indicator after executing the instruction stored in the BSR (or, in embodiments where multiple BSRs are provided, after executing the instruction stored in the last BSR). Some embodiments may provide that the processor determines that an exception was caused by executing the instruction stored in the BSR. In response to determining that an exception was caused, the processor sets the BSR exception indicator and transfers program control to an exception handler. The exception handler determines that the BSR exception indicator is set, obtains an instruction from the BSR, and then performs exception handling for the exception based on the instruction. In embodiments where multiple BSRs are provided, provision may be made for the exception handler to use a BSR pointer (which points to the BSR and advances as each instruction stored in each BSR is executed) to obtain the instruction, as the BSR pointer indicates which BSR stores the instruction that caused the exception. In some embodiments, after executing the instruction stored in the BSR, the processor may continue executing the software process at the next instruction following the software breakpoint instruction in system memory.

[0018] Regarding this, Figure 1An exemplary processor-based device 100 is illustrated that provides a processor 102 for efficiently replacing software breakpoint instructions. Processor 102 may include a central processing unit (CPU) having one or more processor cores (not shown), and in some exemplary embodiments may be one of a plurality of similarly configured processors (not shown) of processor-based device 100. Figure 1 The processor 102 in includes an execution pipeline 104 that includes circuitry configured to execute an instruction stream of computer-executable instructions of an executing software process 106. Figure 1 In the example of FIG, the execution pipeline 104 includes: an instruction fetch stage (in Figure 1 The decoding stage (labeled as "fetch") 108, which converts the fetched instruction into a control signal for executing the instruction. Figure 1 The execution stage (labeled as "decode") 110, which is used to actually perform the execution of the instruction (in Figure 1 ) 112, and a memory access stage (in the Figure 1 It will be appreciated that in some embodiments, the execution pipeline 104 may include more than Figure 1 Fewer or more stages are illustrated in the examples.

[0019] exist Figure 1 In the example shown, processor 102 is communicatively coupled to an interconnect bus 116, which in some embodiments may include additional constituent elements (e.g., bus controller circuitry and / or arbitration circuitry, as non-limiting examples) that are not shown in the figure for clarity. Figure 1 . The processor 102 is also communicatively coupled via an interconnect bus 116 to a memory controller 118, which controls access to and manages the flow of data to and from a system memory 120. The system memory 120 provides addressable memory for the processor-based device 100 to store data, and thus, by way of non-limiting example, may include synchronous dynamic random access memory (SDRAM).

[0020] Figure 1 The processor-based device 100 may include any known digital logic elements, semiconductor circuits, processing cores, and / or memory structures, or any combination thereof. The embodiments described herein are not limited to any particular arrangement of components, and the disclosed techniques may be readily extended to various structures and layouts on semiconductor sockets or packages. It should be understood that some embodiments of the processor-based device 100 may include more than Figure 1For example, the processor 102 may also include more or fewer memory devices, execution pipeline stages, controller circuits, registers, buffers, and / or caches.

[0021] To facilitate debugging of a software process such as software process 106, Figure 1 The processor 102 executes the debugger 122. In some embodiments, the debugger 122 includes software that can coordinate with other hardware or software elements, such as a debug agent (not shown), to provide functionality such as setting breakpoints, stepping through instructions within the software process 106, observing the internal state of the software process 106 and / or the processor 102, and / or performing memory access operations on the system memory 120. During a debugging session, the debugger 122 can replace instructions in the system memory 120 with software breakpoint instructions that will halt execution of the software process 106 and transfer program control to the debugger 122. For example, in Figure 1 In the example of FIG. 1 , a code image 124 of a software process 106 in a system memory 120 (to which a debugger 122 is attached to perform debugging) begins in an initial state 126 that includes instructions (in Figure 1 128. Instructions (in Figure 1 ) 130(0), and instructions (in Figure 1 To halt execution of the software process 106 at instruction 130(0), the debugger 122 replaces instruction 130(0) with a software breakpoint instruction (in the Figure 1 1 (labeled "SOFT BKPTINSTR") 134, resulting in a modified state 136. When the processor 102 executes the software breakpoint instruction 134, an exception (not shown) is raised and program control is transferred to the debugger 122.

[0022] The debugger can then resume execution of the software process 106 at the point where the software breakpoint instruction 134 suspended execution (i.e., at the PC of the software breakpoint instruction 134). As noted above, this requires the debugger 122 to perform a series of operations to replace the software breakpoint instruction 134 in the system memory 120 with the original instruction 130(0), and to perform cache maintenance and synchronization operations to ensure that the original instruction 130(0) is correctly observed by all caches and processor cores of the processor-based device 100. However, this approach may incur significant delays and negatively impact processor performance, and may also require that all execution threads be paused while performing these operations.

[0023] therefore, Figure 1The processor 102 provides a breakpoint slip register (BSR) 138(0) and a breakpoint slip enable (BSE) indicator (in Figure 1 8 ( 0 ) and BSE indicator 140. BSR 138(0) includes a register configured to store an instruction, such as instruction 130(0), and BSE indicator 140 includes a status bit that notifies processor 102 to execute the instruction stored in BSR 138(0) rather than the instruction at the PC to which program control is returned from debugger 122. Thus, in exemplary operation, processor 102 executes software breakpoint instruction 134 in system memory 120 while executing software process 106, thereby causing an exception that causes processor 102 to transfer program control to debugger 122. In some embodiments, when program control is transferred to debugger 122, debugger 122 stores instruction 130(0) of software process 106 (i.e., the original instruction replaced by software breakpoint instruction 134) in BSR 138(0) of processor 102. Debugger 122 then sets BSE indicator 140 and, after the debugging task is complete, returns program control to the PC of software breakpoint instruction 134 (eg, by executing ISA-specific instructions).

[0024] After program control returns from the debugger 122, the processor 102 determines that the BSE indicator 140 of the processor 102 is set and, in response, executes the instruction 130(0) stored in the BSR 138(0). In some embodiments, after executing the instruction 130(0) stored in the BSR 138(0), the processor 102 may continue executing the software process 106 at the next instruction 132 following the software breakpoint instruction 134 in the system memory 120. Some embodiments may provide that the processor 102 includes a plurality of BSRs 138(0)-138(X) storing a corresponding plurality of instructions 130(0)-130(X). In such embodiments, the processor 102 may be configured to execute the plurality of instructions 130(0)-130(X) stored in the plurality of BSRs 138(0)-138(X) before executing the next instruction 132 following the software breakpoint instruction 134 in the system memory 120. In such an embodiment, the BSR pointer 142 is configured to point to one of the BSRs 138(0)-138(X) to indicate the instruction to be executed among the plurality of instructions 130(0)-130(X), and to advance to the next BSR among the BSRs 138(0)-138(X) after execution of each instruction among the plurality of instructions 130(0)-130(X) is completed. According to some embodiments, the processor 102 may also clear the BSE indicator 140 after executing the instruction 130(0) stored in the BSR 138(0) (or, in embodiments in which multiple BSRs 138(0)-138(X) are provided, after executing the instruction 130(X) stored in the final BSR 138(X) indicated by the BSR pointer 142).

[0025] In some embodiments, if an exception occurs while executing an instruction, the exception handler 144 may need to identify the specific instruction that caused the exception to determine how to handle the exception. These embodiments may provide that the processor 102 also includes a BSR exception indicator 146 to indicate that the exception was caused by executing an instruction stored, for example, in the BSR 138(0). Thus, in these embodiments, the processor 102 may determine that the exception was caused by executing the instruction 130(0) stored in the BSR 138(0). In response to determining that the exception was caused, the processor 102 sets the BSR exception indicator 146 and then transfers program control to the exception handler 144. The exception handler 144 determines that the BSR exception indicator 146 is set and, based on this determination, obtains the instruction 130(0) from the BSR 138(0) and performs exception handling for the exception based on the instruction 130(0). In embodiments where multiple BSRs 138(0)-138(X) are provided, exception handler 144 may use BSR pointer 142 to determine which of instructions 130(0)-130(X) caused the exception and to determine which BSR 138(0)-138(X) to obtain the corresponding instruction 130(0)-130(X) from.

[0026] Figure 2A-2C Illustration of a method for efficiently Figure 1 2. Example operations 200 of the processor-based device 100 to replace a software breakpoint instruction. For clarity, in describing Figure 2A-2C When cited Figure 1 According to some embodiments, Figure 2A Operation 200 in the first step is to first receive data from a processor (e.g., Figure 1 processor 102 in the system memory (e.g., Figure 1 120) in the system memory 120) to execute software processes (e.g., Figure 1 Execute a software breakpoint instruction (e.g., Figure 1 In response to executing the software breakpoint instruction 134, the processor 102 transfers program control to a debugger, such as Figure 1 In some embodiments, the debugger 122 executes the instructions of the software process 106 in the system memory 120 (e.g., Figure 1 Instruction 130(0) in is stored in the BSR of processor 102, such as Figure 1 BSR 138(0) (block 206). In this embodiment, debugger 122 then sets a BSE indicator such as Figure 1The debugger 122 then returns program control to the PC of the software breakpoint instruction 134 (eg, by executing an ISA-specific instruction, but not limited thereto) (block 210).

[0027] When program control returns from the debugger 122, the processor 102 determines that the BSE indicator 140 of the processor 102 is set (block 212). In response to determining that the BSE indicator 140 is set, the processor 102 executes the instruction 130(0) stored in the BSR 138(0) (block 214). In some embodiments (e.g., where the processor 102 provides multiple BSRs (such as Figure 1 In those embodiments of the BSRs 138(0)-138(X)), the operations of block 214 for executing the instruction 130(0) stored in the BSR 138(0) may include executing the next instruction after the software breakpoint instruction 134 in the system memory 120 (e.g., Figure 1 Before the next instruction 132), use the BSR pointer (e.g., Figure 1 BSR pointer 142) executes each of the plurality of instructions stored in the plurality of BSRs 138(0)-138(X) (e.g., Figure 1 (block 216). For example, processor 102 may initially configure BSR pointer 142 to indicate first BSR 138(0), and upon executing instruction 130(0) stored in BSR 138(0), may configure BSR pointer 142 to advance to the next BSR 138(1), and so on, until all of instructions 130(0)-130(X) have been executed. In some embodiments, operation 200 may then be performed at Figure 2B Continue at block 218 of Figure 2B According to some embodiments, the exemplary operations 200 may continue after executing the instruction 130(0) stored in the BSR 138(0), with the processor 102 clearing the BSE indicator 140 (block 218). Some embodiments may provide that the processor 102 determines that an exception was raised due to the execution of the instruction 130(0) stored in the BSR 138(0) (block 220). In response to determining that an exception was raised, the processor 102 performs a series of operations (block 222). The processor 102 sets the BSR exception indicator, such as Figure 1 The processor 102 then transfers program control to the exception handler (e.g., Figure 1138(0) indicated by the BSR pointer 142) (block 234). The exception handler 144 then performs exception handling for the exception based on the instruction 130(0) (block 236). In some embodiments, the operation 200 may then be performed at block 236. Figure 2C Continue at block 238.

[0028] Now go to Figure 2C According to some embodiments, operation 200 may include, after executing instruction 130(0) stored in BSR 138(0), processor 102 continuing execution of software process 106 at the next instruction 132 following software breakpoint instruction 134 in system memory 120 (block 238).

[0029] Figure 3 is an exemplary processor-based device 300 (such as Figure 1 1. A block diagram of a processor-based device 100 that efficiently replaces software breakpoint instructions. The processor-based device 300 may be one or more circuits included in an electronic board such as a printed circuit board (PCB), a server, a personal computer, a desktop computer, a laptop computer, a personal digital assistant (PDA), a computing board, a mobile device, or any other device, and may represent, for example, a server or a user computer. In this example, the processor-based device 300 includes a processor 302. The processor 302 represents one or more general-purpose processing circuits such as a microprocessor, a central processing unit, etc., and may correspond to a processor. Figure 1 The processor 102 is configured to execute processing logic in instructions for performing the operations and steps discussed herein. In this example, the processor 302 includes an instruction cache 304, which is a memory storage device for temporary, rapid access to instructions, and instruction processing circuitry 310. Instructions fetched or prefetched from memory (such as from system memory 308 via system bus 306) are stored in the instruction cache 304. The instruction processing circuitry 310 is configured to process the instructions fetched into the instruction cache 304 and process these instructions for execution.

[0030] Processor 302 and system memory 308 are coupled to system bus 306 (corresponding to Figure 1 The processor 302 may be connected to the system bus 306 and may interconnect the peripheral devices included in the processor-based device 300. As is well known, the processor 302 communicates with these other devices by exchanging address, control, and data information on the system bus 306. For example, the processor 302 may pass a bus transaction request to the memory controller 312 (as an example of a peripheral device) in the system memory 308. Figure 3 Although not shown in the figure, multiple system buses 306 may be provided, each of which has a different structure. In this example, a memory controller 312 is configured to provide memory access requests to a memory array 314 in the system memory 308. The memory array 314 is composed of an array of memory bit cells for storing data. As non-limiting examples, the system memory 308 may be a read-only memory (ROM), a flash memory, a dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), and a static memory such as a flash memory, a static random access memory (SRAM), and the like.

[0031] Other devices may be connected to the system bus 306. Figure 3 As illustrated in , these devices may include, by way of example, system memory 308, one or more input devices 316, one or more output devices 318, a modem 324, and one or more display controllers 320. The input device(s) 316 may include any type of input device, including, but not limited to, input keys, switches, voice processors, and the like. The output device(s) 318 may include any type of output device, including, but not limited to, audio, video, other visual indicators, and the like. The modem 324 may be any device configured to allow data to be exchanged with the network 326. The network 326 may be any type of network, including, but not limited to, a wired or wireless network, a private or public network, a local area network (LAN), a wireless local area network (WLAN), a wide area network (WAN), Bluetooth TM The modem 324 can be configured to support any desired communication protocol. The processor 302 can also be configured to access the display controller(s) 320 via the system bus 306 to control the information sent to one or more displays 322. The display(s) 322 can include any type of display, including but not limited to a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma display, etc.

[0032] Figure 3The processor-based device 300 in FIG. 3 may include a set of instructions 328 that may be encoded with an explicit consumer naming model based on coverage and executed by the processor 302 for any desired application according to the instructions. The instructions 328 may be stored in the system memory 308, the processor 302, and / or the instruction cache 304, which are examples of non-transitory computer-readable media 330. The instructions 328 may also reside completely or at least partially within the system memory 308 and / or within the processor 302 during their execution. The instructions 328 may also be transmitted or received over the network 326 via the modem 324, such that the network 326 includes the computer-readable media 330.

[0033] Although the computer-readable medium 330 is shown as a single medium in the exemplary embodiment, the term "computer-readable medium" should be understood to include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store one or more sets of instructions 328. The term "computer-readable medium" should also be understood to include any medium that can store, encode, or carry a set of instructions for execution by a processing device and cause the processing device to perform any one or more of the methods of the embodiments disclosed herein. Therefore, "computer-readable medium" should be understood to include, but is not limited to, solid-state memory, optical media, and magnetic media.

[0034] The embodiments disclosed herein include various steps. The steps of the embodiments disclosed herein may be implemented by hardware components or may be embodied as machine-executable instructions, which may be used by a general-purpose or special-purpose processor programmed with the instructions to perform the steps. Alternatively, the steps may be performed by a combination of hardware and software.

[0035] The embodiments disclosed herein may be provided as a computer program product or software, which may include a machine-readable medium (or computer-readable medium) having instructions stored thereon, which may be used to program a computer system (or other electronic device) to perform a process according to the embodiments disclosed herein. A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes: a machine-readable storage medium (e.g., ROM, random access memory ("RAM"), magnetic disk storage media, optical storage media, flash memory devices, etc.), etc.

[0036] Unless otherwise expressly stated and as is apparent from the preceding discussion, it should be understood that discussions throughout this specification using terms such as "process," "compute," "determine," "display," and the like refer to the actions and processes of a computer system or similar electronic computing device that manipulate data represented as physical (electronic) quantities within the computer system's registers and memory and transform them into other data also represented as physical quantities in the computer system's memory or registers or other such information storage, transmission, or display devices.

[0037] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various systems may be used in conjunction with the programs taught herein, or it may prove convenient to construct more specialized devices to perform the required method steps. The various structures required for these systems will be apparent from the above description. In addition, the embodiments described herein are not described with reference to any particular programming language. It will be appreciated that the teachings of the embodiments described herein may be implemented using a variety of programming languages.

[0038] Those skilled in the art will further appreciate that the various exemplary logic blocks, modules, circuits, and algorithms described in conjunction with the embodiments disclosed herein can be implemented as electronic hardware, instructions stored in a memory or other computer-readable medium and executed by a processor or other processing device, or a combination thereof. For example, the components of the system described herein can be adopted in any circuit, hardware component, integrated circuit (IC), or IC chip. The memory disclosed herein can be a memory of any type and size and can be configured to store any type of required information. In order to clearly illustrate this interchangeability, various exemplary components, blocks, modules, circuits, and steps have been summarized and described above with respect to their functions. The implementation of these functions depends on specific applications, design choices, and / or design constraints imposed on the entire system. Technicians can implement the described functions in a varying manner for each specific application, but this implementation decision should not be interpreted as causing deviations from the scope of the present embodiment.

[0039] The various logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed using a processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, which are designed to perform the functions described herein. In addition, the controller may also be a processor. The processor may be a microprocessor, but in an alternative embodiment, the processor may also be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in combination with a DSP core, or any other such configuration).

[0040] The embodiments disclosed herein may be embodied in hardware and instructions stored in hardware and may reside in, for example, RAM, flash memory, ROM, electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), registers, hard disk, removable disk, CD-ROM, or any other form of computer-readable medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. In an alternative, the storage medium may be integrated into the processor. The processor and storage medium may reside in an ASIC. The ASIC may reside in a remote station. In an alternative, the processor and storage medium may reside as discrete components in a remote station, a base station, or a server.

[0041] It should also be noted that the operational steps described in any exemplary embodiment herein are described to provide examples and discussions. The described operations can be performed in a variety of different orders other than the illustrated order. In addition, the operations described in a single operational step can actually be performed in several different steps. In addition, one or more operational steps discussed in the exemplary embodiment can be used in combination. Those skilled in the art will also understand that information and signals can be represented using any of a variety of techniques and methods. For example, the data, instructions, commands, information, signals, bits, symbols, and chips that may be cited in the above description can be represented by voltage, current, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof.

[0042] Unless otherwise expressly stated, any method described herein is not intended to be construed as requiring that its steps be performed in a specific order. Therefore, if a method claim does not actually recite the order in which its steps should be followed, or if the claims or description do not expressly state that the steps are to be limited to a specific order, no specific order is intended to be inferred.

[0043] It will be apparent to those skilled in the art that various modifications and variations may be made without departing from the spirit or scope of the invention. Since modifications, combinations, sub-combinations, and variations of the disclosed embodiments that incorporate the spirit and substance of the invention may occur to those skilled in the art, the invention should be construed to include all within the scope of the appended claims and their equivalents.

Claims

1. A processor-based device comprising: System memory; as well as A processor, the processor comprising: a breakpoint slip register (BSR) configured to store an instruction of a software process replaced by a software breakpoint instruction in the system memory; and Breakpoint Slip Enable (BSE) indicator; The processor is configured to, during execution of the software process: Executing the software breakpoint instruction; In response to executing the software breakpoint instruction, transferring program control to a debugger; After program control returns from the debugger, determining that the BSE indicator is set; and In response to determining that the BSE indicator is set, executing the instructions stored in the BSR.

2. The processor-based device of claim 1 , wherein the processor is further configured to, after transferring program control to the debugger, execute the debugger to: Storing the instruction in the BSR; Setting the BSE indicator; as well as Returns program control to the program counter (PC) of the software breakpoint instruction.

3. The processor-based device of any one of claims 1-2, wherein the processor is further configured to: clear the BSE indicator after executing the instruction stored in the BSR.

4. The processor-based device of any one of claims 1-3, wherein the processor is further configured to: after executing the instruction stored in the BSR, continue executing the software process at the next instruction after the software breakpoint instruction in the system memory.

5. The processor-based device of any one of claims 1 to 4, wherein: The processor also includes a BSR exception indicator; and The processor is further configured to: determining that an exception was caused by executing the instruction stored in the BSR; and The exception is raised in response to determining: Setting the BSR abnormality indicator; as well as Transfers program control to the exception handler.

6. The processor-based device of claim 5 , wherein the processor is further configured to execute the exception handler to: determining that the BSR abnormality indicator is set; and In response to determining that the BSR anomaly indicator is set: Obtaining the instruction from the BSR; and Exception handling is performed for the exception based on the instruction.

7. The processor-based device of claim 6, wherein: The BSR includes a BSR in a plurality of BSRs storing corresponding plurality of instructions; The processor further includes a BSR pointer configured to indicate a BSR among the plurality of BSRs; as well as The processor is configured to obtain the instruction from the BSR by being configured to obtain the instruction from the BSR indicated by the BSR pointer.

8. The processor-based device of any one of claims 1 to 7, wherein: The BSR includes a BSR in a plurality of BSRs storing corresponding plurality of instructions; The processor further includes a BSR pointer configured to indicate a BSR among the plurality of BSRs; as well as The processor is configured to execute the instructions stored in the BSRs by being configured to execute each of the plurality of instructions stored in the plurality of BSRs using the BSR pointer before executing a next instruction following the software breakpoint instruction in the system memory.

9. A method for efficiently replacing a software breakpoint instruction, comprising: executing, by a processor of a processor-based device, a software breakpoint instruction during execution of a software process in system memory; In response to executing the software breakpoint instruction, the processor transfers program control to a debugger; After program control returns from the debugger, determining, by the processor, that a breakpoint slip enable (BSE) indicator of the processor is set; as well as In response to determining that the BSE indicator is set, instructions stored in a breakpoint slip register (BSR) of the processor are executed by the processor, wherein the instructions include instructions of the software process replaced in the system memory by the software breakpoint instructions.

10. The method according to claim 9, further comprising: The debugger executed by the processor stores the instruction in the BSR; Setting the BSE indicator by the debugger; as well as Returns program control to the program counter (PC) of the software breakpoint instruction.

11. The method according to any one of claims 9-10, further comprising: The BSE indicator is cleared by the processor after executing the instructions stored in the BSR.

12. The method according to any one of claims 9 to 11, further comprising: After executing the instruction stored in the BSR, execution of the software process is continued by the processor at the next instruction following the software breakpoint instruction in the system memory.

13. The method according to any one of claims 9 to 12, further comprising: determining, by the processor, that an exception was caused by executing the instruction stored in the BSR; as well as The exception is raised in response to determining: Setting, by the processor, a BSR exception indicator; and The processor transfers program control to an exception handler.

14. The method according to claim 13, further comprising: The exception handling program executed by the processor determines that the BSR exception indicator is set; as well as In response to determining that the BSR anomaly indicator is set: Obtaining the instruction from the BSR by the exception handling program; as well as The exception handler performs exception handling on the exception based on the instruction.

15. The method according to claim 14, wherein: The BSR includes a BSR in a plurality of BSRs storing corresponding plurality of instructions; as well as Obtaining the instruction from the BSR comprises obtaining the instruction from the BSR indicated by a BSR pointer of the processor; The BSR pointer is configured to indicate a BSR among the multiple BSRs.

16. The method according to any one of claims 9 to 15, wherein: The BSR includes a BSR in a plurality of BSRs storing corresponding plurality of instructions; as well as Executing the instructions stored in the BSR includes: executing each of the plurality of instructions stored in the plurality of BSRs using a BSR pointer of the processor before executing a next instruction following the software breakpoint instruction in the system memory, The BSR pointer is configured to indicate a BSR among the multiple BSRs.

17. A computer-readable medium having stored thereon a program of instructions, the program of instructions comprising a plurality of computer-executable instructions for execution by a processor of a processor-based device, the plurality of computer-executable instructions, when executed by the processor, causing the processor to: executing a software breakpoint instruction during execution of the software process in the system memory; In response to executing the software breakpoint instruction, transferring program control to a debugger; After program control returns from the debugger, determining that a breakpoint slip enable (BSE) indicator of the processor is set; as well as In response to determining that the BSE indicator is set, instructions stored in a breakpoint slip register (BSR) of the processor are executed, wherein the instructions include instructions of the software process replaced in the system memory by the software breakpoint instructions.

18. The computer-readable medium of claim 17, wherein the plurality of computer-executable instructions further cause the processor to: using the debugger executed by the processor, storing the instruction in the BSR; setting the BSE indicator using the debugger; and Returns program control to the program counter (PC) of the software breakpoint instruction.

19. The computer-readable medium of any one of claims 17-18, wherein the plurality of computer-executable instructions further cause the processor to clear the BSE indicator after executing the instruction (130(0)) stored in the BSR.

20. The computer-readable medium of any one of claims 17-19, wherein the plurality of computer-executable instructions further cause the processor to continue executing the software process at a next instruction following the software breakpoint instruction in the system memory after executing the instruction stored in the BSR.

Images