This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]