From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22899 invoked by alias); 15 Oct 2003 18:56:23 -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 22881 invoked from network); 15 Oct 2003 18:56:23 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 15 Oct 2003 18:56:23 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h9FIuMM18780 for ; Wed, 15 Oct 2003 14:56:22 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h9FIuMr24907; Wed, 15 Oct 2003 14:56:22 -0400 Received: from localhost.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h9FIuLwC013864; Wed, 15 Oct 2003 14:56:22 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 7EC6B2C43E; Wed, 15 Oct 2003 15:07:42 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16269.39677.813094.890124@localhost.redhat.com> Date: Wed, 15 Oct 2003 18:56:00 -0000 To: Michael Snyder Cc: Andrew Cagney , Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: RFA: Breakpoint infrastructure cleanups [0/8] In-Reply-To: <3F8D8FEB.8020305@redhat.com> 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> <3F8D8FEB.8020305@redhat.com> X-SW-Source: 2003-10/txt/msg00497.txt.bz2 Michael Snyder writes: > 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. > > > The CLI needs to provide information in at least 3 cases, that I can think of. 1. insert the breakpoint, show confirmation to the user. If we have 20 'real' breakpoints inserted, what do we tell the user? 2. hit the breakpoint, show line info about where we stopped, and breakpoint number. Do we just say the program hit the high level breakpoint number, or also which low level breakpoint number? Hmm, do low level breakpoints have numbers? (I can see that we kind of need a pair of numbers now). 3. list the breakpoints (info break) Ok, this we kind of discussed. And MI? what should we do there? the same 3 cases occur. I would think that MI could just tell the gui everything every time, and then the GUI could decide to display what it wants. However that's a lot of information sent back and forth, maybe for no real advantage. So maybe a two-tier command set is needed there too. Depending on which 'view' the gui is in (I can imagine a gui having 2 views, one which shows all the hidden bps, and one that shows only the high level ones), or in general depending on what it wants to display it would send different commands to gdb/MI. elena