From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id EECTDbBG6WKCKR8AWB0awg (envelope-from ) for ; Tue, 02 Aug 2022 11:45:52 -0400 Received: by simark.ca (Postfix, from userid 112) id 350A01EA05; Tue, 2 Aug 2022 11:45:52 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=n4xf0xWr; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C2E481EA03 for ; Tue, 2 Aug 2022 11:45:51 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4AAD53852745 for ; Tue, 2 Aug 2022 15:45:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4AAD53852745 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1659455151; bh=JqdgIsCn0E2O3Ub84eiiOEF58yxgJCg/+pHr1XJS8ZA=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=n4xf0xWrreNkcJZYZ5BO5Y+ypd4ekAhsWsuOiyI4WbfpmuDO4eOrX8ZHNh2jAIYlz 3QrLCGPzVutRxB7blmCm2RCf7VJJwPwzZ6Xcppt2LKOUHKRvu7H8vugbLwsBxO7yMm w9ReyA9naI7MIRoowaq5w7PFPeCFiJJNmIPA0K1Q= 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 References: <20220802124724.284096-1-lancelot.six@amd.com> <20220802124724.284096-3-lancelot.six@amd.com> In-Reply-To: <20220802124724.284096-3-lancelot.six@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: , From: Tom de Vries via Gdb-patches Reply-To: Tom de Vries Cc: lsix@lancelotsix.com Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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