From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9712 invoked by alias); 21 Dec 2006 23:30:10 -0000 Received: (qmail 9701 invoked by uid 22791); 21 Dec 2006 23:30:09 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 21 Dec 2006 23:30:03 +0000 Received: from kahikatea.snap.net.nz (p202-124-120-96.snap.net.nz [202.124.120.96]) by viper.snap.net.nz (Postfix) with ESMTP id 0564F2F4120; Fri, 22 Dec 2006 12:31:36 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id B5998BE457; Fri, 22 Dec 2006 12:25:26 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17803.6117.15940.138752@kahikatea.snap.net.nz> Date: Thu, 21 Dec 2006 23:30:00 -0000 To: Jim Ingham Cc: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: variable objects and registers In-Reply-To: <0E190425-7C4F-4C6E-B8B3-9A3FA79F6FE3@apple.com> References: <17782.41205.881283.845357@kahikatea.snap.net.nz> <17801.40268.835284.224413@kahikatea.snap.net.nz> <200612210942.54734.ghost@cs.msu.su> <17802.17932.377094.90049@kahikatea.snap.net.nz> <0E190425-7C4F-4C6E-B8B3-9A3FA79F6FE3@apple.com> X-Mailer: VM 7.19 under Emacs 22.0.92.1 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00297.txt.bz2 > you get something like: > > -stack-list-locals 2 1 > ^done,locals=[varobj= > {exp="foo",value="0",name="var1",numchild="0",type="int",typecode="INT", > dynamic_type="",in_scope="true",block_start_addr="0x00002c90",block_end_ > addr="0x00002d10"},varobj= > {exp="bar",value="0",name="var2",numchild="0",type="int",typecode="INT", > dynamic_type="",in_scope="false",block_start_addr="0x00002cc4",block_end > _addr="0x00002cdc"},varobj= > {exp="bar",value="-1881116284",name="var3",numchild="0",type="int",typec > ode="INT",dynamic_type="",in_scope="false",block_start_addr="0x00002cdc" > ,block_end_addr="0x00002cf4"}] Yes this looks exactly like what we want. > It would be pretty easy to add a line number for the block start & > end if you wanted to show that. We also fixed the code that reports > in & out of scope pretty much along the lines that Vlad suggested a > while back so you would get correct reports. -var-update reports > coming in & out of scope, but we didn't change it to report "new > variables" that arise when you step into a deeper scope. That's not > necessary if you report all the blocks up-front. > > Xcode fetches and displays ALL the locals, and then just annotates > the ones that are out of scope. But you could also imagine the UI > fetching all the locals but suppressing the ones that are not in > scope, and then displaying them when it gets the "in scope" message > from -var-update. We didn't do it this way because I find having the > list of variables changing while stepping through code to be > distracting. > > We also didn't so a special update for locals, since Xcode keeps > track of which variable objects are the locals in each frame, and > updates them in batches as needed. That coupled with the ALL_BLOCKS > setting obviates the need for a special locals listing. We (Vlad and I) could try to port this back into FSF but it would be a lot easier (I think) for you to do it. It seems to me that you had a good working relationship with Andrew Cagney (perhaps from Cygnus days) and that Apple contributed more actively to MI then. I'm probably speaking out of order, and maybe opening a can of worms, but I wonder if Apple could be encouraged to contribute more actively once again if in return, say, the Apple GDB code was given a branch on the FSF repository (see http://sourceware.org/ml/gdb/2005-03/msg00197.html). This would make it easier to port changes from FSF to Apple but also Apple to FSF. > Another kind of useful addition along the same lines, we extended the > "FRAME" argument to -var-create so you can say: > > -var-create - +main.c:6 bar > > to create the variable object for bar in the scope surrounding line > 6. This is necessary if you want to do variable values in tooltips > using variable objects. Yes, I see Insight uses variable objects for tooltips too. What advantage do they have over just using "print"? > For the most part, though we are a bit spotty about updating the texi > docs for our MI changes, we do update the command descriptions in the > mi_cmd_* source documentation (though I note there isn't much in the > mi-cmd-var.c file.) AFAICS the texi docs (gdb.texinfo) in my copy of Apple GDB (6.3.50.20050815-cvs) are the same as in FSF. > If you can get your hands on a Mac OS X box for a little while, there > is a way to dump the MI commands Xcode sends to gdb, and the gdb > responses to a log file. That's probably the quickest way to see > what stuff we've added and how we use MI, if you are interested. Its unlikely in the near future, but I've got OpenDarwin 7.2.1. > Sorry for not being active on this thread, but I've been swamped on > other things, and haven't been thinking about the MI for a while now... What about the changes that we've been making recently e.g http://sourceware.org/ml/gdb-patches/2006-12/msg00127.html Do they fix things for Apple too? -- Nick http://www.inet.net.nz/~nickrob