Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Vladimir Prus <vladimir@codesourcery.com>
To: gdb@sources.redhat.com
Subject: Reporting 'out of hardware breakpoints' situation
Date: Wed, 24 Jun 2009 11:58:00 -0000	[thread overview]
Message-ID: <200906241558.23737.vladimir@codesourcery.com> (raw)


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




             reply	other threads:[~2009-06-24 11:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-24 11:58 Vladimir Prus [this message]
2009-06-24 17:37 ` David Daney
2009-06-24 17:47   ` Daniel Jacobowitz
2009-06-24 17:56     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200906241558.23737.vladimir@codesourcery.com \
    --to=vladimir@codesourcery.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox