From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12994 invoked by alias); 30 Nov 2011 19:38:25 -0000 Received: (qmail 12986 invoked by uid 22791); 30 Nov 2011 19:38:25 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 30 Nov 2011 19:38:10 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pAUJc71k009055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Nov 2011 14:38:07 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id pAUJc6lh032414; Wed, 30 Nov 2011 14:38:07 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id pAUJc4bh005436; Wed, 30 Nov 2011 14:38:05 -0500 From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [RFC/WIP PATCH 09/14] I/T set support for breakpoints - trigger set, and stop set References: <20111128153742.17761.21459.stgit@localhost6.localdomain6> <20111128153942.17761.96028.stgit@localhost6.localdomain6> Date: Wed, 30 Nov 2011 19:38:00 -0000 In-Reply-To: (Tom Tromey's message of "Tue, 29 Nov 2011 15:02:11 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-11/txt/msg00856.txt.bz2 >>>>> "Tom" == Tom Tromey writes: Tom> First, I've been thinking we should probably make breakpoint re-setting Tom> more fine-grained. The idea would be to classify the events that Tom> current cause a re-set, giving them separate APIs in breakpoint.c, so Tom> that we can make re-setting more efficient. E.g., a new inferior should Tom> not cause a breakpoint to reset if the breakpoint cannot possibly match Tom> that inferior. I'm just trolling for your reaction to this. Also, I remembered that I think this has a small implication for the itset code. Some event may make it impossible for a breakpoint to ever trigger again; for example it could be inferior-specific and the inferior could exit. It seems like it would be nice to either delete the breakpoint in this case, or at least warn the user. To do this, an itset would need a method for "can this ever possibly match again", with static sets being able to answer "no". Tom