Re: Reporting 'out of hardware breakpoints' situation

[David Daney <ddaney at caviumnetworks dot com>]

Vladimir Prus wrote:
> On most targets, only a few hardware breakpoints are allowed. GDB is
> generally aware of that limitation, however there are two issues with
> how that awareness is implemented:
>
> 1. GDB only reports the problem when trying to continue the application,
> except when always-inserted mode is in effect. For breakpoints inserted
> right after starting GDB, the problem is reported only when starting
> application.
>
> 2. GDB reports the problem as warning, and continues.
>
> So, if user accidentally inserted more hardware breakpoints than target
> supports, the program will run or continue with random subset of those
> breakpoints inserted -- hardly good.
>
> The straightforward approach is to modify insert_breakpoint_locations to
> call "error", not "warning", when we cannot insert some breakpoints. However,
> after looking at this for a while, it does not seem like this can be done
> reliably. [As I have already complained] GDB, despite using exceptions, is
> not exception safe. In particular, proceed first sets the PC to resume,
> and then calls insert_breakpoints. If the latter throws, it does not seem
> like PC will be changed back, and GDB will end up in inconsistent state.
> insert_breakpoints is called in a number of places, examining them all and
> possibly fixing sounds non-trivial. This probably can be handled in a piecemeal
> fashion -- so that 'continue' and 'run' throw an error if breakpoints
> cannot be inserted, and other commands continue to emit a warning until the
> relevant codepaths are examined.
>
> Another approach would to report "too many hardware breakpoints" when a
> breakpoint is added -- regardless of whether it is inserted in the target
> at this point. However:
> - for remote targets we don't have any idea how many breakpoints are supported,
> and we'd need extend the remote protocol (target description) to report that.
> - we don't necessary know the target until find_default_run_target does its magic. 
>
> Anybody has comments on which path is most reasonable, or alternative suggestions?

It is a difficult problem.  There is also the case where multiple 
hardware breakpoints can be covered by a single hardware watch register 
(if two or more watched locations were adjacent in memory).  It makes it 
difficult to know exactly how many breakpoints you can support.

I don't like the idea of refusing to add a breakpoint before we can know 
for certain that it will fail.  Thus I prefer your first option of 
calling error while inserting them.

The drawback is that the naive user will undoubtedly be confused if they 
could add many breakpoints without any warnings, but then when they do a 
'continue' they get cryptic error messages.


With the second approach how do you handle breakpoints that are disabled 
and then enabled?


David Daney