Just found this post when I was looking for arm7_9 force_hw_bkpts.

- How is one supposed to force the use of hardware breakpoints, for example 
when debugging via insight?

- How are software breakpoints handled in the absence of the arm7_9 sw_bkpts 
command? The old behaviour was to disable software breakpoints by default on 
targets that required the use of a watchpoint unit (ARMv4, e.g. ARM7TDMI) and 
enable them on hardware supporting the BKPT instruction (ARMv5, e.g. 
ARM926EJ-S).

Maybe it would have been better to discuss these changes after the list was up 
again, to give people actually a chance to send feedback...

Regards,

Dominic

On Thursday 14 August 2008 16:35:57 Øyvind Harboe wrote:
> Committed.
>
> The mailing list has been out so there are various other things
> that have been fixed as well.
>
> On Wed, Aug 13, 2008 at 5:29 PM, Øyvind Harboe <[EMAIL PROTECTED]> 
wrote:
> > These days GDB will have a much better idea of what sort
> > of breakpoints to ask OpenOCD to set.
> >
> > E.g. if the memory map is set up, then GDB will ask GDB to
> > use hardware breakpoints.
> >
> > In ARM7/9 there is currently some code that promotes hardware/software
> > breakpoints to hardware or software breakpoints according to
> > some more or less nebulous rules.
> >
> > This promotion belongs in gdb_server.c and not in the target.
> >
> > Additionally there is a problem with breakpoints not being set up
> > correctly because it is unclear when the embedded ice watch
> > registers should be set up.
> >
> > The attached patch will:
> >
> > - clear the watchpoint registers before the first breakpoint is
> > added(gdb_server does this upon every step/resume) and
> > after the last breakpoint has been removed.
> > - retires the arm7_9 sw/hw breakpoint configuration commands. If
> > breakpoint type promotion is to be added back, it belongs in
> > gdb_server.c. - there is much less conditional code w.r.t. assumptions
> > about what the state of the watch registers is on the target
> >
> >
> > The patch is not done yet, but I'd appreciate any feedback.


_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to