aboutsummaryrefslogtreecommitdiff
path: root/gdb/varobj.h
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2022-08-10 22:23:28 +0100
committerLancelot SIX <lancelot.six@amd.com>2022-08-11 15:10:35 +0100
commitccb5e559ef13f1c7a32312199f7887b463c56216 (patch)
tree9e4ae08887b358498e0998cb9868e7b00309ae51 /gdb/varobj.h
parent739be95178196df4babdcb47de856a12ba06253f (diff)
downloadgdb-ccb5e559ef13f1c7a32312199f7887b463c56216.zip
gdb-ccb5e559ef13f1c7a32312199f7887b463c56216.tar.gz
gdb-ccb5e559ef13f1c7a32312199f7887b463c56216.tar.bz2
gdb/varobj: Reset varobj after relocations have been computed
[This patch is a followup to the discussion in https://sourceware.org/pipermail/gdb-patches/2022-August/191188.html] PR/29426 shows failures when running the gdb.mi/mi-var-invalidate-shlib test when using a compiler which does not produce a PIE executable by default. In the testcase, a varobj is created to track a global variable, and then the main binary is reloaded in GDB (using the file command). During the load of the new binary, GDB tries to recreate the varobj to track the global in the new binary (varobj_invalidate_iter). At this point, the old process is still in flight. So when we try to access to the value of the global, in a PIE executable we only have access to the unrelocated address (the objfile's text_section_offset () is 0). As a consequence down the line read_value_memory fails to read the unrelated address, so cannot evaluate the value of the global. Note that the expression used to access to the global’s value is valid, so the varobj can be created. When using a non PIE executable, the address of the global GDB knows about at this point does not need relocation, so read_value_memory can access the (old binary’s) value. So at this point, in the case of a non-PIE executable the value field is set, while it is cleared in the case of PIE executable. Later when the test issues a "-var-update global_var", the command sees no change in the case of the non-PIE executable, while in the case of the PIE executable install_new_value sees that value changes, leading to a different output. This patch makes sure that, as we do for breakpoints, we wait until relocation has happened before we try to recreate varobjs. This way we have a consistent behavior between PIE and non-PIE binaries. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29426 Co-authored-by: Lancelot SIX <lancelot.six@amd.com>
Diffstat (limited to 'gdb/varobj.h')
-rw-r--r--gdb/varobj.h5
1 files changed, 4 insertions, 1 deletions
diff --git a/gdb/varobj.h b/gdb/varobj.h
index 073da60..0c92d67 100644
--- a/gdb/varobj.h
+++ b/gdb/varobj.h
@@ -314,7 +314,10 @@ extern void all_root_varobjs (gdb::function_view<void (struct varobj *var)>);
extern std::vector<varobj_update_result>
varobj_update (struct varobj **varp, bool is_explicit);
-extern void varobj_invalidate (void);
+/* Try to recreate any global or floating varobj. This is called after
+ changing symbol files. */
+
+extern void varobj_re_set (void);
extern bool varobj_editable_p (const struct varobj *var);