[varobj] false type-changed status for reference to Ada array

Given the following variable...

   BT : Bounded := New_Bounded (Low => 1, High => 3);

... where type Bounded is defined as a simple unconstrained array:

   type Bounded is array (Integer range <>) of Integer;

Creating a varobj for that variable, and immediately asking for
varobj updates, GDB says that our varobj changed types!

    (gdb)
    -var-create bt * bt
    ^done,name="bt",numchild="3",value="[3]",type="<ref> array (1 .. 3) of integer",has_more="0"
    (gdb)
    -var-update 1 *
    ^done,changelist=[{name="bt",value="[3]",in_scope="true",type_changed="true",new_type="<ref> array (1 .. 3) of integer",new_num_children="3",has_more="0"}]

The expected output for the -var-update command is, in this case:

    (gdb)
    -var-update 1 *
    ^done,changelist=[]

The problem occurs because the ada-varobj module does not handle
references, and while the references gets stripped when the varobj
gets created, it doesn't when computing varobj updates.

More specifically, when creating the varobj, varobj_create creates
a new value which is a reference to a TYPE_CODE_ARRAY. It then calls
install_new_value which calls coerce_ref with the following comment:

    /* We are not interested in the address of references, and given
       that in C++ a reference is not rebindable, it cannot
       meaningfully change.  So, get hold of the real value.  */
    if (value)
      value = coerce_ref (value);

This leaves the varobj's type component still a ref, while
the varobj's value is now our array, without the ref. This explains
why the "value" field in the varobj indicates an array with 3 elements
"[3]" while the "type" field shows a ref to an array. Generally
speaking, most users have said that showing the ref was a useful
piece of information, so this patch is not touching this part.

Next, when the user issues the -var-update request, varobj_update
calls value_of_root to compute the varobj's new value as well as
determine whether the value's type has changed or not. What happens
in a nutshell is that it calls value_of_root_1 (which re-evaluates
the expression and returns the corresponding new value), finds that
the new value is not NULL, and thus asks whether it has mutated:

    else if (varobj_value_has_mutated (var, value, value_type (value)))

This then indirectly delegates the determination to the language-specific
callback, which fails, because it does not handle references.

This patch fixes the issue by adjusting varobj_value_has_mutated to
expect references, and strip them when seen. This allows the various
language-specific implementations to remain unaware of references.

gdb/ChangeLog:

        * varobj.c (varobj_value_has_mutated): If NEW_VALUE is
        a reference, strip the reference layer before calling
        the lang_ops value_has_mutated callback.

gdb/testsuite/ChangeLog:

        * gdb.ada/mi_dyn_arr: New testcase.

1 files changed, 10 insertions, 1 deletions

diff --git a/gdb/varobj.c b/gdb/varobj.c
index bbe42137a1b..10ef5b74062 100644
--- a/gdb/varobj.c
+++ b/gdb/varobj.c
@@ -1649,7 +1649,16 @@ varobj_value_has_mutated (struct varobj *var, struct value *new_value,
     return 0;
 
   if (var->root->lang_ops->value_has_mutated)
-    return var->root->lang_ops->value_has_mutated (var, new_value, new_type);
+    {
+      /* The varobj module, when installing new values, explicitly strips
+	 references, saying that we're not interested in those addresses.
+	 But detection of mutation happens before installing the new
+	 value, so our value may be a reference that we need to strip
+	 in order to remain consistent.  */
+      if (new_value != NULL)
+	new_value = coerce_ref (new_value);
+      return var->root->lang_ops->value_has_mutated (var, new_value, new_type);
+    }
   else
     return 0;
 }