From: Jim Ingham <jingham@apple.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: Vladimir Prus <ghost@cs.msu.su>, GDB List <gdb@sources.redhat.com>
Subject: Re: MI: type prefixes for values
Date: Thu, 06 Apr 2006 18:53:00 -0000 [thread overview]
Message-ID: <FD25C630-173E-494B-A953-49F344A866EF@apple.com> (raw)
In-Reply-To: <20060406144131.GA26938@nevyn.them.org>
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
>>>> 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.
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
>> 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.
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.
Jim
>
> --
> Daniel Jacobowitz
> CodeSourcery
next prev parent reply other threads:[~2006-04-06 16:49 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-17 9:09 Vladimir Prus
2006-02-17 10:22 ` Eli Zaretskii
2006-02-17 10:29 ` Vladimir Prus
2006-02-17 11:26 ` Eli Zaretskii
[not found] ` <200602171450.16858.ghost@cs.msu.su>
2006-02-17 13:49 ` Eli Zaretskii
2006-02-17 13:54 ` Daniel Jacobowitz
2006-02-17 14:08 ` Eli Zaretskii
2006-02-17 13:58 ` Vladimir Prus
2006-02-17 14:11 ` Eli Zaretskii
2006-02-17 14:26 ` Vladimir Prus
2006-02-17 14:36 ` Bob Rossi
2006-02-17 14:43 ` Vladimir Prus
2006-02-17 14:51 ` Bob Rossi
2006-02-17 15:02 ` Vladimir Prus
2006-02-17 19:25 ` Eli Zaretskii
2006-02-17 19:33 ` Daniel Jacobowitz
2006-02-17 19:36 ` Eli Zaretskii
2006-02-17 19:38 ` Daniel Jacobowitz
2006-02-17 19:56 ` Eli Zaretskii
2006-02-17 20:05 ` Bob Rossi
2006-02-17 20:07 ` Eli Zaretskii
2006-02-17 20:17 ` Daniel Jacobowitz
2006-02-17 20:28 ` Eli Zaretskii
2006-02-17 20:33 ` Daniel Jacobowitz
2006-02-17 21:14 ` Jim Ingham
2006-02-18 11:34 ` Eli Zaretskii
2006-02-20 13:47 ` Vladimir Prus
2006-02-20 8:11 ` Vladimir Prus
2006-02-20 19:49 ` Jim Ingham
2006-02-20 20:56 ` Daniel Jacobowitz
2006-02-20 20:57 ` Jim Ingham
2006-02-21 14:15 ` Vladimir Prus
2006-02-21 21:33 ` Jim Ingham
2006-04-06 13:33 ` Vladimir Prus
2006-04-06 13:45 ` Daniel Jacobowitz
2006-04-06 14:05 ` Vladimir Prus
2006-04-06 14:31 ` Daniel Jacobowitz
2006-04-06 15:05 ` Vladimir Prus
2006-04-06 15:32 ` Daniel Jacobowitz
2006-04-06 18:53 ` Jim Ingham [this message]
2006-04-06 16:49 ` Jim Ingham
2006-04-06 16:49 ` Daniel Jacobowitz
2006-04-06 16:52 ` Jim Ingham
2006-04-06 18:58 ` Jim Ingham
2006-04-07 8:13 ` Vladimir Prus
2006-04-07 20:08 ` Jim Ingham
2006-04-12 15:38 ` Vladimir Prus
2006-04-12 19:41 ` Jim Ingham
2006-04-13 16:15 ` Vladimir Prus
2006-02-17 21:19 ` Daniel Jacobowitz
2006-02-17 20:20 ` Bob Rossi
2006-02-17 20:47 ` Daniel Jacobowitz
2006-02-17 19:44 ` Bob Rossi
2006-02-17 19:59 ` Eli Zaretskii
2006-02-20 7:28 ` Vladimir Prus
2006-02-20 23:37 ` Eli Zaretskii
2006-02-21 4:13 ` Daniel Jacobowitz
2006-02-21 14:15 ` Vladimir Prus
2006-02-21 20:41 ` Daniel Jacobowitz
2006-02-20 13:48 ` Vladimir Prus
2006-02-17 11:27 ` Nick Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=FD25C630-173E-494B-A953-49F344A866EF@apple.com \
--to=jingham@apple.com \
--cc=drow@false.org \
--cc=gdb@sources.redhat.com \
--cc=ghost@cs.msu.su \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox