From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15935 invoked by alias); 13 Apr 2006 14:18:49 -0000 Received: (qmail 15925 invoked by uid 22791); 13 Apr 2006 14:18:48 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Apr 2006 14:18:46 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1FU2ef-0001MH-Jq for gdb@sources.redhat.com; Thu, 13 Apr 2006 18:18:42 +0400 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1FU2eR-0001Jm-Qn; Thu, 13 Apr 2006 18:18:27 +0400 From: Vladimir Prus To: Jim Ingham Subject: Re: MI: type prefixes for values Date: Thu, 13 Apr 2006 16:15:00 -0000 User-Agent: KMail/1.7.2 Cc: GDB List References: <200602171724.03824.ghost@cs.msu.su> <200604121537.40398.ghost@cs.msu.su> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604131818.27336.ghost@cs.msu.su> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00158.txt.bz2 On Wednesday 12 April 2006 20:55, Jim Ingham wrote: > On Apr 12, 2006, at 4:37 AM, Vladimir Prus wrote: > > On Friday 07 April 2006 21:37, Jim Ingham wrote: > >> Yes, it looks like we added that. Our -stack-list-frames looks like: > >> > >> 553^done,stack=[frame= > >> {level="0",addr="0x00003db0",fp="0xbffff2c0",func="main",file="/ > >> private/nfsroot/Users/jingham/Projects/ManyThreads/ > >> main.m",fullname="/ > >> private/nfsroot/Users/jingham/Projects/ManyThreads/ > >> main.m",line="64",dir="/private/nfsroot/Users/jingham/Projects/ > >> ManyThreads/"}] > > > > So, why did you decide to handle varobj lifetime in XCode, and not > > in gdb? > > Xcode already has to manage the coming & going of frames. After all, > it would be inefficient if you had to flush & remake Xcode's > representation of the stack every time you stepped. It's actually > pretty important to do as little as possible on each step, this is > one of the performance-critical areas of a GUI debugger. N.B. you > don't have to worry about this in gdb, because the stack is only > presented on demand, but in a UI it's always visible so you HAVE to > refresh it every time you stop. So having Xcode handle the frame- > tied varobj's lifetimes seemed more natural. You mean, you don't get full stack trace on each step, but only when current frame_id changes? Pretty smart! > Also, I think it's a clearer architecture for the UI to own the > things it creates in gdb, and only have them go away when it tells > them to. After all, the UI is going to have to handle the lifetimes > of its side of the variable object. So it's more natural for it to > handle the gdb side as well. That reduces the chance for surprise. > The object can and should be able to say it's gone out of scope, in > case the UI gets confused for some reason. But it shouldn't go away. Well, handling frames on frontend side seems clearer to me too. - Volodya