This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:

private/nfsroot/Users/jingham/Projects/ManyThreads/ main.m",fullname="/

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]