From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id tQvkCIuSAmagnhYAWB0awg (envelope-from ) for ; Tue, 26 Mar 2024 05:16:59 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=epY6u9Kq; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 08C601E0C0; Tue, 26 Mar 2024 05:16:59 -0400 (EDT) Received: from server2.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 ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5B6171E030 for ; Tue, 26 Mar 2024 05:16:56 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6F89F385840B for ; Tue, 26 Mar 2024 09:16:55 +0000 (GMT) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) by sourceware.org (Postfix) with ESMTPS id BF4253858C56 for ; Tue, 26 Mar 2024 09:16:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BF4253858C56 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BF4253858C56 Authentication-Results: server2.sourceware.org; arc=fail smtp.remote-ip=192.198.163.14 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1711444591; cv=fail; b=AEWBlEZiFBMncIofOE8X755UgjcUs01Ybq9/bw9sowe/H6GjcdrLCFGAPK024M0TeXtR4UYrqUGj06tnQ76+WpikJBkU3q/QPlXLA4yN55BPwi3fSaVsKIbsk8hbD5lPamw825F/Vil6QH8yTblz57ZPgbdgbv4/sC8Ul4kt3xk= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1711444591; c=relaxed/simple; bh=mHr5wIwl+SO3GYcBOwQYZe0zU8g0GBKRXSw7a42i4TE=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=qSUQKy7TBGOzhERdYuCBB9Q6SK/5XUtCGjPtEWj1M9OYI+WDDZpQdEm+KMaTxPvm5psgG5Ma5xRffDAE3ulAp8ZqPxBNn0lxiFu5y+aMMqVXPMYhgC2czs4FQfgGwgVYeTqIzTAFkITDOFQ05jZ+DcpzPSNDlm2ufz4+de0e4f0= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1711444588; x=1742980588; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=mHr5wIwl+SO3GYcBOwQYZe0zU8g0GBKRXSw7a42i4TE=; b=epY6u9Kq/vncrsnonqSad7qlNapQrKS62CwuJqq1XhaiFwBSty69rjBY fjqPLlUb7afyKVtO6Wr3lzgnbEpcn6SkvXCzWItUDMFxC6ICie5ZkL0KW 4z6xkuC0/ge3rnAcyFcKG/8hLEZUtK0hIRzeQS9iCG7NJ9tNMi6eX7q4O dkMO2duK8MkrvNkxLwR8tqvX32lp/pM8r2VtUA7d9cLmWm+BkdM+oxmm9 pr+kWAwb6o6JV0kqnS1dqOE+6NVwRE2vK18VFX3fjM+fp6JBoXtX8Bwbu M1imX8qSalRVsAqMM01GOfo0KX4yZOvPfFohISF39fUsAjURFZhpDab/0 w==; X-IronPort-AV: E=McAfee;i="6600,9927,11024"; a="6695695" X-IronPort-AV: E=Sophos;i="6.07,155,1708416000"; d="scan'208";a="6695695" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2024 02:16:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,155,1708416000"; d="scan'208";a="20462424" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmviesa003.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 26 Mar 2024 02:16:23 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar 2024 02:16:22 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Mar 2024 02:16:22 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Tue, 26 Mar 2024 02:16:22 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.40) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Tue, 26 Mar 2024 02:16:22 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ld2XvCQE5OIyuQpi4qmhECYEZHtcniRsgC+/Kksg29LUin2hMIZpytNuw2FDZEpvO8ngzIEzdN1IUQBeDGKDnIzNk5EcWtp1TsEuOBtDyDZSci7cCCPl4Zh4cBTjNmJIeOXc3VO1JJfAVeICgp8bww3B0p8P/sywQPyCJBfS+gnv55TfLRDPB8VN9Sgjbvwd0qlXAJ68BEMckafxdDpvGAbLHGuRvmYJtHRtE29geyzTAxxbJohm8uniilL/CvXN0kd9emJUCPAIocXhVZZ83wyGFNzPMz5Im8UT67oGrBUisDnJf0WJD4eipPq0AqIoGBtVyTGX7W93CmT0Dm4LAA== 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=3qlOCUEO/BnvkJdpvCFEtyBnrbf1ECbb9kJjALQhp3Q=; b=i4j3Ld4cQT9Mxt0+22WJOXbiHN/uaiiJ9iqKmjD8baU4oQsV0nXomBXebeQTDVuYdKZffKP6m7+pz/YzAxb2yvSxp/k8s7XiVPddffU+pX7cGgctrY9mFb+b0UF8DlP/WRZDZD9JLZ4UD7DsEi0B/b2rux7CvCpXpSi0AR+UfXvLkFXdWxarpBX1uj9wIfvecVl6Ho9VMGnByHMPzZHrmXswQQONxBXFJNZH8cBszbZjLNiIy6q4gMdHOZCdRvpyfH/asLHZWgc1n6C81OG05VNvL+82DJCkZLpGHlSgul+aCGU5L3ZWLLZDkVuFMtOXmMqd3AFOhg9QT9QMywzhww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from DM8PR11MB5749.namprd11.prod.outlook.com (2603:10b6:8:10::15) by SJ0PR11MB5894.namprd11.prod.outlook.com (2603:10b6:a03:42a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.32; Tue, 26 Mar 2024 09:16:20 +0000 Received: from DM8PR11MB5749.namprd11.prod.outlook.com ([fe80::9cd7:dc83:b05b:c77d]) by DM8PR11MB5749.namprd11.prod.outlook.com ([fe80::9cd7:dc83:b05b:c77d%4]) with mapi id 15.20.7409.031; Tue, 26 Mar 2024 09:16:19 +0000 From: "Metzger, Markus T" To: "Ijaz, Abdul B" CC: "blarsen@redhat.com" , "gdb-patches@sourceware.org" Subject: RE: [PATCH 1/1] testsuite, btrace: update btrace testsuite to test all btrace recording methods Thread-Topic: [PATCH 1/1] testsuite, btrace: update btrace testsuite to test all btrace recording methods Thread-Index: AQHabg1a2fxxyzoif0+n2Z7UoQf+mbFJqtGA Date: Tue, 26 Mar 2024 09:16:19 +0000 Message-ID: References: <20240304082354.3336-1-abdul.b.ijaz@intel.com> <20240304082354.3336-2-abdul.b.ijaz@intel.com> In-Reply-To: <20240304082354.3336-2-abdul.b.ijaz@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM8PR11MB5749:EE_|SJ0PR11MB5894:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7N1uq3iElM5wikqtG27Re7aEiILAVtdE7Vs6/SHxC+sKR5JucI+MKl/GhTJBM6Q/OaRbK+3uMrd++24HMspTzOAhELvzBzGMXdtsn++JQ6z+4HVcrhFZQT3A1wnIiq2Hr2/onqHayEzh55K5P/t2I2B4maNwIPBbi0sJtY+4RBNDmR5j5t+d/3ZBJviHJCVAK/mHMKp05bMX2mPvFtetn5UFoNrrUjl/86rq06X91/Hea1nau1ceEIWDl5sHT6ShBBK9ugmO6WnKeQ+AsFHq/xlN8bMpYZWqTaBfgmfgo4QiNeDZDh1GCEeWcH71ubD36yHAWLryhYlxVh85zUFH63YA178cg0vziBD5worlhogJlWEREQCid029kF6tYcJEer3v3ZUYSp/QCqm/Naz2h+4tQ2YKm+coHDzu/oJi+EyfKdw7typzkXNmwNSjd6Gh5oD02PKdoDoZ+Q0ivUKl/1hBRLag3SKo/D4jzVjaZZAJu4Zsb32pEAjQW+NY8J0R95z5N3gmOPb5cWDOod4bsrP4W//bDZCqAYslf20Aa/ZsKTw5dkX6GruQigHQcG0zp2KfhQtgAgJdZ09T1zjXDs9umCa0UXeMXN8ZfKp9Fl4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM8PR11MB5749.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(1800799015)(376005)(366007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?l3SItBKU5bYXQMRaYrZnvonSwMVBiefVrBHDGpOIOKa+/v61W7TPd1W/BfCF?= =?us-ascii?Q?PjHI3ovstZHUeTQURS0gKQHlNmMOzCjGg5z3qHfUdSg30epyg3za4bgqOt44?= =?us-ascii?Q?m2daW2BkwHQ47Zck4cEnnDT65j4lcqUM6nDZFhL+axTUAp1VFBnrc5XlglQQ?= =?us-ascii?Q?s6Q2aguH/CP0ZBwJECreL7Kb7U9sLJReBbVHSbYGbgjbLuH/f9X3Gy7jkb/A?= =?us-ascii?Q?CI7dzdevXFBvQmgs3YDqw5eOgcMxGJiHP9e8LjYvwsPHTZxb5yoOYzRhueXx?= =?us-ascii?Q?YtBu16d+ShnFHyZYTxWI74/kN+balkK9YttXoFDIvW7HHktcMF+qAhytprX8?= =?us-ascii?Q?3qahJXMrlACSiAZ/atrFbu51VrKVG+rqzNTYPicwhqLu6QA9H8qoC8ylq1pp?= =?us-ascii?Q?EK/kQmLxzDfFRXVz7WuQonG8ZX47J/cWHW7kN5tkV3oTosC4tVSN0tCZo08b?= =?us-ascii?Q?P6R0ANWcq/fcEYHD/XeMLmBs0acpnR4ZMELq9E8h4K2sK6I/mjQmUsvmSYgL?= =?us-ascii?Q?e9zG8f7B5gIDIlRbAyd2QcbFeagc6HpfyYmEKZJ/ec1tElJnpfM04sLQVFea?= =?us-ascii?Q?uMuxOGoY5tM2RanWM51Ws0MSxgKYpjBoplN/Af0prK8eaRJ/jtFWOO6C82os?= =?us-ascii?Q?XytyQIjeRFUfuTmdILv8TV41hWeEIF4emAskC1tD6ttPxqwQWDCQe0qSPuyb?= =?us-ascii?Q?14zTK7OWX6AMHdKqPeXJwN/QyOl6TSNBvb+AEl60AayhhHHaimslL9lm+lNO?= =?us-ascii?Q?iQiyyHIohXexRNORvN1NXpM18qTV+wsRa8UM9IddgWM6U9msJVDPLU7XKpp1?= =?us-ascii?Q?D/LyeAkHgd2f43rKOWKwT8nHz95HnnUDdyoWAMIVOU3d9MTLiqh5vxM9+RR5?= =?us-ascii?Q?iKQszHYXM3ygNHlCjKIzvDMz2v27XhvqQsEGIwwOmP4+zWRVYkSb1kX2u9Rx?= =?us-ascii?Q?FtpJD37NhCGUa2G2nOY0/a40c5eMJBPr/ocf1Bfi6kh9c8NZ9zwNPJPApzx+?= =?us-ascii?Q?ZuzOfBfaxld+HlSanPYgQA/oqSzBS4xUC9DbLnru3ZR+oZJd3H2NHaKmKh/V?= =?us-ascii?Q?dl5CZuVq5fXVg3gosCDlFoudOIzKvSzBiGd6xE6cOkqKJJ1omYIq30RLbnOG?= =?us-ascii?Q?sB8LDc+hqrlg0NJ5G8ZoAUwdiGXqHYeH+Lbkt4TchHr8to63UwZdQycpXNi2?= =?us-ascii?Q?D5kQAvyU+aiSl2gTgNrcpFG4W4M4ZKJr7SSTnsxB7oIHkyaeO+14XKXGZITP?= =?us-ascii?Q?tVVp+0EJsFSc3N4i1AmBewZmeA0NlHQsCMDyPki4NKkfnT8xE2Fzt66fciMs?= =?us-ascii?Q?z7qsf74inyUvAsGUKc1nGD2Qpeu7+GgNd1ZPlRs0y2bz9SRUX71iMkSednxz?= =?us-ascii?Q?G2gonRBmFUw3bN8xE6J/8lAUDOCobR7MThCf4r7BGjsOn2G2mOzWmMQH/dgb?= =?us-ascii?Q?kXHYn4S8FsjctWTO0UAIuO3dGdk2EgGbTe/NmG1RucV0AIOv2vcYXJRPcP6m?= =?us-ascii?Q?JTmkUvR6e4PsVHrOlgxxo+1vUOcV9qdlL3pPwMW595hK0sToevlCXpDt1Yji?= =?us-ascii?Q?+KWuHJT94iZ/zKdnhtfAtDT2Uv30UBs/sHu3MtOE?= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8PR11MB5749.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce52f045-ed52-49c0-1b3b-08dc4d7565db X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2024 09:16:19.5021 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: paAh3PsU9/ZG1hMCML55TJ2QzVcHwcPglTrbjKheuZ0hmcuiaSo406KecF1XiVZXCBeqkEEqx5PO8xZffM34YUPZNqtItNVnsHaSK6QGjno= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5894 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-10.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Hello Abdul, >With this change, gdb.btrace will, instead of selecting the >default recording method, run all tests for all available and >applicable methods. This increases testing coverage. I reviewed this with 'git show -w'. >+foreach_with_prefix method {"bts" "pt"} { >+ if { ![target_supports_btrace $method] } { >+ unsupported "target does not support record-btrace ${method}" >+ continue >+ } The terminology is 'recording format', not 'recording method'. In the unsupported string, the $method should already be part of the test p= refix. >+ >+ clean_restart "${testfile}" >+ if ![runto_main] { >+ continue >+ } We don't need that since the test is going to start over... >+ >+ # start fresh - without an executable >+ gdb_exit >+ gdb_start ...right here. >+ >+ # record cannot be stopped, if it was never active >+ gdb_test "record stop" "No recording is currently active\\..*" "recor= d stop >without target" >+ >+ # btrace cannot be enabled without a running inferior >+ gdb_test "record btrace ${method}" "The program is not being run\\." >"record btrace without running program" >+ >+ # no function and no instruction history without btrace enabled >+ gdb_test "record function-call-history" "No recording is currently >active\\..*" "record function-call-history without target" >+ gdb_test "record instruction-history" "No recording is currently acti= ve\\..*" >"record instruction-history without target" >+ gdb_test "info record" "No recording is currently active\\." "info re= cord >without target" >+ >+ clean_restart "${testfile}" >+ if ![runto_main] { >+ continue >+ } >+ >+ # enable btrace >+ gdb_test_no_output "record btrace ${method}" "record btrace ${method}" There already is a test prefix supplying $method. We don't need to repeat = that in the test name. There are more instances in this file. >+ # trace the code between the two breakpoints >+ gdb_continue_to_breakpoint "cont to bp.1" ".*$srcfile:$bp_1\r\n.*" >+ # increase the BTS buffer size - the trace can be quite big for bts m= ethod >+ gdb_test_no_output "set record btrace ${method} buffer-size 128000" The comment no longer matches the code. >+ # moving forward and expect to see the latest 6 entries >+ gdb_test "record function-call-history /l +" [multi_line \ >+ "\[0-9\]*\tinc\tat $srcfile:22,2\[34\]" \ >+ "\[0-9\]*\tmain\tat $srcfile:40,41" \ >+ "\[0-9\]*\tinc\tat $srcfile:22,2\[34\]" \ >+ "\[0-9\]*\tmain\tat $srcfile:40,41" \ >+ "\[0-9\]*\tinc\tat $srcfile:22,2\[34\]" \ >+ "\[0-9\]*\tmain\tat $srcfile:40,43" \ >+ >+ ] "forward /l - 2" Why this empty line in the multi_line pattern? >diff --git a/gdb/testsuite/gdb.btrace/multi-inferior.exp >b/gdb/testsuite/gdb.btrace/multi-inferior.exp >index 6996b182e65..06ca93a9686 100644 >--- a/gdb/testsuite/gdb.btrace/multi-inferior.exp >+++ b/gdb/testsuite/gdb.btrace/multi-inferior.exp >+ gdb_test_no_output "record btrace ${method}" "record btrace >${method}" >+ } The $method is already part of the test prefix. We don't need to repeat it in the test message. We may be able to just drop the message and use the default. >diff --git a/gdb/testsuite/gdb.btrace/reconnect.exp >b/gdb/testsuite/gdb.btrace/reconnect.exp >index 41f702a38b3..349d7f7cda9 100644 >-# Test that recording is now off. >-with_test_prefix "third" { >- gdb_test "info record" "No recording is currently active." >+ # Test that recording is now off. >+ with_test_prefix "third" { >+ gdb_test "info record" "No recording is currently active." >+ } >+ gdb_test "disconnect" ".*" > } Is there an extra gdb_test "disconnect" ".*" at the end? It shows more clearly with 'git show -w'. >diff --git a/gdb/testsuite/gdb.btrace/tailcall-only.exp >b/gdb/testsuite/gdb.btrace/tailcall-only.exp >index ae3b04e3b66..c90ba8b1bd3 100644 >--- a/gdb/testsuite/gdb.btrace/tailcall-only.exp >+++ b/gdb/testsuite/gdb.btrace/tailcall-only.exp >-# We can neither finish nor return. >-gdb_test "finish" "Cannot find the caller frame.*" >-gdb_test_multiple "return" "return" { >- -re "Make .* return now.*y or n. $" { >- send_gdb "y\n" >- exp_continue >- } This gets changed from exp_continue... >+ # We can neither finish nor return. >+ gdb_test "finish" "Cannot find the caller frame.*" >+ gdb_test_multiple "return" "return" { >+ -re "Make .* return now.*y or n. $" { >+ send_gdb "y\n" >+ continue >+ } ...to continue. >diff --git a/gdb/testsuite/gdb.btrace/tsx.exp >b/gdb/testsuite/gdb.btrace/tsx.exp >index d312b15027c..11e230c8547 100644 >--- a/gdb/testsuite/gdb.btrace/tsx.exp >+++ b/gdb/testsuite/gdb.btrace/tsx.exp >@@ -15,7 +15,7 @@ > # You should have received a copy of the GNU General Public License > # along with this program. If not, see . > >-require allow_btrace_pt_tests allow_tsx_tests >+require allow_btrace_pt_tests allow_tsx_tests allow_btrace_tests Do we really need allow_btrace_tests when we already require allow_btrace_pt_tests? >diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp >index fe4ac7d2719..62eadc9696f 100644 >--- a/gdb/testsuite/lib/gdb.exp >+++ b/gdb/testsuite/lib/gdb.exp >@@ -4008,68 +4008,29 @@ gdb_caching_proc allow_avx512fp16_tests {} { > return $allow_avx512fp16_tests > } > >-# Run a test on the target to see if it supports btrace hardware. Return= 1 if >so, >-# 0 if it does not. Based on 'check_vmx_hw_available' from the GCC >testsuite. >+# Check if btrace is supported on the target. Return 1 if >+# so, 0 if it does not. > > gdb_caching_proc allow_btrace_tests {} { >- global srcdir subdir gdb_prompt inferior_exited_re >- >- set me "allow_btrace_tests" > if { ![istarget "i?86-*-*"] && ![istarget "x86_64-*-*"] } { >- verbose "$me: target does not support btrace, returning 0" 2 >- return 0 >- } >- >- # Compile a test program. >- set src { int main() { return 0; } } >- if {![gdb_simple_compile $me $src executable]} { >+ verbose "target_supports_btrace: target does not support btrace, >returning 0" 2 Why 'target_supports_btrace:'? Since we now check the different recording formats, I don't think this target check adds anything. > return 0 > } > >- # No error message, compilation succeeded so now run it via gdb. >- >- gdb_exit >- gdb_start >- gdb_reinitialize_dir $srcdir/$subdir >- gdb_load $obj >- if ![runto_main] { >+ if { ![allow_btrace_bts_tests] && ![allow_btrace_pt_tests] } { > return 0 > } The inverted logic may be easier to read and extend, i.e. if { [allow_btrace_bts_tests] } { return 1 } if { [allow_btrace_pt_tests] } { return 1 } return 0 >- # In case of an unexpected output, we return 2 as a fail value. >- set allow_btrace_tests 2 >- gdb_test_multiple "record btrace" "check btrace support" { >- -re "You can't do that when your target is.*\r\n$gdb_prompt $" { >- set allow_btrace_tests 0 >- } >- -re "Target does not support branch tracing.*\r\n$gdb_prompt $" { >- set allow_btrace_tests 0 >- } >- -re "Could not enable branch tracing.*\r\n$gdb_prompt $" { >- set allow_btrace_tests 0 >- } >- -re "^record btrace\r\n$gdb_prompt $" { >- set allow_btrace_tests 1 >- } >- } >- gdb_exit >- remote_file build delete $obj >- >- verbose "$me: returning $allow_btrace_tests" 2 >- return $allow_btrace_tests >+ return 1 > } > >-# Run a test on the target to see if it supports btrace pt hardware. >+# Run a test on the target to see if it supports btrace input method. > # Return 1 if so, 0 if it does not. Based on 'check_vmx_hw_available' > # from the GCC testsuite. > >-gdb_caching_proc allow_btrace_pt_tests {} { >+proc check_btrace_method_support {method} { > global srcdir subdir gdb_prompt inferior_exited_re > >- set me "allow_btrace_pt_tests" >- if { ![istarget "i?86-*-*"] && ![istarget "x86_64-*-*"] } { >- verbose "$me: target does not support btrace, returning 1" 2 >- return 0 >- } >+ set me "check_btrace_${method}_support" Should this be 'check_btrace_method_support ${method}'`? > > # Compile a test program. > set src { int main() { return 0; } } >@@ -4087,31 +4048,62 @@ gdb_caching_proc allow_btrace_pt_tests {} { > return 0 > } > # In case of an unexpected output, we return 2 as a fail value. >- set allow_btrace_pt_tests 2 >- gdb_test_multiple "record btrace pt" "check btrace pt support" { >- -re "You can't do that when your target is.*\r\n$gdb_prompt $" { >- set allow_btrace_pt_tests 0 >- } >- -re "Target does not support branch tracing.*\r\n$gdb_prompt $" { >- set allow_btrace_pt_tests 0 >- } >- -re "Could not enable branch tracing.*\r\n$gdb_prompt $" { >- set allow_btrace_pt_tests 0 >- } >- -re "support was disabled at compile time.*\r\n$gdb_prompt $" { >- set allow_btrace_pt_tests 0 >- } >- -re "^record btrace pt\r\n$gdb_prompt $" { >- set allow_btrace_pt_tests 1 >- } >+ set supports_method 2 >+ gdb_test_multiple "record btrace ${method}" "check btrace ${method} >support" { >+ -re -wrap "You can't do that when your target is.*" { >+ set supports_method 0 >+ } >+ -re -wrap "Target does not support branch tracing.*" { >+ set supports_method 0 >+ } >+ -re -wrap "Could not enable branch tracing.*" { >+ set supports_method 0 >+ } >+ -re -wrap "support was disabled at compile time.*" { >+ set supports_method 0 >+ } We need at least one more fail case: (gdb) record btrace foo Undefined record btrace command: "foo". Try "help record btrace". >+ -re -wrap "" { >+ set supports_method 1 >+ } > } > gdb_exit > remote_file build delete $obj > >- verbose "$me: returning $allow_btrace_pt_tests" 2 >- return $allow_btrace_pt_tests >+ verbose "$me: returning $supports_method" 2 >+ return $supports_method > } > >+# Run a test on the target to see if it supports btrace 'bts' method. Re= turn >+# 1 if so, 0 if it does not. >+ >+gdb_caching_proc allow_btrace_bts_tests {} { >+ return [check_btrace_method_support "bts"] >+} This 'method' sounds a bit odd. Without, it would read 'check_btrace_support "bts"'. We could make it 'btrace_supports "bts"' if we wanted to. I'm wondering if we even need those allow_btrace__tests. Their purpose is to cache the result, but could we declare the underlying check_btrace_method_support caching? We'd still want a better name, e.g. >+proc target_supports_btrace {method} { >+ if {[string match "pt" "${method}"]} { >+ return [allow_btrace_pt_tests] >+ } elseif {[string match "bts" "${method}"]} { >+ return [allow_btrace_bts_tests] >+ } >+ >+ verbose -log "warning: unknown btrace recording method '${method}'" >+ # Skip test for unknown method name. >+ return 0 >+} >+ >+ > # Run a test on the target to see if it supports Aarch64 SVE hardware. > # Return 1 if so, 0 if it does not. Note this causes a restart of GDB. > >-- >2.34.1 Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva = Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928