Implementation of break points

Started by Sandeep Chikkerur October 20, 2004
"Raymond Toy" <> wrote in message
>>>>>> "Andrew" == Andrew Reilly <> writes: > > Andrew> On Tue, 19 Oct 2004 20:42:43 -0700, Sandeep Chikkerur wrote: > >> I am not sure if this is the right place to ask this question. > >> When we are debugging some application , say in simulation, we often put > >> the breakpoints, to see what is happening at that place. > >> > >> (Example : in Code Composer Studio, we put breakpoints ) > >> > >> I want to know how the breakpoints are implemented ? > > Andrew> In the days before "debug assist" hardware was ubiquitous in > processors, > Andrew> debuggers would insert breakpoints by replacing the piece of code > at the > Andrew> desired site with a call to the breakpoint entry routine. > Continuing > Andrew> execution would then involve emulating the replaced instruction(s) > and > Andrew> executing a "return from subroutine" instruction. > > Andrew> Nowadays most processors include special registers that are > compared > Andrew> against the processor's instruction pointer (or even data memory > Andrew> accesses), and either trap (interrupt) or enter > in-circuit-emulation mode > Andrew> when a match occurs. The details tend to be slightly different > from > Andrew> processor to processor. > > But surely, there can't be enough special registers to handle all the > breakpoints that someone might want to use? I might have 20 or more > breakpoints (not necessarily all active) in complicated code. I would > think breakpoints are still implemented by inserting a special > instruction. The special registers would be used for things like > watch-points so you can tell if something is being read or written and > from where. > > But I'm guessing here. > > Ray
Yes, you are correct. If you look at Microsoft's Kernel Level Debugger or NuMega's SoftIce you will find both HW and SW breakpoints. There are usually a few CPU registers that allow you to set a HW breakpoints - these are extremely fast but relatively dumb and you can only set a few of them. On the other hand you can have SW breakpoints which are essentially implemented as people have shown in this thread. In this case you can wrap a great deal of logic around this breakpoint - you can set as many as the software(debugger) and memory allow, but they slow down the execution. Depending on the type of App you're writing you would use different types of breakpoints. Best, Dave