From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28062 invoked by alias); 12 Feb 2004 02:12:03 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 27959 invoked from network); 12 Feb 2004 02:12:00 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 12 Feb 2004 02:12:00 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id DDA48357B; Wed, 11 Feb 2004 18:11:58 -0800 (PST) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.9/8.12.9) with ESMTP id i1C2BwOi011029; Wed, 11 Feb 2004 18:11:58 -0800 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id i1C2Bw7f011025; Wed, 11 Feb 2004 18:11:58 -0800 Date: Thu, 12 Feb 2004 02:12:00 -0000 Message-Id: <200402120211.i1C2Bw7f011025@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: remote protocol support for TARGET_OBJECT_AUXV In-Reply-To: Andrew Cagney's message of Friday, 6 February 2004 12:01:55 -0500 <4023C883.6010407@gnu.org> Emacs: there's a reason it comes with a built-in psychotherapist. X-SW-Source: 2004-02/txt/msg00118.txt.bz2 > > I think these improvements are worth pursuing without delay. However, I > > don't see any reason not to go ahead with the protocol you have proposed in > > the interim, since I can implement that in a few minutes without perturbing > > anything else. > > OK. Once we've seen the numbers we can persue this. What numbers are you referring to? We already know the number of system calls, number of protocol transactions, number of protocol bytes, and such numbers involved in having or not having EOF-detection optimized. > For here, the cases I can think of are: > > - new gdb, old stub, packet not recognized > "" must always be returned > > - new gdb, new stub, no /proc, or no read(write?) /proc access > Operation attempted, Enn returned > > - new gdb, new stub, /proc > Operation attempted, valid response returned > > so perhaphs clearly specifying this may prove sufficient. I think that > the main thing is that the spec has to be clear that: > > -> qPartial:asdfasdf:... > <- "" > > where "asdfasdf" is not "supported" must return "" and not "Enn". The other case is new gdb, new stub, no stub target support. i.e., a new gdbserver on a platform other than Linux 2.6 (until some more gdbserver support is written). I figure "" is the right response here, since it's a "no sense even asking me until I'm recompiled" kind of failure. The last set of wrinkles is -> qPart:auxv:write:... (known obj, writing not supported) -> qPart:auxv:badop:... (known obj, unknown op) -> qPart:auxv:read:foobar:... (known obj+op, unexpected "annex") I tend toward "" for all these as well. If there is an obj+op where "annex" is meaningful in general and is a value rather than a selection among keywords (it's some kind of file name or something like that), then that would be a case to return "Enn" for a bad one. Here is proposed wording for a protocol based on your comments. I have the implementation ready to go as well. Thanks, Roland Index: gdb.texinfo =================================================================== RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v retrieving revision 1.193 diff -u -b -p -r1.193 gdb.texinfo --- gdb.texinfo 6 Feb 2004 15:48:25 -0000 1.193 +++ gdb.texinfo 12 Feb 2004 02:09:07 -0000 @@ -20422,6 +20422,76 @@ encoded). @value{GDBN} will continue to (if available), until the target ceases to request them. @end table +@item @code{qPart}:@var{object}:@code{read}:@var{annex}:@var{offset},@var{length} --- read special data + +Read uninterpreted bytes from the target's special data area +identified by the keyword @code{object}. +Request @var{length} bytes starting at @var{offset} bytes into the data. +The content and encoding of @var{annex} is specific to the object; +it can supply additional details about what data to access. +The following table shows the @var{object} keywords in use so far. + +@table @code +@item auxv +Access the target's @dfn{auxiliary vector}. @xref{Auxiliary Vector}. +@var{annex} must be empty. +@end table + +Reply: +@table @samp +@item OK +The @var{offset} in the request is at the end of the data. +There is no more data to be read. + +@item @var{XX@dots{}} +Hex encoded data bytes read. +This may be fewer bytes than the @var{length} in the request. + +@item @code{E}@var{NN} +The request is bad, the offset is invalid, +or there was an error encountered reading the data. + +@item @code{} +An empty reply indicates the @var{object} or @var{annex} string was not +recognized by the stub. +@end table + +@item @code{qPart}:@var{object}:@code{write}:@var{annex}:@var{offset}:@var{data@dots{}} + +Write uninterpreted bytes into the target's special data area +identified by the keyword @code{object}, +starting at @var{offset} bytes into the data. +@var{data@dots{}} is the hex-encoded data to be written. +The content and encoding of @var{annex} is specific to the object; +it can supply additional details about what data to access. +The following table shows the @var{object} keywords in use so far. + +@table @code +@item auxv +Access the target's @dfn{auxiliary vector}. @xref{Auxiliary Vector}. +@var{annex} must be empty. +@end table + +Reply: +@table @samp +@item @var{NN} +@var{NN} (hex encoded) is the number of bytes written. +This may be fewer bytes than supplied in the request. + +@item @code{E}@var{NN} +The request is bad, the offset is invalid, +or there was an error encountered writing the data. + +@item @code{} +An empty reply indicates the @var{object} or @var{annex} string was not +recognized by the stub, or that the object does not support writing. +@end table + +@item @code{qPart}:@var{object}:@var{operation}:@dots{} +Requests of this form may be added in the future. When a stub does +not recognize the @var{object} keyword, or its support for +@var{object} does not recognize the @var{operation} keyword, +the stub must respond with an empty packet. @end table @node Register Packet Format