From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21960 invoked by alias); 24 Jun 2009 11:58:36 -0000 Received: (qmail 21952 invoked by uid 22791); 24 Jun 2009 11:58:35 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 24 Jun 2009 11:58:30 +0000 Received: (qmail 16004 invoked from network); 24 Jun 2009 11:58:27 -0000 Received: from unknown (HELO wind.localnet) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Jun 2009 11:58:27 -0000 From: Vladimir Prus To: gdb@sources.redhat.com Subject: Reporting 'out of hardware breakpoints' situation Date: Wed, 24 Jun 2009 11:58:00 -0000 User-Agent: KMail/1.11.90 (Linux/2.6.24-24-generic; KDE/4.2.90; i686; svn-979530; 2009-06-10) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200906241558.23737.vladimir@codesourcery.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00223.txt.bz2 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