From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id eQ53MsVIs2bLBj8AWB0awg (envelope-from ) for ; Wed, 07 Aug 2024 06:13:25 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=SU3spDmJ; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=SU3spDmJ; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id BAA271E0D0; Wed, 7 Aug 2024 06:13:25 -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 9F5C91E08C for ; Wed, 7 Aug 2024 06:13:23 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 400A9385841C for ; Wed, 7 Aug 2024 10:13:23 +0000 (GMT) Received: from EUR02-AM0-obe.outbound.protection.outlook.com (mail-am0eur02on20600.outbound.protection.outlook.com [IPv6:2a01:111:f403:2606::600]) by sourceware.org (Postfix) with ESMTPS id B8E023858C41 for ; Wed, 7 Aug 2024 10:13:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B8E023858C41 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B8E023858C41 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=2a01:111:f403:2606::600 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1723025584; cv=pass; b=lB/jZdvFOE7bQLMaN23cMW7+mfT0PnE/gMuUhsfnlgCD/LkJJtmdu79N9qUoH8gidt0ubOqSev56gA8Z2XmsL4WdqyKvwGqRGbIURa9O8G6PJgZ0/plrw6MZPQfoRJSZ/Z3p6vURxgdE50YlL5Mt47v6PcbDpNnln+W4J6EENnI= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1723025584; c=relaxed/simple; bh=AIr1FmLGsR1bhZxB0SewMZ2QI5Goy+V8oU/DZCEqk8o=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:From:To: MIME-Version; b=CfCVSO8biC6usuwWG8wbm89nGDOsLyhx76DH8WZIQeRBkSdzdJhN10W2axQxhZ1Y/D3J0EO6ALti6dlbK5zoqppvh16d5VzjEdyEbhe/DB3f2zC6GKua84+iJhQ9POMOwczzeUvJvw/AgPXMs57lkd15ytyiJLj+jyV0/ZMCJqc= ARC-Authentication-Results: i=3; server2.sourceware.org ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=pZ7yAsV1LdQeaWfSonHmg5IN6ZDaUw6YmZdgfJD4fc10/ENtCvsUmRbe7IsVr88cwjej2rMeyj62Cv+DnkNShe8cYwzZ6caQUktKTRypclXHB9qNfRtWMg5dwClPWaGQMb18lVH7RSZYe8S3nMEdvIKHM5aogWg9kDKtvIH8+APGcSUrdamVp8giEEZ1OkhN59JGwYzOUWUSsSECHeSRONGaf6rYAo49bzHFSVmdkzJk8LI7XXUz7Ffjlztm2nmwo94HIKf6CV9/i15x6Asro++OAjjJbvVBS72yI0fL3xgZUVU6l/1BSaELAXwha/zKZshOHRygzWfVcxznUzTHQw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=xuGrd8LeJdk+GuOnmAgnHjHcajlZIMaM094+UnJS898=; b=m8ypgyIPj6vfspz/oe3Iql7bF3RmEdU8usamnKiReYzHi0hmTWrjVIYbLjDe4IJnShvFPv7Y/vkZZNnrfgr+Yfyi9ykjpaMap7FbeRTC3ROXgT/DwIXsxXqCFkmlJF8VbB6oseV+rrV7IUGqFFD5yPYROX87S9hYeYVC5scS+fwU1Yiz73OUNyZCktYTG80X/gUUS6tpVdhh269tbhhOB1D5KI+DBcEM91japqu1jLqABmMIo3OgaI7B1lrZBljxDxccCgzfQ3rI/yOCDzFok8W7sIFQxJF9o0PfXMKC1ad1ihhp5prGbgBJUAnvFuFqZTodRB8+qNdalVI4WJTU6A== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=sourceware.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xuGrd8LeJdk+GuOnmAgnHjHcajlZIMaM094+UnJS898=; b=SU3spDmJOAVSjfVYRlD+k2TBMAd8Xk9Ug/amfsdkHBppfPW1fFL5BEG8KcsBK6aMyQgI7n5nXa/pjfwdpe/tOjjMGT/pImbzM3dlQFs98DSDxnF/vwqmJ5BBYL5jKIrrmTnCFgCMlYdF3JFIwZ+DN0rz4LZMOdCwSrROZy8UZn0= Received: from AM0PR03CA0088.eurprd03.prod.outlook.com (2603:10a6:208:69::29) by DB3PR08MB8844.eurprd08.prod.outlook.com (2603:10a6:10:439::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7849.13; Wed, 7 Aug 2024 10:12:56 +0000 Received: from AM3PEPF0000A79C.eurprd04.prod.outlook.com (2603:10a6:208:69:cafe::27) by AM0PR03CA0088.outlook.office365.com (2603:10a6:208:69::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7828.25 via Frontend Transport; Wed, 7 Aug 2024 10:12:56 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM3PEPF0000A79C.mail.protection.outlook.com (10.167.16.107) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.7849.8 via Frontend Transport; Wed, 7 Aug 2024 10:12:56 +0000 Received: ("Tessian outbound 6ceac6be275b:v365"); Wed, 07 Aug 2024 10:12:56 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 32806d73b665014e X-CR-MTA-TID: 64aa7808 Received: from Leede9ff307ac.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id B472B751-AC8D-4E75-8492-86F84F28E854.1; Wed, 07 Aug 2024 10:12:50 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id Leede9ff307ac.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 07 Aug 2024 10:12:50 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gTMJJSwLNYdy/DRv+NesVYZkUgnCaEF12dkKQnn8qURZMjdEhkG9cppKg/tEiGWcGT3aAR5HzVW1ORPW76eLyfHDAs59yWaWbnolL7CpaouJtkVtCUTF3SUgx7ncyQF6X9czPtXVPQv3rsL5XD8e8kIhajqIpEelWr1RVJMa7O2g66NG3h2iom8cMaj9oJ7/ok9uTvT1602oRK6KlO5Z/15bq+RpUUo2pJOI2pZvlRD20ozMKoBjEXBoSXej9GTqDV5LQBce+x3txC1Mp5NQUPgy0+063wQyBv5XGemMmlVLU2vNNraR6uHal9RzkSzz33wCCUZXUbxTLmdeb/YrLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=xuGrd8LeJdk+GuOnmAgnHjHcajlZIMaM094+UnJS898=; b=QHqFNFEPnHSpcWF9WA8ZJXFViPNF+m9gAtuRUFbR35lssslrye8nFD/ybom8bB2vWbUZQGeUQqbLc99mLCIMjfYMx7t/3gg37fRcaPShtnrGRVCmG6ih217K1zJiiC0qBlqSkSmr730NGBDidfWFN4KMq+QOOnw/gtox2Fvyt9MNQisYzXXi44kZ4t2LUVi3HgMaeExssXubVBTOyRzYKPUd7zBLBKyqZ+ilqqUxBdbl62LGJz2ucA3M0wAEnJWhrfp8wKigdx781GOgjBDOM1VN1qqZ3yIBG0BGjq3p0vptCeHVwCa+QJmTmJCbpn8VouVkkqXZiOsBXqJtrbzbqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xuGrd8LeJdk+GuOnmAgnHjHcajlZIMaM094+UnJS898=; b=SU3spDmJOAVSjfVYRlD+k2TBMAd8Xk9Ug/amfsdkHBppfPW1fFL5BEG8KcsBK6aMyQgI7n5nXa/pjfwdpe/tOjjMGT/pImbzM3dlQFs98DSDxnF/vwqmJ5BBYL5jKIrrmTnCFgCMlYdF3JFIwZ+DN0rz4LZMOdCwSrROZy8UZn0= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from PR3PR08MB5852.eurprd08.prod.outlook.com (2603:10a6:102:8e::21) by DU0PR08MB8469.eurprd08.prod.outlook.com (2603:10a6:10:407::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7849.13; Wed, 7 Aug 2024 10:12:47 +0000 Received: from PR3PR08MB5852.eurprd08.prod.outlook.com ([fe80::f44:d113:1c29:825d]) by PR3PR08MB5852.eurprd08.prod.outlook.com ([fe80::f44:d113:1c29:825d%3]) with mapi id 15.20.7828.023; Wed, 7 Aug 2024 10:12:47 +0000 Message-ID: <929322d2-7a9c-4ce1-8b41-7e19f0b73794@arm.com> Date: Wed, 7 Aug 2024 11:12:45 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/4] gdb/testsuite: track if a caching proc calls gdb_exit or not Content-Language: en-US From: Luis Machado To: Andrew Burgess , gdb-patches@sourceware.org References: <5dc846ffb6cd8f76ba2769ee7679f5d1b01fae0a.1717438458.git.aburgess@redhat.com> <97973506-79f4-4216-9c0b-57401b3933f5@arm.com> <87zfpovgkr.fsf@redhat.com> <87wmksveip.fsf@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0308.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:197::7) To PR3PR08MB5852.eurprd08.prod.outlook.com (2603:10a6:102:8e::21) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: PR3PR08MB5852:EE_|DU0PR08MB8469:EE_|AM3PEPF0000A79C:EE_|DB3PR08MB8844:EE_ X-MS-Office365-Filtering-Correlation-Id: b2c987ad-1335-4a68-b2ac-08dcb6c9821f x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|366016|1800799024|376014; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?ajFtTXRCcnJXUTNpSUw3N3lzMW9YR3Fac0NneW5tVUtmZ1dTTVRTSFFlVXlE?= =?utf-8?B?UVY3Q2QzNGsrSWRmaWNMOGJVNGwrZGxQdXkzd0hJRTBMVmJJaUV5WGRwZjM1?= =?utf-8?B?S0U4OENLUnoybWRxakpsYzBNVnVzR2o4eUZ3REx4WHIwRWJpQnc1aUJxQ2Qr?= =?utf-8?B?dEt1ekFUcE9Sa1FubC94UVFvUnVidWkxRzRmU3lsSDdGSnJNZllrSldyVTNa?= =?utf-8?B?YUZZcS9NZWVGQUdmR3Nva1UvU2lFU0Z3aXpaK0VzcElDZmkyM1NYSjZOWXk5?= =?utf-8?B?Ly9FZnpGUEtJN1R4RzJVeUJNK001a3Rnd3Q0cncwSWwwZXdVdDdYU2RWZkxa?= =?utf-8?B?a3JJc3pBVmxIZzdxSThPdm04dStOc2VYM0ViTkduY0FqSlRDMzM1clZXOXlq?= =?utf-8?B?N3Y1bWhQNDFmSG56YlpvTFBkTTJYN0k3SGY2c0dlODU1Vmo4UVMyL2Y2VWc4?= =?utf-8?B?em1jTlRCbWQ5K2E1TWxzMlhBbjUyRXlDLzIvd1k1WjRhaDBCVytRa2syaVVO?= =?utf-8?B?REl3MU5Wb2tub3dpWHgwVy9PdkRheEVkbmVUMkVQZDBVNWxySlV1djFFSi92?= =?utf-8?B?NG9Odkk2UVlVUnNnaTB4OXd1ay9BTG9uR2FnbXNHSUMzdDlDUC96VnEvOWF6?= =?utf-8?B?QWwrbFczUS9EODZIUkg5aEpNUnVha2hiSGJmb25BWmt3eVE2VHlUTzhEMUc0?= =?utf-8?B?SXN1a2MvZWZXQ0JnZlZXZnVpdjNDaEpnOUF1aVZ1L3BZeE9DOGpEQ0N0NVBs?= =?utf-8?B?V3NhS09yWCtBQVVIdEM0cUNwNS95UHZudUdvcW13WE0rZUpsTkJ3N0xCUlR1?= =?utf-8?B?dnJ3RVRXRUJWejBOL1MyWnF1Nk1EV0h2dlIzMDhJUFdLaVVkTzFPU0lvTEE1?= =?utf-8?B?RHdhYXdoRytrS0xRSEVwY3BQbS9TQWdnb2JZRldJR0xmVk9Xd3dlcVBvaExt?= =?utf-8?B?MnlmOUNYTUJzOUpVLzlSU0w2M2ZrajFqVmhtaThUUnFSQnR4WU83T1E5MGM5?= =?utf-8?B?bTNGOGIvMGE1eUJSeTNGVFViaWEwWDZ0ZWo5Ni9iZVJ1K0w0VW80VmE1MzVu?= =?utf-8?B?TDR3bjhPWlhXb080MU1ETm8zOWk5S0xPSzRMWjBTaE84NmxZdHFCZ01VWHhU?= =?utf-8?B?Z0x0Rm5GUFIvenl0RlFrOW5yNDA5ejRJWGZEQ1JGWlFSQUVQSTAvTjJKbDJy?= =?utf-8?B?OU1FSVB2Y1JyNDRiN0hSK3p4WGVKZmp3amdpaUJjQ0ZpdllyNG9rTXJvQ2Nl?= =?utf-8?B?ZHNHWHZvRXpXQTNCQmo4aGd0ME82dkcyV3BkTzNxUGVHQmRzaXN6cHdmamVP?= =?utf-8?B?VGVaWmJudG92eDl2bEJLSzRxM1c1VVF5elJkZEdHc1puR2s3alc4U1k5UExZ?= =?utf-8?B?cHF2VTF6MEdlZWF3L3lUcVBoMEdxTFJLblprVm5CUmQvbjZBcmNnR0ZlL1ZJ?= =?utf-8?B?Nzg2T3RQUG1Qdlg5dEpGSStIaERNa3J0WFF6VmtHbHlaNEtMR0dRdFhLYXZk?= =?utf-8?B?blNTdWVQR0dyZ1lpWmJYL1JPWEl0VXZSL01nbjYweEFhVU5iZ2cyYnErQXhU?= =?utf-8?B?Y1h3MXo2dXNGZmtoRFR4dForVkxJVUZqQ0hHWit4VTJhMzhGS2kyVDVUZVFN?= =?utf-8?B?ZUYweFE1T0VybzZmZkhlSklHaGpKQXJ0TjQ0SFF6SGk3ZWNRVjZKb2xZOXpv?= =?utf-8?B?dkNSdjRDN0FkakE5YmpIT2dxOUZFWGMzTmIzdzM4VmZTQ2NwSFR4V3NNaEl0?= =?utf-8?Q?wS6jz7EvyKZufeQW4g=3D?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3PR08MB5852.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(1800799024)(376014); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB8469 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-SkipListedInternetSender: ip=[2603:10a6:102:8e::21]; domain=PR3PR08MB5852.eurprd08.prod.outlook.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM3PEPF0000A79C.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 5aa1b506-ca70-46e1-4046-08dcb6c97c47 X-Microsoft-Antispam: BCL:0; ARA:13230040|82310400026|35042699022|36860700013|376014|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?NEpkUmhxSm0zVkcvKzh1ZE92K2g4Qy9uNUxNcTVzTlNiaFRPU2dpdmc1STl4?= =?utf-8?B?dkh5VHRpaVQ1LzdESE5xenJvcDV3ZzJUcXkwMXBQaVF3c3pkbnVHSWtXN0da?= =?utf-8?B?TWk2cldLT3JFbUpNTmtwVUNIMEZLTEV1U2hWTFpTZW1QbnBUVlZ1VmoweTU4?= =?utf-8?B?Y0Y0M2ZpeHlXR1pYcWg4anU3TjNiUjdkakFJU0ZyQld2R29ON0tWbTRMOHoz?= =?utf-8?B?cHpRY204VEZnaU9VOUtmU2RoMzZid0t3V0tvS0Z4YUo4Yk5oTGU5WGduQ3Zt?= =?utf-8?B?U3VqRGhlUXg4ZFNLR0xBbjlVOWRrOEJFclV1a2VsMXFMSzRmZWRqMEdsSFVY?= =?utf-8?B?NUx2UnNaS2tWOVhhVUl5LzU0bDlVRVFHQWtPaTFGdno2eitJVk9wN2pmUEFn?= =?utf-8?B?NXBjQ0lGM3BlQUQ3SmE3WTJrVlhLdW9YWW10U3UyQzRKQ1NBUCtDcVB6cEM3?= =?utf-8?B?M1J6MUVWTzQ5SU1iRTNvT3FNSjhWSG1veE8vazI1cUJPbis3bEZoNFlxWGZ1?= =?utf-8?B?ZWJrS1BZNXlXcUlneWVUWThNdCtIYlJuSjlVaUh1eU1kYlVXOXZlcFRHT1RY?= =?utf-8?B?Qlc5MHhHQ1B3T0RmTkcrMFRLWjZZM1ZQRDJQSGU2bWhLS3BlQlRIZlU5T084?= =?utf-8?B?ZkEyMGhCMHMvcDVoNlFyNjdmNlRTMm95UDZDeEJhdWpsQ2FBYjB3OE9aajdm?= =?utf-8?B?dFdXcHlTS3k2QVVhcVBrczlHRmNONUo4SVNSZmxKV01rS2MvT2luV2wxUGVv?= =?utf-8?B?KzQ0SVI3Q09pMUIxOFJ2QWpaMDdpbm1jd2xDdlNTcVZSckhQKzM0dXkvanZY?= =?utf-8?B?SGFta2dYZG1WZGszNkhMUjBUdk1OWWVaWWxvZmw4L3E1NU5QUEgxdjNDMlNP?= =?utf-8?B?OUp3c1VTMlBTODBhTTlOem1WamFiY01EWGdmdFQ4b0pJSlppVmVQYWpVelZx?= =?utf-8?B?ZjFQd1BpYUI5U1dSeTdZUHIwakFBRHNJRDZreTZYUmRGNzMvSzZTWFVPbURj?= =?utf-8?B?R3NYdFNqd1ljQUZXQ3REUFNGMld4SjM0dEd4L2N6TzUrczcvTjNMZ3FtV0VF?= =?utf-8?B?a2NnNkFFbTQzQ0RWcXI0L0dySjkzbTZ2cmZmTS9PbGFBTzk5VUloVWxxcEI3?= =?utf-8?B?UThtZjEyd3pFSGNuN1E2dWFQMGlRRnpRSHNpN2VqMTE1blZmUmxxK2c1VFZM?= =?utf-8?B?ZkVLNEFZTDZlYjdiV2g0K3dQRzNpWE5mbjFkNW8xNmRnOWlMK1hjNzNvRHl3?= =?utf-8?B?REtrdG1sdVN4V1JLekFaZUl2c0VIVkV2WEFxemxGSzBpem5lTW9MaTlZOG9t?= =?utf-8?B?dVpJcFFIdm5RU0FEQU9wWUtJeGl2WUlPaDRxYXVqdzdzd1lzbTl5VWNmVTdI?= =?utf-8?B?ZHlZTjgwdXlOanlqRENyZEcxM3hrNDU2ZlVHOVljK3d6SVB1ZVo3OUhCSXFU?= =?utf-8?B?TnBabERwTG5kWjFOYit0NGh5WEZNNWVuL1VwRkg2RVRlUWRuNmNyTlJwa25S?= =?utf-8?B?VDQwbTZ3UlNJajR0eUZjU1M4NUR2c2dWM3hEbkcyL3V6RUV2RkhWV1FFeHJT?= =?utf-8?B?UVV5dDVBNEJOWjM2NWlKMDhROFpGUW9YUWhDaTkwNm01RmNTMXgveWVDQ292?= =?utf-8?B?YzZyTzNtM3NmbEZiMjUreDNwVnNkZUIxclNha2xMSit0MlhYZzVMN3FhZ0NP?= =?utf-8?B?Zm8xbkIyY2VJTG83aExaaTBMeVlZWlZ0UUpoS1FlV3Frcmt6VmVsZmJVWXBE?= =?utf-8?B?ODlBYldIeTdpRFUwQmROV1AwTzJUS2FPUU55Z3NLK1dqeE13K1VDTEVkc1R0?= =?utf-8?B?S2FBUUZpd3I5cGJSSHRxOGR4RVlIQmt3TWJjRC9vY2N1RUtDdnhKeGRmaHN0?= =?utf-8?B?VEd2WHZITlc2S2hwRUJXc0s5NUszUUh4N0tZdkgvdVBqK2c9PQ==?= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230040)(82310400026)(35042699022)(36860700013)(376014)(1800799024); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Aug 2024 10:12:56.6783 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b2c987ad-1335-4a68-b2ac-08dcb6c9821f X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM3PEPF0000A79C.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR08MB8844 X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FORGED_SPF_HELO, GIT_PATCH_0, SPF_HELO_PASS, SPF_NONE, TXREP, UNPARSEABLE_RELAY 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 On 8/7/24 11:08, Luis Machado wrote: > On 8/7/24 11:00, Andrew Burgess wrote: >> Andrew Burgess writes: >> >>> Luis Machado writes: >>> >>>> Hi Andrew, >>>> >>>> On 6/3/24 19:16, Andrew Burgess wrote: >>>>> After a recent patch review I asked myself why can_spawn_for_attach >>>>> exists. This proc currently does some checks, and then calls >>>>> can_spawn_for_attach_1 which is an actual caching proc. >>>>> >>>>> The answer is that can_spawn_for_attach exists in order to call >>>>> gdb_exit the first time can_spawn_for_attach is called within any test >>>>> script. >>>>> >>>>> The reason this is useful is that can_spawn_for_attach_1 calls >>>>> gdb_exit. If imagine the user calling can_spawn_for_attach_1 directly >>>>> then a problem might exist. Imagine a test written like this: >>>>> >>>>> gdb_start >>>>> >>>>> if { [can_spawn_for_attach_1] } { >>>>> ... do stuff that assumes GDB is running ... >>>>> } >>>>> >>>>> If this test is NOT the first test run, and if an earlier test calls >>>>> can_spawn_for_attach_1, then when the above test is run the >>>>> can_spawn_for_attach_1 call will return the cached value and gdb_exit >>>>> will not be called. >>>>> >>>>> But, if the above test IS the first test run then >>>>> can_spawn_for_attach_1 will not returned the cached value, but will >>>>> instead compute the cached value, a process that ends up calling >>>>> gdb_exit. When the body of the if is executed GDB would no longer be >>>>> running and the test would fail! >>>>> >>>>> So can_spawn_for_attach was added which ensures that we _always_ call >>>>> gdb_exit the first time can_spawn_for_attach is called within a single >>>>> test script, this ensures that in the above case, even if the above is >>>>> not the first test run, gdb_exit will still be called. This avoids >>>>> some hidden bugs in the testsuite. >>>>> >>>>> However, what I observe is that can_spawn_for_attach is not the only >>>>> caching proc that calls gdb_exit. Why does can_spawn_for_attach get >>>>> special treatment when surely the same issue exists for any other >>>>> caching proc that calls gdb_exit? >>>>> >>>>> I think a better solution is to move the logic from >>>>> can_spawn_for_attach into cache.exp and generalise it so that it >>>>> applies to all caching procs. >>>>> >>>>> This commit does this by: >>>>> >>>>> 1. When the underlying caching proc is executed we wrap gdb_exit. >>>>> This wrapper sets a global to true if gdb_exit is called. The >>>>> value of this global is stored in gdb_data_cache (using a ',exit' >>>>> suffix), and also written to the cache file if appropriate. >>>>> >>>>> 2. When a cached value is returned from gdb_do_cache, if the >>>>> underlying proc would have called gdb_exit, and if this is the >>>>> first use of the caching proc in this test script, then we call >>>>> gdb_exit. >>>>> >>>>> When storing the ',exit' value into the on-disk cache file, the flag >>>>> value is stored on a second line. Currently every cached value only >>>>> occupies a single line, and a check is added to ensure this remains >>>>> true in the future. >>>>> >>>>> One issue did come up in testing, a FAIL in gdb.base/break-interp.exp, >>>>> this was caused by can_spawn_for_attach_1 calling gdb_start without >>>>> first calling gdb_exit. Under the old way of doing things >>>>> can_spawn_for_attach would call gdb_exit _before_ possibly calling the >>>>> actual caching proc. Under the new scheme gdb_exit is called _after_ >>>>> calling the actual caching proc. What was happening was that >>>>> break-interp.exp would leave GDB running then call >>>>> can_spawn_for_attach, when the test in can_spawn_for_attach_1 tried to >>>>> attach to the inferior, state left in the running GDB would cause some >>>>> unexpected behaviour. Fixed by having can_spawn_for_attach_1 call >>>>> gdb_exit before calling gdb_start, this ensures we have a fresh GDB. >>>>> >>>>> With this done can_spawn_for_attach_1 can be renamed to >>>>> can_spawn_for_attach, and the existing can_spawn_for_attach can be >>>>> deleted. >>>>> --- >>>>> gdb/testsuite/lib/cache.exp | 86 +++++++++++++++++++++++++++++++------ >>>>> gdb/testsuite/lib/gdb.exp | 83 +++++++++-------------------------- >>>>> 2 files changed, 93 insertions(+), 76 deletions(-) >>>>> >>>>> diff --git a/gdb/testsuite/lib/cache.exp b/gdb/testsuite/lib/cache.exp >>>>> index e7b9114058b..fef065ec8b0 100644 >>>>> --- a/gdb/testsuite/lib/cache.exp >>>>> +++ b/gdb/testsuite/lib/cache.exp >>>>> @@ -46,6 +46,40 @@ proc gdb_do_cache_wrap {real_name args} { >>>>> return $result >>>>> } >>>>> >>>>> +# Global written to by wrap_gdb_exit. Set to true if wrap_gdb_exit is >>>>> +# called. >>>>> + >>>>> +set gdb_exit_called false >>>>> + >>>>> +# Wrapper around gdb_exit. Use with_override to replace gdb_exit with >>>>> +# wrap_gdb_exit, the original gdb_exit is renamed to orig_gdb_exit. >>>>> + >>>>> +proc wrap_gdb_exit {} { >>>>> + set ::gdb_exit_called true >>>>> + orig_gdb_exit >>>>> +} >>>>> + >>>>> +# If DO_EXIT is false then this proc does nothing. If DO_EXIT is true >>>>> +# then call gdb_exit the first time this proc is called for each >>>>> +# unique value of NAME within a single test. Every subsequent time >>>>> +# this proc is called within a single test (for a given value of >>>>> +# NAME), don't call gdb_exit. >>>>> + >>>>> +proc gdb_cache_maybe_gdb_exit { name do_exit } { >>>>> + if { !$do_exit } { >>>>> + return >>>>> + } >>>>> + >>>>> + # To track if this proc has been called for NAME we create a >>>>> + # global variable. In gdb_cleanup_globals (see gdb.exp) this >>>>> + # global will be deleted when the test has finished. >>>>> + set global_name __${name}__cached_gdb_exit_called >>>>> + if { ![info exists ::${global_name}] } { >>>>> + gdb_exit >>>>> + set ::${global_name} true >>>>> + } >>>>> +} >>>>> + >>>>> # A helper for gdb_caching_proc that handles the caching. >>>>> >>>>> proc gdb_do_cache {name args} { >>>>> @@ -71,10 +105,12 @@ proc gdb_do_cache {name args} { >>>>> >>>>> set is_cached 0 >>>>> if {[info exists gdb_data_cache(${cache_name},value)]} { >>>>> - set cached $gdb_data_cache(${cache_name},value) >>>>> - verbose "$name: returning '$cached' from cache" 2 >>>>> + set cached_value $gdb_data_cache(${cache_name},value) >>>>> + set cached_exit $gdb_data_cache(${cache_name},exit) >>>>> + verbose "$name: returning '$cached_value' from cache" 2 >>>>> if { $cache_verify == 0 } { >>>>> - return $cached >>>>> + gdb_cache_maybe_gdb_exit $name $cached_exit >>>>> + return $cached_value >>>>> } >>>>> set is_cached 1 >>>>> } >>>>> @@ -83,24 +119,46 @@ proc gdb_do_cache {name args} { >>>>> set cache_filename [make_gdb_parallel_path cache $cache_name] >>>>> if {[file exists $cache_filename]} { >>>>> set fd [open $cache_filename] >>>>> - set gdb_data_cache(${cache_name},value) [read -nonewline $fd] >>>>> + set content [split [read -nonewline $fd] \n] >>>>> close $fd >>>>> - set cached $gdb_data_cache(${cache_name},value) >>>>> - verbose "$name: returning '$cached' from file cache" 2 >>>>> + set gdb_data_cache(${cache_name},value) [lindex $content 0] >>>>> + set gdb_data_cache(${cache_name},exit) [lindex $content 1] >>>>> + set cached_value $gdb_data_cache(${cache_name},value) >>>>> + set cached_exit $gdb_data_cache(${cache_name},exit) >>>>> + verbose "$name: returning '$cached_value' from file cache" 2 >>>>> if { $cache_verify == 0 } { >>>>> - return $cached >>>>> + gdb_cache_maybe_gdb_exit $name $cached_exit >>>>> + return $cached_value >>>>> } >>>>> set is_cached 1 >>>>> } >>>>> } >>>>> >>>>> - set real_name gdb_real__$name >>>>> - set gdb_data_cache(${cache_name},value) [gdb_do_cache_wrap $real_name {*}$args] >>>>> + set ::gdb_exit_called false >>>>> + with_override gdb_exit wrap_gdb_exit orig_gdb_exit { >>>>> + set real_name gdb_real__$name >>>>> + set gdb_data_cache(${cache_name},value) [gdb_do_cache_wrap $real_name {*}$args] >>>>> + } >>>>> + set gdb_data_cache(${cache_name},exit) $::gdb_exit_called >>>>> + >>>>> + # If a value being stored in the cache contains a newline then >>>>> + # when we try to read the value back from an on-disk cache file >>>>> + # we'll interpret the second line of the value as the ',exit' value. >>>>> + if { [regexp "\[\r\n\]" $gdb_data_cache(${cache_name},value)] } { >>>>> + set computed_value $gdb_data_cache(${cache_name},value) >>>>> + error "Newline found in value for $cache_name: $computed_value" >>>>> + } >>>>> + >>>>> if { $cache_verify == 1 && $is_cached == 1 } { >>>>> - set computed $gdb_data_cache(${cache_name},value) >>>>> - if { $cached != $computed } { >>>>> - error [join [list "Inconsistent results for $cache_name:" >>>>> - "cached: $cached vs. computed: $computed"]] >>>>> + set computed_value $gdb_data_cache(${cache_name},value) >>>>> + set computed_exit $gdb_data_cache(${cache_name},exit) >>>>> + if { $cached_value != $computed_value } { >>>>> + error [join [list "Inconsistent value results for $cache_name:" >>>>> + "cached: $cached_value vs. computed: $computed_value"]] >>>>> + } >>>>> + if { $cached_exit != $computed_exit } { >>>>> + error [join [list "Inconsistent exit results for $cache_name:" >>>>> + "cached: $cached_exit vs. computed: $computed_exit"]] >>>>> } >>>>> } >>>>> >>>>> @@ -110,9 +168,11 @@ proc gdb_do_cache {name args} { >>>>> # Make sure to write the results file atomically. >>>>> set fd [open $cache_filename.[pid] w] >>>>> puts $fd $gdb_data_cache(${cache_name},value) >>>>> + puts $fd $gdb_data_cache(${cache_name},exit) >>>>> close $fd >>>>> file rename -force -- $cache_filename.[pid] $cache_filename >>>>> } >>>>> + gdb_cache_maybe_gdb_exit $name $gdb_data_cache(${cache_name},exit) >>>>> return $gdb_data_cache(${cache_name},value) >>>>> } >>>>> >>>>> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp >>>>> index 8235d4f28eb..d29fd740f91 100644 >>>>> --- a/gdb/testsuite/lib/gdb.exp >>>>> +++ b/gdb/testsuite/lib/gdb.exp >>>>> @@ -6186,14 +6186,23 @@ proc gdb_exit { } { >>>>> catch default_gdb_exit >>>>> } >>>>> >>>>> -# Helper function for can_spawn_for_attach. Try to spawn and attach, and >>>>> -# return 0 only if we cannot attach because it's unsupported. >>>>> - >>>>> -gdb_caching_proc can_spawn_for_attach_1 {} { >>>>> - # For the benefit of gdb-caching-proc-consistency.exp, which >>>>> - # calls can_spawn_for_attach_1 directly. Keep in sync with >>>>> - # can_spawn_for_attach. >>>>> - if { [is_remote target] || [target_info exists use_gdb_stub] } { >>>>> +# Return true if we can spawn a program on the target and attach to >>>>> +# it. >>>>> + >>>>> +gdb_caching_proc can_spawn_for_attach {} { >>>>> + # We use exp_pid to get the inferior's pid, assuming that gives >>>>> + # back the pid of the program. On remote boards, that would give >>>>> + # us instead the PID of e.g., the ssh client, etc. >>>>> + if {[is_remote target]} { >>>>> + verbose -log "can't spawn for attach (target is remote)" >>>>> + return 0 >>>>> + } >>>>> + >>>>> + # The "attach" command doesn't make sense when the target is >>>>> + # stub-like, where GDB finds the program already started on >>>>> + # initial connection. >>>>> + if {[target_info exists use_gdb_stub]} { >>>>> + verbose -log "can't spawn for attach (target is stub)" >>>>> return 0 >>>>> } >>>>> >>>>> @@ -6218,6 +6227,9 @@ gdb_caching_proc can_spawn_for_attach_1 {} { >>>>> set test_spawn_id [spawn_wait_for_attach_1 $obj] >>>>> remote_file build delete $obj >>>>> >>>>> + # In case GDB is already running. >>>>> + gdb_exit >>>>> + >>>>> gdb_start >>>>> >>>>> set test_pid [spawn_id_get_pid $test_spawn_id] >>>>> @@ -6239,61 +6251,6 @@ gdb_caching_proc can_spawn_for_attach_1 {} { >>>>> return $res >>>>> } >>>>> >>>>> -# Return true if we can spawn a program on the target and attach to >>>>> -# it. Calls gdb_exit for the first call in a test-case. >>>>> - >>>>> -proc can_spawn_for_attach { } { >>>>> - # We use exp_pid to get the inferior's pid, assuming that gives >>>>> - # back the pid of the program. On remote boards, that would give >>>>> - # us instead the PID of e.g., the ssh client, etc. >>>>> - if {[is_remote target]} { >>>>> - verbose -log "can't spawn for attach (target is remote)" >>>>> - return 0 >>>>> - } >>>>> - >>>>> - # The "attach" command doesn't make sense when the target is >>>>> - # stub-like, where GDB finds the program already started on >>>>> - # initial connection. >>>>> - if {[target_info exists use_gdb_stub]} { >>>>> - verbose -log "can't spawn for attach (target is stub)" >>>>> - return 0 >>>>> - } >>>>> - >>>>> - # The normal sequence to use for a runtime test like >>>>> - # can_spawn_for_attach_1 is: >>>>> - # - gdb_exit (don't use a running gdb, we don't know what state it is in), >>>>> - # - gdb_start (start a new gdb), and >>>>> - # - gdb_exit (cleanup). >>>>> - # >>>>> - # By making can_spawn_for_attach_1 a gdb_caching_proc, we make it >>>>> - # unpredictable which test-case will call it first, and consequently a >>>>> - # test-case may pass in say a full test run, but fail when run >>>>> - # individually, due to a can_spawn_for_attach call in a location where a >>>>> - # gdb_exit (as can_spawn_for_attach_1 does) breaks things. >>>>> - # To avoid this, we move the initial gdb_exit out of >>>>> - # can_spawn_for_attach_1, guaranteeing that we end up in the same state >>>>> - # regardless of whether can_spawn_for_attach_1 is called. However, that >>>>> - # is only necessary for the first call in a test-case, so cache the result >>>>> - # in a global (which should be reset after each test-case) to keep track >>>>> - # of that. >>>>> - # >>>>> - # In summary, we distinguish between three cases: >>>>> - # - first call in first test-case. Executes can_spawn_for_attach_1. >>>>> - # Calls gdb_exit, gdb_start, gdb_exit. >>>>> - # - first call in following test-cases. Uses cached result of >>>>> - # can_spawn_for_attach_1. Calls gdb_exit. >>>>> - # - rest. Use cached result in cache_can_spawn_for_attach_1. Calls no >>>>> - # gdb_start or gdb_exit. >>>>> - global cache_can_spawn_for_attach_1 >>>>> - if { [info exists cache_can_spawn_for_attach_1] } { >>>>> - return $cache_can_spawn_for_attach_1 >>>>> - } >>>>> - gdb_exit >>>>> - >>>>> - set cache_can_spawn_for_attach_1 [can_spawn_for_attach_1] >>>>> - return $cache_can_spawn_for_attach_1 >>>>> -} >>>>> - >>>>> # Centralize the failure checking of "attach" command. >>>>> # Return 0 if attach failed, otherwise return 1. >>>>> >>>> >>>> This is a bit after the fact, but I tracked down some aarch64 sme test regressions >>>> to this particular patch. I'm still investigating exactly why it stopped working, but I >>>> can tell it only happens if we run 2 or more tests in the same run. It is not >>>> clear if making things parallel has an impact, or if it is just the fact we >>>> run 2+ tests in the same run. >>>> >>>> I suspect we may be calling gdb_exit when we shouldn't, and then things just >>>> stop working. >>>> >>>> --- >>>> >>>> Running target unix >>>> Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. >>>> Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. >>>> Using repos/binutils-gdb/gdb/testsuite/config/unix.exp as tool-and-target-specific interface file. >>>> Running repos/binutils-gdb/gdb/testsuite/gdb.arch/aarch64-sme-core-0.exp ... >>>> Running repos/binutils-gdb/gdb/testsuite/gdb.arch/aarch64-sme-regs-unavailable-3.exp ... >>>> ERROR: no fileid for ubuntu >>>> ERROR: no fileid for ubuntu >>>> ERROR: no fileid for ubuntu >>>> ERROR: no fileid for ubuntu >>>> FAIL: gdb.arch/aarch64-sme-regs-unavailable-3.exp: prctl, vl=32 svl=256: check_regs: incorrect ZA state >>>> ERROR: no fileid for ubuntu >>>> ERROR: no fileid for ubuntu >>>> ERROR: no fileid for ubuntu >>>> ERROR: no fileid for ubuntu >>>> ERROR: no fileid for ubuntu >>>> ERROR: no fileid for ubuntu >>>> ERROR: no fileid for ubuntu >>>> FAIL: gdb.arch/aarch64-sme-regs-unavailable-3.exp: gdb, vl=32 svl=256: check_regs: incorrect ZA state >>>> >>>> === gdb Summary === >>>> >>>> # of expected passes 12751 >>>> # of unexpected failures 2 >>>> # of unresolved testcases 11 >>>> >>>> --- >>>> >>>> I wonder if it has anything to do with the fact we first invoke the gdb_caching_proc >>>> allow_aarch64_sme_tests which in turn calls the gdb_caching_proc aarch64_initialize_sme_information. >>>> >>>> Both call gdb_exit, because they run separate sets of tests. Maybe that gets recursive. >>>> >>>> This was uncovered now because sme tests are only executed in emulation, and that doesn't >>>> get tested as often as we'd like. >>>> >>>> Any thoughts? >>> >>> I'd start with adding some logging in gdb_cache_maybe_gdb_exit >>> (lib/cache.exp) like: >>> >>> proc gdb_cache_maybe_gdb_exit { name do_exit } { >>> if { !$do_exit } { >>> return >>> } >>> >>> # To track if this proc has been called for NAME we create a >>> # global variable. In gdb_cleanup_globals (see gdb.exp) this >>> # global will be deleted when the test has finished. >>> set global_name __${name}__cached_gdb_exit_called >>> if { ![info exists ::${global_name}] } { >>> verbose -log "XXXX: gdb_exit triggered by cache" >>> gdb_exit >>> set ::${global_name} true >>> } >>> } >>> >>> then check to see if this is triggered anywhere that you don't expect it >>> to. >>> >>> I'll keep looking on my end to see if I can spot anything. >> >> OK, I see what's going on. >> >> In the first test script, aarch64-sme-core-0.exp, we call the caching >> proc require allow_aarch64_sme_tests, which calls >> aarch64_initialize_sme_information. Both of these call gdb_exit, and >> this fact is recorded in the cache. >> >> In the second test script we also call allow_aarch64_sme_tests, but the >> answer for this is now cached so we invoke gdb_exit (for consistency) >> and then return the cached answer. So far, so good. >> >> Now, the expectation is that caching procs only run their body the first >> time they are called, so a future call to allow_aarch64_sme_tests will >> not call gdb_exit. >> >> Later in the second test script though we call aarch64_supports_sve_vl >> (which is not a caching proc), which then calls >> aarch64_initialize_sve_information, which is a caching proc. However, >> this is the first time that aarch64_initialize_sve_information was >> called, so we call gdb_exit, which is what causes the problem... >> >> The quick fix is to call aarch64_initialize_sve_information before the >> test is started... but that doesn't feel like a great solution. >> >> I'm still trying to work out if there's a better way to fix this. >> >> Thanks, >> Andrew >> > > Ah, thanks for the info. I was checking the code flow with the debugging > output. > > I suppose we could simplify things a bit and group the sve/sme querying > functions into a single function that gets called in the same order > everywhere. Say, a scalable extension initialization function. > > That might leave things open to other folks calling things in interesting > ways that might break the caching ordering though. > > In any case, I'd be fine to do the grouping thing. Wait, maybe I confused things a bit. Is the actual problem that we're not invoking the gdb_caching_proc function directly, and instead are calling it indirectly through some other function?