From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8FFmJoX1CGhCggEAWB0awg (envelope-from ) for ; Wed, 23 Apr 2025 10: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=ozMT+TDD; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=ozMT+TDD; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 8BD1A1E0C3; Wed, 23 Apr 2025 10:13:25 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 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 D985B1E0C0 for ; Wed, 23 Apr 2025 10:13:23 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 73DD43857C7B for ; Wed, 23 Apr 2025 14:13:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 73DD43857C7B Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=ozMT+TDD; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=ozMT+TDD Received: from OSPPR02CU001.outbound.protection.outlook.com (mail-norwayeastazlp170130007.outbound.protection.outlook.com [IPv6:2a01:111:f403:c20f::7]) by sourceware.org (Postfix) with ESMTPS id 115CD3858D26 for ; Wed, 23 Apr 2025 14:12:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 115CD3858D26 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 115CD3858D26 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=2a01:111:f403:c20f::7 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1745417564; cv=pass; b=DDREJqHE9GFx6VsTwqbv8pigP7BD+DPN5Zj3hlvgsN79yxWN0zeJse1h5+7At+wv/MlnTFpRRDhMjIIBOunxCWgnOiQlLsftVrAuz0cZfpazi+DUw50wAyG6s7Kh2ZLm287pOUFGEA6EQ+3fVI63iaR/sArf/01nAwAtWOgyESY= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1745417564; c=relaxed/simple; bh=b5cG+M02Cy+0tMlqOnSz+/IuLvpQBX7dCpMIpPpz6VQ=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=ORGY7C7fUNXRWv09Ul0i1HBi9BCdWAq2Z6EudBmLRSxt+u7NEV7RMC1uhBuxRHkyDEXQPOvEcGPT5htzMzWma2UP6EZs0kqeAulrayZKXdvtF6tpxDlnDWlx/CMP9UHKeksGFm9LqYHb/dPtK52l3cvguthnyBPdG38hYNm0zeA= ARC-Authentication-Results: i=3; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 115CD3858D26 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=yJQ92nx+5GniAiOqyDKjy83HELcOkc4Vjc4UlO7K1aq5uaLHqD/EU2wCrxnXFlUg3ufZMJjg9CSm3QlFSuQQz2L3beXwX3HhPGbB7UCmxzVWLXuqSY+vR1ygxY7iDNexA7fH1riJfuAhvvdw6rtYNwpEWTDFR6eS4+zykl2XBgHvx6qlEgz1laM8gvzsALTPHwZ3SCnz5KmIlVpi9yDqbs2CLX4zA0LfJ/ojuIJyHhdEnqYm1IKA2+Se/ICt8QAtg0N8ee2yJhcPyrO02Ukn6MsnEzuRvlBqUKiciMERYDpfWZFYmpfmJ0v/p0cw65eSLSIta/j7hufC+LRTceX30Q== 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=BtFduKiLvlRH0h60zm3LIaC2ge0wSxq6jJy14bsQHc8=; b=fc5wHrhY6U93E0LbqJ3N5OjJHB7tpFRwZVoERVMae7C4Tz+FzvxILdNjprl6LfyXuzgkKpizrbQ0CTvnOnzx260A9acDEkwqaBItJVGoz+kykJRYZLHPiQtGMWKxYV0MhLSebm82f7SFv6Yay1PPE7ZnwkCOyfxGRTfxkc6jvxCvlyQGLwd1O8O6EJ7SW077g15R/7WmswVqrlyURPm1yj9vZB23hYND1XWfRyPHlSMt4dHkVdvSrBxE2etKtizYfqhahdtIVNEAGilFYovr2lcXlERaCeLx3k5czlj/c2XlnsmT/wNFim5n+SA/JPg3440OaK0YI8OyP06nNMeyUQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=redhat.com 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=BtFduKiLvlRH0h60zm3LIaC2ge0wSxq6jJy14bsQHc8=; b=ozMT+TDDwSQA/hru/w76NF7cCA+HIXC/G52ivRk2ZPKoV0Xrjq6AUo0gKyecslU0XheCXC9rqWZZE4bdglSagCs76q/vqh53bBcFe1M4E5ZwOSxeVJi+pOwFiXSQSYF6L0ewzkTYyXqu9qSkFczrnOU15AKahETRBEzTfa6c87M= Received: from AS9PR06CA0624.eurprd06.prod.outlook.com (2603:10a6:20b:46e::27) by DU0PR08MB9608.eurprd08.prod.outlook.com (2603:10a6:10:448::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8655.35; Wed, 23 Apr 2025 14:12:38 +0000 Received: from AMS1EPF0000004A.eurprd04.prod.outlook.com (2603:10a6:20b:46e:cafe::16) by AS9PR06CA0624.outlook.office365.com (2603:10a6:20b:46e::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8655.36 via Frontend Transport; Wed, 23 Apr 2025 14:12:38 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) 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 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by AMS1EPF0000004A.mail.protection.outlook.com (10.167.16.134) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8655.12 via Frontend Transport; Wed, 23 Apr 2025 14:12:37 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=r7iJW9T6HdaGHpRgDD15WFKOqvAus5vD4rzBzEHdu7QGrtIXT+vrv4BDzXk2tcywj6Rn5XMKYHbScR/FBsZ799IMjp5nPyFz55rq3Jg3KKURJzHt3sCrDa+QsApvxLVgvP1+6CtnV1plMWlfCJg9spbLLXYAU2nlNiCKNZT94md3tLxVsqSZqhPfo1Y4xwzfHRtctDb1nxHyQXABAFijweSrbA06E41XYEbhJz67AbtGPUVRB+ep8uIYg5NjWvs+5twgR6ZmruL2OxlI3i5l+fN1nHCkFSx0jLdz7e7qc65wNFE7FJyuwwFHRMG+73DlalC12CTLp46ZYJfhu0bn3w== 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=BtFduKiLvlRH0h60zm3LIaC2ge0wSxq6jJy14bsQHc8=; b=qXUqlWSVrcrEZs6gh4dXsvbJuMScjxXCqUxKMlJNgkB3vuSraAUPLsA69POeknBli3uqjfLJtKU0aG3IThZP9EgHNnW3XBBNXHHGgPerdzVEerMWUbZ/Wq5A3jku9vxVKNjDcsyqs0nVoBo7+AFFpx1d1oP8z/vpHq6c8zy5V0ChW2xlXwqCoh4MU3xA04t6c6DI14oj+/1dYS5cntBTvIgnTulbyitDNGce54XcK45Js6qO5l9weX/ncA7if6QVT4mK8Sb5gS7tLViX42GZpbRFTD8XxAfANFN2Z9cqtpbPUJkHqos4EW+0UkCqYN7jhyfZcyfpOYQI5Fmgay8RDw== 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=BtFduKiLvlRH0h60zm3LIaC2ge0wSxq6jJy14bsQHc8=; b=ozMT+TDDwSQA/hru/w76NF7cCA+HIXC/G52ivRk2ZPKoV0Xrjq6AUo0gKyecslU0XheCXC9rqWZZE4bdglSagCs76q/vqh53bBcFe1M4E5ZwOSxeVJi+pOwFiXSQSYF6L0ewzkTYyXqu9qSkFczrnOU15AKahETRBEzTfa6c87M= 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 AM7PR08MB5445.eurprd08.prod.outlook.com (2603:10a6:20b:10d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8678.23; Wed, 23 Apr 2025 14:12:03 +0000 Received: from PR3PR08MB5852.eurprd08.prod.outlook.com ([fe80::f44:d113:1c29:825d]) by PR3PR08MB5852.eurprd08.prod.outlook.com ([fe80::f44:d113:1c29:825d%6]) with mapi id 15.20.8655.033; Wed, 23 Apr 2025 14:12:03 +0000 Message-ID: <6cd7b690-6440-442a-88cf-a36e14a5481f@arm.com> Date: Wed, 23 Apr 2025 15:12:01 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 00/11] GDB-internal TLS support for Linux targets Content-Language: en-US To: Kevin Buettner , gdb-patches@sourceware.org References: <20250404234324.1931302-1-kevinb@redhat.com> <20250418113622.2bf410b7@f41-zbm-amd> From: Luis Machado In-Reply-To: <20250418113622.2bf410b7@f41-zbm-amd> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0216.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:33a::8) To PR3PR08MB5852.eurprd08.prod.outlook.com (2603:10a6:102:8e::21) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: PR3PR08MB5852:EE_|AM7PR08MB5445:EE_|AMS1EPF0000004A:EE_|DU0PR08MB9608:EE_ X-MS-Office365-Filtering-Correlation-Id: 9a85246f-a86c-4617-1d91-08dd8270e682 x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; ARA:13230040|376014|1800799024|366016|13003099007|7053199007; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?VEwybnBoSmZBMWVtMUl6NUFYOGw4SDF5RXdkbmhLMGh4ejhCeEJRc0tjaVkr?= =?utf-8?B?eFhyanQ2NnNtQ2l3SG10OExaNmZnK0JpeFJlM3VvNmdzMFBVaGxVWVJQSko2?= =?utf-8?B?RlRLbFp0R3BnT3VYdzB6ZXlrMXlpbFlrU0RIV0E0VE5pZlZFREZRT2pKcFd3?= =?utf-8?B?QmNoOTB5WjBJYWljWDNPRUp5dWcvelRzZDBoWTl6a1pRTmZGMTVQQnYyNmp3?= =?utf-8?B?Q1Z5dzJrWlNNdEtWVjh0M1hMTGtHZ3cxVjRGeGd1QmNUYlIvYjlTbGJVbGlh?= =?utf-8?B?VkNBZFJGaDBvSkt2T29sS0JVTm9yNFArVC9EYXNpZVRUSlBiV1UxU0ZFM014?= =?utf-8?B?WGVYOWZaN2JBTDlSVGNzZFJBUDlKZVRCQ0xMNDdLdStSczVWTkxSa1VKYzN0?= =?utf-8?B?dmM3MmdiVERqNG82cmI5NjdYT2ptNnRyUmVDT0RGMnRDZWRkQ3ZkUThpWVd2?= =?utf-8?B?ZWpGZCtCYmcwQk1sRHVYaEhNdXhnL210YjJjb1kxL0hqcW5OMzdQSVY1ZmVn?= =?utf-8?B?RXR2S3JJWVY4eFdyaEtMd3YybWpXM3grbDNuam9EdzdQRzFxcnVPVFpMV1pw?= =?utf-8?B?M1c0enFiVyt1aHp6elhCeFBmaSt0SzNTT3lWS01Ua0FYbjVMc051amk0Q3N0?= =?utf-8?B?V041WUFIeGhjcGxKQ1Z4YksrY2xRSXNONGZQQlNqM3NZQ0FCNk5QZ1pWeHdL?= =?utf-8?B?aDBveEd2VVV3WmtubHRYVDNJVHZQVWhqRjlrSXo0ZGloK2Z2ZkxsOXhOeHJv?= =?utf-8?B?b0pWT1luVWZGa0lLSnluS2xYeVFZbjRJMFFtQ2VVWWgwampKNGJFWmh6V1Fr?= =?utf-8?B?dmRjUk1OelpTdDhSWVo3NHd0TFhSTU5VQlo0YUhUYlArSXFUcnlZL1lvN3lT?= =?utf-8?B?MEd4VVpWb1hBZGZ5VlFkald2bzJXMHpEZFFRZ1hMWXVHWFl6R1F0VDZiRTdv?= =?utf-8?B?d2djUjJra0xURFl2QVNOcVU3MURraHBkNmIyUjJiVXN2NFBSZWxMRjNHQ1JN?= =?utf-8?B?UjZHdDQ0U21UTm81bmZidCtRMitwZzhvT3R6VG9zYnNKTDFHL29IREJSenRn?= =?utf-8?B?eXJBTzVvNWp4bzNWNXlaTE93eWFsN05QRUtaenRoc3hBNWhBalpsSlVxTzFj?= =?utf-8?B?ektOV1J5YkJKNmNDbmlrK2ZuTFcwdEl0Q2tVMjhKKzJBMXQ5WisxUDFkUlBa?= =?utf-8?B?a1pBdTlFVWo3Q1NPdHRLRVVXTWp3OFdENEY1TlpjZk9xcDZmNHRHbEliMzFF?= =?utf-8?B?WDdFd05IVDZqU1ZMdlFTZDZNdGttc1dGTGE4dHBEQjlBNGlMVVJsSVZpaVVY?= =?utf-8?B?NFBEVEpxME40bytSc29IOXB0YnN6T3ZpVjcwdVNzZThwbVdZaHNXb1hKNHlS?= =?utf-8?B?MWR6clNBYTVyK0VpdFIwb29RRW5FYUhxMHdJVkJ0RmxDSFNXT1lRSC9zaDd1?= =?utf-8?B?ckhreGp2UE8ydkpCak05bkY2ajVmZjdqWEJhNjFUbTRuajMrUEJ6SWI0VWZh?= =?utf-8?B?TStSaFNOeE9mN0NIdEdkeEJ1RXVoNGtSdUZHQ3lYSUJkRG9ZMHE2RkNrVVNQ?= =?utf-8?B?aWo1RDhyWEZ0RmRKMDlNaGIrNVB1cEpzZGhYZG44bmhSVzJEN3A1dzdkUm9k?= =?utf-8?B?aDRGaGFkbEcyY0lUNXNXNUZYaU1Wd0lvVDhTcllOY0oyZnRhZFZoMGFHOFFN?= =?utf-8?B?RWpDY3B2d0RWMWtORXFIaXN3MWp3aDRiWmdPYUYzLy9ZY1E0bDlFRlFncWtE?= =?utf-8?B?MzQyTjZkMU1PVEE3MnhlQnl5MUZ3NUpqSDQzdi93V2JQeC96b09FVHJ1Wnd0?= =?utf-8?B?NFVWaXBTVkEvcHFxOVpKdmxjWUxadmJWZUFRcm9WOXgwZC9kV1Ixcnd3RHBZ?= =?utf-8?Q?4t8ypZOUKKM0Q?= 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)(376014)(1800799024)(366016)(13003099007)(7053199007); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR08MB5445 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AMS1EPF0000004A.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: bffe49b1-9bab-4f12-4e0b-08dd8270d1fc X-Microsoft-Antispam: BCL:0; ARA:13230040|376014|35042699022|1800799024|36860700013|82310400026|14060799003|13003099007|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?THdiZi9Jc1ZySXBZSGtyUXJvcnp2akhGMjVPY1Y4dEZNYk9ZS1V5eFdWdWNO?= =?utf-8?B?UEEwZ3VLSE4xSlF4WG9VNWRyVm5vaVNTRENJSlBlckl0eEVTOFBQNFdnQlQv?= =?utf-8?B?cmFoaTRhajQ0dmNzeEllTXlpczRQdXc1enpnWkxVSVBuT1FpQmtGM2NFSTNw?= =?utf-8?B?UjRQTVV6OVM1R1RrclRRQ29LQjRkYkdsOUYzYW5oQUtlcXRZRTY2TGZCQ2oy?= =?utf-8?B?ZGtVUUY4VC9MMmd4MFFhaUJVSGxRK1puMkxGalRuR0ZFWFpLMUNqdTJzMXFr?= =?utf-8?B?WDFYeElpbFRKakRkcTRubEdwR2l1cGk1V0VVN1JYZ21ScHBiTmc5MW9RZHN5?= =?utf-8?B?dm5OY1pjK01UbXZSenNONDdWRkI0cG5XSlRqeVQ5NVRyTXIwbDRiZUJyV3Bv?= =?utf-8?B?ZUU0RVBWbFByaU1uMkxwVjhtOUtsUUx4bG1JYXY3WE9mU3lIMUhpWjRQK3RQ?= =?utf-8?B?Z3ZGc01sakhZZWNBYS9LRW1iK3V2NXAwWWl6VEozTDFTczRUZ1lnRkE3a1Nj?= =?utf-8?B?WG5vbCtnaFU0S1ozbDM2cUk2cjlMS1VFeE9TaGJOMTF1b09jK1E5dmRxYXph?= =?utf-8?B?Q1JqSFhraGtpTFlxZktTOVN6Y1BxNENlSHZKaDVXU1FuTnM5aFpUTWphQkVw?= =?utf-8?B?SjRhbG5ZY2doMHBYRnhGZHdqbUFpcEswMW9pVmlNc3pDNTNFeWx4RVRLcDho?= =?utf-8?B?K0g3blpTKzlaMkZuNnlqSk53M3RCK3J4bDBCS0x6aExaK1Y0aEZjUk1BcGg2?= =?utf-8?B?TElzTVM0aFc0eE9VaFRkdlBBSW1WaE9pS3ZGVlh1WXM2SDI0eUQ2TmtJK0FS?= =?utf-8?B?MkFGQUFTS0hML2JzNnp6REV4dDkrd2hFQjhhemxDeFVzKzJCSnhpUUNsbkor?= =?utf-8?B?N1ZOMi9YMDVmUkJIRVh2cUdmYTR1bHdST2xpR3BXL3lwazIwNGRYNndDQnZR?= =?utf-8?B?MDhBdng5VkoxdjRMVHRmeWNXS0xFYmE3L2haV2twSk9XTzhkUENCNG1XYzE5?= =?utf-8?B?SWV5SGhkSFNqMDF5Y0Y3ajBpRUpLWmVJUDlkTGtGSWRvdXFHK2pBWm9uQk1s?= =?utf-8?B?WEpCeHRaeGhOdGxjcVlOT1M5YnB2cStMK0R0aytZaVFONytxL3E3cC82Q1hE?= =?utf-8?B?SnMrb1NvL1hsbnNybHIrcDJOSElOZE5wQUQzUkYvUFZWNG5sTjlDQTIwSGN6?= =?utf-8?B?bXh1bUVzOERFTXJmOFY3QjArcGpFNTU1aUdGRmRGWUN3aXNDNEFQbmZXc1d6?= =?utf-8?B?M2hRTFlHMWNtTUI2cDdsQUZIUVkvL2ZCSkpGT3c5ZWNlMzR1QzF6c3MraEwy?= =?utf-8?B?c1poZks1THV2cFhBY3ZxNnlJN3JsTXJsUWRJaVRvNGREK2t2azNNejBPMDUz?= =?utf-8?B?aDJXVGd2Y20zQnVwQzc1dDlNUXhWS0lGR1VpTWpRUzhCeXdwSm9WUDFDekRY?= =?utf-8?B?bThBVjN5b2JyblF1QlNoUHdnVk1XSUlBRDVwN2RiZGNpYjYyUGNLRW1heHRS?= =?utf-8?B?bE1KY3c5c0JXMmIzRXd2MHU0RlJZZWxLbGphQVNnMndiWW1FRFNaWTIzTjVD?= =?utf-8?B?eUxnWWVyUlFNWTF1ZTI2MGZ6VEdab3RFOWh0UEFFejJmcFIyZmdnU2RyUEVR?= =?utf-8?B?TnhpVUoyQXNnWVkxQUJEUFFhQTJlK3ZsWkhQNXMrMDVreWpkakxFek93alpl?= =?utf-8?B?YXNucmZSY3R4N1ZMZGNXYXdDWHdkdFh5UEpWTmFraHJ1VnozSWxQN080TTFI?= =?utf-8?B?UytrT2YvOGpySzZGMitkd0x6TnVSRG9rWXNtWC9jdHl4OVR2WTJhY2FRQXVR?= =?utf-8?B?elRiRTNhYkl6a29KZTdGbFpFR0NwL3djN0drWGI1RE80TjJmZlZSdzBiTURm?= =?utf-8?B?bzFzd2lhODZlcDFUdkhDL0xyM1A2SjM4aTYvek9jM09McE44UzBzdkpWSlZu?= =?utf-8?B?OU44ZHkxUksxam5IVnNEZWZETzlLcW1KdldOZFN3YjFkR2doWlkwcUZxUWt2?= =?utf-8?Q?nIOl61E+sFnz8qwb50Poou+9OZgh68=3D?= X-Forefront-Antispam-Report: CIP:4.158.2.129; CTRY:GB; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:outbound-uk1.az.dlp.m.darktrace.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230040)(376014)(35042699022)(1800799024)(36860700013)(82310400026)(14060799003)(13003099007)(7053199007); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Apr 2025 14:12:37.1400 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9a85246f-a86c-4617-1d91-08dd8270e682 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[4.158.2.129]; Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: AMS1EPF0000004A.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9608 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 4/18/25 19:36, Kevin Buettner wrote: > I plan on pushing this series late next week (on or around April 25) > unless there are objections. > > Kevin > > On Fri, 4 Apr 2025 16:37:31 -0700 > Kevin Buettner wrote: > >> This series of commits adds internal TLS lookup support to GDB for the >> following Linux target architectures: x86_64, aarch64, ppc64, s390x, >> and riscv. When available, libthread_db support for TLS lookup is >> still preferred/used since it should be more accurate. This means >> that existing TLS support will still work as it did before - this new >> TLS support will only be used when libthread_db TLS support is not >> available. That said, it is possible to force internal TLS support to >> be used via a new maintenance command. >> >> Three of the commits in this series provide knowledge about how to >> translate link map addresses to module ids and how to traverse various >> TLS data structures. The latter problem is broken into two parts, >> one which applies to all Linux architectures, and a second which >> adds architecture specific knowledge about TLS data structures. >> >> Translating link map addresses to module ids is tricky. In theory, >> the module id is available in the link map data structure, but it's >> not part of the ABI. I ended up implementing two mechanisms for >> doing this mapping, one for MUSL, and one for GLIBC. For both of >> these, I think the method that I used is less fragile than attempting >> to use an offset to the module id field for current versions of these >> libraries. >> >> Traversing TLS data structures starts with obtaining the value of the >> thread register (or registers for S390X), then finding the field >> containing the DTV (dynamic thread vector) address within the TCB >> (thread control block), then using the module id as an index into the >> DTV in order to obtain the TLS block. For some architectures, the >> MUSL C library requires that a final adjustment be made to obtain the >> actual address of the TLS block. >> >> This patch set also shows how internal TLS support might be added for >> i386, however, due to problems with accessing the gsbase register, it >> doesn't work, so the commit which adds this potential support is then >> immediately deleted in the next commit. The point of doing this is to >> make it available in our git repo to anyone who wishes to work on i386 >> support. IMO, it's not worth doing without also doing corresponding >> ptrace work in the kernel. I think this would have been worth doing >> back in the i386 heyday, but is not worth doing now. That said, >> should anyone wish to look into it, the commit showing how to do it >> will be in our repo as well as on the mailing list. >> >> The details for traversing the TLS data structures differ not only >> between architectures, but also depends upon the C library with which >> the executable being debugged has been linked. The internal TLS >> support in this series is known to work with GLIBC versions 2.27 thru >> 2.41.9000 and MUSL versions 1.1.24, 1.2.3 and 1.2.5. For MUSL, the >> support provided by this series provides new debugging functionality >> that didn't exist before - it will now be possible to examine TLS >> variables in programs linked against MUSL. (It didn't work before >> due to MUSL not implementing the libthread_db library.) >> >> I've done regression testing on recent Fedora versions for all five >> architectures. Bugs were found and fixed during that testing. >> >> Once that was done, I did even more testing, using a limited number of >> tests. These include the new tests that I've added, plus those tests >> with which regression testing identified some problems. The list is: >> >> TESTS="gdb.base/tls-dlobj.exp gdb.base/tls-nothreads.exp \ >> gdb.base/tls-multiobj.exp gdb.threads/tls.exp \ >> gdb.server/no-thread-db.exp" >> >> I tested using targets: >> >> unix, native-gdbserver, native-extended-gdbserver, >> >> and, for x86_64 targets, I also tested with 32-bit variants: >> >> unix/-m32, native-gdbserver/-m32, and native-extended-gdbserver/-m32 >> >> I also tested with no CC_FOR_TARGET (which defaults to gcc), >> CC_FOR_TARGET=musl-gcc, and CC_FOR_TARGET=clang. On Fedora, using >> CC_FOR_TARGET=musl-gcc causes the program and libraries to be compiled >> with gcc, but linked against the MUSL C library. I didn't use this >> option on non-Fedora machines, though my Void linux testing tested >> using the MUSL library since that's what's installed in that test >> environment. >> >> I also ran additional tests using check-read1 for combos with no >> CC_FOR_TARGET. >> >> Using all sensible combinations of the above, I tested on 13 machines / 5 >> architectures: >> >> x86_64 / Fedora 28 / glibc-2.27 >> x86_64 / Fedora 34 / glibc-2.33 / musl-libc-1.2.3 >> x86_64 / Fedora 35 / glibc-2.34 / musl-libc-1.2.3 >> x86_64 / Fedora 40 / glibc-2.39 / musl-libc-1.2.5 >> x86_64 / Fedora 41 / glibc-2.40 / musl-libc-1.2.5 >> x86_64 / rawhide (fc42) / glibc-2.40.9000 / musl-libc-1.2.5 >> x86_64 / OpenSuse Leap 15.5 / glibc-2.31 / no musl >> x86_64 / Ubuntu 22.04 / glibc-2.35 / no musl >> x86_64 / void - 2024-03-14 / no glibc / musl 1.1.24 >> >> aarch64 / Fedora 40 / glibc-2.39 / musl-libc-1.2.5 >> riscv / Fedora 40 / glibc-2.39 / musl-libc-1.2.5 >> ppc64le / Fedora 41 / glibc-2.40 / musl-libc-1.2.5 >> s390x / Fedora 40 / glibc-2.39 / musl-libc-1.2.5 >> >> The point of testing old Fedora releases is to be able to test >> older glibc versions. In particular glibc-2.33 and earlier >> had pthread functionality split into libpthread.so while glibc-2.34 >> and later place it into libc proper. >> >> All of the testing went well except on riscv and s390x with >> CC_FOR_TARGET=clang. That's six test runs total, and they each show >> 799 FAILs. The test results show that riscv mostly prints the wrong >> answer and that s390x shows output like "Cannot access memory at >> address 0x3fff8d494e8". But this happens regardless of whether >> internal TLS support or libthread_db support is used. I think it's >> likely that it's a clang bug of which I can do nothing about (aside >> from filing a bug report). >> >> The v2 series fixed some problems in the gdb.base/tls-dlobj.exp test >> found by the Linaro regression tester, tweaked a comment in >> aarch64-linux-tdep.c, included a discussion of what TLS is in the >> documentation patch, and renamed 'set force-internal-tls-address-lookup' >> to be a maintenance command. Thanks to Luis and Eli for their >> feedback on the v1 series. Thanks, too, to Linaro for regression >> tester feedback. >> >> The v3 series made corrections to the documentation, as requested by >> Eli. >> >> The v4 series fixed some other documentation nits. >> >> The v5 series moves the "target has registers" check and output of a >> suitable error message into target_translate_tls_address. In v4 and >> earlier, this error check was being performed at some of the call >> sites for target_translate_tls_address. The entire series has been >> retested as described above, though on a subset of targets. All >> five architectures (x86_64, aarch64, ppc64le, s390x, and riscv) have >> all been tested though. Additionally, testing has been done on >> machines with recent glibc versions in addition to a version of glibc >> which predates 2.34, specifically glibc-2.33. >> >> This v6 series addresses a problem found by Andrew Burgess: In his >> review of the v5 series, Andrew observed that not all Linux targets >> use SVR4 shared library support, and therefore can not depend on >> extern functions defined in solib-svr4.c to be available. One example >> is FR-V Linux which uses solib-frv.c in order to provide support for >> the FDPIC shared library ABI. I addressed this problem by moving >> non-architecture-specific TLS code out of linux-tdep.c (which is used >> by all Linux targets) into a new file named svr4-tls-tdep.c. In order >> to make sure that svr4-tls-tdep.o is linked into the correct targets >> (when not doing a --enable-targets=all configuration), svr4-tls-tdep.o >> has been added to the target_obs definition in gdb/configure.tgt for >> the various target patterns which should have internal TLS lookup >> support. This change, which moves the generic internal TLS support >> out of a linux specific file into a new file, makes this TLS support >> infrastructure available to other targets which use SVR4 shared libary >> support, whether they're Linux targets or not. For example, GDB's >> GNU/Hurd support or perhaps BSD support could now use these >> mechanisms. (For the latter, I suspect that we'd need to teach it >> about BSD's libc.) >> >> Kevin Buettner (11): >> Don't attempt to find TLS address when target has no registers >> Allow TLS access to work in gdb.server/no-thread-db.exp >> Track and fetch TLS module ids for MUSL and GLIBC >> Implement internal TLS address lookup for select Linux targets >> Internal TLS support for aarch64, x86_64, riscv, ppc64, and s390x >> Internal, but disabled, TLS support for i386 >> Delete disabled i386 internal TLS support >> New test - gdb.base/tls-nothreads.exp >> New test - gdb.base/tls-multiobj.exp >> New test - gdb.base/tls-dlobj.exp >> Add TLS NEWS entry and document 'set >> force-internal-tls-address-lookup' command >> >> gdb/Makefile.in | 3 + >> gdb/NEWS | 20 ++ >> gdb/aarch64-linux-tdep.c | 56 ++++ >> gdb/amd64-linux-tdep.c | 38 +++ >> gdb/configure.tgt | 11 +- >> gdb/doc/gdb.texinfo | 50 +++ >> gdb/findvar.c | 3 +- >> gdb/linux-tdep.c | 1 + >> gdb/minsyms.c | 3 +- >> gdb/ppc-linux-tdep.c | 63 ++++ >> gdb/riscv-linux-tdep.c | 79 +++++ >> gdb/s390-linux-tdep.c | 44 +++ >> gdb/solib-svr4.c | 207 +++++++++++- >> gdb/solib-svr4.h | 12 + >> gdb/svr4-tls-tdep.c | 256 +++++++++++++++ >> gdb/svr4-tls-tdep.h | 59 ++++ >> gdb/target.c | 16 +- >> gdb/target.h | 8 +- >> gdb/testsuite/gdb.base/tls-common.exp.tcl | 50 +++ >> gdb/testsuite/gdb.base/tls-dlobj-lib.c | 87 +++++ >> gdb/testsuite/gdb.base/tls-dlobj.c | 311 ++++++++++++++++++ >> gdb/testsuite/gdb.base/tls-dlobj.exp | 378 ++++++++++++++++++++++ >> gdb/testsuite/gdb.base/tls-multiobj.c | 89 +++++ >> gdb/testsuite/gdb.base/tls-multiobj.exp | 230 +++++++++++++ >> gdb/testsuite/gdb.base/tls-multiobj1.c | 26 ++ >> gdb/testsuite/gdb.base/tls-multiobj2.c | 26 ++ >> gdb/testsuite/gdb.base/tls-multiobj3.c | 26 ++ >> gdb/testsuite/gdb.base/tls-nothreads.c | 57 ++++ >> gdb/testsuite/gdb.base/tls-nothreads.exp | 248 ++++++++++++++ >> gdb/testsuite/gdb.server/no-thread-db.exp | 4 +- >> gdb/testsuite/gdb.threads/tls.exp | 2 +- >> 31 files changed, 2446 insertions(+), 17 deletions(-) >> create mode 100644 gdb/svr4-tls-tdep.c >> create mode 100644 gdb/svr4-tls-tdep.h >> create mode 100644 gdb/testsuite/gdb.base/tls-common.exp.tcl >> create mode 100644 gdb/testsuite/gdb.base/tls-dlobj-lib.c >> create mode 100644 gdb/testsuite/gdb.base/tls-dlobj.c >> create mode 100644 gdb/testsuite/gdb.base/tls-dlobj.exp >> create mode 100644 gdb/testsuite/gdb.base/tls-multiobj.c >> create mode 100644 gdb/testsuite/gdb.base/tls-multiobj.exp >> create mode 100644 gdb/testsuite/gdb.base/tls-multiobj1.c >> create mode 100644 gdb/testsuite/gdb.base/tls-multiobj2.c >> create mode 100644 gdb/testsuite/gdb.base/tls-multiobj3.c >> create mode 100644 gdb/testsuite/gdb.base/tls-nothreads.c >> create mode 100644 gdb/testsuite/gdb.base/tls-nothreads.exp >> >> -- >> 2.48.1 >> > Do you have an updated series that applies cleanly on master? Looks like there are some conflicts at the moment.