Patch for gdb/mi problem 702

Patch for gdb/mi problem 702

[J. Johnston]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

The following fixes a problem with -var-assign whereby an assignment
of a new value is not seen by a subsequent -var-update.  The
underlying varobj_update call looks to see if there is a difference
between the current value and a refreshed value.  Since varobj_set_value
actually changes both the internal value and the actual value, varobj_update
does not add the variable to the changelist.

The fix involves adding a new flag: "updated" to the struct varobj which
is set by varobj_set_value when the value changes and is checked by varobj_update
before comparing current and refreshed values for a varobj.

ChangeLog:

2002-10-03  Jeff Johnston  <jjohnstn@redhat.com>

	* varobj.c (struct varobj): Add new "updated" flag.
	(new_variable): Default "updated" flag to 0.
	(varobj_set_value): Set "updated" flag to 1 if value
	changes.
	(varobj_update): Check varobj "updated" flag before
	comparing old and refreshed values.  Fix for
	PR gdb/702.

Approved?

-- Jeff J.

[-- Attachment #2: 702.patch --]
[-- Type: text/plain, Size: 2102 bytes --]

Index: varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/varobj.c,v
retrieving revision 1.32
diff -u -r1.32 varobj.c
--- varobj.c	24 Sep 2002 18:50:34 -0000	1.32
+++ varobj.c	3 Oct 2002 23:00:54 -0000
@@ -111,6 +111,9 @@
 
   /* The format of the output for this object */
   enum varobj_display_formats format;
+
+  /* Was this variable updated via a varobj_set_value operation */
+  int updated;
 };
 
 /* Every variable keeps a linked list of its children, described
@@ -753,6 +756,7 @@
 varobj_set_value (struct varobj *var, char *expression)
 {
   struct value *val;
+  int error;
   int offset = 0;
 
   /* The argument "expression" contains the variable's new value.
@@ -778,6 +782,8 @@
 	  return 0;
 	}
 
+      if (!my_value_equal (var->value, value, &error))
+        var->updated = 1;
       if (!gdb_value_assign (var->value, value, &val))
 	return 0;
       value_free (var->value);
@@ -893,10 +899,11 @@
   /* If values are not equal, note that it's changed.
      There a couple of exceptions here, though.
      We don't want some types to be reported as "changed". */
-  else if (type_changeable (*varp)
-	   && !my_value_equal ((*varp)->value, new, &error2))
+  else if (type_changeable (*varp) &&
+	   ((*varp)->updated || !my_value_equal ((*varp)->value, new, &error2)))
     {
       vpush (&result, *varp);
+      (*varp)->updated = 0;
       changed++;
       /* error2 replaces var->error since this new value
          WILL replace the old one. */
@@ -933,10 +940,12 @@
 
       /* Update this variable */
       new = value_of_child (v->parent, v->index);
-      if (type_changeable (v) && !my_value_equal (v->value, new, &error2))
+      if (type_changeable (v) && 
+          (v->updated || !my_value_equal (v->value, new, &error2)))
 	{
 	  /* Note that it's changed */
 	  vpush (&result, v);
+	  v->updated = 0;
 	  changed++;
 	}
       /* error2 replaces v->error since this new value
@@ -1294,6 +1303,7 @@
   var->children = NULL;
   var->format = 0;
   var->root = NULL;
+  var->updated = 0;
 
   return var;
 }

Re: Patch for gdb/mi problem 702

[Keith Seitz]

On Thu, 3 Oct 2002, J. Johnston wrote:

> The following fixes a problem with -var-assign whereby an assignment
> of a new value is not seen by a subsequent -var-update.  The
> underlying varobj_update call looks to see if there is a difference
> between the current value and a refreshed value.  Since varobj_set_value
> actually changes both the internal value and the actual value, varobj_update
> does not add the variable to the changelist.

The real question is: is it really necessary for an assignment to show up 
in the udpate list. IMO, it doesn't matter, because the caller will know if 
the assignment succeeded or failed. If it failed, it'll have an error 
message from MI. Otherwise, it knows that it worked and all it needs to do 
is fetch the value of this variable (to get the right display format) and
update the displayed value on the screen. There's no reason to do an 
update, which is not a cheap operation.

I really don't know what to make of this. I don't think this is really 
necessary. It seems like a substitute for error checking.

Perhaps Alain can comment on why this is necessary with Eclipse?

Keith

Re: Patch for gdb/mi problem 702

[J. Johnston]

Keith Seitz wrote:
> 
> On Thu, 3 Oct 2002, J. Johnston wrote:
> 
> > The following fixes a problem with -var-assign whereby an assignment
> > of a new value is not seen by a subsequent -var-update.  The
> > underlying varobj_update call looks to see if there is a difference
> > between the current value and a refreshed value.  Since varobj_set_value
> > actually changes both the internal value and the actual value, varobj_update
> > does not add the variable to the changelist.
> 
> The real question is: is it really necessary for an assignment to show up
> in the udpate list. IMO, it doesn't matter, because the caller will know if
> the assignment succeeded or failed. If it failed, it'll have an error
> message from MI. Otherwise, it knows that it worked and all it needs to do
> is fetch the value of this variable (to get the right display format) and
> update the displayed value on the screen. There's no reason to do an
> update, which is not a cheap operation.
> 
> I really don't know what to make of this. I don't think this is really
> necessary. It seems like a substitute for error checking.
> 
> Perhaps Alain can comment on why this is necessary with Eclipse?
> 
> Keith

Consider the following scenario.  An application has output windows showing a number
of variables.  Some of these output variables are aliases of one another
(e.g. *p which points to a[5] which is also being shown).  The application
kicks off a separate input field operation that changes the value of a[5].
Now, the application knows it changed a[5], but doesn't necessarily know about
the current alias to *p.  With patch, if the -var-update is performed after the -var-assign, both
values will show that they need update.  Without the patch, only the *p value will
show up (the original assignment won't).  Arguably, the application could track
this, but it seems to make sense to keep it clean.  The "change value" window
could simply signal that a value has changed and let any corresponding
windows issue their own updates.

-- Jeff J.

Re: Patch for gdb/mi problem 702

[Keith Seitz]

On Fri, 4 Oct 2002, J. Johnston wrote:

> Some of these output variables are aliases of one another
> (e.g. *p which points to a[5] which is also being shown).  The application
> kicks off a separate input field operation that changes the value of a[5].
> Now, the application knows it changed a[5], but doesn't necessarily know about
> the current alias to *p.

You'll also get a target_changed event. This will cause the UI to run 
-var-update, which will show that the "aliased" object's value has 
changed. This already works in insight.

Keith

Re: Patch for gdb/mi problem 702

[Alain Magloire]

> 
> On Fri, 4 Oct 2002, J. Johnston wrote:
> 
> > Some of these output variables are aliases of one another
> > (e.g. *p which points to a[5] which is also being shown).  The application
> > kicks off a separate input field operation that changes the value of a[5].
> > Now, the application knows it changed a[5], but doesn't necessarily know about
> > the current alias to *p.
> 
> You'll also get a target_changed event. This will cause the UI to run 
> -var-update, which will show that the "aliased" object's value has 
> changed. This already works in insight.
> 

Yes, as J. Johnston was saying, it was more in the case:
you write to a memory, the memory is actually pointing to some variables.
You would want the change events for the variables affected also,
We do actually send the ChangeEvent on behalf of gdb in eclipse, but
we do not know of the side-effects.


The target_changed does not specify who is affected, which force a
cascade of -var-evaluate-expression of all the objects.

And I beleive this will only be in gdb-5.4 and up(can not wait to start
to work on it to take advantage of the improve MI2 8-).

Re: Patch for gdb/mi problem 702

[J. Johnston]

Keith Seitz wrote:
> 
> On Fri, 4 Oct 2002, J. Johnston wrote:
> 
> > Some of these output variables are aliases of one another
> > (e.g. *p which points to a[5] which is also being shown).  The application
> > kicks off a separate input field operation that changes the value of a[5].
> > Now, the application knows it changed a[5], but doesn't necessarily know about
> > the current alias to *p.
> 
> You'll also get a target_changed event. This will cause the UI to run
> -var-update, which will show that the "aliased" object's value has
> changed. This already works in insight.
> 
> Keith

Yes, but the UI won't see the original value that got changed.  So, if you are going to get
the cost of a -var-update anyway, why not add the value that just got changed
and thereby make the code simpler?  Otherwise, the setter of the value
must go and cause a refresh of the changed value in addition to the normal code that will 
trigger due to a target_changed event.  Am I missing something here?

-- Jeff J.

Re: Patch for gdb/mi problem 702

[Keith Seitz]

On Fri, 4 Oct 2002, J. Johnston wrote:

> Am I missing something here?

No. :-)

Like I tried to say, I'm just playing devil's advocate. (Although maybe I 
should stop. It didn't seem to get me too far with Apple.)

I don't think the code is necessary, but that doesn't mean I don't think 
that it is acceptable.

Keith

Re: Patch for gdb/mi problem 702

[Andrew Cagney]

> On Thu, 3 Oct 2002, J. Johnston wrote:
> 
> 
>> The following fixes a problem with -var-assign whereby an assignment
>> of a new value is not seen by a subsequent -var-update.  The
>> underlying varobj_update call looks to see if there is a difference
>> between the current value and a refreshed value.  Since varobj_set_value
>> actually changes both the internal value and the actual value, varobj_update
>> does not add the variable to the changelist.
> 
> 
> The real question is: is it really necessary for an assignment to show up 
> in the udpate list. IMO, it doesn't matter, because the caller will know if 
> the assignment succeeded or failed. If it failed, it'll have an error 
> message from MI. Otherwise, it knows that it worked and all it needs to do 
> is fetch the value of this variable (to get the right display format) and
> update the displayed value on the screen. There's no reason to do an 
> update, which is not a cheap operation.
> 
> I really don't know what to make of this. I don't think this is really 
> necessary. It seems like a substitute for error checking.
> 
> Perhaps Alain can comment on why this is necessary with Eclipse?

To play the devil's devil advocate ...

Consider a memory mapped register with sticky bits (no I'm not just 
making this up, I recently got asked this exact question - I've a vague 
recollection of complaints about gdb's current behavior in this regard).

I think ``the right thing'' is:

- the expression evaluation writes the value all the way through to the 
target
- gdb invalidates everything - memory and register caches, varobj
- gdb evaluates all variable objects including that just written value.
- -var-update lists all values that changed

The result could even be that that the modified variable didn't change 
because that modified variable is truely ``stuck'' or that some of the 
modified value is restored.

So what does the MI and the patch do in this case?

Andrew

Re: Patch for gdb/mi problem 702

[J. Johnston]

Andrew Cagney wrote:
> 
> > On Thu, 3 Oct 2002, J. Johnston wrote:
> >
> >
> >> The following fixes a problem with -var-assign whereby an assignment
> >> of a new value is not seen by a subsequent -var-update.  The
> >> underlying varobj_update call looks to see if there is a difference
> >> between the current value and a refreshed value.  Since varobj_set_value
> >> actually changes both the internal value and the actual value, varobj_update
> >> does not add the variable to the changelist.
> >
> >
> > The real question is: is it really necessary for an assignment to show up
> > in the udpate list. IMO, it doesn't matter, because the caller will know if
> > the assignment succeeded or failed. If it failed, it'll have an error
> > message from MI. Otherwise, it knows that it worked and all it needs to do
> > is fetch the value of this variable (to get the right display format) and
> > update the displayed value on the screen. There's no reason to do an
> > update, which is not a cheap operation.
> >
> > I really don't know what to make of this. I don't think this is really
> > necessary. It seems like a substitute for error checking.
> >
> > Perhaps Alain can comment on why this is necessary with Eclipse?
> 
> To play the devil's devil advocate ...
> 
> Consider a memory mapped register with sticky bits (no I'm not just
> making this up, I recently got asked this exact question - I've a vague
> recollection of complaints about gdb's current behavior in this regard).
> 
> I think ``the right thing'' is:
> 
> - the expression evaluation writes the value all the way through to the
> target
> - gdb invalidates everything - memory and register caches, varobj
> - gdb evaluates all variable objects including that just written value.
> - -var-update lists all values that changed
> 
> The result could even be that that the modified variable didn't change
> because that modified variable is truely ``stuck'' or that some of the
> modified value is restored.
> 
> So what does the MI and the patch do in this case?
> 

I think we are ok.

The -var-update code calls value_of_root at the top to get a "new"
value before comparing.  This operation ends up calling gdb_evaluate_expression
which should handle fetching the real value and any sticky bits should be
set properly.

The new code now looks at the "updated" flag which I added.  If this
flag is on, it puts the item on the list.  This causes the current varobj value to
be updated with value "new" so all should be fine.

-- Jeff J.

> Andrew

Re: Patch for gdb/mi problem 702

[J. Johnston]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

I have added test scenarios to gdb.mi testsuite to verify the new assign/update
behavior.

gdb/testsuite/gdb.mi/ChangeLog

2002-10-23  Jeff Johnston  <jjohnstn@redhat.com>

	* mi-var-cmd.exp: Add tests to verify that a -var-assign that changes
	a value shows up in the changelist of a -var-update.
	* mi1-var-cmd.exp: Ditto.

Andrew, are you satisfied with my answer to your previous question and may I commit 
the original patch plus these changes?

-- Jeff J.

[-- Attachment #2: 702.test.patch --]
[-- Type: text/plain, Size: 2781 bytes --]

Index: mi-var-cmd.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-var-cmd.exp,v
retrieving revision 1.13
diff -u -r1.13 mi-var-cmd.exp
--- mi-var-cmd.exp	3 Oct 2002 20:03:55 -0000	1.13
+++ mi-var-cmd.exp	23 Oct 2002 22:12:48 -0000
@@ -288,6 +288,18 @@
 	"\\^done,value=\"3333\"" \
 	"assign to linteger"
 
+mi_gdb_test "-var-update *" \
+	"\\^done,changelist=\\\[\{name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
+	"update all vars: linteger changed after assign"
+
+mi_gdb_test "-var-assign linteger 3333" \
+	"\\^done,value=\"3333\"" \
+	"assign to linteger again, same value"
+
+mi_gdb_test "-var-update *" \
+	"\\^done,changelist=\\\[\\\]" \
+	"update all vars: linteger not changed after same assign"
+
 mi_gdb_test "-var-evaluate-expression linteger" \
 	"\\^done,value=\"3333\"" \
 	"eval linteger"
@@ -295,6 +307,14 @@
 mi_gdb_test "-var-assign lpinteger \"&linteger + 3\"" \
 	"\\^done,value=\"$hex\"" \
 	"assign to lpinteger"
+
+mi_gdb_test "-var-update *" \
+	"\\^done,changelist=\\\[\{name=\"lpinteger\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \
+	"update all vars: lpinteger changed after assign"
+
+mi_gdb_test "-var-update *" \
+	"\\^done,changelist=\\\[\\\]" \
+	"update all vars: no changes on second update"
 
 mi_gdb_test "-var-evaluate-expression lpinteger" \
 	"\\^done,value=\"$hex\"" \
Index: mi1-var-cmd.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi1-var-cmd.exp,v
retrieving revision 1.2
diff -u -r1.2 mi1-var-cmd.exp
--- mi1-var-cmd.exp	1 Oct 2002 16:01:37 -0000	1.2
+++ mi1-var-cmd.exp	23 Oct 2002 22:12:48 -0000
@@ -288,6 +288,18 @@
 	"\\^done,value=\"3333\"" \
 	"assign to linteger"
 
+mi_gdb_test "-var-update *" \
+	"\\^done,changelist=\{name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"update all vars: linteger changed after assign"
+
+mi_gdb_test "-var-assign linteger 3333" \
+	"\\^done,value=\"3333\"" \
+	"reassign to linteger"
+
+mi_gdb_test "-var-update *" \
+	"\\^done,changelist=\{\}" \
+	"update all vars: linteger not changed after same assign"
+
 mi_gdb_test "-var-evaluate-expression linteger" \
 	"\\^done,value=\"3333\"" \
 	"eval linteger"
@@ -295,6 +307,14 @@
 mi_gdb_test "-var-assign lpinteger \"&linteger + 3\"" \
 	"\\^done,value=\"$hex\"" \
 	"assign to lpinteger"
+
+mi_gdb_test "-var-update *" \
+	"\\^done,changelist=\{name=\"lpinteger\",in_scope=\"true\",type_changed=\"false\"\}" \
+	"update all vars: lpinteger changed after assign"
+
+mi_gdb_test "-var-update *" \
+	"\\^done,changelist=\{\}" \
+	"update all vars: no changes for second update"
 
 mi_gdb_test "-var-evaluate-expression lpinteger" \
 	"\\^done,value=\"$hex\"" \

Re: Patch for gdb/mi problem 702

[Andrew Cagney]

> I have added test scenarios to gdb.mi testsuite to verify the new assign/update
> behavior.
> 
> gdb/testsuite/gdb.mi/ChangeLog
> 
> 2002-10-23  Jeff Johnston  <jjohnstn@redhat.com>
> 
> 	* mi-var-cmd.exp: Add tests to verify that a -var-assign that changes
> 	a value shows up in the changelist of a -var-update.
> 	* mi1-var-cmd.exp: Ditto.
> 
> Andrew, are you satisfied with my answer to your previous question

Yep.

> and may I commit 
> the original patch plus these changes?

Yep, but.  Can you just quickly check that, within each MI file, the new 
test messages are unique.

Please also add something to the NEWS file.

Andrew

Re: Patch for gdb/mi problem 702

[Andrew Cagney]

> I have added test scenarios to gdb.mi testsuite to verify the new assign/update
> behavior.
> 
> gdb/testsuite/gdb.mi/ChangeLog
> 
> 2002-10-23  Jeff Johnston  <jjohnstn@redhat.com>
> 
> 	* mi-var-cmd.exp: Add tests to verify that a -var-assign that changes
> 	a value shows up in the changelist of a -var-update.
> 	* mi1-var-cmd.exp: Ditto.
> 
> Andrew, are you satisfied with my answer to your previous question and may I commit 
> the original patch plus these changes?

Er, oops, PS:

Can you please (separate) update the doco so that -var-assign has:
- an example (steal something from your test case)
- a note mentioning that the assigned object is intentionally included 
with a very brief rationale.

Just get an ok from Eli on this one.

Andrew

Re: Patch for gdb/mi problem 702

[J. Johnston]

Andrew Cagney wrote:
> 
> > I have added test scenarios to gdb.mi testsuite to verify the new assign/update
> > behavior.
> >
> > gdb/testsuite/gdb.mi/ChangeLog
> >
> > 2002-10-23  Jeff Johnston  <jjohnstn@redhat.com>
> >
> >       * mi-var-cmd.exp: Add tests to verify that a -var-assign that changes
> >       a value shows up in the changelist of a -var-update.
> >       * mi1-var-cmd.exp: Ditto.
> >
> > Andrew, are you satisfied with my answer to your previous question
> 
> Yep.
> 
> > and may I commit
> > the original patch plus these changes?
> 
> Yep, but.  Can you just quickly check that, within each MI file, the new
> test messages are unique.
> 

Confirmed.


> Please also add something to the NEWS file.
> 

Done.  Also added the other fixes I have added recently.

Patches committed.

-- Jeff J.

Re: Patch for gdb/mi problem 702

[J. Johnston]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

Andrew Cagney wrote:
> 
> > I have added test scenarios to gdb.mi testsuite to verify the new assign/update
> > behavior.
> >
> > gdb/testsuite/gdb.mi/ChangeLog
> >
> > 2002-10-23  Jeff Johnston  <jjohnstn@redhat.com>
> >
> >       * mi-var-cmd.exp: Add tests to verify that a -var-assign that changes
> >       a value shows up in the changelist of a -var-update.
> >       * mi1-var-cmd.exp: Ditto.
> >
> > Andrew, are you satisfied with my answer to your previous question and may I commit
> > the original patch plus these changes?
> 
> Er, oops, PS:
> 
> Can you please (separate) update the doco so that -var-assign has:
> - an example (steal something from your test case)
> - a note mentioning that the assigned object is intentionally included
> with a very brief rationale.
> 
> Just get an ok from Eli on this one.
> 
> Andrew

I have attached the requested doc change.  Eli, ok to commit?

-- Jeff J.

[-- Attachment #2: 702.doc.patch --]
[-- Type: text/plain, Size: 914 bytes --]

Index: gdbmi.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/mi/gdbmi.texinfo,v
retrieving revision 1.29
diff -u -r1.29 gdbmi.texinfo
--- gdbmi.texinfo	3 Oct 2002 22:31:31 -0000	1.29
+++ gdbmi.texinfo	8 Nov 2002 21:34:52 -0000
@@ -3799,7 +3799,21 @@
 @end example
 
 Assigns the value of @var{expression} to the variable object specified
-by @var{name}.  The object must be @samp{editable}.
+by @var{name}.  The object must be @samp{editable}.  If the variable's
+value is altered by the assign, the variable will show up in any 
+subsequent @code{-var-update} list.
+
+@subsubheading Example
+
+@example
+(@value{GDBP})
+-var-assign var1 3
+^done,value="3"
+(@value{GDBP})
+-var-update *
+^done,changelist=[@{name="var1",in_scope="true",type_changed="false"@}]
+(@value{GDBP})
+@end example
 
 @subheading The @code{-var-update} Command
 @findex -var-update

Re: Patch for gdb/mi problem 702

[Eli Zaretskii]

> Date: Fri, 08 Nov 2002 16:42:14 -0500
> From: "J. Johnston" <jjohnstn@redhat.com>
> > 
> > Just get an ok from Eli on this one.
> > 
> > Andrew
> 
> I have attached the requested doc change.  Eli, ok to commit?

Yes, thanks.

Re: Patch for gdb/mi problem 702

[J. Johnston]

Eli Zaretskii wrote:
> 
> > Date: Fri, 08 Nov 2002 16:42:14 -0500
> > From: "J. Johnston" <jjohnstn@redhat.com>
> > >
> > > Just get an ok from Eli on this one.
> > >
> > > Andrew
> >
> > I have attached the requested doc change.  Eli, ok to commit?
> 
> Yes, thanks.

Thanks.  Patch committed.  All changes for this PR are now checked in.
I left out the ChangeLog entry in my last post, so I have included it
here.

gdb/mi/ChangeLog:

2002-11-11  Jeff Johnston  <jjohnstn@redhat.com>

        * gdbmi.texinfo (-var-assign): Add comments about interaction
        with -var-update and add an example.  Part of fix for gdb/702.


-- Jeff J.

Re: Patch for gdb/mi problem 702

[Keith Seitz]

On Fri, 4 Oct 2002, Alain Magloire wrote:

> Yes, as J. Johnston was saying, it was more in the case:
> you write to a memory, the memory is actually pointing to some variables.
> You would want the change events for the variables affected also,
> We do actually send the ChangeEvent on behalf of gdb in eclipse, but
> we do not know of the side-effects.

That's because you're using an older version of gdb. If you were 
developing on CVS head, you would soon get:

(gdb)
-var-create - * &argc
^done,name="var1",numchild="1",type="int *"
(gdb)
-var-list-children var1
^done,numchild="1",children={child={name="var1.*&argc",exp="*&argc",numchild="0",type="int"}}
(gdb)
&"set *(int*)&argc = 32\n"
=target-changed
^done
(gdb)
-var-update *
^done,changelist={name="var1.*&argc",in_scope="true",type_changed="false"}
(gdb)

> The target_changed does not specify who is affected, which force a
> cascade of -var-evaluate-expression of all the objects.

It could potentially cause a cascade of -var-evaluate-expression commands 
and several others, too, but it does this for a reason. GDB cannot tell 
you what exactly happened. Your CPU could have memory-mapped registers. 
What if the user changes a memory address which is pointing to the stack 
pointer? Do you want gdb to know that the register and the memory and a 
variable has changed and send you update events for all three? I don't 
cannot even imagine how to tell GDB to do this without a massive rewrite 
of GDB internals.

Quite frankly, there is no way that one target_changed event can possibly 
introduce such a large time-lag in the UI. With target_changed, one 
updates:

  memory view
  viewed variables
  registers

So on a system where the UI is displaying X bytes of memory, Y variables 
(varobj only -- children don't count), and Z registers, this results in:

(gdb)
-data-read-memory 0xbffff684 x 8 5 8 .
^done,addr="0xbffff684",nr-bytes="320",total-bytes="320",next-row="0xbffff6c4",prev-row="0xbffff644",next-page="0xbffff7c4",prev-page="0xbffff544",memory=[{addr="0xbffff684",data=["0x00000000bffff853","0xbffff891bffff872","0xbffff903bffff8cd","0xbffff933bffff915","0xbffff968bffff946","0xbffff9adbffff9a1","0xbffffb7cbffff9b9","0xbffffbafbffffb9b"],ascii="S.......r...................3...F...h...............|..........."},{addr="0xbffff6c4",data=["0xbffffc54bffffc38","0xbffffc75bffffc69","0xbffffcf8bffffcb0","0xbffffd1dbffffd09","0xbffffd33bffffd28","0xbffffd52bffffd47","0xbffffd69bffffd61","0xbffffde6bffffd7c"],ascii="8...T...i...u...................(...3...G...R...a...i...|......."},{addr="0xbffff704",data=["0xbffffe31bffffe25","0xbffffe74bffffe64","0xbffffeb2bffffe82","0xbffffeccbffffebb","0xbffffeecbffffeda","0xbfffff2abffffef7","0x00000000bfffff55","0x0383fbff00000010"],ascii="%...1...d...t...............................*...U..............."},{addr="0xbffff744",data=["0x00!
00100000000006","0x0000006400000011","0x0804803400000003","0x0000002000000004","0x0000000600000005","0x4000000000000007","0x0000000000000008","0x0808c2f000000009"],ascii="............d.......4....... 
..................@................"},{addr="0xbffff784",data=["0x000001f40000000b","0x000001f40000000c","0x000001f40000000d","0x000001f40000000e","0xbffff7ce0000000f","0x0000000000000000","0x0000000000000000","0x0000000000000000"],ascii="................................................................"}]
(gdb)
-var-update *
^done,changelist={...}
(gdb)
-data-list-changed-registers
^done,changelist={...}

That's an insiginificant amount of work to be done. Now if GDB cached the 
memory values so that it could tell you what memory changed, then this 
would cause even less work to be done.

Keith