From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id PBK3C0tzjGgrdQEAWB0awg (envelope-from ) for ; Fri, 01 Aug 2025 03:56:59 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=CeUi0sD3; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 1A8FE1E102; Fri, 1 Aug 2025 03:56:59 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-10.1 required=5.0 tests=ARC_SIGNED,ARC_VALID, BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU, 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 96A791E089 for ; Fri, 1 Aug 2025 03:56:57 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 12CED3858418 for ; Fri, 1 Aug 2025 07:56:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 12CED3858418 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=CeUi0sD3 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) by sourceware.org (Postfix) with ESMTPS id 398C03858CDA for ; Fri, 1 Aug 2025 07:56:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 398C03858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 398C03858CDA Authentication-Results: server2.sourceware.org; arc=fail smtp.remote-ip=198.175.65.12 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1754034976; cv=fail; b=izSr8V+CfpGNN/WKxqWQoPU9qLMVeoZ4iYUE/thkZOFPf5CXYSaOpa5QPfN9GmjHX7co/ZIh68qiYFYmmOR+wIQdKJl93KpE2eQyyLAe8Ztz5ANJOXY50hqFY1IuXpvg76cvewQHZvyCCFuqM9rqVl7vrtC36FMV3mR3Q/0ezgo= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1754034976; c=relaxed/simple; bh=Zi8tlguPdG7hS1YAUJY5rl4DzHv/x++8yA8eCXPm+wE=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=UAhUXbYo85v7nhfY1WUSmFmBfRMGAh4+CqRbjcWnia7QVJeP8EY6kIZKVaxeIXg3TWsSTI8q54mPPZ7KcY/j0w9l2Rr9c4B8qEfrZp7wdLUlzyxTQIV9YkPAFTd6xQkuUHp5RVMo8zqZXh5A/+UMJvZi+crVodacpcCvsfLGXD0= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 398C03858CDA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1754034977; x=1785570977; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=Zi8tlguPdG7hS1YAUJY5rl4DzHv/x++8yA8eCXPm+wE=; b=CeUi0sD3VDEjPB2j4ziG/i7emBiIw9xdydyLlVL6BleMOwcViCF+/05Z yOvq3mYPyp1JO5ZSnXAocuvoWOv6MVHuP4xGk/h3JG1XQ1FfF+7v0TMqz Tg7ITG+R4A4Z5gmNf9fXkrb+anmt0mOYrE8RjcEt/QwT7bnr4AGppn1uZ LjvUmV8BRJ4tzV7owvXKuXI/ORoqnB1P0VpllfmMwuB6G4YCq6fmLE6uf s6g9tZInPvmwPIsbMz/Dv5AV/FTD7ewSw8OUPjeg5nJDVnru06oaHl/63 RD90DRs72kxee5EiGbHLg5Pkz0DEsQXSIAC+SIbMtq8tgrkmJ9Uzx+S6H Q==; X-CSE-ConnectionGUID: SFedD1oIQcCih0/HgdoW8Q== X-CSE-MsgGUID: HLsINyuBTOG4V+m/93FqMw== X-IronPort-AV: E=McAfee;i="6800,10657,11508"; a="67821471" X-IronPort-AV: E=Sophos;i="6.17,255,1747724400"; d="scan'208";a="67821471" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Aug 2025 00:56:15 -0700 X-CSE-ConnectionGUID: LIFDbF71RQKJo+fw8SqMCQ== X-CSE-MsgGUID: UGC3UNRsQmC77DA+6NPd+w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.17,255,1747724400"; d="scan'208";a="194473519" Received: from orsmsx903.amr.corp.intel.com ([10.22.229.25]) by orviesa002.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Aug 2025 00:56:15 -0700 Received: from ORSMSX902.amr.corp.intel.com (10.22.229.24) by ORSMSX903.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26; Fri, 1 Aug 2025 00:56:13 -0700 Received: from ORSEDG901.ED.cps.intel.com (10.7.248.11) by ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26 via Frontend Transport; Fri, 1 Aug 2025 00:56:13 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (40.107.96.87) by edgegateway.intel.com (134.134.137.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26; Fri, 1 Aug 2025 00:56:13 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rwyZSYGEAr1hyqrUlCHApkaGYby5sdTzFHonDVnOYXlY6sCASZKysA4IlCK+Ak9EeLKT/+rZyIcITxCNYKt19A0xeremIiDtAyxwD+gr0yJY7zzx6eii0RQU/yb6cgerlUGivf06tauXpp5Qn7EbYsbH8quyDIQiMmOo4c4945Aq/d0wTKmJDwHfE1Jqu5phdYd/D9WmrMcrCuwXMkNd7tfenfwVqv8s+v+N2vNYlsX7HMZR+r+Atn7lsa//o5poHintB7QSl/fIFP60aomB2ZPXFlJZLg763rfaWfo7GYI6kLzRWNrS2D4iKKiRRatzURusmnHuFukLneDm+1lWjQ== 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=q0ZgWzWI4xE9aQWd9C3+umzjizXuWRYEkZFX65lG9mM=; b=Atvhb4G2mjbk3IpFVGsBs/Fh+IYuRr+da25nG2CdrfLPF0IF17KiRY4fajRRMZOYAIeg1XVfvrNG4VzI5/OJwIUecNzy6tAgmEDFBnf7qunN98dkuQ2gGnctgPSWZNZdLoj6o+ZSFx1yRmAxnXBRJt681SL8RyFl5UHLYsJU4VtZXeafGPBfkXcg0npjfLZJGZxSfDEMwoJLmmMiYAEpfbhLuZFnTM2o+N466GXD+ZFCn3o2/rL7gJBMmFhKajGR+IDy51IDKS4WVyuKfMJ72LAVFVnGYAg6Al2qs8EVnNeaDsZKVQc9qugzm2EWc4NcodOmelxGV65Riq1zdEvsKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from BN0PR11MB5757.namprd11.prod.outlook.com (2603:10b6:408:165::23) by SA1PR11MB8427.namprd11.prod.outlook.com (2603:10b6:806:373::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8989.11; Fri, 1 Aug 2025 07:55:57 +0000 Received: from BN0PR11MB5757.namprd11.prod.outlook.com ([fe80::a0ec:f769:6d2e:e4b9]) by BN0PR11MB5757.namprd11.prod.outlook.com ([fe80::a0ec:f769:6d2e:e4b9%7]) with mapi id 15.20.8989.015; Fri, 1 Aug 2025 07:55:57 +0000 From: "Metzger, Markus T" To: Thiago Jung Bauermann CC: "gdb-patches@sourceware.org" , "Aktemur, Tankut Baris" Subject: RE: [PATCH v2 13/47] gdb, remote, ze: fix "$Hc-1#09...Packet received: E01" during startup Thread-Topic: [PATCH v2 13/47] gdb, remote, ze: fix "$Hc-1#09...Packet received: E01" during startup Thread-Index: AQHb93zOeobOsbw1v0660Bqq5Spzc7RL3+WA Date: Fri, 1 Aug 2025 07:55:56 +0000 Message-ID: References: <20241213-upstream-intelgt-mvp-v2-0-5c4caeb7b33d@intel.com> <20241213-upstream-intelgt-mvp-v2-13-5c4caeb7b33d@intel.com> <878qkmfhyi.fsf@linaro.org> In-Reply-To: <878qkmfhyi.fsf@linaro.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BN0PR11MB5757:EE_|SA1PR11MB8427:EE_ x-ms-office365-filtering-correlation-id: c7627f9c-5f2d-4ba4-6c9b-08ddd0d0d914 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|376014|366016|1800799024|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?Vq6YI/dsMd+Vx3952Xxa6jDhdAbyzm+0xWlWLVvtmM458fY0uHahJvyORczY?= =?us-ascii?Q?FHR/NX8exDQQfsRXyy7TDi/fVnvS/CWZ38dvxOXNoBYM5lW1I7wb7FcNkGyP?= =?us-ascii?Q?0Yqd0L8D16e3GIs+PFjhtZ4h+i2s5H3Y5OURdOU/HI0ujutpECsogKa79/cm?= =?us-ascii?Q?KR2K7MNFkh/cCJPRnKahRnOrzQOWCA0HQvHPNLQOw1rpQ6m37dWxpJzswPPw?= =?us-ascii?Q?s+IdxRiAy7fdC+5FZgIUllbqLPMiQ5YmfPs6HK74UyPKsId5iHhiGAJ8nrHq?= =?us-ascii?Q?OmNYlvq3OHiA2goSqPHjRhFyAzRCEa5UPfJvgND42kONmanVWpfbCUjYnBf3?= =?us-ascii?Q?2ubg8k7F7mTQKnUc9yYjdvOOWTVx+Mk9icOL5tIuanwRkQKhlI5JfUCLcZer?= =?us-ascii?Q?l7cN/0O/hZV/5YJCVeDx9PcLxaO/VwgxYw3TnKqgdiVJzAdVJ6wDgzeowRiI?= =?us-ascii?Q?PUTnq6ZJfsE4uUmtIMwsdhA2s/H+3Ux1FX+HVV+kHzWevhGe4WexO6jhJg/C?= =?us-ascii?Q?MW1ZQ5uUWFc+FXG0wtAOSY/FH/x4S6HYEyz+2PFUilZ7K606HunccXxOqtPh?= =?us-ascii?Q?XRYyTWlWwPdCQ+lWkF6x++1upjchkpbuVI0YJdrwY/Lj+2r+qmYG8j3pcmuf?= =?us-ascii?Q?VFYva6KMmuB7bEuBj0l88ydcenAO/cN0GfDTM1R54fmPapMZDXR7pxZm208B?= =?us-ascii?Q?3Q+AwSaMCXP2R/u+HfW7QhMw3yl8CoVO7goy47iglRdUV/ffKLM8kBCXxddh?= =?us-ascii?Q?zZQVUyZLY7MifHt+vfjM0+e22gqLb7bawnVjVg3P+VELV//FQ6K2zQivp3iU?= =?us-ascii?Q?cbRSp9fG203EvyH8mbPIk02cN3nKuJeuu6tXEEi7+PTMt61w1jlYkc8xAjUu?= =?us-ascii?Q?yaBX8LCkC9saQ3Pi3wXDjPkJwPTGo9QPlbo2tsPwZcZam+SMNpIwZuUbxCr2?= =?us-ascii?Q?rBTQTudMlJVKF3RmfZKjYVnYLbSKrtoAI+cnL2R0soz2wOjMsHWFip9uAbJf?= =?us-ascii?Q?Ltmha5r169yi0Rba0Qx4rDOlUFD3N5PjcBF6gZT44l3SUVg5rpt7jowRVYdV?= =?us-ascii?Q?K8LWr2cT/yCaFgVUjP0ig094hNZKjpJCBCn/0DyNvm7SjsfEHJSS8CQIUnta?= =?us-ascii?Q?AS1Z5guskXivOzrKv5n5RMg4z8sbZ4po1ie2TugkXaxr9ONx4n5j7nObO3S0?= =?us-ascii?Q?fDDtHrxd9JwsZ/zoP8fIL9EEzLqfPuPSQIy52udm2buRSXUt9FTPe7W9fyma?= =?us-ascii?Q?QIaNB7AM+EwlATCvjQ2G4qjqp4UG3zDHISQDtB26xVxSADfPAx/ZJv+y0kf6?= =?us-ascii?Q?an6vWCljFlpfFwxmc6Od9NO8ia4r8J9WjGKnjG/6pjhd/s65e07oHp0UXSgk?= =?us-ascii?Q?M6Vroj0OmHhBxAZ76JMhbJb50tDoG78SmJcmdPPELDYkz1HxBArkXP6LhPea?= =?us-ascii?Q?Cr11aoLaFm86D3HOIrNbEoHDlK3EB9vOjEhVRV6ZkaRCgqoH+EdGNw=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN0PR11MB5757.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(376014)(366016)(1800799024)(38070700018); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?ps3ZP+MSW7ZLDzDUWPNMqrToOs0etfPMVM/aIOZFSfSLj23cuu4rIiz0AgoJ?= =?us-ascii?Q?i7Xqq0j3RkqDUQ3A2Ls19j0YY4QZDonl/MOcm/eIwdD78t/+q+aPjHJojQfj?= =?us-ascii?Q?A1o/2rGlIGoZRAgPJ1v1hjp/fw7laHjdq3+5+xCiHd4T4wBVUeNQ8x/7Ltnh?= =?us-ascii?Q?ZDdp+D3N3OXcfWLggQMM3xCvK6mrMGNcy5NfQ7L3CqFxPEns7LBPlxTRcQtt?= =?us-ascii?Q?agoHB3iSBxHJAkpCIP8XjulxC1hfShhfOzvO0aTZllIVUwUjHLHv89ViQMWX?= =?us-ascii?Q?oaBFcis0SCWW3LuurMcVykaD1ymZwBrsu6yIqYgxcgbo1ZHhK9GTt0KOvPqg?= =?us-ascii?Q?M8GR1hpb9wSfoRH9ANmgO3WBOH+AaJsADegK7NnP2ZF+wG553weNkye96GuA?= =?us-ascii?Q?DR8S1FvPoIA0Oqr4ug8c+pokyzuFGGx+aF5P6sOkcMLsAwwojB8NiFiOVbuj?= =?us-ascii?Q?LIyGMd1c82/z5hRtblDCwcneOfoW0eFdM7RYB8gsy5YM9cJnl/tnKC/x18sh?= =?us-ascii?Q?mGj6CDEZdfjEMK9ZZK0xc5lQx79OiGnk8FfB7PBQt+AFcw7HRN1Y/c15xyct?= =?us-ascii?Q?7vnalXSMB21vPiDmpc6Cs3tT5rEUrkE0QLACwjx7jkxFMyKkyOHEf8y8ntcN?= =?us-ascii?Q?15mgy/JaVJTilifTtpqbu2HZGhCo5eUZAPr7TQ3C0bfGBreFWEZLst6y/sm3?= =?us-ascii?Q?pPuMFfcSopNwNfTMnqsFRcorfbiUkDmYRzALBQSYyQcDIBkRY5oFyvOJAXTa?= =?us-ascii?Q?A/siJhAvA2Zekvhb4i75IcTbIJ0u6ZFqyJFTCVFwTSHm5q3Ppv5rT+Uhb6hz?= =?us-ascii?Q?YuNE5D+cCiotLw52IncTlcoTWsAmi/Dh/sBO9D68uzsBQ8lvKXLJf5lAXoiu?= =?us-ascii?Q?VA2HIIqsjUdQ6wjYKqly6T9scQ/ejZuwTLBlUgdm4u5nwLDbCl53Ney1YjeI?= =?us-ascii?Q?UewH3hEVRnK6bj05SY24iIoWWwqMTzJI+ywnpqWBlDqESlxaOPa1GFbQkA5m?= =?us-ascii?Q?l2L4wtxFu9OATYMvRJ8QF8L6LhbvELZizmoGHvRsuMLcA6tsS79OgZlrAZFN?= =?us-ascii?Q?iSeRW71fQDcPk2sltrOw0D3IC8lUjl9mk+JNqzsuDywPn2fyVNcQ9FlXMRNT?= =?us-ascii?Q?rPnscKkefThI0LQDDG0eLGC1xc0uQht+EeFfW2M3MbOadHpq6+HVj1H+m824?= =?us-ascii?Q?8AJwINNn7GD4t5Ck3yz5OFbfTiDJNgiLH+DbGwxzXKeZAZrlR8jYR7dRiUyH?= =?us-ascii?Q?lfsQMPmKtc6d1C1POwyWsZPQDNHl6xQKZ+T2Z7fATc83o8PzcaGRN9Tn/Y4J?= =?us-ascii?Q?wD1qTt0Z/iaJtQ+mePvZb22YYGRrq8xpMUWz2/zUPqTAo5xGlHVKPh36T9fZ?= =?us-ascii?Q?grItC1C4DaYMB5hUY5AlG/fgR2w5F3X16f2R7LxGJQk3O/L194RfMsGT6ghe?= =?us-ascii?Q?w0WKt9HViuUY7bXsjIejZEJLEYj+3DS8kBI/MIlF7FtADvVkER1i/VhnZCxN?= =?us-ascii?Q?t71LzzVPWPgtNuSZ6bvBZVNcz3qGaq7mjd2K37+xZ5zA2nvPLTJS5PtUeQiY?= =?us-ascii?Q?dmwax/4CH3IBAP5BYrIVflxmNEonDkSgNoAGWaMi?= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN0PR11MB5757.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c7627f9c-5f2d-4ba4-6c9b-08ddd0d0d914 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2025 07:55:56.9811 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GyPvrfth12pUKH7IYhTC0p8PVLNQzgMDrfTDejQWxgH7QO4jdo1R0VKANDGWIETk5M+XfXem8yC0hDDfz/+OAL7WgfMc9MAFI9bHmjnXcj8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB8427 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hello Thiago, Thanks for your review. >Regarding the subject: > >Can you expand a bit on what conditions cause this error to happen? Is >it broken only for the ze target, or do other targets also get the >error? > >Is it returned when, during handling of 'H', find_thread_ptid can't find >the ".-1" thread? I.e., by this code? > > else > { > /* The ptid represents a lwp/tid. */ > if (find_thread_ptid (thread_id) =3D=3D NULL) > { > write_enn (cs.own_buf); > break; > } > } It's been a while, so to answer your question I reverted the patch to trigger the error again. And it no longer reproduces. I still think something is wrong, here. >> When opening a connection, the remote target does >> >> set_continue_thread (minus_one_ptid); > >One interesting aspect of this line is the comment above it: > > /* Let the stub know that we want it to return the thread. */ > set_continue_thread (minus_one_ptid); > >What does it "the stub [...] to return the thread" mean? I tried reading >in gdbserver code what it would do if it understood the Hc packet as >referring to null_ptid or minus_one_ptid, but I couldn't find anything >that could be described as "returning the thread". > >And yet it appears to be the purpose of the line above. I'd say we need >someone who understands this aspect to review the patch. Agreed. >> which results in >> >> $Hc-1#09 >> >> to be send to gdbserver. In remote-utils.c:read_ptid (), this is read as >> >> { , -1, 0 } > >Nit: I'd say "" rather than "". > >> and not recognized as minus_one_ptid when handling 'H' in >> >> ptid_t thread_id =3D read_ptid (&cs.own_buf[2], NULL); >> >> if (thread_id =3D=3D null_ptid || thread_id =3D=3D minus_one_ptid) >> thread_id =3D null_ptid; >> >> Since minus_one_ptid and null_ptid are treated the same way, this is >> probably what we want. > >Not sure I understood what "this" means in the sentence. If it means "we >want our Hc packet to be interpreted as thread_id =3D=3D nullptid in the if >condition above", then that's not what this patch does (sorry if I >misunderstood). As you noted, read_ptid can't return a minus_one_ptid, >but it can't return a null_ptid either. > >With the patch applied, read_ptid will return { , 0, 0 }, >which ptid_t::is_pid () considers a PID and thus the handling of 'H' >will call find_any_thread_of_pid, which I'd guess is why this patch >works. > >> In remote_target::remote_resume_with_hc (), we do >> >> if (ptid =3D=3D minus_one_ptid) >> set_continue_thread (any_thread_ptid); >> else >> set_continue_thread (ptid); > >There's no talk of wanting the stub to "return the thread" here though. > >> which amounts to the same thing as set_thread () does > >Not exactly. In the code below, there's one more "else if" branch: > >> *buf++ =3D 'H'; >> *buf++ =3D gen ? 'g' : 'c'; >> if (ptid =3D=3D magic_null_ptid) >> xsnprintf (buf, endbuf - buf, "0"); >> else if (ptid =3D=3D any_thread_ptid) >> xsnprintf (buf, endbuf - buf, "0"); > > else if (ptid =3D=3D minus_one_ptid) > xsnprintf (buf, endbuf - buf, "-1"); I argue that on the GDB side, magic_null_ptid and any_thread_ptid are treated similarly and that on the gdbserver side minus_one_ptid and null_ptid are treated similarly. When resuming, GDB even turns minus_one_ptid into any_thread_ptid. But I believe the issue lies elsewhere. >So remote_target::set_thread doesn't treat any_thread_ptid and >minus_one_ptid the same way, even though gdbserver apparently does. > >Also, the doc comment of set_thread says: "If PTID is MAGIC_NULL_PTID, >don't set any thread. If PTID is MINUS_ONE_PTID, set the thread to -1, >so the stub returns the thread." > >Here's the talk about asking the stub to "return the thread" >again. Frustrating. The comment was added in 79d7f229011 Use ptid_t.tid to store thread ids instead of ptid_t.pi= d. probably based on an earlier comment at the startup set_thread() call in c906108c214 (tag: gdb-4_18-branchpoint) Initial creation of sourceware = repository + /* Let the stub know that we want it to return the thread. */ + set_thread (-1, 0); + + inferior_pid =3D remote_current_thread (inferior_pid); The set_continue_thread() (or just set_thread() in earlier versions) is fol= lowed by remote_current_thread() (also today), which sends qC to query the current t= hread. This could be what is meant by the target returning the thread. This query, however, uses the general thread, not the continue thread: /* Reply the current thread id. */ if (strcmp ("qC", own_buf) =3D=3D 0 && !disable_packet_qC) { ptid_t ptid; require_running_or_return (own_buf); if (cs.general_thread !=3D null_ptid && cs.general_thread !=3D minus_= one_ptid) ptid =3D cs.general_thread; else { init_thread_iter (); ptid =3D thread_iter->id; } This special handling of the general thread was introduced in bd99dc85838 Non-stop mode support. and it had always been the general thread, not the continue thread. Before, there was only the else part. So, if we wanted to let the target tell us its current thread, we should re= ally be setting the general thread. And it doesn't matter if we set it to null_pti= d or to minus_one_ptid. For Hg we also see some special handling of null_ptid and minus_one_ptid, which got turned into null_ptid earlier: if (cs.own_buf[1] =3D=3D 'g') { if (thread_id =3D=3D null_ptid) { /* GDB is telling us to choose any thread. Check if the currently selected thread is still valid. If it is not, select the first available. */ thread_info *thread =3D find_thread_ptid (cs.general_thread); if (thread =3D=3D NULL) thread =3D get_first_thread (); thread_id =3D thread->id; } cs.general_thread =3D thread_id; Maybe we could also rely on gdbserver initial state, as we're just starting, and remove set_thread() in remote_target::start_remote_1(). It further looks like read_ptid() needs special handling for the special thread-ids -1 and 0. This needs more discussion. We'll drop this patch from the series as it turned out to be unrelated. Regards, Markus. Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928