From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id 37A5A3857C77 for ; Wed, 13 Mar 2024 15:58:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 37A5A3857C77 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 37A5A3857C77 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.51.188.92 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710345534; cv=none; b=ZxbShgdMjD1y3Loh/Ta6uQI9XxbNVsIgY/XH0IZKkQfnagJZ+QhAUPjabs3xt65IvTrmC0H8UNqgEMJSnXnu1ihDGu1MjQT8uKQiMktO7oJQS8mIrJ2vjmzFSauCEcZoLX1S3dDvDooJDT1L3Yk30pLUJ4cfQwokqAL7m09K1do= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710345534; c=relaxed/simple; bh=s3SRq6B13fx43DaC3vHEWX3MHCuYqoG7vsxuSauZxGk=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=RcpbwBBe+SW3koeDDCyQ5PkgPg9gVTuZ5w2OmI2T9ll/kOVfrdzJ4j9/pD5wRu6hBA9BZOK8kN+0NJRDnirw56aBKo1eVExUPo/S2DcXf1+J5QEGZ4goQIcMTRnXz7sh+od3iaX/n68Cgxf/2JnvFqN6T2dJr3TZ+60mU8NYoM0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rkR0F-0001ut-M0; Wed, 13 Mar 2024 11:58:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=nU0n65HPIfvqBLjDt1GiyhxUDRSJldWCPqaiGb5Ah/Q=; b=iR6daLoCkyTI Nktnb8qMqGmNt6SxHTVwQJYnC5Gv83HZTdNJzEqjLfdAPGJuwikBIV5QJpRPVObEU5KVVzwjBE+2i s3int/GaGzY9fjc9MNDoToR8izkCXOwm6Ys5vlckVHYV1rhsdmVfaJOZ4gwpCok58vu6TvtfSA7s8 zDgZqp0VfX0+qFuSp/QA087PsVp8Cg5RIU9MmW3AEYWe3ts9BFKU4RvvfRj5W9HVrfrx+cb4h3G/p amcG/sLRVShGS8B37KTrNMeAmdQvf+S2ia6W9BZ3NPLsooJplfJsbat5ZKcGwaoc258RpkKQyl7Na CM1aGzVWDmXG3EMMBGV5Ow==; Date: Wed, 13 Mar 2024 17:58:48 +0200 Message-Id: <86zfv2azt3.fsf@gnu.org> From: Eli Zaretskii To: Tankut Baris Aktemur Cc: gdb-patches@sourceware.org In-Reply-To: <990be8b42f1f6ca33ffed7a8ae7ead327009d847.1710343840.git.tankut.baris.aktemur@intel.com> (message from Tankut Baris Aktemur on Wed, 13 Mar 2024 16:35:45 +0100) Subject: Re: [PATCH 3/3] gdb, gdbserver: introduce the 'x' RSP packet for binary memory read References: <990be8b42f1f6ca33ffed7a8ae7ead327009d847.1710343840.git.tankut.baris.aktemur@intel.com> X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > From: Tankut Baris Aktemur > Date: Wed, 13 Mar 2024 16:35:45 +0100 > > gdb/NEWS | 7 ++++++ > gdb/doc/gdb.texinfo | 29 +++++++++++++++++++++++++ > gdb/remote.c | 45 +++++++++++++++++++++++++++++++++------ > gdbserver/remote-utils.cc | 39 ++++++++++++++++++++++++++++----- > gdbserver/remote-utils.h | 2 ++ > gdbserver/server.cc | 21 ++++++++++++++++++ > 6 files changed, 132 insertions(+), 11 deletions(-) Thanks. > --- a/gdb/NEWS > +++ b/gdb/NEWS > @@ -152,6 +152,13 @@ QThreadOptions in qSupported > QThreadOptions packet, and the qSupported response can contain the > set of thread options the remote stub supports. > > +x > + > + Given ADDR and LENGTH, fetch LENGTH units from the memory at address > + ADDR and send the fetched data in binary format. This packet is > + equivalent to 'm', except that the data in the response are in > + binary format. This part is OK, but I wonder whether it would have been better to mention the packet parameters on the line that now says just "x"? > +Read @var{length} addressable memory units starting at address @var{addr} > +(@pxref{addressable memory unit}). Note that @var{addr} may not be aligned > +to any particular boundary. That "may not be aligned" could be misinterpreted to mean "must not be aligned". I suggest to rephrase: Note that @var{addr} does not have to be aligned to any particular boundary. > +The stub need not use any particular size or alignment when gathering > +data from memory for the response; even if @var{addr} is word-aligned > +and @var{length} is a multiple of the word size, the stub is free to > +use byte accesses, or not. For this reason, this packet may not be > +suitable for accessing memory-mapped I/O devices. > +@cindex alignment of remote memory accesses > +@cindex size of remote memory accesses > +@cindex memory, alignment and size of remote accesses These @cindex entries should be before the text they index, not after it. Reviewed-By: Eli Zaretskii