From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26066 invoked by alias); 15 Oct 2003 18:20:36 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26059 invoked from network); 15 Oct 2003 18:20:35 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 15 Oct 2003 18:20:35 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h9FIKYM05664 for ; Wed, 15 Oct 2003 14:20:34 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h9FIKRL11669; Wed, 15 Oct 2003 14:20:27 -0400 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h9FIKRJ29374; Wed, 15 Oct 2003 11:20:27 -0700 Message-ID: <3F8D8FEB.8020305@redhat.com> Date: Wed, 15 Oct 2003 18:20:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Cagney CC: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: RFA: Breakpoint infrastructure cleanups [0/8] References: <20031008165534.GA8718@nevyn.them.org> <20031008190502.GA13579@nevyn.them.org> <3F846B04.2070801@redhat.com> <3F85B4AC.7000000@redhat.com> <20031014013831.GB6118@nevyn.them.org> <3F8C18DD.3020508@redhat.com> <20031014155126.GA10669@nevyn.them.org> <3F8C605E.1060604@redhat.com> <3F8D6181.6070409@redhat.com> In-Reply-To: <3F8D6181.6070409@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00495.txt.bz2 Andrew Cagney wrote: > >> If this is just an internals issue, then toss a coin, it >> doesn't matter. But for the picture that we present to the >> user, remember -- we always present a fictional picture that >> hides most of the underlying details. The unsophisticated >> user thinks he is debugging his code -- not the underlying >> machine. If possible, he doesn't want to know eg. that >> line seventeen has been broken into several locations and >> intermixed with code from 3 other lines. We're sometimes >> forced to tell him anyway, but we don't if we can avoid it. > > > Yes, it is user visible (which is why people are also looking for a > user-level command, different to "maint info break" and "info break", > that displays both the logical and physical breakpoint). Yep. Didn't mean to imply that it wasn't user visible. > With a GUI, I can see each logical breakpoint having an expand widget > (correct technical term is?) that lets the user see (modify?) the > underlying physical breakpoint list. Yep, pretty much what I had in mind. For the cli interface I would hope for something similar -- something that initially displayed only the "high level" breakpoints, but maybe with an asterisk or something to indicate that there was more to the picture if one wanted to know. And some syntax equivalent to clicking on the GUI expand widget, which could be a variation on an existing command, or a new command (I have no preference). > This is needed, as otherwize something apparently simple "break strcmp" > could result in the user unknowingly setting 1000's of breakpoints. That's true as it is -- I guess what we have now is that pop-up menu that says "Which one of these did you mean?" I presume that when that interface was implemented, we did not expect it to come up all that often. Now, with overloaded functions, templates, weird constructors and so forth, we anticipate that it will come up more often, so we need a less intrusive interface.