From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta34.uswest2.a.cloudfilter.net (omta34.uswest2.a.cloudfilter.net [35.89.44.33]) by sourceware.org (Postfix) with ESMTPS id 9203E3865C11 for ; Wed, 22 May 2024 15:38:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9203E3865C11 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9203E3865C11 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=35.89.44.33 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716392341; cv=none; b=OyCiecICZJ0zHG6GXs9TrOwkrzH12KlR2bEEc3PCuFdeb42vW/46Pegj8lCjq3qhLizKWQ2N3T27nGwUHzZANBwtsg/rn1V93KvAOY+0vl+kVtTCTKUontQILw8Dlf/H/PDGxioEI7o6CZWHCSSXhdOoWoBgFQcRtYRekGfoQzM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716392341; c=relaxed/simple; bh=jrIjn6M8SaUKIUTCcDKhIqLotSdKr+YoDUYEpg1TWFE=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=jEOLOIRGIWCV3ev2YXWo//vIUJP/8y6TPJ6ck02B8sz/bYEoyuHP7UJa4l36txpuyOJLfcgIORusaCLdVEgUw7yP8vdzIBkMORio9KBBpWCQEohSnPtQQgkqNGwbx5/RKVvhSVcPsxy2piza53sa+VK0yGo4ZF6pWWOGrs3VJXE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from eig-obgw-5002a.ext.cloudfilter.net ([10.0.29.215]) by cmsmtp with ESMTPS id 9gtHs6Eo0ezZ49o3OsL09P; Wed, 22 May 2024 15:38:58 +0000 Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTPS id 9o3NsFTaor1If9o3Os5v30; Wed, 22 May 2024 15:38:58 +0000 X-Authority-Analysis: v=2.4 cv=BawT0at2 c=1 sm=1 tr=0 ts=664e1192 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=TpHVaj0NuXgA:10 a=Qbun_eYptAEA:10 a=H2PDYelqagCDyiCtqBgA:9 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=7jQorX1QJvzthuztA5zYVFzMtJsTu5v3QRxtySs5tM0=; b=ghpC7jsuGz3KGIKnz0Um8bdEll GSN25oiyz812Bz4p088OVPpBcUbo8OeTv7F6oOnE0ohqOdy7+sob9OBMANyCux+pIqPO1WUAdVnzS inVQamclWu+R+Is5dY9adbigd; Received: from 75-166-134-4.hlrn.qwest.net ([75.166.134.4]:46336 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from ) id 1s9o3N-001YTg-0f; Wed, 22 May 2024 09:38:57 -0600 From: Tom Tromey To: Tom de Vries Cc: Thiago Jung Bauermann , Pedro Alves , gdb-patches@sourceware.org, Christophe Lyon Subject: Re: [PATCH v2 3/5] gdb/testsuite: Add gdb.arch/aarch64-mops-watchpoint.exp In-Reply-To: <2582ba11-c8b7-428c-a36f-b7504121608c@suse.de> (Tom de Vries's message of "Wed, 22 May 2024 11:22:43 +0200") References: <20240507022249.554831-1-thiago.bauermann@linaro.org> <20240507022249.554831-4-thiago.bauermann@linaro.org> <42b9869a-2012-4657-bae4-e8e2bb3a89a4@palves.net> <878r02vpw1.fsf@linaro.org> <2582ba11-c8b7-428c-a36f-b7504121608c@suse.de> X-Attribution: Tom Date: Wed, 22 May 2024 09:38:56 -0600 Message-ID: <878r01ua9b.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 75.166.134.4 X-Source-L: No X-Exim-ID: 1s9o3N-001YTg-0f X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 75-166-134-4.hlrn.qwest.net (murgatroyd) [75.166.134.4]:46336 X-Source-Auth: tom+tromey.com X-Email-Count: 6 X-Org: HG=bhshared;ORG=bluehost; X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfONB8AqIvU7ncUYIc2aomP8E7i7ftIrmJ9cEpSZ940pTruMCXQtNZUUfQSmksJaz64PgCirwjpjik9JvFSXwcpHoElYe59sWVQLubcddoZ7FNMYrOCJQ N6lTuDXhar8GF5q1xyM8ZkEK/laskTBFQfTDYUkUYt5XTvLSAHh4xUsY5WY8OVb70ygjLxylOxeZYPrA+Pyaon0k5OSu2QFbicU= X-Spam-Status: No, score=-3014.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,JMQ_SPF_NEUTRAL,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: >>>>> "Tom" == Tom de Vries writes: Tom> - obviously, using a gdb_exit in a proc results in trouble if the proc Tom> is called at a point in the test-case where we don't want a gdb_exit Tom> - using a gdb_exit in a caching proc may or may not result in trouble if Tom> the proc is called at a point in the test-case where we don't want Tom> gdb_exit. Whether we run into trouble depends on whether the result Tom> of the proc is already cached or not. This behaviour is undesirable. I didn't really follow this thread, but I tend to think that caching procs should be in two categories: those that require gdb to already be running, and those that are standalone. Having a proc like this call gdb_exit seems like a recipe for some confusion, to me. Even having one start a new gdb seems like trouble, since IIRC that's hard to do without introducing new test results, but the nature of a caching proc is that the test names would then depend on which process wins the race to run it first. I've thought sometimes about adding some mechanism to enforce this split. Tom