public inbox for gdb-cvs@sourceware.org help / color / mirror / Atom feed
From: Lancelot SIX <lsix@sourceware.org> To: gdb-cvs@sourceware.org Subject: [binutils-gdb] gdb/varobj: Do not invalidate locals in varobj_invalidate_iter Date: Thu, 11 Aug 2022 14:17:19 +0000 (GMT) [thread overview] Message-ID: <20220811141719.D4CD93858C74@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=739be95178196df4babdcb47de856a12ba06253f commit 739be95178196df4babdcb47de856a12ba06253f Author: Lancelot SIX <lancelot.six@amd.com> Date: Thu Aug 11 15:09:55 2022 +0100 gdb/varobj: Do not invalidate locals in varobj_invalidate_iter The varobj_invalidate_iter function has logic to invalidate any local varobj it can find. However since bc20e562ec0 "gdb/varobj: Fix use after free in varobj" all varobj containing references to an objfile are cleared when the objfile goes out of scope. This means that at this point any local varobj seen by varobj_invalidate_iter either has already been invalidated by varobj_invalidate_if_uses_objfile or only contains valid references and there is no reason to invalidate it. This patch proposes to remove this unnecessary invalidation and adds a testcase which exercises a scenario where a local varobj can legitimately survive a call to varobj_invalidate_iter. At this point the varobj_invalidate and varobj_invalidate_iter seem misnamed since they deal with re-creating invalid objects and do not do invalidation, but this will be fixed in a following patch. Tested on x86_64-linux. Diff: --- gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp | 40 +++++++++++++++++++++--- gdb/varobj.c | 2 -- 2 files changed, 36 insertions(+), 6 deletions(-) diff --git a/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp b/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp index 87d1d4a6a9d..c8b9b3e039a 100644 --- a/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp +++ b/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp @@ -40,10 +40,6 @@ if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable $opt } proc do_test { separate_debuginfo } { - if { $separate_debuginfo } { - gdb_gnu_strip_debug $::shlib_path - } - if { [mi_clean_restart] } { unsupported "failed to start GDB" return @@ -132,6 +128,42 @@ proc do_test { separate_debuginfo } { } } +proc_with_prefix local_not_invalidated { separate_debuginfo } { + if { [mi_clean_restart] } { + unsupported "failed to start GDB" + return + } + + # Start the process once and create varobjs referencing the loaded objfiles. + with_test_prefix "setup" { + mi_load_shlibs $::shlib_path + if { $separate_debuginfo } { + mi_load_shlibs ${::shlib_path}.debug + } + + mi_gdb_reinitialize_dir $::srcdir/$::subdir + mi_gdb_load $::binfile + + mi_runto foo -pending + mi_next "next" + mi_create_varobj local_var local_var "create local varobj" + } + + # At this point we are stopped in the shared library. If we reload symbols + # for the main binary, symbols for the shared library remain valid. A + # varobj tracking variables in the scope of the shared library only should + # not be invalidated. + mi_gdb_load ${::binfile} + mi_gdb_test "-var-update local_var" \ + "\\^done,changelist=\\\[\\\]" \ + "local_var preserved" +} + foreach_with_prefix separate_debuginfo {0 1} { + if { $separate_debuginfo } { + gdb_gnu_strip_debug $::shlib_path + } + do_test $separate_debuginfo + local_not_invalidated $separate_debuginfo } diff --git a/gdb/varobj.c b/gdb/varobj.c index 0683af1991e..a142bb02e03 100644 --- a/gdb/varobj.c +++ b/gdb/varobj.c @@ -2387,8 +2387,6 @@ varobj_invalidate_iter (struct varobj *var) var->root->is_valid = false; } } - else /* locals must be invalidated. */ - var->root->is_valid = false; } /* Invalidate the varobjs that are tied to locals and re-create the ones that
reply other threads:[~2022-08-11 14:17 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220811141719.D4CD93858C74@sourceware.org \ --to=lsix@sourceware.org \ --cc=gdb-cvs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).