From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id QMLIH9niFGbmyigAWB0awg (envelope-from ) for ; Tue, 09 Apr 2024 02:40:25 -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=d6yH9dpo; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 624551E0C0; Tue, 9 Apr 2024 02:40:25 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id D13BC1E092 for ; Tue, 9 Apr 2024 02:40:22 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 239D0385841C for ; Tue, 9 Apr 2024 06:40:22 +0000 (GMT) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) by sourceware.org (Postfix) with ESMTPS id AA8253858CD1 for ; Tue, 9 Apr 2024 06:39:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AA8253858CD1 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 AA8253858CD1 Authentication-Results: server2.sourceware.org; arc=fail smtp.remote-ip=198.175.65.21 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1712644801; cv=fail; b=FHTqqvwHaXrOFUTWR3i5s/LbGn7qZwNukh7ftylnlY5R1Ux+YToq6i3PrzTPF5zx0nwp2YsqX/ZGOeXfZ0LKj3xjZnPBmgQuVZOvl+ju6c/k7oKHJXN79e8l10Db9swWGoV16g1HtsVlcg3PVqZF/cK8Bz4JFmDHQ3wTsht4+YE= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1712644801; c=relaxed/simple; bh=vnbSOItym2SGkDTmASWKZG1DWx5YZrgS0x2qfVE4nnQ=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=IvC7vDD6KnBHO+vX+TyUimJZytwCebhUYMRsoXLhnLydTii5azo1cgxgRHTt0nQbNiWbZDWVgIodflOS8XoCgWuXdvvjKkExRIH/8fZlAdAWf9/vrFBMS65BpUB0x1/5QzDpIzypIn6i5GiAKmk86zdoWxDMng3N7/AVNn5hb/E= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712644799; x=1744180799; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=vnbSOItym2SGkDTmASWKZG1DWx5YZrgS0x2qfVE4nnQ=; b=d6yH9dpoQ1vPQqyJ6aF/fUDh01M4kWajemtm7xxF7Ma2qh7s8ha4iezy MmMAl5OJYReLX3coLtjtxQwJ/HJkzQRab1+2OBYJtHsV9orkwtgDsawsJ zpxh++u1pXME/umPiv1vBGkYhRZT4fDK81Yr0HOFVvI8YjisPKqCQ1gCD qxR4Vwp2wm9xrbf7t7rdf8F4r56CV3m1UvTNg6dGO88WJH5llq/ychFk7 BwJx5UfgxZnvD4C+HP0Z9ZY/dn9cQ8sS7uzRpjuPftrKOwhLnXme+vUrV AQZx83evTd3UTPlPBVuD+9hbBOAD7jMTbNkC93xKJpy93skSUkjQy/Hzf w==; X-CSE-ConnectionGUID: f9QCRIdVT+qUWUK2aXTxgw== X-CSE-MsgGUID: iJsCBJIiQ6CgigCg1uZe3Q== X-IronPort-AV: E=McAfee;i="6600,9927,11038"; a="7858024" X-IronPort-AV: E=Sophos;i="6.07,188,1708416000"; d="scan'208";a="7858024" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2024 23:39:57 -0700 X-CSE-ConnectionGUID: 7h2w48O5TW6xZQkn69v5Xw== X-CSE-MsgGUID: hFwcFUg5R2qzbev6no0XOQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,188,1708416000"; d="scan'208";a="24618942" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmviesa003.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 08 Apr 2024 23:39:57 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 8 Apr 2024 23:39:56 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Mon, 8 Apr 2024 23:39:56 -0700 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.101) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 8 Apr 2024 23:39:56 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HPnTCBoJfYewPUaTbCK7f8HPGw7/ywexu8EK20qu7EBBjAODszYq8fQRuvjREtP4Je7RyLmwsYph2tjSSpyajaifdzXqAV9GCSzcEvUomrRgpa5RVU+pY0QYPpzKZcFTMN7KdsbF7dZblDKWmWRHQpWE6p+bYMgKpfncp2FPjxiq6AkeJlp3+9aJmsX6MTl98zjmsQYmPMLxAe/edUK8PziMK5OimcGjlIYqoxGlkwC/Llnkgh6qHRZeafEL6JqspW0jL74DNOhqeKC4xK7lHupMeLAFsUkTOappHn1282mrHJlmTBfB8obi5PaK2jz6koGABmj676jdkCAJ+ZTeuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=FByLMj+Uipto2DS8QCT/J3HPUYwzrDfAJGbsLWgsHy4=; b=dEJmgKHbTtOm1B/79zEjDGtE4COJuSAezl8jMweYXMSPrx/l5lLb9IOKpAjyLpFIAwtp6TdNoKKEJbKKr8rKIG+5AYll2u2KcFBSclpN5U0z+WakzahaQVhmIqtt+EUY+LZ8UCyJDG0P3zOFuHwgbzznUS2W+P4RMJzZ/fBTHU/Go6x2rA0z7ZyCHdsU4eovLUKX1qzRYFO8wy9rbQ4V9kYKDIP+lEkrY1Mbh7DfXFO/BMZjtXZ6yzfjXfTKawLPDXiB22QuuIdOAO0QOYJ8/Mntsi2uCTueCcJ26PZpxdgWfzpkTh5DE71GNC5H6DTB+lUcM//xASH1nb1a4ZpeFQ== 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 DM4PR11MB7303.namprd11.prod.outlook.com (2603:10b6:8:108::21) by DM4PR11MB6456.namprd11.prod.outlook.com (2603:10b6:8:bc::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7452.26; Tue, 9 Apr 2024 06:39:54 +0000 Received: from DM4PR11MB7303.namprd11.prod.outlook.com ([fe80::9c92:b02a:3add:529e]) by DM4PR11MB7303.namprd11.prod.outlook.com ([fe80::9c92:b02a:3add:529e%5]) with mapi id 15.20.7452.019; Tue, 9 Apr 2024 06:39:54 +0000 From: "Aktemur, Tankut Baris" To: Andrew Burgess , "gdb-patches@sourceware.org" CC: Tom Tromey Subject: RE: [RFC PATCH] gdb, rsp: clarify a 0-length memory access Thread-Topic: [RFC PATCH] gdb, rsp: clarify a 0-length memory access Thread-Index: AQHae5P97Bt70e8XK0WzwXRPCk6ObrFNPPUAgAAUirCADGyOgIAF2B6g Date: Tue, 9 Apr 2024 06:39:54 +0000 Message-ID: References: <20240321133018.602537-1-tankut.baris.aktemur@intel.com> <87jzlm4f7v.fsf@redhat.com> <87il0w2bwm.fsf@redhat.com> In-Reply-To: <87il0w2bwm.fsf@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM4PR11MB7303:EE_|DM4PR11MB6456:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oUFoBEEiAsVm2w3FjN0domWspaSYJne9NQ7qHzgiKfiu/sUChc12NPUaSJA1YKoqYDTKSFavyt/kQ5XQ0TtlPEgO8qSBJ+EZ1G+0dDGWm7AYshjygLh05OnZHn08fkBmLCMR2MuPXWCORk3V/8prWWRCpgdVu6px97QKoBeQBuPiY+dZWRtOmhI7pNpXm3XDoCG75AhM8kM1smODqswhwFcOWL5seZl3M1rjkir/faAWbrXOTEIzLnPcZOM20o8omsz4OK1Mg/EoBqEBLi1+HAm71s7fGFKOKdlm8Z0joUX0smz5Wu2y8sFkUnutP31JTvLVLm0QVjZgmpJaGysQHAxAcSs6sIl4bz4/lTsDCfmS92/8gBRn0DfDASZ1i7Lpvmd++Qr3f6sPQqrfWoPfk8EF8KLahjenAY3V/46L79vP94OKLIpFfan4yDx0ZdgeMG7d9HJtKnKU4iOfk4jqKqCF+ErAfL8S1X98TA6c1OBgb9iioTvLn5/K/V03CPFZ71SMJtirCm6PgjJSdyXFxW2SSO3tFdAgdnkvbk11phSlie0iVEyEgznqHZ6CQBxgBre6TO+BFKqGwf5sxROG6EUsMZndFy3qxvoQ2l0zBIxeY5DkVKROtlgIht4LxDGyPzieoR7qZNgRe1ppwcIcFQX/uHU0Zryrt6nzH2EuAXY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB7303.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366007)(376005)(1800799015); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?KGw6tMQs4sJot9hvtC4tOTgWlTzfJHQJirhcsecyIR2E0LPMWsm5hmsFF+Se?= =?us-ascii?Q?rtZDRGF6e1Gq3OrqT8t09BZ1O1WwygZxBtOuV717b77Yt3sIyuiu8W/tqk7l?= =?us-ascii?Q?QQV/0I1juTP2HxEF36ufMXh4bZsneVhKxVG1o++HiQjbtNciCOW5YDwCJoDB?= =?us-ascii?Q?TAoD+ZrPaPZaoZ+FC7+lBm7E78yjN5wtBZzzHFdgB2b9/6gY7HBPvc4mPEQu?= =?us-ascii?Q?hEMLWohbpWwe5XgeAEfIZlszBzlENtKiLxJziNjI57RPLzdrCBguDIqbhKiI?= =?us-ascii?Q?PLIyvY8Li8UKOwImWEfC8/NmSBAwRVWA/69qDob75ZA+TEThSLOExFQY962r?= =?us-ascii?Q?GrPr2WzUlesrWL4ZeVn1VRHFUt4HxzqghAND54zz97XzxIlptBSYBDblGhbv?= =?us-ascii?Q?lEXAULr/tdBO2do2wCkeLRo6rmCRSnBHSSfU3JA3OdgxuXx1LaqcOFOpIdRm?= =?us-ascii?Q?ngTAlYy7hcNxXES0zVrLbhtVIBvA4CuRz40Moo6VIa52lLzTc3UZ7QN+ovkw?= =?us-ascii?Q?gQowUA8jfWIxF2c6SgNnHMMK1sukA3FAGxJw1UxNqn/LBdwoYwLTiAvAX0Pi?= =?us-ascii?Q?705qp6H5vRQm1y95Jv23eOrBbtqh/6jrQFGpOG0iBTjLQL0GrCumcA4BWtHB?= =?us-ascii?Q?0V6v/VTfVRpkyCy1D3sTmIs4pnM1K8+v6hFtO7DxXqf18gE4993w+43yfmJI?= =?us-ascii?Q?j+ZO2V90ndS16u8Xq1K6MVpJk7jhInVk0q4eX9thxkFL/ldufFyGaBM3rUXB?= =?us-ascii?Q?Kl+drGTsQlM1QgEhAjxyo1HU+HV0+laGBting3mmdK/m3XoL6jWJeRMjEBUb?= =?us-ascii?Q?fjTUeT8Iq7cBSZ8lQng0s8AJOLkCOSaAGfKPlc+RubU1TEzJZG91X8g7lPUV?= =?us-ascii?Q?nXI1MySmhXDKDN/JPM/gAZoNbbibv6eWzouDugsPlH4XDc0/RC0YrC72K0aE?= =?us-ascii?Q?DhZ+wp9JYQbhTTYBHrT6bGZnKoeZUfG7wnyo7qz+KVmEWQ7JJAoed0hNa/qN?= =?us-ascii?Q?Psahbk1MYx5qYMQhtBTfU4veKXHBoiWZ+0J/66iEt3Ch6iyJTRuZifADZql8?= =?us-ascii?Q?xW+svVwG6g3/xy0UUVl7RL5WVyQSJ6d3wwEze4Wbod/LKhCzKFDo71Jz3zJL?= =?us-ascii?Q?cqcfVmh+XjYU6NYkxg7HvX2MU1hhgPWX+AYbL0ScbPa7N036yinzeAVgQKVj?= =?us-ascii?Q?LT/lnZco/DVKED5HsvQIkX0wh6gmfLCA3K09Z98JrANJdKL2L71iSz0gzIH2?= =?us-ascii?Q?VIHAoLPYahRcll/z7Pst2uW9YbjPp8ZVs2rIKZ6CLpoc8qwWl5sjkP0JW7um?= =?us-ascii?Q?udgPHSyqCELHuWMgCF+H3vdlne3hhWWSp2YLqN00/14BA+WB2JiAbWI6hxor?= =?us-ascii?Q?CFwFez0cQ7HqSlEf2uLpvNbSIOcaTzhpCjbO7MMuIVMKWw3eYo3zTVWoKY07?= =?us-ascii?Q?jt5Of3E7K59dme/d0T2bm2Z0CF6ZGjInSmIByu621gXOJcBsACQQ6COsEA/U?= =?us-ascii?Q?FEQ7RHeDm4EEM5HPKx1VtJfsIxVT01WHolaNx4KN5YOY3sQkvp31EKnuhHv3?= =?us-ascii?Q?RTtESfIwyFv7mI70jTDAQXbBfE+8Bg8jktEE/Rv4+TrQbbIS5Bv9RLX83mxg?= =?us-ascii?Q?cA=3D=3D?= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB7303.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 15b1f6c2-81f3-46f1-a0fe-08dc585fdddd X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2024 06:39:54.6579 (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: bQbXL7WtDBPM05xQdQx5BpyPYokTq8zy4xCTqUTBAXf9kdpueoscZ5nhFxnYLIfgJ69cWzj3aDb7xrMn5EPEmb2H7t/uS9rKTy15zXEIO+E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6456 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org On Friday, April 5, 2024 3:10 PM, Andrew Burgess wrote: > "Aktemur, Tankut Baris" writes: > = > > On Thursday, March 28, 2024 3:13 PM, Andrew Burgess wrote: > >> Tankut Baris Aktemur writes: > >> > >> > Currently GDB uses a 0-length write access to probe for the 'X' pack= et > >> > support. However, it is not clear from the document what a 0-length > >> > read or write attempt should do. Clarify the document that it is > >> > an error. Also update gdbserver's implementation to return an error. > >> > >> We're usually pretty conservative about changing existing remote > >> protocol behaviour. > >> > >> If I understand the current behaviour correctly, we treat the zero > >> length access as always succeeding, but you propose to change this to > >> always fail. > >> > >> What's the motivation for this change? Does the existing behaviour > >> cause some problem? > >> > >> Usually, when the docs are ambiguous we update the docs to reflect GDB= 's > >> current behaviour, unless the current behaviour is clearly wrong. > >> > >> Thanks, > >> Andrew > > > > Hi Andrew, > > > > The background of the submission is the thread linked below, where Tom = expressed > > his tendency to think that a 0-length access should be an error: > > > > https://sourceware.org/pipermail/gdb-patches/2024-March/207411.html > = > OK. But here's my real worry. Right now gdbserver always succeeds for > a zero length read/write, and it's possible that there exists other > remote targets that have copied this behaviour. > = > If we change the behaviour for this case, and an updated GDB, that > expects zero length will result in failure, connects to an old gdbserver > (or some other remote target), what happens? > = > Even if *this* patch doesn't introduce a dependency on the new > behaviour, future patches might, so the question I think is still a > valid one to ask. > = > Maybe we can show that older GDBs would _never_ send a zero length > request? In that case maybe this is OK. I'm not sure how we could show that feasibly. Currently in = `check_binary_download`, GDB sends a 0-length memory write ('X') packet to see if the packet is supported. Receiving a success or a failure does not matter, they both denote support. We can check the git history of the `check_binary_download` function; it was most likely always like that. But maybe there was a time an older GDB sent a 0-length access packet somewhere else and explicitly expected success or failure, and that code was removed later on, I don't know. It seems very difficult to me to prove that no such check existed in the past. I can update the document to match gdbserver's current behavior of sending success. One glitch there is the 'm' packet, which replies with an empty response if the length is 0; so, distinguishing success from unsupported is not possible. (gdb) maintenance packet m01234,0 sending: m01234,0 received: "" (gdb) maintenance packet foo sending: foo received: "" (gdb) But maybe 'm' is always supposed to be supported? = > The solid solution would be to add a qSupported packet to control the > behaviour of a zero length access. The default would continue the > current "success" strategy, while if the remote supports the new packet > the behaviour can switch to a "failure" strategy. > = > Thanks, > Andrew Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva = Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928