From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30841 invoked by alias); 16 Oct 2003 18:58:46 -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 30807 invoked from network); 16 Oct 2003 18:58:45 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sources.redhat.com with SMTP; 16 Oct 2003 18:58:45 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id h9GIwhk0002369 for ; Thu, 16 Oct 2003 11:58:43 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 16 Oct 2003 11:58:12 -0700 Received: from [17.201.22.245] (inghji6.apple.com [17.201.22.245]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h9GIwRWI005785 for ; Thu, 16 Oct 2003 11:58:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <1066321046.18949.ezmlm@sources.redhat.com> References: <1066321046.18949.ezmlm@sources.redhat.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: RFA: Breakpoint infrastructure cleanups [0/8] Date: Thu, 16 Oct 2003 18:58:00 -0000 To: gdb-patches@sources.redhat.com X-SW-Source: 2003-10/txt/msg00557.txt.bz2 On Oct 16, 2003, at 9:17 AM, gdb-patches-digest-help@sources.redhat.com wrote: >>>> 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. > > I think in all cases the UI will want to know about the multiple hits. One case that would be very useful is a single breakpoint that turns into many logically distinct entities. For instance, breaking on a file & line in a template function or class method turns into breakpoints on all the instantiations of that template function/method. In this case the GUI really would be interested in this, since it would be useful to display these choices to the user and have her pick which ones she actually wants. The other is where the multiple breakpoints are not really distinct. An example of this is breaking on an inlined function. Without expanding inlined calls in the source view of the call sites, knowing where all the breakpoints are in source view is not terribly helpful. But if somebody switches to Assembly view, we had better show them the breakpoints that have been set or they will get very confused... So I think we do need them. Our experience with MI is that as long as the information dump is not too large, multiple round trips are more expensive than lots of info. Parsing the MI output is pretty quick. I bet if we start getting ~1000's of breakpoints the time gdb spends finding all the instances will swamp the time it takes to ship them across the pipe... So my guess is that doing it simply and just telling the user about all the breakpoints as they are set is okay. The one thing we do need to be careful about is to not reset all the breakpoints in all the shared libraries each time a new one is loaded. This is the current gdb behavior, but it will quickly get very inefficient as the number of shared libraries & breakpoints therein increase. It is pretty easy to get around this with a little judicial hacking, however. Jim -- Jim Ingham jingham@apple.com Developer Tools Apple Computer