On Friday 15 January 2010, David Brownell wrote: > On Friday 15 January 2010, Igor Skochinsky wrote: > > This is pretty standard. Most targets cannot continue from a > > breakpoint (i.e. they just stop at the same position), so GDB removes > > breakpoint, steps, puts it back and then continues. > > On the other hand, if there's no breakpoint at the current address, GDB > > should just issue continue straight away. If it doesn't, there might > > be something else at work... > > Another theory about what might be happening on ARM11: > > There's partial hardware breakpoint support in the new DMP code, > and maybe it's kicking in when it shouldn't. It *should* kick in > to erase breakpoints at OpenOCD startup; they'd be left over from > a previous debug session. > > But unless the particular core is using the DPM breakpoint > code, it shouldn't kick in at any other time.
In fact, that's a clear bug ... I committed a workaround. Later, the patch adding DPM breakpoint support will override that as needed. Can you see if that change resolves the issue you saw? The confusion about what that flag means is a separate issue. - Dave > I might not have noticed such a bug when I tested a while back, > since I have (still incomplete) patches to make ARM11 use that > breakpoint code. But mainline should still be using the older > ARM11-internal breakpoint code (which among other things does > not support soft breakpoints). > > I'll look at that as soon as I finish a few other bits; I've > not yet done my ARM11 sanity testing for the 0.4 code. > > - Dave > > _______________________________________________ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
