Re: [Openocd-development] Very confusing situation w/OpenOCD software breakpoints

[Vincent P. <vin...@m4...>]

On Friday 30 November 2007 13:42, Øyvind Harboe wrote:
> The solution that comes to mind:
>
> - OpenOCD should check if the application modified the breakpoint sites,
> and if so, it should not restore the breakpoint site.
> - The user must set a breakpoint after code has been copied
> from flash to RAM, e.g. main(). At this point, the breakpoint sites
> are not restored,
> but left alone and when debugging resumes, the breakpoint sites in RAM are
> set up correctly.

I think we should really fix that.

 I have quickly written a small patch. I don't have hardware here, but I 
attach a patch if your target is ARM7/9, feel free to test it and give us 
results.

> - OpenOCD has no way of knowing whether the application wrote a value to
> the breakpoint site that is identical to the breakpoint instruction.
> In this case OpenOCD would mistakenly restore the breakpoint site. 
> Tough. I don't believe this would be observed much, if at all, in real life.

In fact, OpenOCD writes "BKPT" instruction in the breakpoint site. This 
instruction is never used by real life program, so this case should not occur
( excepted if user try to use some very special programs such as kernel 
debugger along with JTAG session)

> Comments?

For the described situation (ie debugging around code relocation) , IMHO the 
user should use hardware breakpoints and not software ones.
(by using GDB "hbreak" keyword)

-- 
Vincent