This is the mail archive of the
mailing list for the GDB project.
Re: MI: type prefixes for values
On Apr 6, 2006, at 7:41 AM, Daniel Jacobowitz wrote:
On Thu, Apr 06, 2006 at 06:31:24PM +0400, Vladimir Prus wrote:
There's no indication that 'TMP' varobj belongs to the stack
already left. This is with vanilla 6.4.
Interesting, the check isn't on this path. I wonder if we really
both different ways to get at the value of a variable.
uses value_of_root, but -var-evaluate-expression uses
value_of_variable. I bet we have some redundant code here.
value_of_variable is only used for strings, the others work on
I don't quite understand if you're saying that the current
behaviour is a bug,
or not. Can you clarify?
I don't know. It's an interface.
Maybe it is an error for you to try to evaluate something after
-var-update says it has gone out of scope.
Maybe -var-evaluate-expression should report not in scope.
Someone with more MI experience would have to decide.
I don't know why it was originally done this way. But in practice it
doesn't much matter. The separation between "update" and "evaluate"
is useful, since "what's changed" and "give me a value" are questions
you want to ask separately. Since the UI generally knows what it
wants to fetch, having -var-evaluate-expression error if the varobj
was out of scope hasn't been a big deal in practice.
Yes, this is indeed what I'm after. However, now there's reverse
I create variable object for variable 'i'. Then during stepping I
function that also has variable 'i'. I need to detect, somehow,
varobj created earlier relates to the parent stack frame, not the
and that I have to create new variable object.
How do I do that? Using -var-update does not seem to produce this
Am I supposed to manually keep track of frame-id where variable
created? And if so, how do I get frame-id?
I don't know. Maybe Jim will comment.
One of the changes that I made early on when we started using the MI
seriously for Xcode was to add an option to -stack-list-locals and -
stack-list-args to make varobj's for all the locals/args. We always
use these commands to get the varobj's that correspond to the stack
frame. Then it is a simple matter in the UI to tie these variable
objects to their frames, and update, evaluate, whatever, them as
appropriate for the frame the user is currently looking at.
I think it's a lot easier doing it this way than having an option in
the MI to report the varobj's frame, and then having to check that
against the stack each time.
The other bit involved here is that Xcode does keep track of the last
stack and compares it against the current stack every time you stop.
That way it knows which frames it does or doesn't have to create new
variable objects for.