This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI: type prefixes for values
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/"}]
Hi Jim,
I've now got one last questions. Why do you do this managements of
variable
objects in XCode, and not on gdb side, using -var-update?
If I understand correctly, each time program stops, we need to know
for each
variable object if:
- it's still alive (containing frame has not exited)
- changed the value
- is in different frame from the current (when we enter the
function)
- if the expression variable object was created with refers to
different variables now (say, if you created varobj for global
'i',
now just entered a block containing local 'i').
In mainline, -var-update handles the first two points already. It's
possible
to support third point easily. I'm not sure about the fourth.
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.
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.
Jim