From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id CA3F038582A7 for ; Tue, 2 Aug 2022 15:45:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CA3F038582A7 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 088A734D88; Tue, 2 Aug 2022 15:45:31 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id E3B8A1345B; Tue, 2 Aug 2022 15:45:30 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id NqZ3NppG6WKsGAAAMHmgww (envelope-from ); Tue, 02 Aug 2022 15:45:30 +0000 Message-ID: Date: Tue, 2 Aug 2022 17:45:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 2/2] gdb/testsuite: Accept PIE/noPIE programs in gdb.mi/mi-var-invalidate-shlib.exp Content-Language: en-US To: Lancelot SIX , gdb-patches@sourceware.org Cc: lsix@lancelotsix.com References: <20220802124724.284096-1-lancelot.six@amd.com> <20220802124724.284096-3-lancelot.six@amd.com> From: Tom de Vries In-Reply-To: <20220802124724.284096-3-lancelot.six@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2022 15:45:33 -0000 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