From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 14kkONuuSWHqKgAAWB0awg (envelope-from ) for ; Tue, 21 Sep 2021 06:07:23 -0400 Received: by simark.ca (Postfix, from userid 112) id D2F2C1EE25; Tue, 21 Sep 2021 06:07:23 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 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 1ECA31EDDB for ; Tue, 21 Sep 2021 06:07:23 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A768B3858412 for ; Tue, 21 Sep 2021 10:07:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A768B3858412 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1632218842; bh=S4IidZ7MIxdr3Gj7wdD7nQk6yNiaGar7upPgU1tcv4E=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=E+1CMP/6TExZLCvVceSuHM3+WuFTU/MrNc+yvvk5dr/acnwm4rmt8hz682Np6wgCv lRdvJi5+vA3u+iRuH5xUAhqUTBJmUny74UXscXQQuXOvkNiKHxcK59Q+/ADPj+NxxP jNZa5NPwf8k2BgnywYu6fFOolAos0FNlvQldkdUQ= Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 8B2823858C3A for ; Tue, 21 Sep 2021 10:07:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8B2823858C3A 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-out2.suse.de (Postfix) with ESMTPS id B2AD81FD61 for ; Tue, 21 Sep 2021 10:07:03 +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 9AA4113BC2 for ; Tue, 21 Sep 2021 10:07:03 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id qGykIceuSWFHUwAAMHmgww (envelope-from ) for ; Tue, 21 Sep 2021 10:07:03 +0000 Date: Tue, 21 Sep 2021 12:07:01 +0200 To: gdb-patches@sourceware.org Subject: [committed][gdb/testsuite] Handle supports_memtag in gdb.base/gdb-caching-proc.exp Message-ID: <20210921100655.GA21585@delia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) 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 Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi, In test-case gdb.base/gdb-caching-proc.exp, we run all procs declared with gdb_caching_proc. Some of these require a gdb instance, some not. We could just do a clean_restart every time, but that would amount to 44 gdb restarts. We try to minimize this by doing this only for the few procs that need it, and hardcoding those in the test-case. For those procs, we do a clean_restart, execute the proc, and then do a gdb_exit, to make sure the gdb instance doesn't linger such that we detect procs that need a gdb instance but are not listed in the test-case. However, that doesn't work in the case of gnat_runtime_has_debug_info. This proc doesn't require a gdb instance because it starts its own. But it doesn't clean up the gdb instance, and since it's not listed, the test-case doesn't clean up the gdb instance eiter. Consequently, the proc supports_memtag (which should be listed, but isn't) uses the gdb instance started by gnat_runtime_has_debug_info rather than throwing an error. Well, unless gnat_runtime_has_debug_info fails before starting a gdb instance, in which case we do run into the error. Fix this by: - doing gdb_exit unconditionally - fixing the resulting error by adding supports_memtag in the test-case to the "needing gdb instance" list Tested on x86_64-linux. Committed to trunk. Thanks, - Tom [gdb/testsuite] Handle supports_memtag in gdb.base/gdb-caching-proc.exp --- gdb/testsuite/gdb.base/gdb-caching-proc.exp | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/gdb/testsuite/gdb.base/gdb-caching-proc.exp b/gdb/testsuite/gdb.base/gdb-caching-proc.exp index 82675dfc061..a3f08f5db32 100644 --- a/gdb/testsuite/gdb.base/gdb-caching-proc.exp +++ b/gdb/testsuite/gdb.base/gdb-caching-proc.exp @@ -85,6 +85,7 @@ proc test_file { file } { switch $procname { "is_address_zero_readable" { set setup_gdb 1 } "target_is_gdbserver" { set setup_gdb 1 } + "supports_memtag" { set setup_gdb 1 } default {set setup_gdb 0 } } @@ -94,9 +95,7 @@ proc test_file { file } { test_proc $procname - if { $setup_gdb } { - gdb_exit - } + gdb_exit } } }