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

[sergiodj+buildbot at sergiodj dot net]

*** TEST RESULTS FOR COMMIT e707fc445e68ccfa136a52cd4989b0cb778d1ca7 ***

Author: Andrew Burgess <andrew.burgess@embecosm.com>
Branch: master
Commit: e707fc445e68ccfa136a52cd4989b0cb778d1ca7

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.