Re: MI: type prefixes for values

[Vladimir Prus <ghost@cs.msu.su>]

On Wednesday 12 April 2006 20:55, Jim Ingham wrote:
> 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/"}]
> >

> > 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.

You mean, you don't get full stack trace on each step, but only when current 
frame_id changes? Pretty smart!

> 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.

Well, handling frames on frontend side seems clearer to me too.

- Volodya