From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28407 invoked by alias); 29 May 2011 13:01:17 -0000 Received: (qmail 28391 invoked by uid 22791); 29 May 2011 13:01:15 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_40,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-yi0-f41.google.com (HELO mail-yi0-f41.google.com) (209.85.218.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 29 May 2011 13:01:00 +0000 Received: by yib18 with SMTP id 18so1624535yib.0 for ; Sun, 29 May 2011 06:00:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.176.74 with SMTP id a50mr4559990yhm.507.1306674059260; Sun, 29 May 2011 06:00:59 -0700 (PDT) Received: by 10.236.111.40 with HTTP; Sun, 29 May 2011 06:00:59 -0700 (PDT) In-Reply-To: References: <20110505162855.GA2546@adacore.com> <83bozgmhil.fsf@gnu.org> Date: Sun, 29 May 2011 13:01:00 -0000 Message-ID: Subject: Re: [RFC] canonical linespec and multiple breakpoints ... From: Matt Rice To: Tom Tromey Cc: Eli Zaretskii , brobecker@adacore.com, gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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-05/txt/msg00663.txt.bz2 On Thu, May 26, 2011 at 2:05 PM, Tom Tromey wrote: > It is worth thinking about "time invariance". =A0E.g., suppose we adopt > Jerome's "menu" plan. =A0In this case, an ambiguous linespec can present > the user with a menu (depending on a setting). =A0But what happens if a > linespec is not ambiguous, but then becomes ambiguous due to changes in > the inferior? > > Time invariance and canonicalization also affects the multi-inferior > case. =A0The current plan is to handle multi-inferior breakpoints using > I/T sets; but it seems to me that these may match names in different > ways across inferiors. =A0A simple example is just `break [*] main' -- > this either makes a single breakpoint (with all the attendant true > multi-location problems), or binds eagerly (contra the `[*]' spec), or > introduces a tiered breakpoint (but with a more complex example perhaps > one requires 4 tiers? =A0It is unclear to me). I guess it is worth noting that I had previously thought about the Time invariance problem in isolation of the grouping problem. At that time what I had imagined was a 'perpetually pending breakpoint', or a 'pending rolling snowball breakpoint', basically a pending breakpoint which is not removed when it is resolved, it inserts the resolved breakpoint, but does not remove the pending one. thinking about the grouping mechanism also in isolation leads one to consider the idea of 'breakpoint groups', where the 'perpetually pending breakpoint', contains a group ID, and when it resolves, the newly inserted breakpoint gets inserted into the same group as its pending one. If a breakpoint group could contain breakpoint groups, as well as breakpoints, we have a tiering mechanism. Additionally i could see some benefit in being able to enable/disable whole groups of breakpoints at a time.