Implementation of break points

"Raymond Toy" <raymond.toy@ericsson.com> wrote in message 
news:sxdmzyhv6jq.fsf@edgedsp4.rtp.ericsson.se...
>>>>>> "Andrew" == Andrew Reilly <andrew-newspost@areilly.bpc-users.org> 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