diff options
author | Lancelot SIX <lancelot.six@amd.com> | 2022-07-08 11:37:19 +0100 |
---|---|---|
committer | Lancelot SIX <lsix@lancelotsix.com> | 2022-07-26 08:27:27 +0100 |
commit | 6c96b937df01064526470694da9b6d24761e57fc (patch) | |
tree | c7c8f92c90cc142dc259846a8695c191cb4f4fb1 /gdbserver | |
parent | bc20e562ec0436b6117b989c0e3d8f66c9d4d979 (diff) | |
download | gdb-6c96b937df01064526470694da9b6d24761e57fc.zip gdb-6c96b937df01064526470694da9b6d24761e57fc.tar.gz gdb-6c96b937df01064526470694da9b6d24761e57fc.tar.bz2 |
gdb/varobj: Fix varobj_invalidate_iter
The varobj_invalidate function is meant to be called when restarting a
process, and check at this point if some of the previously existing
varobj can be recreated in the context of the new process.
Two kind of varobj are subject to re-creation: global varobj (i.e.
varobj which reference a global variable), and floating varobj (i.e.
varobj which are always re-evaluated in the context of whatever is
the currently selected frame at the time of evaluation).
However, in the re-creation process, the varobj_invalidate_iter
recreates floating varobj as non-floating, due to an invalid parameter.
This patches fixes this and adds an assertion to check that if a varobj
is indeed recreated, it matches the original varobj "floating" property.
Another issue is that if at this recreation time the expression watched
by the floating varobj is not in scope, then the varobj is marked as
invalid. If later the user selects a frame where the expression becomes
valid, the varobj remains invalid and this is wrong. This patch also
make sure that floating varobj are not invalidated if they cannot be
evaluated.
The last important thing to note is that due to the previous patch, when
varobj_invalidate is executed (in the context of a new process), any
global var have already been invalidated (this has been done when the
objfile it referred to got invalidated). As a consequence,
varobj_invalidate tries to recreate vars which are already marked as
invalid. This does not entirely feels right, but I keep this behavior
for backward compatibility.
Tested on x86_64-linux
Diffstat (limited to 'gdbserver')
0 files changed, 0 insertions, 0 deletions