From: Mo DeJong <supermo@bayarea.net>
To: gdb@sources.redhat.com
Subject: Re: Problem with MI -var-evaluate-expression command
Date: Thu, 11 Jul 2002 12:13:00 -0000 [thread overview]
Message-ID: <20020711121839.275ae39f.supermo@bayarea.net> (raw)
In-Reply-To: <Pine.GSO.4.33.0207101722060.12727-100000@makita.cygnus.com>
On Wed, 10 Jul 2002 17:31:11 -0700 (PDT)
Keith Seitz <keiths@redhat.com> wrote:
> How is a UI to know what the children of svar are? You do, because you're
> a human, but a UI reacting programmatically could not automatically know
> that svar has a child named "v1" _until_ it asks svar for its children
> (thus creating the varobjs).
...
> Now, when the user hits the "+", Insight will ask the varobj for its
> children. It gets back a list of varobjs. It then repeats steps 2-5 for
> each of these new varobjs.
It sounds like that works just fine for a watch window where each
child will be displayed. I just wonder if that is the only valid use case.
I am looking at building a scripting interface to the gdb/mi, so I don't need
watch window semantics just now.
My reading of the docs seems to indicate that the variable objects
interface is an improvement over just evaluating plain expressions
since the same "syntax" would be used to access C, C++, or Java
objects with children. I also liked the fact that you could set the
format of the returned value and then pass the whole "var object"
around from one function to another. That said, this -var-evaluate-expression
children thing has got me thinking that I should just stick with
-data-evaluate-expression and skip the -var-* methods. Here is why.
One can evaluate an expression like so quite easily:
-data-evaluate-expression "objPtr->member1->dataPtr->bytes"
But to do this same thing with a variable object I would need to
send these commands.
-var-create objPtr * "objPtr"
-var-list-children objPtr
-var-list-children objPtr.member1
-var-list-children objPtr.member1.dataPtr
-var-evaluate-expression objPtr.member1.dataPtr.bytes
Now, I could keep my own record of the variables that "know" what
their children are and check this record every time a variable is
accessed from my API. But, that just strikes me as really ugly and
it seems to waste a lot of bandwidth. I don't have a problem with
leaving support for the -var-* methods out of my wrapper
because of this issue, I just thought I would bring it up.
In any event, the docs for the -var-evaluate-expression should be
updated to explicitly state that the user needs to call -var-list-children
for a variable object before accessing any children.
Mo
next prev parent reply other threads:[~2002-07-11 19:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-10 17:15 Mo DeJong
2002-07-10 17:31 ` Keith Seitz
2002-07-11 12:13 ` Mo DeJong [this message]
2002-07-11 12:43 ` Keith Seitz
[not found] <1026487389.32493.ezmlm@sources.redhat.com>
2002-07-12 11:30 ` Jim Ingham
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=20020711121839.275ae39f.supermo@bayarea.net \
--to=supermo@bayarea.net \
--cc=gdb@sources.redhat.com \
/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