From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25329 invoked by alias); 11 Oct 2011 14:50:44 -0000 Received: (qmail 25314 invoked by uid 22791); 11 Oct 2011 14:50:43 -0000 X-SWARE-Spam-Status: No, hits=-7.2 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; Tue, 11 Oct 2011 14:50:26 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9BEoN5s032741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Oct 2011 10:50:23 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p9BEoNeJ024861; Tue, 11 Oct 2011 10:50:23 -0400 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 p9BEoLvM011644; Tue, 11 Oct 2011 10:50:22 -0400 From: Tom Tromey To: Pedro Alves Cc: gdb@sourceware.org Subject: Re: some questions about ranged breakpoints References: <201110111110.49848.pedro@codesourcery.com> Date: Tue, 11 Oct 2011 14:50:00 -0000 In-Reply-To: <201110111110.49848.pedro@codesourcery.com> (Pedro Alves's message of "Tue, 11 Oct 2011 11:10:49 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2011-10/txt/msg00057.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Tom> What should actually happen here? Pedro> I think we should remove the assertion, and have each location map to a Pedro> hardware accelerated ranged breakpoint, instead of assuming there can Pedro> be only one. This isn't much different from creating a regular Pedro> (non-range) hardware breakpoint that ends up mapping to more than Pedro> one location. Ok, that makes sense, but unfortunately I think it yields other weird behavior. The problem is that you must somehow pair start and end locations; you might even see more of one than the other. I thought that pairing could perhaps be done by sorting the addresses and, for each address in the first list, choose the nearest greater address from the second list. However, my worry with any heuristic like this is that a re-set could cause the breakpoint to change in an unforseen way, yielding wrong results for the user. Also the parsing is a pain when you have multiple matches. Consider the difference between a relative linespec (break-range file.c:73, +5) and an absolute one (break-range file.c:73, file.c:78). We don't know before parsing whether a linespec is relative. So, I think we have to reparse the second linespec in the context of each result from the first linespec, then eliminate dups... gross, but I guess doable. Tom