Reporting 'out of hardware breakpoints' situation

Reporting 'out of hardware breakpoints' situation

[Vladimir Prus]

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?

Thanks,
Volodya

Re: Reporting 'out of hardware breakpoints' situation

[David Daney]

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

Re: Reporting 'out of hardware breakpoints' situation

[Daniel Jacobowitz]

On Wed, Jun 24, 2009 at 10:35:45AM -0700, David Daney wrote:
> 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.

FYI, I noticed a target we're working on that has two ways to
implement hardware breakpoints.  One only works in a certain address
space, and the other shares hardware resources with watchpoints.
So figuring out how many breakpoints are available is pretty
complex.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Reporting 'out of hardware breakpoints' situation

[Eli Zaretskii]

> Date: Wed, 24 Jun 2009 13:46:54 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Vladimir Prus <vladimir@codesourcery.com>, gdb@sources.redhat.com
> 
> So figuring out how many breakpoints are available is pretty
> complex.

I think it's pretty much impossible.  (We have a similar problem with
hardware watchpoints.)  Several breakpoints can be set to the same
address, in which case a single register can serve all of them, but
deciding that this is the case is tricky at best.

I think the way of throwing an exception and then handling it to
revert to the original state is much more promising.