This is the mail archive of the gdb@sourceware.org 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] |
On Thu, Apr 06, 2006 at 06:31:24PM +0400, Vladimir Prus wrote:There's no indication that 'TMP' varobj belongs to the stack frame we've
already left. This is with vanilla 6.4.
Interesting, the check isn't on this path. I wonder if we really need
both different ways to get at the value of a variable. varobj_update
uses value_of_root, but -var-evaluate-expression uses
value_of_variable. I bet we have some redundant code here. Maybe not,
value_of_variable is only used for strings, the others work on struct
value.
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.
Yes, this is indeed what I'm after. However, now there's reverse problem. Say
I create variable object for variable 'i'. Then during stepping I enter
function that also has variable 'i'. I need to detect, somehow, that 'i'
varobj created earlier relates to the parent stack frame, not the current,
and that I have to create new variable object.
How do I do that? Using -var-update does not seem to produce this information?
Am I supposed to manually keep track of frame-id where variable object was
created? And if so, how do I get frame-id?
I don't know. Maybe Jim will comment.
-- Daniel Jacobowitz CodeSourcery
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |