gdb: Don't store a thread-id for floating varobj

When creating a varobj with -var-create a user can create either fixed
varobj, or floating varobj.

A fixed varobj will always be evaluated within the thread/frame/block in
which the varobj was created, if that thread/frame/block is no longer
available then the varobj is considered out of scope.

A floating varobj will always be evaluated within the current
thread/frame/block.

Despite never using them GDB was storing the thread/frame/block into a
floating varobj, and the thread-id would then be displayed when GDB
reported on the state of the varobj, this could confuse a user into
thinking that the thread-id was relevant.

This commit prevents GDB storing the thread/frame/block onto floating
varobj, and updates the few tests where this impacts the results.

gdb/ChangeLog:

	* varobj.c (varobj_create): Don't set valid_block when creating a
	floating varobj.

gdb/testsuite/ChangeLog:

	* gdb.python/py-mi.exp: Don't expect a thread-id for floating
	varobj.
	* gdb.mi/mi-var-create-rtti.exp: Likewise.

1 files changed, 2 insertions, 1 deletions

diff --git a/gdb/varobj.c b/gdb/varobj.c
index 523f746..b6a2d8f 100644
--- a/gdb/varobj.c
+++ b/gdb/varobj.c
@@ -336,7 +336,8 @@ varobj_create (const char *objname,
 	}
 
       var->format = variable_default_display (var.get ());
-      var->root->valid_block = innermost_block.block ();
+      var->root->valid_block =
+	var->root->floating ? NULL : innermost_block.block ();
       var->name = expression;
       /* For a root var, the name and the expr are the same.  */
       var->path_expr = expression;