From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ODYfJRuIOGiOeTkAWB0awg (envelope-from ) for ; Thu, 29 May 2025 12:15:23 -0400 Received: by simark.ca (Postfix, from userid 112) id 85FE11E11C; Thu, 29 May 2025 12:15:23 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.0 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL,RCVD_IN_VALIDITY_SAFE 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 D11851E100 for ; Thu, 29 May 2025 12:15:21 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3FD1E3857BB0 for ; Thu, 29 May 2025 16:15:21 +0000 (GMT) Received: from EUR03-AM7-obe.outbound.protection.outlook.com (mail-am7eur03on20631.outbound.protection.outlook.com [IPv6:2a01:111:f403:260e::631]) by sourceware.org (Postfix) with ESMTPS id DE72C3858C54 for ; Thu, 29 May 2025 16:14:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DE72C3858C54 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DE72C3858C54 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1748535290; cv=pass; b=FFZH+p+HQoTj0Hj4mWwKG8pPe1vY2td0U8V2gQMZuke2VHlGPFHLbVFknPPeV7sa+gwMw8eyQamgeKkgHIx1atVeW2Ow1H22x+M9BINCVmJjGwtBjRFXtp9gCBoLr1rDc6fiZ7OWG3LIuGBZWqVF9+fTmk2W+VpDQdWjPYis2WI= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1748535290; c=relaxed/simple; bh=kokWdir0LkKTGeOfHRQ+kKAnu6CLeP/ANeLhNvdfdcg=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:From:Subject:To: MIME-Version; b=lSY8pHs64hBABwmxCMIgePI55rNYIuppuRJD4b+9cHNMOnHaiDEmskfCLXgJmECuDWdCf+02Uz1VfoI6BwCQXGXQ0aWC7qjYvOncsBnlpIvGPARXPAhyn1WkhLUNsyuNZdibhps/wEmjpg/SXUQDUKIYWrhVadBxZkbYHL57jRM= ARC-Authentication-Results: i=3; server2.sourceware.org ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=xFXwtFYsjDn+eHGYSHu0nt4wVU62r04G0n24YOumZAMZgXdUqn5S8JH+cbvqXuDqfQEg8uTKShFD9/sm9Q97en1WZjM4tS6aGJgy56ZLwLxMSkXk+cW5eebtwMTDGtddUZPyYfX1UoCkemLJGKFXTogsAX7D+hXVjXwOKzguNftOH1Lwo8SimMs9P5KOEPK6ty2wX7RcUHGKcEDIQyzko4tp38wmMb82b+trINmgzFsU19PlioqYae9OnAd95M8FFL/+T6uT+SQmnMKpd7c4P8pAOTSxJpejoYXQRMEcv7l+zOkZDqxSQdNvcTPRNtLhYrgCOGFD/ql+dubp+oG2Tg== 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=xp6xuDQwK6kDH8UPrUUOz/dIklr0HmvhdOHXd4Ve/mg=; b=bcXBP3r4Oz3UCC7shVJzqadvn4/bEaXS5lgkvTD/BvtcJo8aGhEqurScXYHaMrESC4d5QoD5dWi2IQuyDRPnTUsFGUPesxx3hVMKp79HiYRH5XLAOxr0zzcLpdHkEalk2pKRH0lPPcyOZXqYRTXNou0JBglGlMPKWBPOlZI60Q9IfApr3pZRm4DWSByzgjA2yAi6LTxDzulIl7+nDGZ2T1LOb1TaljrUAlZXaxmakbOv9NGWJenj0bjxFVRiwt+TbPoOIejQg0AUazkyUtpEwQrSgsXLDoiZwry4tQdP81AdBmgF17K0g6Ppvegjem1/OWGij3thlh8TPI3kIfzn5w== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) 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]) Received: from AS4P191CA0039.EURP191.PROD.OUTLOOK.COM (2603:10a6:20b:657::24) by GV1PR08MB8081.eurprd08.prod.outlook.com (2603:10a6:150:97::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.30; Thu, 29 May 2025 16:14:45 +0000 Received: from AMS1EPF00000045.eurprd04.prod.outlook.com (2603:10a6:20b:657:cafe::e6) by AS4P191CA0039.outlook.office365.com (2603:10a6:20b:657::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.22 via Frontend Transport; Thu, 29 May 2025 16:14:44 +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 AMS1EPF00000045.mail.protection.outlook.com (10.167.16.42) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18 via Frontend Transport; Thu, 29 May 2025 16:14:42 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iYl+QBoG0folQUndAXeHeWXc9t+vx/cvRoehwjB8TysPNdnKCsyzA4qHP4zsQAJVwRoBuC+NDlHrub89dgPXG1A67MG14CMsU1aZeHU5uoHVuXBDYzjW37zFS0E3owRembOOq/InRAetlKWToW1BCM//rd21Lz3NdJTC1mmiWJc/QgcZ5yiXb46MLRwO3Dr9tjSPlhyYzOYqTux/Z2nP8v1bY6agzDyTImliPH7fn0fNhTbuMYtIASqRvhDjNcAjq6l9N6UV40byAHThiBU83yO+aZEY849qiftNnnSjZgTbErY7jyYVutjyiym4Ta7p9Y06cKy6SXy0sE8XnrLP7Q== 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=xp6xuDQwK6kDH8UPrUUOz/dIklr0HmvhdOHXd4Ve/mg=; b=M9Q57xZ1rp3gMNnyzEnUpDzlWNF+WUxix148/ZgV8Yd/RTfQTsC3Qvxmh9BsGcHZVfCLq935cAoPR24qxHVmjj38C3TY4r8rEXilfgtGqkysWuM3yIyk2qSkLO7/xiWW+c/MOsIr8Kq463fG5p3fMZBNrPGjwhuvLqdJMch9vPhxhlWPE95F19w0PTbDPI43rQd8MsGABS1JVXJvmNptB3FtkGVfuZbEyhpHlqfTSCQdW7lYsFNTilfXv06JNZ+hboIjCGboPSfTFv0yhckLqfynBsWP2/hLcE+7ff8VQaQjkyQnxvfHylLasQSituzKI2G2Sf2EnmwUQRHLgLt9fg== 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 Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from VE1PR08MB5872.eurprd08.prod.outlook.com (2603:10a6:800:1aa::16) by DBBPR08MB10464.eurprd08.prod.outlook.com (2603:10a6:10:53a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.26; Thu, 29 May 2025 16:14:09 +0000 Received: from VE1PR08MB5872.eurprd08.prod.outlook.com ([fe80::d9b3:7cc4:1aa7:7454]) by VE1PR08MB5872.eurprd08.prod.outlook.com ([fe80::d9b3:7cc4:1aa7:7454%3]) with mapi id 15.20.8769.021; Thu, 29 May 2025 16:14:09 +0000 Message-ID: <314abf0a-007c-457d-bcc3-c28384b9f098@arm.com> Date: Thu, 29 May 2025 17:14:07 +0100 User-Agent: Mozilla Thunderbird Subject: [RFC] Allowing GDB to use a more recent version of Python at runtime than it was compiled with To: gdb@sourceware.org Cc: Tamar Christina , Andre Simoes Dias Vieira , Tom Tromey , Simon Marchi , Luis Machado , Andrew Burgess Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PAZP264CA0032.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:122::19) To VE1PR08MB5872.eurprd08.prod.outlook.com (2603:10a6:800:1aa::16) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VE1PR08MB5872:EE_|DBBPR08MB10464:EE_|AMS1EPF00000045:EE_|GV1PR08MB8081:EE_ X-MS-Office365-Filtering-Correlation-Id: cb9f34fd-4cf2-4a49-9879-08dd9ecbebb4 x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|1800799024|366016|376014; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?alE1cFFzUi9hTUVacGROUGEyQk9MdUhuSFU5dHFrS2tmbVRhaFZ5UlhqV1BI?= =?utf-8?B?MXpUZWlSeDVmUjE2OVI1N3IwRE54Z29FNU5RQkNrb21SUE5pc3hNbG5WaDh5?= =?utf-8?B?dzBKaDVlaUx6cklvVERYM3VQK0ZodWFDK2Z5d2g4TS9uMHc3aWYrZHhjaW1M?= =?utf-8?B?Z3NLNnZXcXhVS2JwdUFHQVRpSEJ1c0dpd1prK0RiNk9jU1dEaktwSTQxdjlk?= =?utf-8?B?VjdENC9hYUhDQUh3NFptOEVIVktqNTZvdmxxeWVTUnpyZVl6QjR0a0ppVjJM?= =?utf-8?B?NDBlQkU2eEZMZjJ4d0FzVkZBZUxBSm5YR09EaHZYOVc1NVk2ZWZXVVR1TFJF?= =?utf-8?B?Y2p2Yk90YklGS1oxRk5LVm9obzNiclBRM2pTTk9hRThQUnZVSUFLYXhHVzRK?= =?utf-8?B?YVAwcWp2QWZYVDJpU1A2TkZ4d250RU5LYlc0YTQ3TG02YzBFL3hBNDljeUJF?= =?utf-8?B?SVZxR0NteGs5elpOcUhUOFdxeXpXUzBUMWREMXdheTBDMnF6aktmNyt5M09o?= =?utf-8?B?TWFPUk9Xa015czNZTmRHV25JTjEvU0Nkald2cTFTa2tvOC9tT1lBWExrVlFX?= =?utf-8?B?YU53aVFENmcxYmFTclBBMmc3cDJaVjBwdE9aNGFGdjMxR2YrbVZMZTJVVTF2?= =?utf-8?B?ZEo1Q3B1Uzc3ckFlYlBMVThqQWl1SkVld2Jwa2RkN0pyZWFvNnpFdDltdG1E?= =?utf-8?B?VEN5WE82UzMzWWdaM3FJclFDQitaMUlXaTZWVzI3aVJrTUlPNzB6U2RBdFRF?= =?utf-8?B?QkEzVVE1SU8ydVZocmFEZEE2OHNiY2d1Q3F1eXFPTWE1MkpQSkk5eklnYU9I?= =?utf-8?B?U2tnTjVObVJrWmdrZTdXSVM1WmkrQ3hXM3k5NlYwT0J0YzNiQTZUTVN0dDkw?= =?utf-8?B?bkVFWWNEeEliTXlvNFRCN2RkN3piNzRFRno4OXBrZFhPL3hmOThKckVXdTJZ?= =?utf-8?B?cEluZmVtekY4czRIcHZmUDhNWDdaVUhLWXh1YkhzaFhsakhDM0I2MEFTS3Br?= =?utf-8?B?WTlUU3IzZ1pRZHhYS2RIRkx1THhybVo0SzVGelNRUlF0eEE1cWJaQlA5OEYw?= =?utf-8?B?dVBjTGM3cG5mQ2F5OVZpYmtTQjlPMEpKOXJib0FGNmwyKzF2anllV2JSQVhm?= =?utf-8?B?a1djYnFwbjU3V3p1VmJGQ1FGcXlOdWdOSkN6V0RoWldROXg5bkJFVVFvdDZh?= =?utf-8?B?R3Z1VXJicmZHR1BLRkozQWFJUjUyQUZLQldGaVdQRElpUDJmSktraHRvRWlp?= =?utf-8?B?MUZrdlN1Rzl0OWh1YjJCQ1U2SGlYRjlDNDYreEt5U2Q5ZklFU21VdEJqKzVv?= =?utf-8?B?b2NTSXZGUmY2YnN2d29TelNBZEkwNmZLaS9hdXI2OGg4SVI4MlMvWFpFeWZK?= =?utf-8?B?RFhoSjV1YVQwVFZCWHVFMk1WYk5tdVJ4UFhRUFAzT21vcFNQcngvaERjVDRo?= =?utf-8?B?U1FzTkUvVktGR0EzOG9YNkFOeUtvQUloSDRLQXIzVVFFeXZpSTZLbGN4VitH?= =?utf-8?B?VUgwaFdNektSUDVYQ1QwQS91cUVWTmc4bG51R1YzSkJFYXQzSlZETGJsV1lE?= =?utf-8?B?Z216cy9NMUY2OHJEQVBFNGE0ZGl0VS9JS0NhcVA3THBTQjlaR3JJcnpWZko5?= =?utf-8?B?M2E3T1VlSHZYaXlTOU1McG51NDNVSWZUbXpuOGs5cmw1emVjeVBmSE5nU3gy?= =?utf-8?B?NHZvSGFBWGZOblJIL3hhZmRNRDA0blVORUVMK0JPWjFjSk5uU01EUmVrQmZu?= =?utf-8?B?Z2RsaGRweU41R2M3ZVoxTVBZeldya0ZPVUl1ZUFwNGh6cFlOeFlvMXdSbnlx?= =?utf-8?B?T2s1dXNRSDBPeSt0ZTFHL0QrZ1JvdnMyZGIvT0U1Zy8xZU1UQ0YxSnkyZFFX?= =?utf-8?Q?cy/IP11LsPI55?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VE1PR08MB5872.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(1800799024)(366016)(376014); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB10464 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AMS1EPF00000045.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: eab72dca-94be-46e0-cbec-08dd9ecbd787 X-Microsoft-Antispam: BCL:0; ARA:13230040|1800799024|36860700013|35042699022|376014|14060799003|82310400026|13003099007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?OUxHd2ZzK0ZmeU9ialY2Z1Q1N2dqcVpqWU9aMXBhenZKcUJ5S2Y2dFR2ZFE5?= =?utf-8?B?b3N0SzdiVW03bi9LNEZhSEc2N0RTS25PemFwdmlGQ0orQkZ1KzV5VUc4enMw?= =?utf-8?B?V21uN0hoV2tyTkp0emVWQkJNVjRraS9rcmtFaXdCWXlRUVZ0cWZRVTZCVEFh?= =?utf-8?B?UitEWCtMU3FaQjh3WFBvTm5Ta2x2aW9WTzExbldqd2tOS1dWaDBUWGdnUGR5?= =?utf-8?B?TzA1Sm1YQVpLWVV6emloMHZsL0toUUxQS09nb1dHd3VXMWJNMng1N3FKTFph?= =?utf-8?B?K00zaW1JNTlia2VVK0NZd2ViNVYwY3hBUWtBSGYxTnBLMEk3SGJkazA1aDlz?= =?utf-8?B?blByRlZXS3k1cU1BZmhCdXlmcDdtc3pFZVVyOXJOYnRlT1VZN2EvTVlNUStq?= =?utf-8?B?RUhZdU9HTEtiQWdHK25qZWx3WitOb1hrZnl1c0QwaGc4cHRhVTNWQUlDdGVj?= =?utf-8?B?WmZIRzJneHhYRERpU2pBeDZnK1pNVldCcVd1ZWdNbWV4aWJwTGsxaXQxMkZQ?= =?utf-8?B?WWdtOW5DTXFDWm9Jb0xHbzVOWkYzUWhIVGFNOVpQUXpYSmJaVkdBZXRRQmpK?= =?utf-8?B?b1BEcHhnaTNzUlA4YUc1eUZGa0tZOVlmSmIvZjBkUm1SaExnVnNRK3hGd0NO?= =?utf-8?B?bHBhb1A4dm1NWGNqWXVxcTBOYlJrSGxNTnRsdkhxOHVxTzMzZFQ4aTdzSERx?= =?utf-8?B?RE9XUnlLMm1tQU43K29UdWkyWEFyK3Q4UkRJZXRmNzV0SExHWDZGUW0vOG1r?= =?utf-8?B?eUc5SmgranhaSFhBUXNpbVFHM1JuZ2RBVkttTElUSGVUbHhQaFJmM25DOWZy?= =?utf-8?B?SHdweGdtWnd3THZVZWVUejhZOVE5ZkszUE94QW5GY1JURmZXcmRqT2YvbEMr?= =?utf-8?B?bHRnQzduVWZCQ01kZDREVmhiRzZzTmlNOGRMckxycTFaeVZkVG11bk5ldHJM?= =?utf-8?B?MEpxd2RVRTNzaENWRG0yV0NjaXFzbWhFMnU1QVlGZ0lzT204N1o2OFdvclMw?= =?utf-8?B?OUVVcGZCUmp0RUtiR29xbjlDcUdTenVCZHFJVjFZUmdvT0luZTVIOXVEV1pG?= =?utf-8?B?VzNPNGlzTUZWNDUvVlFPS2tGbzhwUjZXdS9nZXRwS2V3SzR5b1RKb25RQ0p4?= =?utf-8?B?TzFQYjByWjVDVnlKSk01Z2dYbjRmZnRCeEhoeWZlMmQ4K2ZxUEJaeU55NFFa?= =?utf-8?B?eHgycmdKbmR2RXp6bkNuVVB0eXU1WFE2YWFueU1TS1YxYkZUeUtRek5XSFdQ?= =?utf-8?B?cHA5NUJXVVVPbWZidTVYMVM5YTBuaWNsdGRJWG9NUzVqOFErcmlKWHlqR2lY?= =?utf-8?B?a0IxM3NGOU1Pd0g0VzR6V1JrNnJFWjNZUysvRzZCVUllejBVZURaTDYwTU0x?= =?utf-8?B?V2VDT1YxSFE0bXdHTFNEMEFHS25KZFhmbkp0VVd6N3NOOC9QL3BoaW16OXJT?= =?utf-8?B?NllDU2YwYjBSWEZDK0J5Sy9OZzJqQ2wyck5lN1VKTUVkMUFHQTJicFRwdE84?= =?utf-8?B?QXg5REZYNVlyVU1xeGhyYXUwSUJoUVRlUk9wVzluNDBGb3BYUE5iYTJrdTVj?= =?utf-8?B?TzdOd01qdDlJbnh0cGRUa2N4ZS92eTcyMU1XYW5LVEpqMDZ3S3Vrc2didXFX?= =?utf-8?B?cU5IL0NwUnM1Z2MrSnM3ekJEWStiVEJtaXM0eDl5a1BxbGY0YTRlWnpvQ1NR?= =?utf-8?B?Sjc5ZXdQVGNUVzNpSVZnUlFaaXRneGlkVXJGd0hQVEMzelo5SlBHYzlESzRq?= =?utf-8?B?b2tvam5hemJQMVlFbXY4bW85ZUs2bUp5dTJWdzBVazVWMkp5aUcwL1YySGZj?= =?utf-8?B?cUpvSGd2WEpGNTh1MWhmNEFBSE5reEtoRldGWEhGK09IVWJ4WVBtTjJSVnIz?= =?utf-8?B?WHMvZ3AyemhDMHRiRGNySlpoVDZGL1ltQ1QydktoK1JqR1pBWDh1TDJsTkVQ?= =?utf-8?B?UzJOQytZblhOWFZOVGtQWU9Sd0FxT1crK0FvbVhtVXozUks4bFNtUHg5VDMw?= =?utf-8?Q?5daH+pY7ID5Hjnxk/QW4y7C3zA6ULc=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)(1800799024)(36860700013)(35042699022)(376014)(14060799003)(82310400026)(13003099007); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 May 2025 16:14:42.5586 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cb9f34fd-4cf2-4a49-9879-08dd9ecbebb4 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: AMS1EPF00000045.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB8081 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Matthieu Longo via Gdb Reply-To: Matthieu Longo Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" ## End goal Allowing GDB to use a more recent version of Python at runtime than it was compiled with. ## Arm's context We have a CI building release artifacts of Arm GNU toolchains (GDB is shipped along the toolchain) on a Linux distribution with the oldest glibc version among all the distributions that we want to support. The rationale for using the distribution with the oldest glibc version is to leverage the ABI backward compatibility of glibc. If we build a C binary on the old distribution, we expect it to work on more recent distributions. Same thing for C++ artifacts. See https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html for more information. However, CPython does not provide backward compatibility guarantees as glibc or libstdc++ does. This means that a GDB compiled against an old CPython won't run with a more recent CPython due to ABI divergences between the Python versions [1]. This situation obliges us to provide GDB with two flavors, one with Python support and one without (in case there is a conflicting version of Python already installed on the system). ## General packaging difficulties Usually, Linux distributions embed a default Python version and don't change it much along the life time of a release. Providing a GDB for a distribution means that we would have to compile and bundle a GDB for each of the supported distributions. Given the number of distributions out there, this approach does not look very sustainable for us (even using Docker [2]). Others platforms, like Windows, don't ship Python by default. This means that we cannot know the version of Python that the user has installed or will install on his machine. ## How does CPython propose to tackle this issue ? PEP 384 – Defining a Stable ABI [3] and PEP 652 – Maintaining the Stable ABI [4] defined a Limited API and Stable ABI, which allow extenders and embedders of CPython to compile extension modules that are binary-compatible with any subsequent version of 3.x More details about the current state of this limited API is available at https://docs.python.org/3/c-api/stable.html ### Experiment: build the master branch of GDB with the Python limited API I defined `#define Py_LIMITED_API 0x03020000` (Python 3.2: introduction of the limited API) before `#include ` in gdb/python/python-internal.h, and tried to recompile GDB to have an rough idea of how many incompatibilities there is. I got errors about Py_buffer and PyBuffer_Release (part of the Stable ABI (including all members) since version 3.11, so changed Py_LIMITED_API to 0x030b0000): https://docs.python.org/3/c-api/buffer.html#c.Py_buffer All the remaining errors seems to be related to PyTypeObject: https://docs.python.org/3/c-api/type.html#c.PyTypeObject The Python doc says: > Part of the Limited API (as an opaque struct). Except that GDB uses it as a non-opaque structure. ### Experiment summary At a first glance, : - The main bottle neck to make GDB compliant with the limited Python API is PyTypeObject, which is used in a lot of places (41 c files out of 51 in gdb/python). - The secondary issue to support older version than 3.11 is Py_buffer and related functions. Pragmatically, this does not look like an issue we want to tackle unless we absolutely want to support older versions than 3.11. For information, Python 3.11 should reach its EOL in 2027 [5]. There might be more issues as the build process stopped and didn't go over all the files in gdb/python. Regarding the first issue, from what I could understand of the usages of PyTypeObject in the GDB code base, they seem to be used to declare "static types" to Python, i.e. exposing C data structure to Python. More information at https://docs.python.org/3/c-api/typeobj.html#static-types Making the usage of PyTypeObject opaque would consist in transforming the declaration of those PyTypeObjects to a static PyType_Slot and PyType_Spec equivalent, and then creating a PyObject* by calling PyType_FromSpec() instead of PyModule_AddObject(), which is, by the way, "soft deprecated" since Python 3.13. The Python extensions seem to have a reasonable test coverage (tests in gdb/testsuite/gdb.python), but I don't have any information on its completeness. The testsuite should be a good enough safety net to at least validate the approach, but might require new tests to make sure no regression are introduced. Given the data above, and after reading an example of such a transition to the limited Python ABI in Qt [6], making GDB use the limited C API does not seem out of reach. ## Shared library naming issue in CPython For several years, it seems that the CPython project has an issue when generating libpython3.so, the expected name of the Python shared library exposing the Python limited C API. The file is empty and doesn't contain any symbol. Ticket: https://github.com/python/cpython/issues/104612 (status: OPEN) From what I could understand, libpython3.so is supposed to only expose the symbols of the Python limited C API, and have a runtime dependency against libpython3.x.so. However, it has never been implemented and in the meantime, someone decided to make it an empty file. Since nobody followed up on this, Python build still generates an empty file. So packagers came with a workaround (for those who cared) for people trying to use the Python limited C API, i.e. with a DT_NEEDED reference in the binary set to libpython3.so. They either created a symbolic link libpython3.so to libpython3.x.so, or copied and renamed libpython3.x.so With this solution, the limited C API is not isolated from the whole(=unstable) Python C API, but a program using only the limited C API should work in the same way. ### How does it impact GDB ? Let's assume that GDB can compile only using the Python limited C API. Following the logic of PEP-384, linking against the Python limited C API means linking against libpython3.so, not libpython3.x.so With in the current state of Python packaging, this creates issues at different stages: 1. Most of packagers don't expose a symbolic link libpython3.so to libpython3.x.so, or a copy of libpython3.x.so named libpython3.so 2. If it is not exposed on the build environment, we can still link against libpython3.x.so, and patch manually the reference in DT_NEEDED before bundling the artifact in the distributed archive. ``` patchelf --replace-needed libpython3.12.so.1.0 libpython3.so gdb ``` 3. If the runtime environment does not have libpython3.so, the user needs to create a symbolic link himself. ### A light of hope from some packagers Brew (on Linux, I didn't test on MacOS) exposes a symbolic link libpython3.so (instead of the actual shared library for the limited C API) which points to libpython3.x.so There are probably others good examples out there that I am not aware of. ## Conclusion Clearly, today the user experience of GDB with Python enabled can vary a lot depending on how Python was installed on the end system, and how GDB was built by the packagers. Allowing GDB to use a more recent version of Python at runtime than it was compiled with, would allow to improve both the user experience, and also the packagers experience. From my understanding, this goal can be achieved thanks to the two following conditions: - one internal to GDB: adapting GDB to use the Python limited C API. - one external to GDB: lobbying the packagers to provide a default Python installation with libpython3.so so that a binary using the Python limited C API is supported without change to the build and runtime environment. ## RFC Please let me know your thoughts on the above. On the recommendation of Luis Machado, I added in CC Andrew Burgess, Tom Tromer and Simon Marchi. Feel free to add anyone you think relevant into the loop. I am particularly interested in: - any experience using the Python limited C API. - stories of transition to the Python limited C API, and any pain point you met on the road. - testing. I have had a look at the test coverage of the Python GDB API, and it seems ok at a first glance. Please let me know if you can see any difficulty with the current coverage. - any performance impact caused by this transition that I should be aware of. And how did you measure it ? How critical are performances regarding the Python limited C API ? - implementation details in GDB where you think that we might face problems with this approach. ## References [1] This is true unless the program uses the Python limited C API, and the name of the shared library in DT_NEEDED matches libpython.so. [2] This topic was already raised on the GDB mailing list in the past: https://inbox.sourceware.org/gdb/0aa701db281b$b8ac9df0$2a05d9d0$@symas.com/ The proposed "right way" of packaging GDB consists in building GDB for every supported distributions against the default Python version of that distribution. This approach can certainly be made easier using Docker instead of physical machine. [3] PEP 384 – Defining a Stable ABI, https://peps.python.org/pep-0384/ [4] PEP 652 – Maintaining the Stable ABI, https://peps.python.org/pep-0652/ [5] Status of Python versions, https://devguide.python.org/versions/ [6] Qt: The Transition To The Limited Python API (PEP384), https://doc.qt.io/qtforpython-6/developer/limited_api.html