Re: variable objects and registers

[Nick Roberts <nickrob@snap.net.nz>]

 > 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