This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI: type prefixes for values
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