From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16512 invoked by alias); 4 Jul 2011 19:20:28 -0000 Received: (qmail 16504 invoked by uid 22791); 4 Jul 2011 19:20:27 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 04 Jul 2011 19:20:11 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 940FE2BB1EE; Mon, 4 Jul 2011 15:20:10 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id s8EN260GZhxa; Mon, 4 Jul 2011 15:20:10 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 654842BB1E8; Mon, 4 Jul 2011 15:20:10 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id E968D145615; Mon, 4 Jul 2011 12:20:05 -0700 (PDT) Date: Mon, 04 Jul 2011 19:32:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [RFC] canonical linespec and multiple breakpoints ... Message-ID: <20110704192005.GQ2407@adacore.com> References: <20110505162855.GA2546@adacore.com> <83bozgmhil.fsf@gnu.org> <83k4dcd1bh.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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-07/txt/msg00114.txt.bz2 > Here is my proposal for how to handle ambiguous linespecs. First I'll > describe it in general terms, with a few specifics about the > implementation. Then I'll describe how it handles each scenario I > posted yesterday. Overal, I think that this is a very nice proposal. > I propose a simple rule for the handling of ambiguous linespecs: a > breakpoint whose argument is ambiguous will fire at all matching > locations. I think that this is a good general rule, and something we should encourage our users to use. But it seems that it does not cover the case where 'set multiple-symbols ask' is in use, does it? My understanding, when `ask' is that, if the user selects `all', then we're in the case above (fire at all locations, add new locations as we discover them), but if the user selects a sub-sets of the potential matches, what should we do? My suggestion, in that case, is to make the list of selected locations static. In other words, we do not add new locations as they get discovered. The typical scenario is when we have multiple instantiations of a given generic, and the user is only interested in debugging one, or at least a small subset. In that case, a typical user debugging using a GUI or an IDE will click on the code, which is often translated into a FILE:LINE linespec. > In order to properly re-set breakpoints, we need a canonical form of the > linespec. Currently this is done by constructing a new canonicalized > linespec. In my proposal we will replace this with a structure, the > better to add more precise behavior without needing to construct > linespec syntax for every possible case. E.g., we can have a bit > indicating whether this canonical linespec matches symbols without > debuginfo. I think it's important to have some kind of canonical form that the user's can use as the linespec as well. That way, they can enter a linespec that, in the vast majority of cases, is not ambiguous. For our purposes, FILE:FUNCTION:LINE has worked really well... > I am not sure how the breakpoint location information should be arranged > internally. Perhaps each bp_location will need a canonical linespec > struct. I would think so. > Tom> 4. Set a pending breakpoint. > Tom> (gdb) break lib_function > Tom> 5. The same, but the pending name is ambiguous. > > These both make a pending breakpoint; inferior changes may cause > locations to be added or removed. So, pending breakpoints are implicitly treated as breakpoints with multiple-symbols set to `all', right? I think that'd be fair. > Tom> 7. 'break main', then start multiple inferiors > > Each new inferior causes new locations to be added; gdb stops at the > 'main' of each one. I hadn't thought about that. I thought that breakpoints were specific to a given inferior, but I guess we'd want that, at least in certain scenarios (the ones where we're trying to follow a process and all its children for instance). I think this behavior makes sense, new inferior and new SOs can be treated the same. > Tom> 8. Any of the above, but with a breakpoint condition. > Tom> Of particular importance is the case where the condition cannot be > Tom> parsed in one location. > > This, I think, is the one bad part of this proposal. When a location is > added to a breakpoint, it may cause the condition to no longer be > parseable. > > In this situation I think we should change gdb in 2 ways, to give the > user more control: > > 1. When a condition is no longer parseable, provide the option to stop > the inferior so the user can correct it. > 2. Also provide a way for the user to respecify the breakpoint location. > > For the latter I think something like: > > modify breakpoint N location LINESPEC Looks good. By extension, we could also allow 'modify breakpoint N condition', as an alias of the 'cond' command (I am not suggesting this too seriously, just to say that I like the `modify ' syntax, which we can extend for other stuff we might need in the future). -- Joel