This is the mail archive of the gdb@sourceware.org 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]

Reporting 'out of hardware breakpoints' situation


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




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