This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: ARM7, remote GDB, Software Breakpoints
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