From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 3f4sNBR7BWYgkRkAWB0awg (envelope-from ) for ; Thu, 28 Mar 2024 10:13:40 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=UiCYORC6; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id C27D21E0C0; Thu, 28 Mar 2024 10:13:40 -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 A801D1E030 for ; Thu, 28 Mar 2024 10:13:38 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 252023858D28 for ; Thu, 28 Mar 2024 14:13:38 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 7AC183858D1E for ; Thu, 28 Mar 2024 14:13:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7AC183858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7AC183858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711635196; cv=none; b=HvftuL/MCJpQDOAp/JIPmAgy9l2JaS4sWN90ppmn5+pz498jJH9FxOVQyBB1jzdvPYG1NZAOSPaZGuLXQ3GIq0qEoM/9LbGxnAy8iWhMkG1ZBRX328nSBgjmzOQykETXIpWnIQViQTr+mT09F2k3JhbP91KqpR59mjTAc3n0eHU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711635196; c=relaxed/simple; bh=58BBbMoHs1zfnKn/sdGBGVCbgsBpEcgoUyIUMcWIPNM=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=tI8BwLeOG8iwX6pXG4ce4Imcdz0RT+ygoL+OFww3cnnjXUAPskH2MjYosaLH3WSRWPqXKvnhs/+1FvuPGNlT/UJTEaJGMIipbRku+STEsNEj14ZDrjbbTgqKlv8QM77kpS4GJWas7PYDDiWIEK5QSPmoCipZZId5Hdh6ZLWOSVI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1711635194; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fUQdj706eMCGdjMbgR2qjdHG68zukUcS/3HWZzjIdCM=; b=UiCYORC6ou2QcikAHDHvmY1PTUTUm7B9hdCr39ONaGmQVa9S4aKDPlRoThV2GWAxvFEk05 3EMXnRqY7u52Tfrf6meB/hbNvbcA50/q2VuAwznz3bi+eNQnoBDJ0AaZad8yHmgS5hqc/P nzH/kC1FuiWikIkLoRCNcPSVA+hAGcg= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-680-ahjRUH5HOQW6sBsOEfq9oQ-1; Thu, 28 Mar 2024 10:13:12 -0400 X-MC-Unique: ahjRUH5HOQW6sBsOEfq9oQ-1 Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2d499513d62so8997861fa.0 for ; Thu, 28 Mar 2024 07:13:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711635190; x=1712239990; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fUQdj706eMCGdjMbgR2qjdHG68zukUcS/3HWZzjIdCM=; b=Br+jcSG9WeOZhfmGjDvZwVPA30EowbXjeTawniwjdEr8qTpxeu4FNMCUu8WK3kszYA 9IMKItVJZLxhnI9UYsQfUbAq2E/yVFmSOxwY2Pku0tPUrjrO6IiDMXyuHL/42Wm4En8u 5wxOFvVMkpNNGDXVmQcBg358DcngAEHfjRsPdAi0pduGfluFo3G7NCSMrVMj8jXf9SUV d9cDKq2RbfWYBAlvojjbqOpxOINj58iSOSohjFTv2UyDRzCRCIsUEB/PWMuC+qrBfSQ3 9pDjyxanwLiLLQLkKTuKifz52rRbXqDj3IKX/mxhuWqzujxY/nundckee1gLma3zTT8V N+tA== X-Forwarded-Encrypted: i=1; AJvYcCWMBM8ukVMK/OHlWMN4rKFhiBx5od0ELFgGs722B/msjE7wGx3BL4kIw/kHCtlxxDMX7EVrXUPCLnQEn4nm9+9F3nq9tDx7i8BKHg== X-Gm-Message-State: AOJu0YxV8I9gsBH71VzDCIBm8j92zC6u2VOQd8MD9PmBTB0R1PO+kDxA o2kZph9LHxO+RFhqtkuCAUrVva0CsRJ1inIbPMKc/uvZ2x5/WTDVBp7pcu4AtQZTxqEUGJMp1Z7 uUcc4OoniVCrakGefX1Hj0iCYkawv7klqHYSFNs1JTHlB7bXqv7I3QCOxTWLiMjPVqL8= X-Received: by 2002:a19:7609:0:b0:515:ab7b:fc23 with SMTP id c9-20020a197609000000b00515ab7bfc23mr1920597lff.34.1711635190456; Thu, 28 Mar 2024 07:13:10 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFv8X0GrlVijf/FGoWTD6eSKySh21xO6CGHybN178efpJZDnErGRWkCGhjHOGxhaJ9STAbUNA== X-Received: by 2002:a19:7609:0:b0:515:ab7b:fc23 with SMTP id c9-20020a197609000000b00515ab7bfc23mr1920570lff.34.1711635189750; Thu, 28 Mar 2024 07:13:09 -0700 (PDT) Received: from localhost (185.223.159.143.dyn.plus.net. [143.159.223.185]) by smtp.gmail.com with ESMTPSA id p17-20020a170906785100b00a4e08e81e7esm788698ejm.27.2024.03.28.07.13.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Mar 2024 07:13:09 -0700 (PDT) From: Andrew Burgess To: Tankut Baris Aktemur , gdb-patches@sourceware.org Subject: Re: [RFC PATCH] gdb, rsp: clarify a 0-length memory access In-Reply-To: <20240321133018.602537-1-tankut.baris.aktemur@intel.com> References: <20240321133018.602537-1-tankut.baris.aktemur@intel.com> Date: Thu, 28 Mar 2024 14:13:08 +0000 Message-ID: <87jzlm4f7v.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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 Tankut Baris Aktemur writes: > Currently GDB uses a 0-length write access to probe for the 'X' packet > 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 > > Note that for probing, returning an error is fine. It successfully > shows that the packet is supported. > > Regression-tested on X86-64 Linux using the default (unix) and > native-extended-gdbserver board files. > --- > gdb/doc/gdb.texinfo | 9 +++++++++ > gdbserver/target.cc | 9 ++++++--- > 2 files changed, 15 insertions(+), 3 deletions(-) > > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo > index 6099d125a60..0a08c73f8df 100644 > --- a/gdb/doc/gdb.texinfo > +++ b/gdb/doc/gdb.texinfo > @@ -42755,6 +42755,9 @@ suitable for accessing memory-mapped I/O devices. > @cindex size of remote memory accesses > @cindex memory, alignment and size of remote accesses > > +The @var{length} argument has to be a positive value; otherwise, an > +error is returned. > + > Reply: > @table @samp > @item @var{XX@dots{}} > @@ -42771,6 +42774,9 @@ Write @var{length} addressable memory units starting at address @var{addr} > (@pxref{addressable memory unit}). The data is given by @var{XX@dots{}}; each > byte is transmitted as a two-digit hexadecimal number. > > +The @var{length} argument has to be a positive value; otherwise, an > +error is returned. > + > Reply: > @table @samp > @item OK > @@ -43127,6 +43133,9 @@ Memory is specified by its address @var{addr} and number of addressable memory > units @var{length} (@pxref{addressable memory unit}); > @samp{@var{XX}@dots{}} is binary data (@pxref{Binary Data}). > > +The @var{length} argument has to be a positive value; otherwise, an > +error is returned. > + > Reply: > @table @samp > @item OK > diff --git a/gdbserver/target.cc b/gdbserver/target.cc > index 23b699d33bb..6173ebb79f8 100644 > --- a/gdbserver/target.cc > +++ b/gdbserver/target.cc > @@ -89,7 +89,7 @@ read_inferior_memory (CORE_ADDR memaddr, unsigned char *myaddr, int len) > doesn't hurt to prevent problems if it ever does, or we're > connected to some client other than GDB that does. */ > if (len == 0) > - return 0; > + return EINVAL; > > int res = the_target->read_memory (memaddr, myaddr, len); > check_mem_read (memaddr, myaddr, len); > @@ -121,9 +121,12 @@ target_write_memory (CORE_ADDR memaddr, const unsigned char *myaddr, > /* GDB may send X packets with LEN==0, for probing packet support. > If we let such a request go through, then buffer.data() below may > return NULL, which may confuse target implementations. Handle it > - here to avoid lower levels having to care about this case. */ > + here to avoid lower levels having to care about this case. > + > + Sending an error code is sufficient for GDB to conclude that the > + server supports the packet. */ > if (len == 0) > - return 0; > + return EINVAL; > > /* Make a copy of the data because check_mem_write may need to > update it. */ > -- > 2.34.1 > > 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