ARM7, remote GDB, Software Breakpoints

[Steven Johnson]

>
>
>This was touched recently.  The remote logic decides that 0 hardware
>breakpoint resources are available; I don't remember if the patch to
>fix it was checked in.  You might want to ask Andrew if he remembers
>the problem.
>
>There's probably something in the host gdb you have to set.
>
>  
>

Very recently, I posted a patch to the gdb patches list, that allows the 
user to set the number of hardware breakpoints and watchpoints their 
target supports by way of commands within GDB.  I never received any 
feedback for it, so I don't know what status it is.

I also tackeled it defferently.  In my stub, when I set a breakpoint I 
Favour Hardware breakpints (because I think they are better).  So if gdb 
tells the stub to set a breakpoint, regardless of type, then I set 
hardware breakpoints until they are exhausted, and then I fall back to 
software breakpoints.  If GDB explicitly tells my stub to set hardware 
breakpoints it sets these first. (And then falls back to software).  So 
basically I prioritise breakpoints and use what GDB tells the stub as a 
hint, so:

1. Set GDB Requested Hardware Breakpoints first.
2. Set GDB Requested Software Breakpoints second.
3. Until all hardware breakpoints are consumed, set hardware breakpoints.
4. When all hardware breakpoints are consumed revert to software 
breakpoints.

This works really well for me.  The only thing the user has to be 
carefull of is not setting too many breakpoints when debugging in ROM. 
 But if your not carefull enough to do this, your probably not capable 
of debugging ROM based code anyway :)

Steven Johnson