From: Nick Roberts <nickrob@snap.net.nz>
To: Denis PILAT <denis.pilat@st.com>
Cc: gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [RFC] varobj deletion after the binary has changed
Date: Mon, 29 Jan 2007 22:12:00 -0000 [thread overview]
Message-ID: <17854.28971.170898.231523@kahikatea.snap.net.nz> (raw)
In-Reply-To: <45BDEAEC.1050006@st.com>
> Attached is a new implementation, it takes care of more cases where seg
> fault occured.
>
> I take Nick's suggestion into account, -var-update outputs the following
> for invalid variables:
> changelist=[{name="linteger",in_scope="invalid"}]
>
> About this last change, I'm wondering if frond-ends that expect "true"
> or "false" will handle this new outputs correctly, it's just a question
> of backward compatibility. Of course it will be better that the old
> behavior that crashes gdb !
The documentation doesn't say that "true" and "false" are exhaustive
possibilities but it may be reasonable to expect that they are. It's only
needed when the inferior is rebuilt with extant variable objects. I've never
found a problem in my use, although it clearly depends on pattern of use.
In any case, as you say, if we make no change gdb will just crash.
If Daniel approves the patch, I will submit some documentation as we are
considering other values for in_scope such as "exited". That way frontend
developers can factor in the possobility of further values.
> If you're fine I'll write appropriate ChangeLogs.
>
> I also wrote a new .exp file in gdb.mi testsuite, I'll propose it on
> this one approval.
Looks good. Maybe varobj_update could use an enum:
enum varobj_update_values
{
SCOPE_FALSE = -1,
TYPE_CHANGED,
SCOPE_INVALID
}
>...
> Index: mi/mi-cmd-var.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/mi/mi-cmd-var.c,v
> retrieving revision 1.28
> diff -u -p -r1.28 mi-cmd-var.c
> --- mi/mi-cmd-var.c 9 Jan 2007 17:59:08 -0000 1.28
> +++ mi/mi-cmd-var.c 29 Jan 2007 12:09:58 -0000
> @@ -555,12 +555,12 @@ varobj_update_one (struct varobj *var, e
>
> if (nc == 0)
> return 1;
> - else if (nc == -1)
> + else if (nc == -1 || nc == -3)
> {
> if (mi_version (uiout) > 1)
> cleanup = make_cleanup_ui_out_tuple_begin_end (uiout, NULL);
> ui_out_field_string (uiout, "name", varobj_get_objname(var));
> - ui_out_field_string (uiout, "in_scope", "false");
> + ui_out_field_string (uiout, "in_scope", (nc == -3 ? "invalid" : "false"));
> if (mi_version (uiout) > 1)
> do_cleanups (cleanup);
> return -1;
Including the case nc == -2, maybe this reads more easily (just thinking out
aloud):
else if (nc < 0)
{
if (mi_version (uiout) > 1)
cleanup = make_cleanup_ui_out_tuple_begin_end (uiout, NULL);
ui_out_field_string (uiout, "name", varobj_get_objname(var));
switch (nc)
{
case (SCOPE_FALSE)
ui_out_field_string (uiout, "in_scope", "false");
break;
case (TYPE_CHANGED)
ui_out_field_string (uiout, "in_scope", "true");
ui_out_field_string (uiout, "new_type", varobj_get_type(var));
ui_out_field_int (uiout, "new_num_children",
varobj_get_num_children(var));
break;
case (SCOPE_invalid)
ui_out_field_string (uiout, "in_scope", "invalid");
break;
}
if (mi_version (uiout) > 1)
do_cleanups (cleanup);
}
(It looks like we could remove the return value of varobj_update_one as it
doesn't seem to be used.)
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2007-01-29 22:12 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-23 12:32 Denis PILAT
2007-01-23 12:45 ` Daniel Jacobowitz
2007-01-23 12:52 ` Vladimir Prus
2007-01-23 14:49 ` Denis PILAT
2007-01-24 21:49 ` Nick Roberts
2007-01-24 22:07 ` Daniel Jacobowitz
2007-01-24 22:08 ` Frédéric Riss
2007-01-24 22:18 ` Nick Roberts
2007-01-24 22:52 ` Frédéric Riss
2007-01-24 23:14 ` Nick Roberts
2007-01-25 2:41 ` Daniel Jacobowitz
2007-01-25 20:50 ` Nick Roberts
2007-01-26 7:25 ` Denis PILAT
2007-01-23 17:20 ` Denis PILAT
2007-01-25 17:28 ` Denis PILAT
2007-01-25 22:31 ` Nick Roberts
2007-01-25 23:27 ` Daniel Jacobowitz
2007-01-29 12:39 ` Denis PILAT
2007-01-29 22:12 ` Nick Roberts [this message]
2007-01-30 8:49 ` Denis PILAT
2007-01-31 19:07 ` Denis PILAT
2007-01-31 21:29 ` Nick Roberts
2007-02-01 9:49 ` Denis PILAT
2007-02-08 16:41 ` Daniel Jacobowitz
2007-02-08 19:33 ` Nick Roberts
2007-02-08 19:55 ` Daniel Jacobowitz
2007-02-09 15:43 ` Eli Zaretskii
2007-02-12 21:10 ` Denis PILAT
2007-02-13 0:11 ` Nick Roberts
2007-02-13 8:26 ` Denis PILAT
2007-02-20 16:06 ` Andreas Schwab
2007-02-20 16:17 ` Denis PILAT
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=17854.28971.170898.231523@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=denis.pilat@st.com \
--cc=gdb-patches@sourceware.org \
/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