Efficiently exchanging software breakpoint instructions in processor-based devices - Patent Application 20070122967

Abstract

Efficient exchange of software breakpoint instructions in a processor-based device is disclosed. In this regard, in one exemplary embodiment, a processor for the 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 exchanged for a software breakpoint instruction in the system memory, and further includes a breakpoint slip enable (BSE) indicator. The processor is configured to execute the software breakpoint instruction during execution of the software process. In response to executing the software breakpoint instruction, the processor is further configured to transfer program control to a debugger. The processor is further configured to determine to set the BSE indicator when program control returns from the debugger. In response to determining to set the BSE indicator, the processor is further configured to execute the instructions stored in the BSR.

Description

[Technical Field]

[0001] Field of Disclosure The disclosed technology relates to debugging in processor-based devices, and more particularly to handling software breakpoint instructions during debugging. [Background technology]

[0002] background The instruction set architectures (ISAs) on which conventional processor-based devices are based provide software breakpoint instructions that can be used during debugging of a software process. To debug a software process, a developer tool known as a debugger attaches to a target software process in system memory, providing the ability to control program flow and inspect the internal state of the target software process. The software breakpoint instructions may be used by the debugger to stop execution of the target software process at a specified point (i.e., at a given program counter (PC) within the target software process). To accomplish this during a debugging session, the debugger replaces instructions in system memory with software breakpoint instructions at the specified point. When the processor executes the software breakpoint instruction, it causes an exception, thereby stopping execution of the target software process and transferring program control to the debugger.

[0003] The debugger may then resume execution of the target software process at the point where execution was stopped 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 to perform cache maintenance and synchronization operations to ensure that the original instruction is properly observed by all caches and processor cores within the processor-based device. The debugger may further configure the processor to re-enter debugging at the next instruction following the software breakpoint instruction, requiring that the next instruction be replaced with another software breakpoint instruction and further cache maintenance and synchronization operations to ensure that the newly inserted software breakpoint instruction is properly 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, there are drawbacks associated with conventional approaches to handling software breakpoint instructions. The above-described operations of performing cache maintenance and synchronization each time an instruction in system memory is swapped for a software breakpoint instruction (or vice versa) can incur significant latency and adversely affect processor performance. Furthermore, there is a risk that while the debugger is performing the above-described operations, another processor thread executing on the processor-based device may not observe the software breakpoint instruction. To mitigate this risk, the entire thread of execution may be stopped while the operations are being performed, resulting in further degradation of processor performance.

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

[0006] overview Exemplary embodiments disclosed herein include efficiently exchanging software breakpoint instructions in a processor-based device. In this regard, in one exemplary embodiment, a processor of a processor-based device includes a breakpoint slip register (BSR) that can store instructions to be exchanged for software breakpoint instructions in system memory by a debugger. Additionally, the processor includes a breakpoint slip enable (BSE) indicator, which is a status bit that notifies the processor to execute the instructions stored in the BSR instead of the instructions at the location where program control returns from the debugger (e.g., the program counter (PC) of the software breakpoint instruction). During typical operation, the processor executes a software breakpoint instruction while executing a software process in system memory, and the processor transfers program control to the debugger. When program control returns from the debugger, the processor determines to set the processor's BSE indicator. In response, the processor executes the instructions stored in the BSR instead of the instructions at the PC where program control returns from the debugger. In some embodiments, the processor may include multiple BSRs that store corresponding instructions. In such an embodiment, the processor may be configured to execute multiple instructions stored in 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 the debugger, the debugger stores the software operation instructions (i.e., the original instructions replaced with the software breakpoint instructions) in the processor's BSR. The debugger then sets a BSE flag and, upon completion of 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 flag after executing the instructions stored in the BSR (or, in embodiments with multiple BSRs, after executing the instructions stored in the final BSR). In some embodiments, the processor may determine that an exception has occurred as a result of executing the instructions stored in the BSR. In response to determining that an exception has occurred, the processor sets a BSR exception flag and transfers program control to an exception handler. The exception handler determines to set the BSR exception flag, retrieves the instructions from the BSR, and then performs exception handling for the exception based on the instructions. In embodiments with multiple BSRs, a BSR pointer, which points to a BSR and is advanced with execution of each instruction stored in each BSR, may be used by the exception handler to retrieve the instruction because 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 in system memory following the software breakpoint instruction.

[0008] In another exemplary embodiment, a processor for 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 instructions for a software process exchanged with a software breakpoint instruction in the system memory, and further 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 to set the BSE indicator when program control returns from the debugger. The processor is further configured to execute the instructions stored in the BSR in response to determining to set the BSE indicator.

[0009] In another exemplary embodiment, a method for efficiently exchanging software breakpoint instructions in a processor-based device is provided. The method includes executing, by a processor of the processor-based device, a software breakpoint instruction during execution of a software process in system memory. The method further includes transferring program control, by the processor, to a debugger in response to executing the software breakpoint instruction. The method further includes determining, by the processor, to set a BSE flag of the processor when program control returns from the debugger. The method further includes, in response to determining to set the BSE flag, executing, by the processor, instructions stored in a BSR of the processor, the instructions including instructions of the software process that have been exchanged for the software breakpoint instruction in system memory.

[0010] In another exemplary embodiment, a non-transitory computer-readable medium is provided. The computer-readable memory stores a program of instructions including a plurality of computer-executable instructions for execution by a processor of a processor-based device. 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, when program control returns from the debugger, to set a BSE indicator of the processor. The computer-executable instructions further cause the processor to execute instructions stored in a BSR of the processor in response to determining to set the BSE indicator, the instructions including instructions of the software process replaced in system memory with the software breakpoint instruction.

[0011] Those skilled in the art will appreciate the scope of the present disclosure and realize additional embodiments of the present disclosure after reading the following detailed description of the preferred embodiments in conjunction with the accompanying drawings.

[0012] BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and form a part of this specification, illustrate several embodiments of the disclosure and, together with the description, serve to explain the principles of the disclosure. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a block diagram of an example processor-based device including a processor that efficiently exchanges software breakpoint instructions, according to some example embodiments. [Figure 2A] 2 is a flowchart illustrating an example operation for efficiently exchanging software breakpoint instructions by the processor-based device of FIG. 1. [Figure 2B]2 is a flowchart illustrating an example operation for efficiently exchanging software breakpoint instructions by the processor-based device of FIG. 1. [Figure 2C] 2 is a flowchart illustrating an example operation for efficiently exchanging software breakpoint instructions by the processor-based device of FIG. 1. [Figure 3] 1 is a block diagram of an example processor-based device (e.g., the processor-based device of FIG. 1) configured to efficiently exchange software breakpoint instructions, according to some example embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0014] Detailed Description Exemplary embodiments disclosed herein include efficiently exchanging software breakpoint instructions in a processor-based device. In this regard, in one exemplary embodiment, a processor of a processor-based device includes a breakpoint slip register (BSR) that can store instructions to be exchanged for software breakpoint instructions in system memory by a debugger. Additionally, the processor includes a breakpoint slip enable (BSE) indicator, which is a status bit that notifies the processor to execute the instructions stored in the BSR instead of the instructions at the location where program control returns from the debugger (e.g., the program counter (PC) of the software breakpoint instruction). During typical operation, the processor executes a software breakpoint instruction while executing a software process in system memory, and the processor transfers program control to the debugger. When program control returns from the debugger, the processor determines to set the processor's BSE indicator. In response, the processor executes the instructions stored in the BSR instead of the instructions at the PC where program control returns from the debugger. In some embodiments, the processor may include multiple BSRs that store corresponding instructions. In such an embodiment, the processor may be configured to execute multiple instructions stored in multiple BSRs before executing the next instruction following the software breakpoint instruction in system memory.

[0015] According to some embodiments, when program control is transferred to the debugger, the debugger stores the software operation instructions (i.e., the original instructions replaced with the software breakpoint instructions) in the processor's BSR. The debugger then sets a BSE flag and, upon completion of 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 flag after executing the instructions stored in the BSR (or, in embodiments with multiple BSRs, after executing the instructions stored in the final BSR). In some embodiments, the processor may determine that an exception has occurred as a result of executing the instructions stored in the BSR. In response to determining that an exception has occurred, the processor sets a BSR exception flag and transfers program control to an exception handler. The exception handler determines to set the BSR exception flag, retrieves the instructions from the BSR, and then performs exception handling for the exception based on the instructions. In embodiments with multiple BSRs, a BSR pointer, which points to a BSR and is advanced with execution of each instruction stored in each BSR, may be used by the exception handler to retrieve the instruction because 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 in system memory following the software breakpoint instruction.

[0016] In this regard, Figure 1 illustrates an exemplary processor-based device 100 that provides a processor 102 that efficiently exchanges 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 multiple similarly configured processors (not shown) of processor-based device 100. Processor 102 of Figure 1 includes an execution pipeline 104 that includes circuitry configured to execute an instruction stream of computer-executable instructions for executing software process 106. 1, execution pipeline 104 includes a fetch stage 108 (labeled "FETCH" in FIG. 1) that retrieves instructions for execution, a decode stage 110 (labeled "DECODE" in FIG. 1) that converts the fetched instructions into control signals for instruction execution, an execute stage 112 (labeled "EXECUTE" in FIG. 1) that actually performs the instruction execution, and a memory access stage 114 (labeled "MEMORY ACCESS" in FIG. 1) that performs memory access operations (e.g., memory load operations and / or memory store operations) that result from the instruction execution. In some embodiments, execution pipeline 104 may include fewer or more stages than those illustrated in FIG. 1.

[0017] 1, processor 102 is communicatively coupled to interconnect bus 116, which in some embodiments may include additional components not shown in FIG. 1 for clarity (e.g., bus controller circuitry and / or arbitration circuitry, as non-limiting examples). Processor 102 is further communicatively coupled via interconnect bus 116 to memory controller 118, which controls access to and manages the flow of data into system memory 120. System memory 120 provides addressable memory used for data storage by processor-based device 100, and as such may include, as non-limiting example, synchronous dynamic random access memory (SDRAM).

[0018] The processor-based device 100 of FIG. 1 may include, among other elements, any one or combination of known digital logic elements, semiconductor circuits, processing cores, and / or memory structures. The embodiments described herein are not limited to any particular arrangement of elements, and the disclosed techniques can be readily extended to various configurations and layouts on a semiconductor socket or package. It is understood that some embodiments of the processor-based device 100 may include more or fewer elements than those illustrated in FIG. 1. For example, the processor 102 may further include more or fewer memory devices, execution pipeline stages, controller circuits, registers, buffers, and / or caches.

[0019] 1 executes a debugger 122. In some embodiments, the debugger 122 includes software that can coordinate with other hardware or software elements, such as a debugging agent (not shown), to provide functionality (e.g., setting breakpoints), step through the execution of instructions within the software process 106, observe the internal state of the software process 106 and / or the processor 102, and / or perform memory access operations to the system memory 120. During a debugging session, the debugger 122 may exchange instructions in the system memory 120 with software breakpoint instructions that halt execution of the software process 106 and transfer program control to the debugger 122. 1 , code image 124 of software process 106 in system memory 120 (as debugger 122 performs debugging) begins with initial state 126, which includes instruction 128 (labeled "INSTR" in FIG. 1 ), instruction 130(0) (labeled "INSTR" in FIG. 1 ), and instruction 132 (labeled "INSTR" in FIG. 1 ). To stop execution of software process 106 at instruction 130(0), debugger 122 replaces instruction 130(0) with software breakpoint instruction 134 (labeled "SOFT BKPT INSTR" in FIG. 1 ), resulting in modified state 136. When software breakpoint instruction 134 is executed by processor 102, it causes an exception (not shown) to transfer program control to debugger 122.

[0020] The debugger may then resume execution of software process 106 at the point where execution was stopped by software breakpoint instruction 134 (i.e., at the PC of software breakpoint instruction 134). As described above, this requires debugger 122 to perform a series of operations to replace software breakpoint instruction 134 with original instruction 130(0) in system memory 120, and to perform cache maintenance and synchronization operations to ensure that original instruction 130(0) is properly observed by all caches and processor cores of processor-based device 100. However, this approach can incur significant latency, adversely affecting processor performance, and may further require the halting of all threads of execution while performing these operations.

[0021] 1 provides a breakpoint slip register (BSR) 138(0) and a breakpoint slip enable (BSE) indicator 140 (labeled "BSE INDICATOR" in FIG. 1). BSR 138(0) includes a register configured to store an instruction (e.g., instruction 130(0)), while BSE indicator 140 includes a status bit that informs processor 102 to execute the instruction stored in BSR 138(0) instead of the instruction in the PC that returns program control from debugger 122. Thus, during typical operation, processor 102, while executing software process 106, executes software breakpoint instruction 134 in system memory 120, 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 that was swapped for software breakpoint instruction 134) in BSR 138(0) of processor 102. Debugger 122 then sets BSE flag 140 and, upon completion of the debugging task, returns program control to the PC of software breakpoint instruction 134 (e.g., by executing an ISA-specific instruction).

[0022] When program control returns from debugger 122, processor 102 determines to set processor 102's BSE flag 140 and, in response, executes instruction 130(0) stored in BSR 138(0). In some embodiments, after executing instruction 130(0) stored in BSR 138(0), processor 102 may continue executing software process 106 at the next instruction 132 following software breakpoint instruction 134 in system memory 120. In some embodiments, processor 102 may include multiple BSRs 138(0)-138(X) that store a corresponding plurality of instructions 130(0)-130(X). In such embodiments, processor 102 may be configured to execute the plurality of instructions 130(0)-130(X) stored in multiple BSRs 138(0)-138(X) before executing the next instruction 132 following software breakpoint instruction 134 in system memory 120. In such an embodiment, BSR pointer 142 is configured to point to one of BSRs 138(0)-138(X), to indicate an instruction among the plurality of instructions 130(0)-130(X) to execute, and is advanced to the next BSR among BSRs 138(0)-138(X) upon completion of execution of each instruction among the plurality of instructions 130(0)-130(X). According to some embodiments, processor 102 may clear BSE indicator 140 after executing instruction 130(0) stored in BSR 138(0) (or, in embodiments providing multiple BSRs 138(0)-138(X), after executing instruction 130(X) stored in the final BSR 138(X) as indicated by BSR pointer 142).

[0023] In some embodiments, when an exception occurs when executing an instruction, exception handler 144 must identify the specific instruction that caused the exception to determine how to handle the exception. In such embodiments, processor 102 may further include BSR exception flag 146, which indicates, for example, that the exception was caused by execution of an instruction stored in BSR 138(0). Thus, in such embodiments, processor 102 may determine that the exception was caused as a result of execution of instruction 130(0) stored in BSR 138(0). In response to determining that the exception was caused, processor 102 sets BSR exception flag 146 and then transfers program control to exception handler 144. Exception handler 144 determines to set BSR exception flag 146 and, based on the determination, retrieves instruction 130(0) from BSR 138(0) and performs exception handling for the exception based on instruction 130(0). In embodiments with multiple BSRs 138(0)-138(X), the exception handler 144 may use the BSR pointer 142 to determine which instruction 130(0)-130(X) caused the exception and from which BSR 138(0)-138(X) to obtain the corresponding instruction 130(0)-130(X).

[0024] 2A-2C illustrate example operations 200 for efficiently exchanging software breakpoint instructions by the processor-based device 100 of FIG. 1. For clarity, reference will be made to elements of FIG. 1 when describing FIGS. 2A-2C. According to some embodiments, operation 200 in FIG. 2A begins with a processor (e.g., processor 102 of FIG. 1) executing a software breakpoint instruction (e.g., software breakpoint instruction 134 of FIG. 1) during execution of a software process (e.g., software process 106 of FIG. 1) in a system memory (e.g., system memory 120 of FIG. 1) (block 202). In response to executing software breakpoint instruction 134, processor 102 transfers program control to a debugger (e.g., debugger 122 of FIG. 1) (block 204). In some embodiments, debugger 122 stores the instruction of software process 106 in system memory 120 (e.g., instruction 130(0) in FIG. 1 ) in a BSR of processor 102 (e.g., BSR 138(0) in FIG. 1 ) (block 206). In such an embodiment, debugger 122 then sets a BSE flag (e.g., BSE flag 140 in FIG. 1 ) (block 208). Debugger 122 then returns program control to the PC of software breakpoint instruction 134 (e.g., by executing an ISA-specific instruction, as a non-limiting example) (block 210).

[0025] When program control returns from debugger 122, processor 102 determines to set BSE flag 140 of processor 102 (block 212). In response to determining to set BSE flag 140, processor 102 executes instruction 130(0) stored in BSR 138(0) (block 214). In some embodiments (e.g., embodiments in which processor 102 provides multiple BSRs (e.g., BSRs 138(0)-138(X) in FIG. 1 )), the operation of block 214 of executing instruction 130(0) stored in BSR 138(0) may include executing each of the multiple instructions (e.g., instructions 130(0)-130(X) in FIG. 1 ) stored in multiple BSRs 138(0)-138(X) using a BSR pointer (e.g., BSR pointer 142 in FIG. 1 ) before executing the next instruction following software breakpoint instruction 134 in system memory 120 (e.g., next instruction 132 in FIG. 1 ) (block 216). For example, processor 102 may first configure BSR pointer 142 to point to first BSR 138(0), and upon execution of instruction 130(0) stored in BSR 138(0), configure BSR pointer 142 to advance to the next BSR 138(1), continuing in the same manner until all instructions 130(0)-130(X) have executed. In some embodiments, operation 200 may then continue to block 218 of FIG. 2B.

[0026] Referring now to FIG. 2B , according to some embodiments, the example operations 200 may continue with processor 102 clearing BSE indicator 140 after executing instruction 130(0) stored in BSR 138(0) (block 218). In some embodiments, processor 102 may determine that an exception has occurred as a result of executing instruction 130(0) stored in BSR 138(0) (block 220). In response to determining that an exception has occurred, processor 102 performs a series of actions (block 222). Processor 102 sets a BSR exception indicator (e.g., BSR exception indicator 146 of FIG. 1 ) (block 224). Processor 102 then transfers program control to an exception handler (e.g., exception handler 144 of FIG. 1 ) (block 226). Exception handler 144 determines to set BSR exception indicator 146 (block 228). In response to determining to set BSR exception flag 146, processor 102 performs a series of operations (block 230). Exception handler 144 retrieves instruction 130(0) from BSR 138(0) (block 232). In embodiments that provide multiple BSRs 138(0)-138(X), the operation of block 232 to retrieve instruction 130(0) may include exception handler 144 retrieving instruction 130(0) from BSR 138(0) indicated by BSR pointer 142 (block 234). Exception handler 144 then performs exception processing for the exception based on instruction 130(0) (block 236). In some embodiments, operation 200 may then continue to block 238 of FIG. 2C.

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

[0028] 3 is a block diagram of an exemplary processor-based device 300 (e.g., processor-based device 100 of FIG. 1) that efficiently exchanges software breakpoint instructions. Processor-based device 300 may be a circuit or circuits included in an electronic board card, e.g., a printed circuit board (PCB), a server, a personal computer, a desktop computer, a laptop computer, a personal digital assistant (PDA), a computing pad, a handheld device, or any other device, and may represent, for example, a server or a user computer. In this example, processor-based device 300 includes processor 302. Processor 302 represents one or more general-purpose processing circuits (e.g., a microprocessor, a central processing unit, etc.) and may correspond to processor 102 of FIG. 1. Processor 302 is configured to execute processing logic with instructions that perform the operations and steps described herein. In this example, processor 302 includes an instruction cache 304 for temporary fast-access memory storage of instructions, and instruction processing circuitry 310. Instructions fetched or prefetched from memory (e.g., system memory 308) across system bus 306 are stored in instruction cache 304. Instruction processing circuitry 310 is configured to process instructions fetched into instruction cache 304 and to process the instructions for execution.

[0029] The processor 302 and the system memory 308 are coupled to a system bus 306 (corresponding to interconnection bus 116 in FIG. 1 ), which may interconnect 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 over the system bus 306. For example, the processor 302 may communicate bus transaction requests to a memory controller 312 in the system memory 308, as an example of a peripheral device. Although not illustrated in FIG. 3 , multiple system buses 306 may be provided, with each system bus comprising a different fabric. In this example, the memory controller 312 is configured to provide memory access requests to a memory array 314 in the system memory 308. The memory array 314 consists of an array of storage bit cells that store data. The system memory 308 may be, by way of non-limiting example, read-only memory (ROM), flash memory, dynamic random access memory (DRAM) (e.g., synchronous DRAM (SDRAM)), and static memory (e.g., flash memory, static random access memory (SRAM)), etc.).

[0030] Other devices may be connected to the system bus 306. As illustrated in FIG. 3, these devices may include, by way of example, a 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 devices 316 may include any type of input device, including, but not limited to, input keys, switches, audio processors, etc. The output devices 318 may include any type of output device, including, but not limited to, audio, video, other visual indicators, etc. The modem 324 may be any device configured to enable the exchange of data over a 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), a Bluetooth™ network, and the Internet. The modem 324 may be configured to support any type of desired communication protocol. Additionally, the processor 302 may be configured to access a display controller 320 over the system bus 306 to control information sent to one or more displays 322. The displays 322 may include any type of display, including, but not limited to, a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma display, etc.

[0031] 3 may include a set of instructions 328 encoding a reach-based explicit consumer naming model to be executed by processor 302 for any desired application in accordance with the instructions. The instructions 328 may be stored in system memory 308, processor 302, and / or instruction cache 304, as examples of a non-transitory computer-readable medium 330. Furthermore, the instructions 328 may reside completely or at least partially within system memory 308 and / or processor 302 during execution. Furthermore, the instructions 328 may be transmitted or received over network 326 via modem 324, such that network 326 includes computer-readable medium 330.

[0032] Although the computer-readable medium 330 is shown in an exemplary embodiment to be a single medium, the term "computer-readable medium" should be taken 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. Furthermore, the term "computer-readable medium" should be taken to include any medium that can store, encode, or retain a set of instructions for execution by a processing device, causing the processing device to perform any one or more of the methodologies of the embodiments disclosed herein. Accordingly, the term "computer-readable medium" should be taken to include, but is not limited to, solid-state memory, optical media, and magnetic media.

[0033] The embodiments disclosed herein include various steps. The steps of the embodiments disclosed herein may be formed by hardware components or embodied in machine-executable instructions usable to cause 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.

[0034] Embodiments disclosed herein may be provided as a computer program product or software that includes a machine-readable medium (or computer-readable medium) having instructions (stored on the machine-readable medium) usable to program a computer system (or other electronic device) to perform processes according to 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, machine-readable media include machine-readable storage media (e.g., ROM, random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices, etc.).

[0035] Unless otherwise specified, as is apparent from the above, throughout the specification, descriptions using, for example, the terms "processing," "computing," "determining," "displaying," etc., will be understood to refer to the operations and processing of a computer system or similar electronic computing device that manipulates and transforms data and memory represented as physical (electronic) quantities in the registers of the computer system into other data that is similarly represented as physical quantities in the memory or registers of the computer system or other such information storage, transmission, or display device.

[0036] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will emerge from the description above. Further, the embodiments described herein are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages ​​can be used to implement the teachings of the embodiments as described herein.

[0037] Furthermore, those skilled in the art will appreciate that the various illustrative logic blocks, modules, circuits, and algorithms described in connection with the embodiments disclosed herein can be implemented as electronic hardware, instructions stored in a memory or another computer-readable medium and executed by a processor or other processing device, or a combination of both. The components of the systems described herein may be used in, by way of example, any circuit, hardware component, integrated circuit (IC), or IC chip. The memories disclosed herein may be any type and size of memory and may be configured to store any type of desired information. To clearly illustrate this interchangeability, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. How such functionality is implemented will depend on the particular application, design choices, and / or design constraints imposed on the overall system. While skilled artisans may implement the described functionality in various ways for each particular application, such implementation decisions should not be interpreted as a departure from the scope of the present embodiments.

[0038] The various illustrative logic blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed by 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 designed to perform the functions described herein. Further, a controller may be a processor. A processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. Further, a processor may be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).

[0039] The embodiments disclosed herein may be embodied in hardware and with instructions stored in hardware, which may reside, for example, in 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 the processor such that the processor can read information from, and write information to, the storage medium. Alternatively, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a remote station. Alternatively, the processor and the storage medium may reside as discrete components in a remote station, base station, or server.

[0040] It is also noted that the operational steps described in any of the exemplary embodiments described herein are described for purposes of example and explanation. The described operations may be performed in many different orders other than the illustrated order. Furthermore, an operation described as a single operational step may actually be performed in many different steps. Furthermore, one or more operational steps described in an exemplary embodiment may be combined. Furthermore, those skilled in the art will appreciate that information and signals may be represented using any of a variety of technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips referenced throughout the above specification may be represented by voltages, currents, electromagnetic waves, magnetic fields, or particles, optical fields or particles, or any combination thereof.

[0041] Unless otherwise expressly specified, it is in no way intended that any method described herein be construed as requiring that the method steps be performed in a particular order. Thus, unless a method claim actually recites the order in which the method steps should be followed, or unless the claim or specification specifically states otherwise that the steps should be limited to a particular order, no particular order is intended to be inferred.

[0042] It will be apparent to those skilled in the art that various modifications and variations can be made without departing from the spirit or scope of the present invention. Since modifications, combinations, subcombinations and variations of the disclosed embodiments that incorporate the spirit and essence of the present invention may occur to those skilled in the art, the present invention should be construed as including all within the scope of the appended claims and equivalents of the claims.

Claims

1. System memory; a breakpoint slip register (BSR) configured to store software operation instructions that are replaced with software breakpoint instructions in the system memory; Breakpoint Slip Enable (BSE) indicator and a processor including Including, The processor, during execution of the software process, Execute the software breakpoint instruction; transferring program control to a debugger in response to executing said software breakpoint instruction; determining that the BSE flag is set when program control returns from the debugger; In response to determining to set the BSE flag, execute the instructions stored in the BSR. It is configured as follows: Processor-based devices.

2. After the processor transfers program control to the debugger, storing the instructions in the BSR; establishing the BSE tag; Return program control to the program counter (PC) of the software breakpoint instruction The processor-based device of claim 1 , further configured to execute the debugger.

3. 3. The processor-based device of claim 1, wherein the processor is further configured to clear the BSE indicator after executing the instructions stored in the BSR.

4. 4. The processor-based device of claim 1, wherein the processor is further configured to, after executing the instruction stored in the BSR, continue execution of the software process at a next instruction in the system memory following the software breakpoint instruction.

5. The processor further includes a BSR exception indicator; The processor: determining that an exception occurred as a result of execution of the instruction stored in the BSR; In response to determining that the exception has been caused, setting the BSR exception indicator; Transfers program control to an exception handler The processor-based device of any one of claims 1 to 4, further configured to:

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

7. the BSR includes one of a plurality of BSRs storing a corresponding plurality of instructions; the processor further includes a BSR pointer configured to point to a BSR among the plurality of BSRs; the processor is configured to retrieve the instruction from the BSR indicated by the BSR pointer, thereby retrieving the instruction from the BSR; The processor-based device of claim 6.

8. the BSR includes one of a plurality of BSRs storing a corresponding plurality of instructions; the processor further includes a BSR pointer configured to point to a BSR among the plurality of BSRs; the processor is configured to execute the instructions stored in the BSRs by using the BSR pointer to execute each of the instructions stored in the BSRs before executing a next instruction following the software breakpoint instruction in the system memory. A processor-based device according to any one of claims 1 to 7.

9. 1. A method for efficiently exchanging software breakpoint instructions, comprising: Executing, by a processor of the processor-based device, a software breakpoint instruction during execution of a software process in a system memory; transferring program control by the processor to a debugger in response to executing the software breakpoint instruction; determining by the processor to set a breakpoint slip enable (BSE) flag for the processor when program control returns from the debugger; executing, by the processor, instructions stored in a breakpoint slip register (BSR) of the processor in response to determining to set the BSE flag, the instructions including instructions of the software process replaced in the system memory with the software breakpoint instructions; A method comprising:

10. storing the instructions in the BSR by the debugger executed by the processor; setting the BSE flag by the debugger; returning program control to the program counter (PC) of said software breakpoint instruction; The method of claim 9 further comprising:

11. 11. The method of claim 9 or 10, further comprising clearing, by the processor, the BSE indicator after executing the instructions stored in the BSR.

12. 12. The method of claim 9, further comprising, after executing the instruction stored in the BSR, continuing execution of the software process by the processor at a next instruction in the system memory following the software breakpoint instruction.

13. determining by the processor that an exception occurred as a result of execution of the instruction stored in the BSR; In response to determining that the exception has been caused, setting a BSR exception flag by said processor; transferring program control by said processor to an exception handler; The method of any one of claims 9 to 12, further comprising:

14. determining by the exception handler executed by the processor that the BSR exception flag is set; In response to determining to set the BSR exception indicator, obtaining the instruction from the BSR by the exception handler; executing exception processing for the exception based on the instruction by the exception handler; The method of claim 13 further comprising:

15. the BSR includes one of a plurality of BSRs storing a corresponding plurality of instructions; retrieving the instruction from the BSR includes retrieving the instruction from the BSR indicated by a BSR pointer of the processor; the BSR pointer is configured to indicate a BSR among the plurality of BSRs; 15. The method of claim 14.

16. the BSR includes one of a plurality of BSRs storing a corresponding plurality of instructions; executing the instructions stored in the BSR includes executing each of the instructions stored in the 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 plurality of BSRs; The method according to any one of claims 9 to 15.

17. 1. A computer-readable medium having stored thereon a program of instructions including a plurality of computer-executable instructions for execution by a processor of a processor-based device, wherein when the plurality of computer-executable instructions are executed by the processor, the processor: Execute a software breakpoint instruction while a software process is running in system memory; transferring program control to a debugger in response to executing said software breakpoint instruction; determining that a breakpoint slip enable (BSE) indicator for the processor is set when program control returns from the debugger; In response to determining to set the BSE flag, executing instructions stored in a breakpoint slip register (BSR) of the processor, the instructions including instructions of the software process that have been replaced in the system memory with the software breakpoint instructions. So that, Computer-readable medium.

18. The plurality of computer-executable instructions may further cause the processor to: storing the instructions in the BSR with the debugger executed by the processor; setting the BSE flag with the debugger; Return program control to the program counter (PC) of the software breakpoint instruction 20. The computer-readable medium of claim 17,

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

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

Images