This is the mail archive of the
mailing list for the GDB project.
Re: -var-update and address changes
On Apr 14, 2006, at 12:53 PM, Daniel Jacobowitz wrote:
On Fri, Apr 14, 2006 at 12:49:05PM -0700, Jim Ingham wrote:
Note as an aside, that we had to add another varobj type which is
evaluated in the selected frame, whatever that happens to be. That
was useful for a general "variable inspector" window. People wanted
to put some expression there, and have it re-evaluated in the topmost
frame whenever they stopped. So we added that functionality. But
that is clearly distinct from what the "*" varobj type is supposed to
Well, I interpreted it the other way around, so I'll dispute your
Yeah, every time I have to fix this code, I have to figure out the
difference between "current frame" and "selected frame". Once I've
thought about it a bit, I'm convinced that it's clear. But then I
forget it almost immediately...
The fp part is just used as part of the frame fingerprint. The pc is
used for other purposes of course (for instance if the disassembly
window is open), but the fp part is just used to check whether the
frame needs to be refreshed. I have no problem with it being opaque.
It's the PC of the frame, not the current PC; I'm not sure why you'd
want to use it. In any case, you can always fetch it for the frame,
or report it separately. So, let's plan on using frame IDs in MI,
and defining them opaquely. I'd even go so far as to make them
rather than numbers.
If you have a disassembly view showing, and you are clicking around
on the stack, Xcode fetches enough code to fill the disassembly
window around the pc of the frame you've selected on the stack.
Having the pc returned with the stack frame eliminates one round
trip. People tend to nervously click around on the stack for no
apparent reason while they are thinking about the problem they are
working on. So this needs to be somewhat quick, though this one
round trip is probably negligible. OTOH the fewer things you have to
do by "send a request, wait for the reply, do the next request" the
easier it is to program on the client side. I wouldn't lean too hard
on this one way or another.