From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26396 invoked by alias); 24 Sep 2004 20:07:02 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26304 invoked from network); 24 Sep 2004 20:06:58 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 24 Sep 2004 20:06:58 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8OK6vqe021322 for ; Fri, 24 Sep 2004 16:06:57 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8OK6sr21960; Fri, 24 Sep 2004 16:06:56 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 07A9628D2; Fri, 24 Sep 2004 16:04:38 -0400 (EDT) Message-ID: <41547DD5.5020100@gnu.org> Date: Fri, 24 Sep 2004 20:07:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831 MIME-Version: 1.0 To: Robert Picco , Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: new gdb remote packet type References: <407F2BAB.4060408@hp.com> <40802711.3040104@gnu.org> <4087E8C0.30806@hp.com> <4087EE4B.4010805@gnu.org> <40912015.7070902@hp.com> <40928D64.8010209@gnu.org> <4097D9DE.2030004@hp.com> <40993C21.1040500@gnu.org> <409A95AB.6020101@hp.com> <40A26AF4.4050001@gnu.org> <410E623C.3020107@hp.com> In-Reply-To: <410E623C.3020107@hp.com> Content-Type: multipart/mixed; boundary="------------030401020904070405080108" X-SW-Source: 2004-09/txt/msg00416.txt.bz2 This is a multi-part message in MIME format. --------------030401020904070405080108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1390 [draining my backlog] > Andrew Cagney wrote: > >> >> To get this in, there's some additional leg work: >> >> - copyright assignment? >> >> - documentation (see gdb/doc/gdb.texinfo near the end) >> >> - a corresponding gdbserver patch >> >> - not to forget, ChangeLogs :-) >> >> Andrew I cleaned up the ChangeLog and commited the remote.c change (adding a nod to Fernando Nasser who wrote a part of the original code). Eli, How's the attached slightly revised doco tweak? Andrew > FSF has a copyright assignment on file for me. The other items you mentioned are contained in the patch below with the exception of gdbserver patch. There wasn't any feedback on 'P' packet support not being in gdbserver. So I'm assuming that not adding 'p' packet support is o.k. > > thanks, > > Bob > > diff -ruN gdb-6.1.1-orig/gdb/ChangeLog gdb-6.1.1/gdb/ChangeLog > --- gdb-6.1.1-orig/gdb/ChangeLog 2004-06-14 18:39:49.000000000 -0400 > +++ gdb-6.1.1/gdb/ChangeLog 2004-08-02 10:33:03.993382712 -0400 > @@ -1,3 +1,9 @@ > +2004-06-28 Robert Picco > + * Add new 'p' packet to gdb/remote.c. The 'p' is for fetching > + the value of a single register. It complements the 'P' which > + writes a single register. Should the remote gdbserver support > + the 'p', then 'g' packets aren't used. > + > 2004-06-14 GDB Administrator --------------030401020904070405080108 Content-Type: text/plain; name="diffs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diffs" Content-length: 1135 2004-09-24 Andrew Cagney Robert Picco * gdb.texinfo (Packets): Document the "p" packet. Index: gdb.texinfo =================================================================== RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v retrieving revision 1.214 diff -p -u -r1.214 gdb.texinfo --- gdb.texinfo 20 Sep 2004 22:26:21 -0000 1.214 +++ gdb.texinfo 24 Sep 2004 20:04:27 -0000 @@ -19963,17 +19963,20 @@ Reserved for future use. @item @code{O} --- reserved -Reserved for future use. - -@item @code{p}@var{n@dots{}} --- read reg @strong{(reserved)} +@item @code{p}@var{hex number of register} --- read register packet @cindex @code{p} packet -@xref{write register packet}. +@xref{read registers packet}, for a description of how the returned +register value is encoded. Reply: @table @samp -@item @var{r@dots{}.} -The hex encoded value of the register in target byte order. +@item @var{XX@dots{}} +the register's value +@item E@var{NN} +for an error +@item +Indicating an unrecognized @var{query}. @end table @item @code{P}@var{n@dots{}}@code{=}@var{r@dots{}} --- write register --------------030401020904070405080108--