From: Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
To: "Six, Lancelot" <Lancelot.Six@amd.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: "lsix@lancelotsix.com" <lsix@lancelotsix.com>
Subject: Re: [PATCH 2/2] gdb/testsuite: Accept PIE/noPIE programs in gdb.mi/mi-var-invalidate-shlib.exp
Date: Wed, 3 Aug 2022 13:51:05 +0200 [thread overview]
Message-ID: <88befc1b-1288-16d0-f3d2-20a8af4cf616@suse.de> (raw)
In-Reply-To: <DM4PR12MB5745FABE635835F101B69C02839C9@DM4PR12MB5745.namprd12.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]
On 8/3/22 11:35, Six, Lancelot wrote:
> [AMD Official Use Only - General]
>
>> Hi,
>>
>> thanks for the analysis.
>>
>> After looking into this a bit, I wonder if the root cause is really
>> looking at the values in the old process.
>>
>> Maybe we should either:
>> - not try to sample the values when recreating, or
>> - move the recreation to a later point when we have access to the memory
>> of the new process.
>>
>> At least we would have consistency between PIE and no-PIE with either
>> solution.
>>
>> Thanks,
>> - Tom
>
> Hi,
>
> I do agree that it is strange to look for a value for the new objfile in the old process. I wonder if there are legitimate usecases where one would want to still use "file ..." to load new symbols but keep the same process running while keeping a global varobj around. If we delay the recreation of the varobj, we would break such usecase.
>
You're right, apparently that's a valid use case.
> One way could be to be just invalidate the varobj when the objfile it relies on goes away and give the user a "-var-reinflate" command (or "-var-update -reinflate") so he can try to revive an invalidated varobj at his convenience. This would break existing behavior but could avoid.
I've now reached the conclusion that the bug is merely that for
recreating the varobjs we don't wait until relocation has happened, as
we do for breakpoints.
This WIP patch delays recreation of the varobj to the point that the
file command has relocated the PIE exec.
This makes behaviour equal between PIE and no-PIE (meaning we see the
same two FAILs now for gdb.mi/mi-var-invalidate-shlib.exp).
I'm not sure about the split between invalidate and re_set, I'm not
familiar with this code.
WDYT?
Thanks,
- Tom
[-- Attachment #2: tmp.patch --]
[-- Type: text/x-patch, Size: 2226 bytes --]
diff --git a/gdb/symfile.c b/gdb/symfile.c
index aea8c762ee6..d0a32d13231 100644
--- a/gdb/symfile.c
+++ b/gdb/symfile.c
@@ -1656,6 +1656,9 @@ symbol_file_command (const char *args, int from_tty)
/* Now it's safe to re-add the breakpoints. */
breakpoint_re_set ();
+
+ /* Also, it's safe to re-add varobjs. */
+ varobj_re_set ();
}
}
diff --git a/gdb/varobj.c b/gdb/varobj.c
index 0683af1991e..ecc53f2643d 100644
--- a/gdb/varobj.c
+++ b/gdb/varobj.c
@@ -2362,6 +2362,26 @@ all_root_varobjs (gdb::function_view<void (struct varobj *var)> func)
static void
varobj_invalidate_iter (struct varobj *var)
+{
+ /* global and floating var must be re-evaluated. */
+ if (var->root->floating || var->root->global)
+ ;
+ else /* locals must be invalidated. */
+ var->root->is_valid = false;
+}
+
+/* Invalidate the varobjs that are tied to locals and re-create the ones that
+ are defined on globals.
+ Invalidated varobjs will be always printed in_scope="invalid". */
+
+void
+varobj_invalidate (void)
+{
+ all_root_varobjs (varobj_invalidate_iter);
+}
+
+static void
+varobj_re_set_iter (struct varobj *var)
{
/* global and floating var must be re-evaluated. */
if (var->root->floating || var->root->global)
@@ -2387,18 +2407,12 @@ 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
- are defined on globals.
- Invalidated varobjs will be always printed in_scope="invalid". */
-
void
-varobj_invalidate (void)
+varobj_re_set (void)
{
- all_root_varobjs (varobj_invalidate_iter);
+ all_root_varobjs (varobj_re_set_iter);
}
/* Ensure that no varobj keep references to OBJFILE. */
diff --git a/gdb/varobj.h b/gdb/varobj.h
index 073da60d772..f3cce8ebfbd 100644
--- a/gdb/varobj.h
+++ b/gdb/varobj.h
@@ -316,6 +316,8 @@ extern std::vector<varobj_update_result>
extern void varobj_invalidate (void);
+extern void varobj_re_set (void);
+
extern bool varobj_editable_p (const struct varobj *var);
extern bool varobj_floating_p (const struct varobj *var);
next prev parent reply other threads:[~2022-08-03 11:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-02 12:47 [PATCH 0/2] Fix regressions in varobj recreation Lancelot SIX via Gdb-patches
2022-08-02 12:47 ` [PATCH 1/2] gdb: Fix regression " Lancelot SIX via Gdb-patches
2022-08-02 13:26 ` Tom de Vries via Gdb-patches
2022-08-03 9:06 ` Six, Lancelot via Gdb-patches
2022-08-02 12:47 ` [PATCH 2/2] gdb/testsuite: Accept PIE/noPIE programs in gdb.mi/mi-var-invalidate-shlib.exp Lancelot SIX via Gdb-patches
2022-08-02 15:45 ` Tom de Vries via Gdb-patches
2022-08-03 9:35 ` Six, Lancelot via Gdb-patches
2022-08-03 11:51 ` Tom de Vries via Gdb-patches [this message]
2022-08-03 13:23 ` Six, Lancelot via Gdb-patches
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=88befc1b-1288-16d0-f3d2-20a8af4cf616@suse.de \
--to=gdb-patches@sourceware.org \
--cc=Lancelot.Six@amd.com \
--cc=lsix@lancelotsix.com \
--cc=tdevries@suse.de \
/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: link
Be 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