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/2] gdb/testsuite: Accept PIE/noPIE programs in gdb.mi/mi-var-invalidate-shlib.exp
Date: Tue, 2 Aug 2022 17:45:30 +0200	[thread overview]
Message-ID: <f53bcf57-b887-348a-79a3-24345141d2f9@suse.de> (raw)
In-Reply-To: <20220802124724.284096-3-lancelot.six@amd.com>

On 8/2/22 14:47, Lancelot SIX wrote:
> 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 changes the testcase to accept both behaviors.

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

  reply	other threads:[~2022-08-02 15:45 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 [this message]
2022-08-03  9:35     ` Six, Lancelot via Gdb-patches
2022-08-03 11:51       ` Tom de Vries via Gdb-patches
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=f53bcf57-b887-348a-79a3-24345141d2f9@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