Re: MI: type prefixes for values

[Jim Ingham <jingham@apple.com>]

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