From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14918 invoked by alias); 16 Oct 2003 14:21:37 -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 14902 invoked from network); 16 Oct 2003 14:21:36 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 16 Oct 2003 14:21:36 -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 h9GELZM10230 for ; Thu, 16 Oct 2003 10:21:35 -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 h9GELZr14770 for ; Thu, 16 Oct 2003 10:21:35 -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 h9GELZwC020102 for ; Thu, 16 Oct 2003 10:21:35 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id C85362CD41; Thu, 16 Oct 2003 10:32:58 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16270.44057.973638.26816@localhost.redhat.com> Date: Thu, 16 Oct 2003 14:21:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: Breakpoint infrastructure cleanups [0/8] In-Reply-To: <20031016131144.GA14202@nevyn.them.org> References: <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> <16269.39677.813094.890124@localhost.redhat.com> <2719-Thu16Oct2003085405+0200-eliz@elta.co.il> <20031016131144.GA14202@nevyn.them.org> X-SW-Source: 2003-10/txt/msg00540.txt.bz2 Daniel Jacobowitz writes: > On Thu, Oct 16, 2003 at 08:54:05AM +0200, Eli Zaretskii wrote: > > > From: Elena Zannoni > > > Date: Wed, 15 Oct 2003 15:07:41 -0400 > > > > > > 1. insert the breakpoint, show confirmation to the user. If we have 20 > > > 'real' breakpoints inserted, what do we tell the user? > > > > If we can guess the one address which is what the user wants to see in > > the current context, let's show that single address. Otherwise, let's > > either show all of them or none at all, perhaps controlled by some > > user option. > > Seems reasonable. > sounds ok to me. Just occurred to me that maybe the user sometimes would want to set a breakpoint in just one particular instance of an inlined function, we should still allow that. I.e. should setting the multiple breakpoints be the default? > > > 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? > > > > I'd say we show the high-level number and the precise machine address > > where it breaks. > > Right now we show the breakpoint address for breakpoints which are not > at the beginning of a source line, and just the breakpoint and line > numbers for breakpoints which are at the beginning of a line. How > would this interact with that? Show the address always, or for > breakpoints which either are in the middle of a line or in multiple > locations? > Maybe we should show 'Breakpoint 5.3' and then use the same rule we have now to decide whether to show the line or the address. This way the user knows which high level bp was hit. How a gui is going to represent that, it's beyond me. > > > Hmm, do low level breakpoints have numbers? > > > > I don't think we need numbers for them, so let's not have them. > > I actually think that we do need numbers for them. > > My hypothetical use case is something like this: > (gdb) break inline_foo > Breakpoint 5 set at inline_foo, which has multiple locations. > Say "info breakpoint 5" for more details. > (gdb) info break 5 > Num Type Enb Address What > 1 sw breakpoint y 0x8040222 inlined into foo > 2 sw breakpoint y 0x8040822 inlined into bar > 3 sw breakpoint y 0x8040852 inlined into boring_loop > (gdb) disable 5.3 > (gdb) run > Yes, I was thinking something like that too. Even though, there should probably be a 5 somewhere in the output of info break. > I am not sure about "delete 5.3", though - that makes tracking which > breakpoints have been set a little trickier, for not much gain. > Maybe delete could be implemented internally as mark the child breakpoint as deleted, instead of removing it from the list. Similar to disabling it but the user will not be able to access it ever again. > > > 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. > > > > Probably. > > > > > 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. > > > > Yes, probably. > > These make sense to me also. > I'd like to hear from MI users otherwise we'll be designing in a vacuum. I'll send something to the eclipse folks. elena > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer