This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: variable objects and registers
> 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