Re: -var-update and address changes

[Jim Ingham <jingham at apple dot com>]

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
> > mean.
>
> Well, I interpreted it the other way around, so I'll dispute your
> "clearly" :-)

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

Jim