From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id WtS8HAod6WLaEx8AWB0awg (envelope-from ) for ; Tue, 02 Aug 2022 08:48:10 -0400 Received: by simark.ca (Postfix, from userid 112) id 68B0E1EA05; Tue, 2 Aug 2022 08:48:10 -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=uqdad7d8; 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,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.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 6B73C1EA03 for ; Tue, 2 Aug 2022 08:48:09 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 87CA7385274A for ; Tue, 2 Aug 2022 12:48:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 87CA7385274A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1659444488; bh=XImEpE6PhbdMQqJ0KlRWLWXDrYM89xmPD3f3m6IEgJQ=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=uqdad7d8x00rnmS2xe1WaokIRKs8Bt76EtfSF/Dez5AjzEaiKA+kh3VL1lLbfRrLQ KEW3Xm2kaIuydPLO+umABUDg1yatqaFz/w3XmMLepyw+1hMqp32mfW0qyndHVIF9DT hLLC2coAwoqd18xT5C/sB9X/AAhjvuyLIBDaG5pk= Received: from lndn.lancelotsix.com (vps-42846194.vps.ovh.net [IPv6:2001:41d0:801:2000::2400]) by sourceware.org (Postfix) with ESMTPS id 8F0D23856242 for ; Tue, 2 Aug 2022 12:47:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8F0D23856242 Received: from octopus.. (unknown [IPv6:2a01:e0a:535:2750:1299:7061:a63:c92]) by lndn.lancelotsix.com (Postfix) with ESMTPSA id 525DC8980E; Tue, 2 Aug 2022 12:47:46 +0000 (UTC) To: gdb-patches@sourceware.org Subject: [PATCH 2/2] gdb/testsuite: Accept PIE/noPIE programs in gdb.mi/mi-var-invalidate-shlib.exp Date: Tue, 2 Aug 2022 13:47:24 +0100 Message-Id: <20220802124724.284096-3-lancelot.six@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220802124724.284096-1-lancelot.six@amd.com> References: <20220802124724.284096-1-lancelot.six@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (lndn.lancelotsix.com [0.0.0.0]); Tue, 02 Aug 2022 12:47:46 +0000 (UTC) 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: Lancelot SIX via Gdb-patches Reply-To: Lancelot SIX Cc: lsix@lancelotsix.com, Lancelot SIX Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29426 --- gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp b/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp index 87d1d4a6a9d..d44b492ae6b 100644 --- a/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp +++ b/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp @@ -103,7 +103,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=\\\[({name=\"global_var\",in_scope=\"true\",type_changed=\"false\",has_more=\"0\"})?\\\]" \ "global_var recreated" mi_gdb_test "-var-update global_shlib_var" \ "\\^done,changelist=\\\[{name=\"global_shlib_var\",in_scope=\"invalid\",has_more=\"0\"}\\\]" \ -- 2.34.1