From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id gFT1HIjD62KWlSAAWB0awg (envelope-from ) for ; Thu, 04 Aug 2022 09:03:04 -0400 Received: by simark.ca (Postfix, from userid 112) id 73BB31EA05; Thu, 4 Aug 2022 09:03:04 -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=AOgSR9Yh; 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=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,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 11B411E9EB for ; Thu, 4 Aug 2022 09:03:04 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 07105385C017 for ; Thu, 4 Aug 2022 13:03:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 07105385C017 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1659618182; bh=CIciMWhiOrxZH13r6NAV1w/j4eT2fpC34rs/c/itJlo=; 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=AOgSR9YhGXA3Na2SlIYh/KH8lQ/rtYLOf2AGCF0pgqNj+dS5dLp8C3CFuI2L/P2AB 0+7kIGgLbePgFk0LH6FD3sBhtl3b1r0I3q3pyrC0eImrwMnokCPPGVM9kKWclZQJ/K zP6/sHhsREmsoUNvzc4zrArvH5LzyhZdRkGUFaig= Received: from lndn.lancelotsix.com (lndn.lancelotsix.com [51.195.220.111]) by sourceware.org (Postfix) with ESMTPS id 62C943857025 for ; Thu, 4 Aug 2022 13:02:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 62C943857025 Received: from octopus.. (unknown [IPv6:2a01:e0a:535:2750:508f:a0d5:5691:a9a3]) by lndn.lancelotsix.com (Postfix) with ESMTPSA id E140A89878; Thu, 4 Aug 2022 13:02:40 +0000 (UTC) To: gdb-patches@sourceware.org Subject: [PATCH 3/3] gdb/varobj: Only re-evaluate invalid globals during re_set Date: Thu, 4 Aug 2022 14:02:31 +0100 Message-Id: <20220804130231.2126565-4-lancelot.six@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220804130231.2126565-1-lancelot.six@amd.com> References: <20220804130231.2126565-1-lancelot.six@amd.com> MIME-Version: 1.0 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]); Thu, 04 Aug 2022 13:02:41 +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" When doing varobj_re_set, we currently try to recreate floating varobj. This was introduced by 4e969b4f0128 "Re-evaluate floating varobj as part of varobj_invalidate" to deal with use a after free issue. However since bc20e562ec0 "Fix use after free in varobj" we now ensure that we never have dangling pointers so this all recreation is not strictly needed anymore for floating varobjs. This commit proposes to remove this recreation process for floating varobjs. Tested on x86_64-linux. --- gdb/testsuite/gdb.mi/mi-var-invalidate.exp | 4 ++-- gdb/varobj.c | 18 +++++------------- 2 files changed, 7 insertions(+), 15 deletions(-) diff --git a/gdb/testsuite/gdb.mi/mi-var-invalidate.exp b/gdb/testsuite/gdb.mi/mi-var-invalidate.exp index 1b2c68df18e..348515671c1 100644 --- a/gdb/testsuite/gdb.mi/mi-var-invalidate.exp +++ b/gdb/testsuite/gdb.mi/mi-var-invalidate.exp @@ -75,8 +75,8 @@ mi_runto_main # Change format of floating variable immediately after reload reveals a # bug where gdb still uses a free'd pointer. mi_gdb_test "-var-set-format float_simple hexadecimal" \ - "\\^done,format=\"hexadecimal\",value=\"\\\[-1\\\]\"" \ - "set format variable float_simple" + "\\^done,format=\"hexadecimal\",value=\"\\\[3\\\]\"" \ + "set format variable float_simple" # Check local variable is "invalid". mi_gdb_test "-var-update linteger" \ diff --git a/gdb/varobj.c b/gdb/varobj.c index 55a7bd97f43..d3df608c55f 100644 --- a/gdb/varobj.c +++ b/gdb/varobj.c @@ -2359,29 +2359,21 @@ all_root_varobjs (gdb::function_view func) static void varobj_re_set_iter (struct varobj *var) { - /* Invalidated globals and floating var must be re-evaluated. */ - if (var->root->global || var->root->floating) + /* Invalidated global varobjs must be re-evaluated. */ + if (!var->root->is_valid && var->root->global) { struct varobj *tmp_var; /* Try to create a varobj with same expression. If we succeed - replace the old varobj, otherwise invalidate it. */ + and have a global replace the old varobj. */ tmp_var = varobj_create (nullptr, var->name.c_str (), (CORE_ADDR) 0, - var->root->floating - ? USE_SELECTED_FRAME : USE_CURRENT_FRAME); - if (tmp_var != nullptr) + USE_CURRENT_FRAME); + if (tmp_var != nullptr && tmp_var->root->global) { - gdb_assert (var->root->floating == tmp_var->root->floating); tmp_var->obj_name = var->obj_name; varobj_delete (var, 0); install_variable (tmp_var); } - else if (var->root->global) - { - /* Only invalidate globals as floating vars might still be valid in - some other frame. */ - var->root->is_valid = false; - } } } -- 2.34.1