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. 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 [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
