From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id UmvjNL9vkme8oRgAWB0awg (envelope-from ) for ; Thu, 23 Jan 2025 11:35:11 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=JBmUVXmd; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id C8D7C1E100; Thu, 23 Jan 2025 11:35:11 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.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,RCVD_IN_MSPIKE_H2,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=4.0.0 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 A49E61E08E for ; Thu, 23 Jan 2025 11:35:10 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 386D33858C48 for ; Thu, 23 Jan 2025 16:35:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 386D33858C48 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1737650110; bh=/SFFtoI4fHTVT1TUec9kZT8/sWj3u/n7X5N85A4myx8=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=JBmUVXmdJ+2x1cmZhhG+t7h26T0Fc6hbu9wL/yh4CLGSGybgeKt3tNoGQLPJZyJM2 vVzeM+P56omqjnczxQD/TQf3nPQZB0F2Ov4n/v2O1WDbTGt8h8ibmySG9z3fZc/h/d rolKFEk/4jm5bw6irQlLjjRskULQW7f8jo5u3POA= Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazlp170130007.outbound.protection.outlook.com [IPv6:2a01:111:f403:c20a::7]) by sourceware.org (Postfix) with ESMTPS id E9C6B3858C52 for ; Thu, 23 Jan 2025 16:33:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E9C6B3858C52 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E9C6B3858C52 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1737650011; cv=pass; b=pUZvPCu6cEGF/sfVPjxttQun2rWwpwdwvZbeUHYYMXOE2pNSvOf18JVZB8FFTx3lIcWTSVrUPy6MzM8wPT9brhM5yyct2jN8jVdV9e4u5FjiHZ3sPDZsUXWVYZs3dNs0fwNbohaGtK+9bHM3HO6V+5XhWYC5ojt/Lo1KrkQuK/4= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1737650011; c=relaxed/simple; bh=ZKovu7fPWyL3ZoCcN44MlQT5qCNsDmq6lt+hPwSqy/0=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=g71ei4/o9Bqptsow8+OuGBf7XHJVhUVPe7Ryl/AumXWxXduDs7d/7I+EIMAA6r48lFbNsAhor3mtPrBzEwpL9kuNwK6LjKy3fuM8EAdJ9OmaoI8/R5KtJKLq3hLjyMomKntu+4b0cWvzn4dM06EHhNPTdnnYm2MT6qYdUCtAHok= ARC-Authentication-Results: i=3; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E9C6B3858C52 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=c4EaTS9lI9fAsYpFCvFhwgzQo0Il3wtVZAkIYQ7JStdukTcC5+RoFEVagCTtezez2x27nvyh5hqL6BPhECJt+15OHt+ohSfXQvT9UbE9X1VsA9AEsUA8hjq2lQntKtVFEftGOrBSRN0oyKzR3CRbSXRFu+TkQOSW3T/zJ57MEggCBZ/uj3O2cV+Ut16G66VKzzx4M4nCB68fvLwnNX+Dbw42Xl8OvewpyCWAefcc4DCooDe90KFfwPO7RC2lmG1cjWlt2xZLFJI4xzZP83Hlol0d6O+baewZqAc0Mdqc4eoJ9Lv8K92uVVD3df7TaFjAqFht1agkGRNWAPkgS5oAxg== 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=/SFFtoI4fHTVT1TUec9kZT8/sWj3u/n7X5N85A4myx8=; b=EGnWtNA7S1KiJ7lPPcKOyIlYLvvj9TepYZkne7fAsgfNZnxYd7cfTI9kf395hb4qZYoN8SDfKWS/ZVhKqZ8QkZAasenKRoa4ACqx2d1Tn5QSwaMumn8zlFVOY2Py79Bt+t8+hqbguPtKGXdK+SJQEBgMPcwj+gAFvNCU1ypfkL7Gi7oM3z7i2oUMONBut3SuURW9phIcpgAHjcu5twR8ZGi9iLbbtLzTxXkZJE73Vz49QJLsAp2GykX/3V5ZjYLOmOb+tYi0ZhlOg9euPwNGLxEOQCzRWYLual24rW/29MbBLGwuDiWcbYWaTtwK/0ppuRpYIaOhn8Cbq97Dyv98aA== 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]) Received: from DU7P189CA0020.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:552::30) by DU0PR08MB9419.eurprd08.prod.outlook.com (2603:10a6:10:422::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8377.17; Thu, 23 Jan 2025 16:33:24 +0000 Received: from DU6PEPF0000A7E2.eurprd02.prod.outlook.com (2603:10a6:10:552:cafe::1a) by DU7P189CA0020.outlook.office365.com (2603:10a6:10:552::30) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8356.22 via Frontend Transport; Thu, 23 Jan 2025 16:33:24 +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 DU6PEPF0000A7E2.mail.protection.outlook.com (10.167.8.42) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8377.8 via Frontend Transport; Thu, 23 Jan 2025 16:33:22 +0000 Received: ("Tessian outbound fc2e7feb7122:v554"); Thu, 23 Jan 2025 16:33:22 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 4cc9bdf9c8282184 X-TessianGatewayMetadata: tVzwii5RDKEepgIG8IKo8onG6ZhPSDHoaKkpP62EU5olmfpEPxcZXKT6NGsQ4ObBvULXzN3LeBVeWKhZKKX40UGeQV1V07A6heQVU2lfql1XYon97zOPhGBhIZM1U6pILSGGNfNL2L1yP6sCLWS6QAv1rJbauswh0LZkfVJPg7w= X-CR-MTA-TID: 64aa7808 Received: from Lbaf20a2f0ffc.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 521FEED4-3800-488F-B887-337C4ED1CF9E.1; Thu, 23 Jan 2025 16:33:15 +0000 Received: from AS8PR04CU009.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id Lbaf20a2f0ffc.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 23 Jan 2025 16:33:15 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MAvx5jzW4SSZQTz9cXAcgwTa7yVBHDtl96lDM4rRiHBsQT3vKdqdJb94h+InAepWqUPFbhtPukIQ8XTHNVpvh1RBT4Y1KnokSwTE3IQLzJkRyRj1l6eXIOuaapIDe3yxs/gM0Ngi9Tlj0MrexiTAG8+3vC/GPcGvMbRrSbMxRb+elc4D3kHNyM79WB/zKlgw4JLNOVTf/0WU5NGF0Ya9k1Pw7yNJFpREOt4Wv3dWuF85WucPS/AH6pqafiBvfmUD/SMAWII2V63WhLlDxvu3NBBv+SqlKcOcsBSWgYDXZW1wdqNOPJMTAO109+XL81h/nOrZUFWl3o1ZEtXdLAXgtg== 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=/SFFtoI4fHTVT1TUec9kZT8/sWj3u/n7X5N85A4myx8=; b=ugHVhu6fIEgs7gTPKn9oDVC9LTr//EkUQ4A2I+ojqPVOnKYntA+WesFBXpYd82/Dkwf66iH6Or83gT1+MvHDE3V0pG8hoA0tB1/WPyyAs70OYiDXy7ZZQuU2f/RzdhCuUVflgcIerHq8ulovXdXZa/brqzbodRh6qXHVpjXVETFkeF9V4bWTv6zfCeCzxIrUuiZ80TB8f3XtgLYSaAHiO1OWOIa6gHI++qufJuG/vaUonMr1UQbkYD+pkZK3f1fHJxwASU7bnmMBedSRdLAz6oAcnajCGJMjqhIh4eyowaApxuvZRfaojVaRZF/VsUOKqAysdNN9rb7kgykATW7bZA== 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 PR3PR08MB5852.eurprd08.prod.outlook.com (2603:10a6:102:8e::21) by GVXPR08MB10715.eurprd08.prod.outlook.com (2603:10a6:150:157::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.21; Thu, 23 Jan 2025 16:33:13 +0000 Received: from PR3PR08MB5852.eurprd08.prod.outlook.com ([fe80::f44:d113:1c29:825d]) by PR3PR08MB5852.eurprd08.prod.outlook.com ([fe80::f44:d113:1c29:825d%4]) with mapi id 15.20.8356.017; Thu, 23 Jan 2025 16:33:13 +0000 Message-ID: Date: Thu, 23 Jan 2025 16:33:11 +0000 User-Agent: Mozilla Thunderbird Subject: Re: Incompatible implementat ion of 'x' packet in GDB vs LLDB Content-Language: en-US To: Andrew Burgess , "Aktemur, Tankut Baris" , "robert@ocallahan.org" , "gdb@sourceware.org" References: <87a5bhmrre.fsf@redhat.com> In-Reply-To: <87a5bhmrre.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO0P123CA0008.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:354::7) To PR3PR08MB5852.eurprd08.prod.outlook.com (2603:10a6:102:8e::21) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: PR3PR08MB5852:EE_|GVXPR08MB10715:EE_|DU6PEPF0000A7E2:EE_|DU0PR08MB9419:EE_ X-MS-Office365-Filtering-Correlation-Id: 2e4321fa-804e-4ade-2f29-08dd3bcba766 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?M1NsUjByZGFJZ25QS05ZY2l2ZDVXZU5tWHYrNmhXNm43L1BYY0hqandVNjBB?= =?utf-8?B?Y3FCMTZIclBRMlBwSDVRTGdMNHFJQVRmdkJYZWlNQlBYeUlGSjM2Q05lbG0z?= =?utf-8?B?RzBIYUVOUUdBYXozY2NtTURjUHlMalFycExVTlc3WmIvZHNoTUNJNUlyQi9P?= =?utf-8?B?T0oyUDN2c01QWWZSbm5aaGhVUDJ2ek5hRGpLRTZnVnZhTURPMHZLUnhWWE0z?= =?utf-8?B?RmswNFhuM2hyK0lKajZKM3dJNUNaV2FHUUdHeFVYSlRoeU9ybHBPSUdqaUNs?= =?utf-8?B?WWpqRUZnS3VweGlERVJPWTBQMXdMRTk2NzNRQUFqSEhHTU5sS0RLTkVWaDNQ?= =?utf-8?B?K2dSUllXdU5DYzBudVNHeFhLMmJoV0RXTUhlRlJYcEJDTUt2WGNrOG9sRCt2?= =?utf-8?B?elBFSm5yWVFacE1ySU0xQ2xob3F6TUZIcjRhQXAxWWRadjZZYTlqRW4vZlF0?= =?utf-8?B?MlRHOWowby9sK1owZVAySmVXUWs1V0VqMDVVZzJxaXhqbnRRSFlWRUdiVlhS?= =?utf-8?B?aW5xSkJuNFhxY1ZFYkxFRkM0ZmI2dm5yY3FOSFhiMk1WREV4L2JlbnRwQ0o5?= =?utf-8?B?cjgyU3E1SE5PTXJHZy9tWkhGZ0x6c1VGTnRKN3NMN3hla3RKT2cxQ1lkTkNV?= =?utf-8?B?TVRVRUcwNlZ5NTY0WEkrSGlMR3U4Z2IxeHRlUEVFSkVqcmR3SFlDR2cyVzVW?= =?utf-8?B?RzlsUmNCSENVeTl5czdTY1BJNkcrbWFoWW50NVl1MTFJZnNBbE1sVGFObnFn?= =?utf-8?B?aG5TMitVT0VtRXo5bi9yZUdtQ2R0dFRRSGhaTFUrQmQ4M3A2WnNYTzJ1ZFdi?= =?utf-8?B?d2FoaDArNFFpNTdMemhRYmd3dE5EWDhMTUp3SXQra3ZtTTU5YlRDNmFRVUw5?= =?utf-8?B?N05PNjdzdDUwOGFBUFBDMUNFSDIwTk5Eazlmb1hoU2hxY0JGelRMMFR0OUxv?= =?utf-8?B?TEh5STIwRENFenJaZERYbG40L05WWjZpdnZFcUR2Ylc2RkhtZlcwMjFHZ3cv?= =?utf-8?B?QmRwc1NOdDRKYTdVMlREMXpFRFh6d1FoYnkyRHExQS82WEFTYThXTnFOQ3h5?= =?utf-8?B?b1lnblZGT05QcTlyWHNSbkpvZURsSUYwVncxSWtBQlhvQWNOYmJFOXAzR0Zo?= =?utf-8?B?MHJZV0hIbnNabk92Y0ttUm9XeG80Ykw0QW1sYzIwOVZ6MWxWbmJzY01OQTBp?= =?utf-8?B?RFhUOFJMZ05YZTRFNlJwZHVFTnlSS0hrRDlldStxeUhIN2RybklHVjE5cXJ0?= =?utf-8?B?ZnlHcDd2eTg4aGRFcEhHdEtBZVZORjlldXd1MlRCLzlLQWRwUDJ0bDJaTmhC?= =?utf-8?B?UUZUUXp4NWJvZ0QreEU2dEtkbzJWT2o3UHZQTjdPMFQrelY4aEsxZ2dFOUlV?= =?utf-8?B?TCszUmpJa0ROWG03TURxUnJSUWNIR2NaUFRQanQrUWpuS1JUVHpDUTFnL3R5?= =?utf-8?B?TjJkN0NIUnBFdUJaRVNmbTFxWFllYmlVaVlSbWN0UnRaUkdVQUdUOTJuTjlD?= =?utf-8?B?N3dEa1RLU3NoSTBUNkM4cUYyMUZHV0dIUDRleDNKY21uQ2dicjNLOWRFSlp3?= =?utf-8?B?eG50djZMN2puTDJmMHlRaUVveFhTcHhRSkxtTkFPSDQxYVFHWGJtZUkxUUtE?= =?utf-8?B?R3JvbVpkNFVQcDBpT2RiS3JscWFVdGpFNEJrR3NXamlOSTNCc3Bxem9kTkw3?= =?utf-8?B?TFJ6UVJrQWhxOUoyL2dRbkgxN1VsK3FWQVFSd1ROR0ZhdHBlYWtyd0JkMXdQ?= =?utf-8?B?NC92Mmc0UGlnRlh2Sk13dUQvMVBhK09FSEdPdCthcTJIOFA2Rjk1WG9SRkdi?= =?utf-8?B?b1RPUjRaZXNVMVEyVFdvQT09?= 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: GVXPR08MB10715 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: DU6PEPF0000A7E2.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: b7e2f3fb-35b4-47ac-504b-08dd3bcba1bc X-Microsoft-Antispam: BCL:0; ARA:13230040|36860700013|82310400026|35042699022|1800799024|14060799003|376014|7053199007|13003099007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?WEFmN0c3bEFablo5dDYvSG5wOUgxYWhNTks4REhZM3kyaDc4UHd5bzlQcXBU?= =?utf-8?B?WENxWEZZdHl1Z1IwWXhpTE54b1pZRzRFTC85dGZDbG16R1NKV1FEU0JncnI2?= =?utf-8?B?L2puNXJxem5rY0tFWHJIZnBVdXVpK0pWV0w4TGFlbVExL0xKRUJ4L1BIWnlO?= =?utf-8?B?Z2dPYVZLVlNuN0piK1p2dUl1anNTKzNHVDFPb0Z5WG1FNWRuMXhISVhjUEFP?= =?utf-8?B?MVlQQStOcjlOZ3JKbG52bFJZcmY1S2RlNFpqMUFxRWR4dzY5T3M5VC9nT0Ev?= =?utf-8?B?UzZaZ3JTbDRhbGF4SWpiREphcnFUQ1U3elZja1YwZkwyUmQ5VHVNZDk3NFpH?= =?utf-8?B?QW1Qa1d6LzZ6ZGFKVGRKNGIzUHN6bW80MWZGM1JZQ1RHV0x6aVhCcmx3WG9l?= =?utf-8?B?REdLd3loVWU4b1hHMW1UK0t2V0xKa3lxbklFbDBiZjFTeEhWTHJDaTd4Mi8y?= =?utf-8?B?eDJTSktvcXJ1STJ2SXVnNVhkNE9UZEdhZVNqcXU5QkhQeHdyUW9NeEJGcW1k?= =?utf-8?B?RS9XZzNvSU56Y1RtZElJVnR2ZUwvVjZxdCt0V3BGWEZmRzhCTmM5d3J1bklY?= =?utf-8?B?MG5OcnJMMkZwdEhMQ1huZnQ3d2hmSlBMU2kyWXQ0Uk5TY3pTamo4N09PNVlM?= =?utf-8?B?Q0pjSXZVcHNYOXZVUzNSWGFGSGxoSDI5d0hPWE9PRm5LNmxQZTUwOFhqdUln?= =?utf-8?B?NHFxNlFkU0M5R3NDaWc4WU1XWkc0UGNjQ0dOV202L1d2SktVK3I4SHZKYjZR?= =?utf-8?B?Rld4aEMzMHhFL0xkREYxS0I2SEJPU090WlZTdlBtVE16bFg1aHBzZTZSTm42?= =?utf-8?B?RVJTN2ZOQktOQUVBZjlFNy9aS1BYOWx3L0IyeExxbi9qbG9CSytERmZMckox?= =?utf-8?B?NWoxZ3pEQmZ0NUlJWC9ZMzBiT2ttTXE5YjVpbkFZQndPazIwcjhqVUJ0dDJS?= =?utf-8?B?NU9OZFZ5NnBId21IbUlWeXh0RlFDbnpyeUdrb2J4aG55NDZ6T0swRG1nRXMz?= =?utf-8?B?SjIrWkw2Qnluc3RaV1lBSEs3TzFndno2aGtSK2dFVThvSFN6bWxBUHdjM1RM?= =?utf-8?B?K3Q3eFBibUpkdVhkYjFmajdnNG80bGJmcXhRUVdKWnpNbktiZ3pCakhTVWd5?= =?utf-8?B?TUZpUE15QjNRaEFRbHZDbjNGOVhiT3BCZVBCL21JcmFQQ1o3bE9vcnBaTzdE?= =?utf-8?B?VXNBUlZHd2dTRkFnZVVlQU0wR1RGUTUwUjZ6UlJCbW91ZGQ1TnQ0SkhzejBv?= =?utf-8?B?SEJxbm9BbkpCcUNOK3hvZHI0OUFKMHRqWGFkNjhpeklKYzNYOW1UY3h0c1Qr?= =?utf-8?B?MzNYaytHa0dXUUxwVTRBSGxETWN6VmFETVg2U2hhY1FIdFZnL1NLL1lGSXpt?= =?utf-8?B?ejU1VnR1UlBtQzdtaDNCQlFzUktDd0tkTDhMdVhrN0NjeU9IQnJhRGFDV2F3?= =?utf-8?B?dWFUWUJCSU5vOWM2S0g1Z0IrbU8zS2RWRXg5dVhKWE10Ky9VTCt4TmdoZzVC?= =?utf-8?B?UkxNRFZlaUZNTVBjMWxBeE9paUsvMy9xOWxycDh5T1NJZi93T1R0YnB4cjZH?= =?utf-8?B?bVloVWR4dVBZYXNpT1FNZkRmZzQwUE5VM3lFSXZjZEd5dEdMcGd1dTI1c2Yv?= =?utf-8?B?QUVueElyK0FpRkVyVnVPQk43SFZPUStxZFJ5cXF2QXJReDhtai9JcHhYWHl3?= =?utf-8?B?ai9SV3I3cEJUWGpickI1cUdNbHM0aEFseXR6d3Y1R1dFNzY4dkFrMXNrWlNa?= =?utf-8?B?K0t3UkJ0U0c5bDN0T05WVmpINFZSM2lhcHY4N3BsWjI0RkxqZVhjS1JHMkFZ?= =?utf-8?B?dk1vUkJYaWdZZjVzQnIycDdNalQwOC9mWVdkb3Y4ZFU0dXZia25wOGdwK0dn?= =?utf-8?B?TnBYazZiZnN0Wnh6aXNMSUw4b0dnc0Q0QlRFZ24zWnV0YmYyc0VxTi9DSGJs?= =?utf-8?Q?3t/Z5YXpyl7CPscAa/9h5WhFWcJJJn8F?= 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:64aa7808-outbound-1.mta.getcheckrecipient.com; CAT:NONE; SFS:(13230040)(36860700013)(82310400026)(35042699022)(1800799024)(14060799003)(376014)(7053199007)(13003099007); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2025 16:33:22.9213 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2e4321fa-804e-4ade-2f29-08dd3bcba766 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: DU6PEPF0000A7E2.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9419 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: Luis Machado via Gdb Reply-To: Luis Machado Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 1/23/25 16:14, Andrew Burgess via Gdb wrote: > "Aktemur, Tankut Baris via Gdb" writes: > >> On Thursday, January 23, 2025 8:13 AM, Robert O'Callahan wrote: >>> On Thu, 23 Jan 2025 at 08:57, Robert O'Callahan >>> wrote: >>> >>>> GDB (client) 16.1 started sending the gdbserver 'x' packet. It follows the >>>> documentation [1] and expects a leading 'b' in the response [2]. >>>> Unfortunately LLDB has supported this packet for quite a long time [3] and >>>> does not expect a leading 'b' in the response. We added support for this >>>> packet to rr last year and followed LLDB's format because it was the only >>>> user of the packet at that time. So GDB 16.1 doesn't work with rr. [4] >>>> >>>> I realize that compatibility between GDB and LLDB flavoured gdbserver >>>> protocols is not a priority for either team, but until now it has actually >>>> worked in practice --- rr hasn't needed a client mode switch. We can add >>>> one, but it will be unfortunate if GDB 16.1 and later is incompatible for >>>> anyone who's installed the latest rr since May 2024. >>>> >>>> Could you make a GDB 16.1 point release that removes the 'b'? AFAIK it >>>> serves no purpose. >>>> >>> >>> It has been pointed out that if you want to return different error codes >>> then you need the 'b'. Is that the rationale? >> >> Hello Rob, >> >> Essentially, yes. In case of an error, the server responds with an 'E' packet. >> To be able to distinguish an error packet from binary data, 'E' would have to be >> added to the list of escaped characters. Having the 'b' marker avoids that. >> >> Additionally, when the response is empty, per RSP, it means the packet is unsupported. >> So, in case of a zero-length request, the 'b' marker could help us distinguish the >> unsupported case from an actual zero-response. >> LLDB doc says >> >> To test if this packet is available, send a addr/len of 0: >> >> x0,0 >> >> You will get an OK response if it is supported. >> The reply will be the data requested in 8-bit binary data format. >> >> How does LLDB distinguish an "OK" response, an empty binary data, an error, >> and an unsupported case? These were not clear to me from the docs. >> Is the x0,0 query special-cased? >> >> For the record, the 'x' packet series were discussed in >> >> https://inbox.sourceware.org/gdb-patches/cover.1710343840.git.tankut.baris.aktemur@intel.com/#r >> >> with the part specific to the 'b' marker in >> >> https://inbox.sourceware.org/gdb-patches/87msq82ced.fsf@redhat.com/ > > I also am not entirely sure how lldb's implementation can work in all > cases given their description. For now at least, I still think we made > the right choice with our implementation, though I guess if we'd known > we were diverging from llvm we might have picked a different letter for > packet in order to make it completely different. > > I have two thoughts for things we could do to possibly help with > compatibility here though: > > 1. Hide the 'x' packet behind a feature flag. So instead of using the > empty reply to indicate 'x' packet support, we ask remote targets to > send 'gdb-x+' in their qSupported reply. If a remote target sends > this to GDB then we will assume that they support GDB's style of 'x' > packet, and can make use of the packet. Otherwise, it's 'm' packets > all the way. > > > 2. The other option would be to probe for 'x' packet support as a > separate action. Right now probing is done the first time we send an > 'x' packet. The packet is sent, and if we get back the empty packet, > then we know 'x' packets are supported. > > But if instead, we sent a zero length read, then by GDB's rules we > should get back a lone 'b'. By lldb's rules we should get back > .... maybe "OK" ... or maybe the empty packet? It's not really > clear. But the important thing is that neither of those replies are > 'b'. > > So the first time we consider sending an 'x' packet, we send > 'xADDR,0', if we get back 'b', then we know that we have GDB style > support, otherwise, we disable the 'x' packet, and fall back to the > 'm' packet. > > Approach #1 is pretty straight forward, but I wanted to check what > approach #2 would look like, so I drafted the patch below. This patch > is pretty rough right now, but can easily be cleaned up. > > For testing this patch I hacked up gdbserver so it no longer added the > 'b' prefix, then I tried connecting with GDB. I see GDB send the zero > length probe, then switch back to 'm' packets. Thanks for the input. > > Questions: > > + Do people think we should change GDB to improve compatibility? My > thinking is yes, so long as the cost isn't too high. Sounds reasonable. I think we should too, as it seems to be good timing (just after the release of gdb 16) for us to try to improve this. > > + Do people prefer approach #1 or #2? I'm leaning slightly more to #2 > right now, but not massively so. If people prefer #1 I can write > the patch for that instead. Approach #2 seems to be a bit better from your description, as it checks things from gdb's side as opposed to chaging the server side. At least that's my personal take on it. > > Thanks, > Andrew > > --- > > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo > index b65124d807f..e92227d3803 100644 > --- a/gdb/doc/gdb.texinfo > +++ b/gdb/doc/gdb.texinfo > @@ -43531,6 +43531,10 @@ Packets > use byte accesses, or not. For this reason, this packet may not be > suitable for accessing memory-mapped I/O devices. > > +If @var{length} is zero then the reply should contain the leading > +@samp{b} prefix and not data. @value{GDBN} sends a zero length > +@samp{x} packet to probe for support. > + > Reply: > @table @samp > @item b @var{XX@dots{}} > diff --git a/gdb/remote.c b/gdb/remote.c > index 64622dbfcdf..a332fcd6f95 100644 > --- a/gdb/remote.c > +++ b/gdb/remote.c > @@ -9683,17 +9683,55 @@ remote_target::remote_read_bytes_1 (CORE_ADDR memaddr, gdb_byte *myaddr, > memaddr = remote_address_masked (memaddr); > > /* Construct "m/x"","". */ > - auto send_request = [this, rs, memaddr, todo_units] (char format) -> void > + auto send_request = [this, rs, memaddr] (char format, int len) -> void > { > char *buffer = rs->buf.data (); > *buffer++ = format; > buffer += hexnumstr (buffer, (ULONGEST) memaddr); > *buffer++ = ','; > - buffer += hexnumstr (buffer, (ULONGEST) todo_units); > + buffer += hexnumstr (buffer, (ULONGEST) len); > *buffer = '\0'; > putpkt (rs->buf); > }; > > + /* Unfortunately, lldb and GDB disagree on the reply format for the 'x' > + packet. GDB expects a 'b' as the first byte of a successful packet, > + while lldb does not. There are good reasons why GDB uses the 'b' > + prefix; it's not possible to distinguish between an empty > + not-supported reply and a failed read empty reply, unless there is a > + prefix. > + > + As lldb "got there first", and there are clients in the wild that > + support the lldb style reply, we probe with a zero length read. If > + this returns a single 'b' then we know that the 'x' packet is > + supported. > + > + If we get back an error packet (starts with 'E') then we cannot know > + if a successful read would start with a 'b' or not. We'll probe again > + next time. */ > + if (m_features.packet_support (PACKET_x) == PACKET_SUPPORT_UNKNOWN) > + { > + send_request ('x', 0); > + int packet_len = getpkt (&rs->buf); > + > + /* Catastrophic error fetching packet. */ > + if (packet_len < 0) > + return TARGET_XFER_E_IO; > + > + /* If we get back a lone 'b' with no data then the remote replied as > + expected. Anything else and we just disable the 'x' packet. */ > + if (rs->buf[0] == 'b' && rs->buf[1] == '\0') > + { > + remote_debug_printf ("binary memory read is supported by target"); > + m_features.m_protocol_packets[PACKET_x].support = PACKET_ENABLE; > + } > + else > + { > + remote_debug_printf ("binary memory read NOT supported by target"); > + m_features.m_protocol_packets[PACKET_x].support = PACKET_DISABLE; > + } > + } > + > /* Determine which packet format to use. The target's support for > 'x' may be unknown. We just try. If it doesn't work, we try > again using 'm'. */ > @@ -9703,32 +9741,11 @@ remote_target::remote_read_bytes_1 (CORE_ADDR memaddr, gdb_byte *myaddr, > else > packet_format = 'x'; > > - send_request (packet_format); > + send_request (packet_format, todo_units); > int packet_len = getpkt (&rs->buf); > if (packet_len < 0) > return TARGET_XFER_E_IO; > > - if (m_features.packet_support (PACKET_x) == PACKET_SUPPORT_UNKNOWN) > - { > - if (rs->buf[0] == '\0') > - { > - remote_debug_printf ("binary uploading NOT supported by target"); > - m_features.m_protocol_packets[PACKET_x].support = PACKET_DISABLE; > - > - /* Try again using 'm'. */ > - packet_format = 'm'; > - send_request (packet_format); > - packet_len = getpkt (&rs->buf); > - if (packet_len < 0) > - return TARGET_XFER_E_IO; > - } > - else > - { > - remote_debug_printf ("binary uploading supported by target"); > - m_features.m_protocol_packets[PACKET_x].support = PACKET_ENABLE; > - } > - } > - > packet_result result = packet_check_result (rs->buf); > if (result.status () == PACKET_ERROR) > return TARGET_XFER_E_IO; >