From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id C0214385841F for ; Tue, 17 Oct 2023 14:48:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C0214385841F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C0214385841F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697554115; cv=none; b=vMxcdgtbDAagwYXVAFy8zRcULhJ0R8lm9IzGdB/szwBBgtSqhTtr2eAeSlO/udfHMmmTNDZuRELbrxLle63bK2E1Sskl/Mq2k6ckAlAhA/wQ6L3pM/84Mq+xKjabLD2ozqVNMfToQDigDDoha//Q9ObFevEF9JsuZGdbaMLy7HI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697554115; c=relaxed/simple; bh=CRVZpB+FOtlvbtX+UACT09dAeQKAe00roeKcoGE9Zz0=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=hQznTkmPuKdd1eSusMZ4kurOEv5EjPLnkLRjs/dAYY8DUh5PkpuTfgGqIKje6Oseme0hX5PccIseQBiLMNhRhgQeH104S0Ebak9+heaHIn9mYxiXQtIUjVegjFKREBdz+6LTqOBnT29Wxod44BOs2KPD2FwCI7QER0Tn4dry11A= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1697554105; bh=CRVZpB+FOtlvbtX+UACT09dAeQKAe00roeKcoGE9Zz0=; h=Date:Subject:To:References:From:In-Reply-To:From; b=cKZpFLw17Jags/Rc25qrCg1nkte7FR6bCUi1PVEiERkjmxAYFeWpyiAkEUBC2D0iH PM1dmkPcwJ3l5uo6XOFfUsutN/aUjWV/Vk1AlITtY7+EgVns+U1C6Vs9VI2T2RWvsH 6RRnk8Xsv42+3561ur7qJQeW5UscYrVMcyhJ3wBQ= Received: from [172.16.0.192] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 17E241E00F; Tue, 17 Oct 2023 10:48:25 -0400 (EDT) Message-ID: <0a223be2-f3c8-4cf1-90ea-1084232622ea@simark.ca> Date: Tue, 17 Oct 2023 10:48:24 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb/testsuite/gdb.rocm: Fix incorrect use of continue N in multi-inferior-gpu.exp Content-Language: fr To: Lancelot SIX , gdb-patches@sourceware.org References: <20231017111629.307261-1-lancelot.six@amd.com> <6e3b93f0-f9b1-4e92-aa8b-65ee0d56ebc1@simark.ca> <60a7f9cd-3c64-4100-9334-5879db42a62a@amd.com> From: Simon Marchi In-Reply-To: <60a7f9cd-3c64-4100-9334-5879db42a62a@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 10/17/23 10:41, Lancelot SIX wrote: > >> On 10/17/23 07:16, Lancelot Six wrote: >>> The gdb.rocm/multi-inferior-gpu.exp testcase uses a "continue $thread" >>> command, but this is incorrect. If "continue" is given an argument, it >>> sets the ignore count of the breakpoint the thread stopped at. >>> >>> For this testcase it does not really matter since the breakpoint is not >>> meant to be hit anymore, so whatever the ignore count is won't influence >>> the outcome of the test. It is worth fixing nevertheless. >>> >>> While at changing it, switch to using "continue&" to consume the GDB >>> prompt right away. This makes the following pattern matching more >>> reliable. >> >> I don't understand the "more reliable" part, can you explain? >> >> Simon > > There will be a "(gdb) " prompt appearing at some point after a "continue", but in non-stop we don't really control when it appears (if I understand correctly). It seems that other non-stop tests use the "&" variant and consume the prompt immediately. > > With this, before the next command is issued, we know that 1) we got a prompt and 2) we have seen the process we just released finish. > > Overall, I am mostly trying to follow patterns I caught in other non-stop tests. Ah, I missed that we were in non-stop. If we run a single thread at a time, I think it will be reliable to use the sync variant of continue. Using the async variant is useful when you resume multiple threads and expect multiple events (like breakpoint hits) which can happen in any order. At least that's my understanding. Simon