Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
To: Lancelot SIX <lancelot.six@amd.com>, gdb-patches@sourceware.org
Cc: lsix@lancelotsix.com
Subject: Re: [PATCH 2/3] gdb/varobj: Reset varobj after relocations have been computed
Date: Tue, 9 Aug 2022 12:55:37 +0200	[thread overview]
Message-ID: <3956798c-7ab8-90f5-e0fb-cfc7d9d00834@suse.de> (raw)
In-Reply-To: <20220804130231.2126565-3-lancelot.six@amd.com>

On 8/4/22 15:02, Lancelot SIX wrote:
> From: Tom de Vries <tdevries@suse.de>
> 
> [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.
> 

LGTM.

Thanks,
- Tom

> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29426
> Co-authored-by: Lancelot SIX <lancelot.six@amd.com>
> ---
>   gdb/symfile.c                                 |  6 ++---
>   .../gdb.mi/mi-var-invalidate-shlib.exp        |  2 +-
>   gdb/varobj.c                                  | 22 +++++++------------
>   gdb/varobj.h                                  |  5 ++++-
>   4 files changed, 16 insertions(+), 19 deletions(-)
> 
> diff --git a/gdb/symfile.c b/gdb/symfile.c
> index aea8c762ee6..f61235dd271 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 ();
>       }
>   }
>   
> @@ -2870,9 +2873,6 @@ clear_symtab_users (symfile_add_flags add_flags)
>     clear_pc_function_cache ();
>     gdb::observers::new_objfile.notify (NULL);
>   
> -  /* Varobj may refer to old symbols, perform a cleanup.  */
> -  varobj_invalidate ();
> -
>     /* Now that the various caches have been cleared, we can re_set
>        our breakpoints without risking it using stale data.  */
>     if ((add_flags & SYMFILE_DEFER_BP_RESET) == 0)
> diff --git a/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp b/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp
> index 9ba5af0c028..fdf80b79741 100644
> --- a/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp
> +++ b/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp
> @@ -99,7 +99,7 @@ proc do_test { separate_debuginfo } {
>   	# When reloading the symbol file, only the var for the global in the main
>   	# executable is re-created.
>   	mi_gdb_test "-var-update global_var" \
> -	    "\\^done,changelist=\\\[{name=\"global_var\",in_scope=\"true\",type_changed=\"false\",has_more=\"0\"}\\\]" \
> +	    "\\^done,changelist=\\\[\\\]" \
>   	    "global_var recreated"
>   	mi_gdb_test "-var-update global_shlib_var" \
>   	    "\\^done,changelist=\\\[{name=\"global_shlib_var\",in_scope=\"invalid\",has_more=\"0\"}\\\]" \
> diff --git a/gdb/varobj.c b/gdb/varobj.c
> index a142bb02e03..55a7bd97f43 100644
> --- a/gdb/varobj.c
> +++ b/gdb/varobj.c
> @@ -2353,18 +2353,14 @@ all_root_varobjs (gdb::function_view<void (struct varobj *var)> func)
>       }
>   }
>   
> -/* Invalidate varobj VAR if it is tied to locals and re-create it if it is
> -   defined on globals.  It is a helper for varobj_invalidate.
> -
> -   This function is called after changing the symbol file, in this case the
> -   pointers to "struct type" stored by the varobj are no longer valid.  All
> -   varobj must be either re-evaluated, or marked as invalid here.  */
> +/* Try to recreate the varobj VAR if it is a global or floating.  This is a
> +   helper function for varobj_re_set.  */
>   
>   static void
> -varobj_invalidate_iter (struct varobj *var)
> +varobj_re_set_iter (struct varobj *var)
>   {
> -  /* global and floating var must be re-evaluated.  */
> -  if (var->root->floating || var->root->global)
> +  /* Invalidated globals and floating var must be re-evaluated.  */
> +  if (var->root->global || var->root->floating)
>       {
>         struct varobj *tmp_var;
>   
> @@ -2389,14 +2385,12 @@ varobj_invalidate_iter (struct varobj *var)
>       }
>   }
>   
> -/* 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".  */
> +/* See varobj.h.  */
>   
>   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..0c92d67e4f4 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);
>   

  reply	other threads:[~2022-08-09 10:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-04 13:02 [PATCH 0/3] Varobj re_set clanup Lancelot SIX via Gdb-patches
2022-08-04 13:02 ` [PATCH 1/3] gdb/varobj: Do not invalidate locals in varobj_invalidate_iter Lancelot SIX via Gdb-patches
2022-08-05 15:03   ` Tom de Vries via Gdb-patches
2022-08-04 13:02 ` [PATCH 2/3] gdb/varobj: Reset varobj after relocations have been computed Lancelot SIX via Gdb-patches
2022-08-09 10:55   ` Tom de Vries via Gdb-patches [this message]
2022-08-04 13:02 ` [PATCH 3/3] gdb/varobj: Only re-evaluate invalid globals during re_set Lancelot SIX via Gdb-patches
2022-08-09 10:55   ` Tom de Vries via Gdb-patches
2022-08-11 14:07     ` Lancelot SIX 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=3956798c-7ab8-90f5-e0fb-cfc7d9d00834@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