Browse Prior Art Database

Method for Allowing Multiple Breakpoints on a Processor with a Single Breakpoint Address Register Disclosure Number: IPCOM000016319D
Original Publication Date: 2002-Oct-18
Included in the Prior Art Database: 2003-Jun-21

Publishing Venue



A method is disclosed that utilizes a single breakpoint address register to emulate multiple breakpoints. Breakpoints are an essential feature in software debugging tools. Some processor architectures, including the NP4GS3 model of the IBM PowerNP, only provide a single breakpoint address register that stores an instruction address at which the processor halts execution. When the processor is halted, an attached debugger can read and display the current state information of the processor allowing a programmer to test and identify problems in the software. This disclosure addresses the need for a debugger to set breakpoints on multiple instruction addresses when the target processor architecture only provides a single breakpoint address register, while using the minimum amount of processor resources to avoid interfering with the execution environment of the programmer. The proposed method utilizes a single instruction address to store a return instruction. When a debugger is attached to a processor, a return instruction is first stored at a specified location in the instruction address space and the address of that instruction is stored in the breakpoint address register. Each time a programmer sets a breakpoint on an instruction address, the debugger inserts a branch-and-return instruction in place of the programmer’s instruction and stores the programmer’s instruction in a table along with the address of the instruction. The branch-and-return instruction is assembled such that the target address of the branch is the address of the inserted return instruction. If the processor has cached the instruction where the programmer is setting the breakpoint at the time it is being set, or if the instruction is in the processor pipeline at that time, the processor must be forced to refetch the instruction and/or flush the pipeline. When the processor executes the instruction at the address of the effective breakpoint, it will branch to the address where the return instruction has been inserted and then halt. At this time the debugger can intervene to replace the previously inserted branch-and-return instruction with the programmer’s original instruction, which is obtained from the forementioned table. The debugger also needs to decrement the address at the top of the call stack so that the processor returns to the instruction address at which it branched from. Now the debugger will single-step the processor causing it to return to the address where the breakpoint was set and the programmer’s original instruction will be awaiting execution. The state of the processor can then be read and displayed by the debugger. When the user requests the processor to run again, the processor will be single-stepped once by the debugger and then the branch-and-return instruction will be reinserted, so that the breakpoint will halt the processor again the next time it is hit. When the breakpoint is removed by the programmer, the original instruction is inserted back into the old breakpoint address and the corresponding table entry is removed.