From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25141 invoked by alias); 12 Apr 2011 20:34:29 -0000 Received: (qmail 25017 invoked by uid 22791); 12 Apr 2011 20:34:28 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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, 12 Apr 2011 20:34:22 +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 p3CKYH96016641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2011 16:34:17 -0400 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 p3CKYGdu029299; Tue, 12 Apr 2011 16:34:16 -0400 Received: from opsy.redhat.com (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 p3CKYFTu021602; Tue, 12 Apr 2011 16:34:16 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id A8C4B3791BA; Tue, 12 Apr 2011 14:34:15 -0600 (MDT) From: Tom Tromey To: Pedro Alves Cc: Jan Kratochvil , gdb-patches@sourceware.org, Sergio Durigan Junior Subject: Re: [PATCH 2/6] Introduce `pre_expanded sals' References: <201104121218.08910.pedro@codesourcery.com> <20110412115308.GA384@host1.jankratochvil.net> <201104121430.24596.pedro@codesourcery.com> Date: Tue, 12 Apr 2011 20:34:00 -0000 In-Reply-To: <201104121430.24596.pedro@codesourcery.com> (Pedro Alves's message of "Tue, 12 Apr 2011 14:30:24 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-04/txt/msg00173.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> I disagree with that generalization. E.g., next, you'll want that Pedro> a break on "C::C" (with C being a C++ class) sets a location on each Pedro> contructor overload). Yes. Pedro> And then breakpoints set in in-charge and Pedro> not-in-charge versions of each of those constructors ends up at the Pedro> same hierarchycal level under that super breakpoint. If the user wants Pedro> to disable one of the (source level) overloads, he now needs to know Pedro> about the multiple locations of that specific overload. Sure, because `break C::C' is ambiguous. In some particular subset of such cases, gdb recognizes the ambiguity and presents a menu to the user. In other cases gdb either does something random (it picks a location according to a hidden algorithm) or sets a breakpoint on all locations (the `break file.c:73' inline case -- but even that seems to involve some mystery, since from what I see it seems to check for matching enclosing function names). I don't think this is a very good state of affairs. Pedro> Another argument, is that frontends and users using them aren't Pedro> expecting that a single breakpoint is represented by more than Pedro> one visual "point", circle next to the sources, or something like Pedro> that. Hitting F8 to toggle a breakpoint's enablement changing Pedro> some other location source "point" enablement in the sources not Pedro> currently visible seems to break some abstration to me. I think Pedro> such design change needs to consider all these issues (and be Pedro> experimented with some frontend). I think we should not worry excessively about CLI users adapting. I see what you mean about MI, but in practice I think MI clients generally set `file:line' breakpoints anyway. In any case historical arguments don't apply to the SystemTap case, which is new. No existing front end will request probe points. Tom