From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2457 invoked by alias); 17 Nov 2003 21:12:04 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2439 invoked from network); 17 Nov 2003 21:12:03 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sources.redhat.com with SMTP; 17 Nov 2003 21:12:03 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id hAHLC3nc005110 for ; Mon, 17 Nov 2003 13:12:03 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 17 Nov 2003 13:11:29 -0800 Received: from [17.201.22.21] (moleja.apple.com [17.201.22.21]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id hAHLBgEV006032; Mon, 17 Nov 2003 13:11:43 -0800 (PST) In-Reply-To: <200311172039.PAA17856@smtp.ott.qnx.com> References: <200311172039.PAA17856@smtp.ott.qnx.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <97CC3FB5-1942-11D8-812A-000393D457E2@apple.com> Content-Transfer-Encoding: 7bit Cc: nick@nick.uklinux.net (Nick Roberts), gdb@sources.redhat.com From: Jason Molenda Subject: Re: MI command -stack-list-locals Date: Mon, 17 Nov 2003 21:12:00 -0000 To: Alain Magloire X-SW-Source: 2003-11/txt/msg00134.txt.bz2 On Nov 14, 2003, at 3:10 PM, Nick Roberts wrote: >> >> >>> We've added a "2" version of -stack-list-locals which prints out a >>> lot >>> more information, as well as automatically creates varobj's for all >>> of >>> the local variables. >> >> Do these variable objects get deleted and replaced with a new set >> every >> time the current frame changes? Does that not slow down the user >> interface? > > For us, it will be slow. Yeah, for a native system we can get at the inferior's memory space quickly and easily. The timing overhead to create a whole mess of varobj's is amazingly small - must be the incredible power of the G5 processor or something. :-) :-) No, seriously though, every time we've done profiling this stuff is pure noise. I just tried debugging a smallish ObjC program; the entire series of MI commands to get the arguments and locals for a function with two arguments and no locals took 0.01 seconds wallclock. For a function with 11 locals/arguments, it took 0.02 seconds wallclock. You figure that after a stop you want to get give the user control in, say, 0.2-0.3 seconds to get a reasonable feel (I'm just throwing out numbers). Given that budget of time, 0.01-0.02 seconds for varobj's is not important. On Nov 14, 2003, at 3:10 PM, Nick Roberts wrote: > I suspect that I could use this approach for Emacs and I certainly > don't want to try do things that others have already done. At some > stage, will Apple put these changes into the RedHat CVS repository for > FSF gdb? Apple has a copyright assignment to the FSF on file for all our gdb work--there should be no issues with using our changes, and we're happy to share. Our source base is (ahem) a bit diverged from the FSF sources and we haven't completed a merge since January to boot, so contributing much back to the FSF in the short term is not likely to happen. It's something all of us, up through our managers, wants to happen, but I honestly don't expect a lot of time to be spent on that in the immediate future. On Nov 17, 2003, at 12:39 PM, Alain Magloire wrote: > The Eclipse/CDT/MI use the fact that -stack-list-locals is not > creating > varobj(lightweight) to allow users to pick and choose which variable > to monitor. > This can be an issue when debugging a board, where you want to be less > intrusive > or when having a very high number of variables in a stackframe. Yeah, for an embedded environment you'll have a different set of tradeoffs you're working with. We've been shipping a UI that works on top of MI for a few years now, and we've hit (and solved) a number of problems along the way. I expect that other people implementing a debugger UI via MI will encounter many of the same issues and it'd be nice if we can share the experiences and solutions we came up with here at Apple... Jason