Message ID | 20231017111629.307261-1-lancelot.six@amd.com |
---|---|
State | New |
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 712CB3858426 for <patchwork@sourceware.org>; Tue, 17 Oct 2023 11:17:02 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2061.outbound.protection.outlook.com [40.107.223.61]) by sourceware.org (Postfix) with ESMTPS id D6EBD3858D33 for <gdb-patches@sourceware.org>; Tue, 17 Oct 2023 11:16:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D6EBD3858D33 Authentication-Results: sourceware.org; dmarc=fail (p=quarantine dis=none) header.from=amd.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=amd.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D6EBD3858D33 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.223.61 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1697541409; cv=pass; b=sERSNnSkAafLEw9oSrw9EQqdpwRyIVHFHAS8dpGrGzixHrv/ZBJm+l1tQA8V0bATgJdBaTCRGSZMkzjLZ6kJFYa/mzjpymCSXvZiksiTHn43HloWffHCPIbiwdq60bQRa0p6XginGuAdUiDvM6HXgx7ge3Aa3lQW4GkhJC6es5M= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1697541409; c=relaxed/simple; bh=tH6mDWmZvJL0IpmKQLrGJroy783fvyjm7o0miOsgSXQ=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=LZsMCedfGhbLD2AHBimaNq27SEMcTKSKXlBymUkPpk5YllwUtFUTSRpxGPehRxpRhaxquLXeB12mnHYal2/1bTo43RzkZk2Ak36H/g/m9xBlUaqsS42AMksZj+QZVrYp8Ha0Qv+m5eg35yYUaPLpBCnN63F13EWJ89/+kpAj0fQ= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O5rcwK0+A2y+Wj4srVZWfv669abVibP0Dhb/oyG8Nmv+rWJMkFNccpMbm77yZ/qnqJisWucLw2o8oUk6JasOcI0exz9lhg5cZgnhGTaStmz4GzayTiggutGjGKNO6x70LjEonJvDCmPC+iWB9zvWWtWg2QtyFnjsZsPy0+UqFA5RtuozlHxum7gbDbDgE7gGBsDY2/gSRkOd+3MsqOOIt99XNdlb82kBv7xn+NfLBvZT8KefgVXHZKYmKsm8LDM7VrUnSncFJ+oIedZSu/Y4qWStNaGrxWYlje1hqw4sXCWP27mHCMFqY0vF9e9RoZAL9KpozhRQLM+1oQu4iRyu6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6SaD7rcYQbSRrWVBUn9BuqtMcD+jemv6ijz6cjlJ8lg=; b=aLCa1J/BDlZXrKb9aXL/lmnXh6ogH5SHPLCdhmse/mnnF57V1PxwkB3Y051Af9/jDf7gE3VasL8DzfvRZznNZBN99c0g8rxXBVGSDvDMy2aRrLMvFxho70h68d4wxGpUxgroX4LUOVxWW3LeFemQyLLLJYI+WVvggTZ1pOTlYO33tq6RuKFeN4cdN+iFH7rnvuyQK/kvMJNw6DplTzjIAA4LXfN197Q6NPkGQmq47dYLqK0AaZD1xh1uQYHdS9vZ2xNf9lIezCMZq9ZLKlCp0fFu0M5KfxS6hz1gfhE7tnF2EIheTgBvrf1jsHHwNtAfqZlYih71E28mIqZxj9fv+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=sourceware.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6SaD7rcYQbSRrWVBUn9BuqtMcD+jemv6ijz6cjlJ8lg=; b=AU2Qt689ocHFiJSU0kWZfijH9bg/zZkfcuBueEQYWo16dzCvt4jv5PN9OMdtrrgj2SS62jjkeyuBPtzJBlutIpZQFwud4NN1rgfAWpXfWY8RbyqKVOBHobiK2QWjB+8gCN7n3KPSzcPUiwMVsLZR0cYAF0Hug7v4BZaqtD3WmlI= Received: from PR1P264CA0196.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:34d::7) by MW4PR12MB6729.namprd12.prod.outlook.com (2603:10b6:303:1ed::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6886.35; Tue, 17 Oct 2023 11:16:43 +0000 Received: from SN1PEPF0002BA50.namprd03.prod.outlook.com (2603:10a6:102:34d:cafe::a3) by PR1P264CA0196.outlook.office365.com (2603:10a6:102:34d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6886.35 via Frontend Transport; Tue, 17 Oct 2023 11:16:42 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by SN1PEPF0002BA50.mail.protection.outlook.com (10.167.242.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6907.20 via Frontend Transport; Tue, 17 Oct 2023 11:16:42 +0000 Received: from hpe6u-23.amd.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Tue, 17 Oct 2023 06:16:41 -0500 From: Lancelot Six <lancelot.six@amd.com> To: <gdb-patches@sourceware.org> CC: Lancelot Six <lancelot.six@amd.com> Subject: [PATCH] gdb/testsuite/gdb.rocm: Fix incorrect use of continue N in multi-inferior-gpu.exp Date: Tue, 17 Oct 2023 11:16:29 +0000 Message-ID: <20231017111629.307261-1-lancelot.six@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF0002BA50:EE_|MW4PR12MB6729:EE_ X-MS-Office365-Filtering-Correlation-Id: 66ab22cd-37cc-4195-705c-08dbcf028a5c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +blHYVl5XzHlmcFJ5l+ttzMy7k16ZK/khXEkza0h8/7XhwBFcECPimCNY9oVbylYMra8zEjng7qGl0zaei2uPoXrf4zxTYudYyEHNDpVH1joehDEWlslJUL23YXFXCbsfgAD28ekhnsBkQocWYUzeI4QvJWRMnwa3LZj+prGpj7wvsU0Nd6d5QpmNFefYI2ARKo2zVBsr6xnmgCVeoQF0tDaHI2LaD4WI+uhatPn/VcC6A6wRmDnFqzJvE0FKl/pqZZf2RKU+K9fvrn9w1V3sf7ELb/MmdYrW3Ui4tfTfyCZio2A/ptG02R2R824LiPVaQ6/gvMLl40sG5tggfM03h5wqui73XKCrS9kWigX6lpMGu3M7u5kSptZYWw3etIM75qWj0ZE2BBRicmBPHnGlGboqZDF2CcBZB/wwhr9OiX8gMh/a3U7kynQrXJRv8xzhbKyOXee2Y0EmLmnpmN0Pq8flVi7un6sOy2LNASIiumGyUMf+zWbZF5z326kGJuV+K36mL1P2FiYWt7bhthsBb19wrCzzuPwv1HXCXVFAFA3zP3Pvc/dnp8wHn9wdJDOvUu+d+cS8WqsLJbt8+NtnvcFphA9kCYY3R/UW8jiFzJRtUxLJEg68bSHsBTG3t69qkNbplCx1Ytf/kdXCCZYmxiXMAESOqonNJFfywKR326nR0AtTmoVLsrWH5VBVeQk5lyUq7scVQnxzfQfgsjLqOCrvlGtrelBRrhQJgnOKeoC1L3mkJqGt4bnoFUTiRY4 X-Forefront-Antispam-Report: CIP:165.204.84.17; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:SATLEXMB04.amd.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230031)(4636009)(136003)(346002)(376002)(39860400002)(396003)(230922051799003)(64100799003)(451199024)(1800799009)(186009)(82310400011)(36840700001)(40470700004)(46966006)(84970400001)(86362001)(36756003)(40480700001)(26005)(40460700003)(478600001)(2906002)(7696005)(44832011)(5660300002)(81166007)(41300700001)(82740400003)(356005)(6666004)(2616005)(36860700001)(1076003)(16526019)(336012)(426003)(316002)(70206006)(8936002)(8676002)(6916009)(70586007)(4326008)(83380400001)(47076005)(36900700001); DIR:OUT; SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Oct 2023 11:16:42.0786 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 66ab22cd-37cc-4195-705c-08dbcf028a5c X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d; Ip=[165.204.84.17]; Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SN1PEPF0002BA50.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB6729 X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FORGED_SPF_HELO, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, 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 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org |
Series |
gdb/testsuite/gdb.rocm: Fix incorrect use of continue N in multi-inferior-gpu.exp
|
|
Checks
Context | Check | Description |
---|---|---|
linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 | success | Testing passed |
linaro-tcwg-bot/tcwg_gdb_build--master-arm | success | Testing passed |
linaro-tcwg-bot/tcwg_gdb_check--master-arm | success | Testing passed |
linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 | success | Testing passed |
Commit Message
Lancelot SIX
Oct. 17, 2023, 11:16 a.m. UTC
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. Change-Id: I0eb674d5529cdeb9e808b74870a29b6077265737 --- gdb/testsuite/gdb.rocm/multi-inferior-gpu.exp | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
Comments
Hi, > diff --git a/gdb/testsuite/gdb.rocm/multi-inferior-gpu.exp b/gdb/testsuite/gdb.rocm/multi-inferior-gpu.exp > index 18b4172ff09..958b70e6df1 100644 > --- a/gdb/testsuite/gdb.rocm/multi-inferior-gpu.exp > +++ b/gdb/testsuite/gdb.rocm/multi-inferior-gpu.exp > @@ -68,8 +68,10 @@ proc do_test {} { > foreach thread $stopped_gpu_threads { > set infnumber [lindex [split $thread .] 0] > gdb_test "thread $thread" "Switching to thread.*" > - gdb_test_multiple "continue $thread" "" { > - -re "\\\[Inferior $infnumber \[^\n\r\]* exited normally\\]\r\n$::gdb_prompt " { > + # Continue this thread, and consime the prompt ^ There is a typo here. I have fixed it locally. Best, Lancelot. > + gdb_test "continue&" "" "continue GPU thread in $infnumber" > + gdb_test_multiple "" "wait for inferior $infnumber" { > + -re "\\\[Inferior $infnumber \[^\n\r\]* exited normally\\\]\r\n" { > pass $gdb_test_name > } > }
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
> 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. Best, Lancelot.
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
On 17/10/2023 15:48, Simon Marchi wrote: > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. > > > 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 OK, if you find it is overdoing it, I'll revert this part of the patch and submit a V2 shortly. Thanks, Lancelot.
diff --git a/gdb/testsuite/gdb.rocm/multi-inferior-gpu.exp b/gdb/testsuite/gdb.rocm/multi-inferior-gpu.exp index 18b4172ff09..958b70e6df1 100644 --- a/gdb/testsuite/gdb.rocm/multi-inferior-gpu.exp +++ b/gdb/testsuite/gdb.rocm/multi-inferior-gpu.exp @@ -68,8 +68,10 @@ proc do_test {} { foreach thread $stopped_gpu_threads { set infnumber [lindex [split $thread .] 0] gdb_test "thread $thread" "Switching to thread.*" - gdb_test_multiple "continue $thread" "" { - -re "\\\[Inferior $infnumber \[^\n\r\]* exited normally\\]\r\n$::gdb_prompt " { + # Continue this thread, and consime the prompt + gdb_test "continue&" "" "continue GPU thread in $infnumber" + gdb_test_multiple "" "wait for inferior $infnumber" { + -re "\\\[Inferior $infnumber \[^\n\r\]* exited normally\\\]\r\n" { pass $gdb_test_name } }