On Wed, Sep 15, 2010 at 7:58 PM, Mike Dunn <miked...@newsguy.com> wrote:
>  On 09/15/2010 08:47 AM, Drasko DRASKOVIC wrote:
>
> I sent in a patch a while back to fix this very problem on the xscale; i.e.,
> software breakpoints didn't work because of cache issues.  The problem was
> clear: execution failed to halt on software breakpoints most of the time.  And
> always if set a few instructions ahead of the current value of the pc.  Once 
> the
> code to clean and flush the cache was added, the problem went away and I 
> haven't
> seen any issues since, and I use sw breakpoints frequently.
Yes, not hitting breakpoint can make one suspect on caches, i.e.
breakpoint was put in RAM, but not replicated in cache.
Here we are facing different behavior : breakpoint is always hit, no
mater at which instruction it is put.

>
> My guess is that this is not a cache issue.  I never saw wierd behavior like
> winding up at the same instruction after a step.  If I were seeing the same
> problem on my target, I would guess a bug in the single-stepping code.
I am thinking the same - not a cache issue, but breakpoint
management/single stepping bug. I also said that it might have
something to do with interrupt handling, having in mind of SIGINT
involved in a SW breakpoint mechanism...

Best regards,
Drasko
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to