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


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