From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1641 invoked by alias); 16 Jan 2006 06:58:59 -0000 Received: (qmail 1629 invoked by uid 22791); 16 Jan 2006 06:58:58 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.204) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 16 Jan 2006 06:58:55 +0000 Received: by zproxy.gmail.com with SMTP id m22so1035167nzf for ; Sun, 15 Jan 2006 22:58:54 -0800 (PST) Received: by 10.36.77.16 with SMTP id z16mr4826083nza; Sun, 15 Jan 2006 22:58:53 -0800 (PST) Received: by 10.37.2.42 with HTTP; Sun, 15 Jan 2006 22:58:53 -0800 (PST) Message-ID: <8f2776cb0601152258n1210346ak95154a1dda2a22d1@mail.gmail.com> Date: Mon, 16 Jan 2006 06:58:00 -0000 From: Jim Blandy To: Robert Dewar Subject: Re: : Re: [RFC] multiple breakpoints from FILE:LINE Cc: Paul Koning , comar@adacore.com, hilfingr@gnat.com, gdb@sourceware.org In-Reply-To: <43CA888E.20607@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43C9AAA8.2030605@adacore.com> <17354.31047.417000.385481@gargle.gargle.HOWL> <43CA888E.20607@adacore.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00134.txt.bz2 On 1/15/06, Robert Dewar wrote: > I strongly object to removing the menus which are very convenient to > use. No proposal here comes close to being as convenient. For the > overriding case, here is typical usage: Your example doesn't correspond to the case we're discussing. In your example (if I'm guessing my way through Ada and your .gdbinit user-defined functions properly), there is an ambiguity in what "parent" refers to; the menu lets you select one. But the case being discussed in this thread is menus that appear in response to a location specified by a filename and line number. It's not clear that the kind of legitimate ambiguity you're concerned about is present here. When a function has been inlined, it's odd for users to demand to be able to set breakpoints on one inlined instance but not another. You can't set a breakpoint on a function conditional on it having been called from a certain place; why would users suddenly require that functionality just because the compiler decided to optimize the code in a certain way? In-charge and not-in-charge constructors are a similar situation.=20 There's nothing in the semantics of the source language that ever suggests that there are two separate reifications of the single block of code the user wrote. This differs from instantiations of generics, which (if I understand right) are things that the user actually did ask for. The two constructor instances don't behave differently, as far as the source level in concerned. Separating the two is purely an implementation strategy, and should be hidden from the user when reasonable. In cases where the same code has been #included twice, I think there's more of a case that users might want to choose one or the other, since it is indeed explicit in the source code that this particular source line is going to contribute twice to the translation unit. But even here, setting the breakpoint in both places would be a clear improvement over what we do now: choose one #inclusion randomly. (The last time we discussed this, Michael Chastain pointed out that you actually *do* want to choose a specific constructor instance when you're disassembling. But we're talking about breakpoints here; the decision just needs to be made at the right place, so we can do one thing for 'break' and a different thing for 'disass'.)