I think breakpoint handling has been kind of a mess for a long time. No documentation on internal interfaces ... and in some cases there seemed to be internal conflicts.
On Wednesday 13 January 2010, yintang gu wrote: > > In function > > arm7_9_resume(struct target *target, int current, uint32_t address, > int handle_breakpoints, int debug_execution) (arm7_9_common.c), ... called by target_resume(), and which is called with handle_breakpoints=true from handle_resume_command() and armv4_5_run_algorithm_inner() ... and with that flag set "false" from other places. > the argument handle_breakpoints is only used to deal with the condition in > which a breakpoint is set at current PC. If that flag is set and there's a breakpoint at the current PC, it does some fairly awkward stuff to execute that instruction then continue. > But in function arm11_resume() (arm11.c) it is used to decide weather setting > the breakpoints and watch points to the target hardware. We're slowly making the ARM11 code behave "just like other ARMs", but that's slow going ... it started being VERY different. In the current code (0.4-rc) it's changed to be a lot more similar; large chunks of standard ARM infrastructure now work with it. Note that ec64acf536942168b4e038c6720c83687d3a0d08 is where one bug was fixed, making it do the same "if there's a breakpoint at current PC" stuff for ARM11 ... previously ARM11 wouldn't work with the standard run_algorithm() code. The approach to breakpoint handling in the ARM11 code is not quite the same as for ARM9. Some of it is hardware-related, and thus necessarily different. One difference just avoids doing some foolish and slow stuff: ARM11 and Cortex-A8 avoid modifying breakpoint or and watchpoint state unless it really needs to change it. See dpm_maybe_update_bpwp(). So where ARM9 wastes time clearing and restoring breakpoints, those newer cores may just leave them always active. > The GDB cannot operate correctly for arm11, for gdb server call target_resume > with handle_breakpoints=0 which leads to the breakpoints cannot be set to the > target correctly. Hmm ... is this a bug you've observed, or is this something you've wondered after poking through the code? I recall setting breakpoints through the Tcl interface and having them behave correctly. Haven't tried to do that any time recently, though. And I could believe there's a bit of a semantic conflict between debug via GDB and via Tcl; not one we want, of course!! > Any one can explain what's argument handle_breakpoints > meaning? thanks. I've had that question many times myself. You'll notice there's about zero documentation on that topic, and its semantics are evidently both overloaded and vague. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
