diff options
| author | Andrew Burgess <andrew.burgess@embecosm.com> | 2017-10-19 11:27:48 +0100 |
|---|---|---|
| committer | Andrew Burgess <andrew.burgess@embecosm.com> | 2018-01-21 15:47:28 +0000 |
| commit | e707fc445e68ccfa136a52cd4989b0cb778d1ca7 (patch) | |
| tree | b84a1d3be858bb6bccf2fc0260562568b5c6de2d /gdb/m32c-tdep.c | |
| parent | 03d0bf7b78b142a5e03dfa1c80100893753d0022 (diff) | |
| download | gdb-e707fc445e68ccfa136a52cd4989b0cb778d1ca7.zip gdb-e707fc445e68ccfa136a52cd4989b0cb778d1ca7.tar.gz gdb-e707fc445e68ccfa136a52cd4989b0cb778d1ca7.tar.bz2 | |
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.
Diffstat (limited to 'gdb/m32c-tdep.c')
0 files changed, 0 insertions, 0 deletions