From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26013 invoked by alias); 12 Feb 2004 16:42:04 -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 26003 invoked from network); 12 Feb 2004 16:42:02 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 12 Feb 2004 16:42:02 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id B25002B92; Thu, 12 Feb 2004 11:42:00 -0500 (EST) Message-ID: <402BACD8.9040104@gnu.org> Date: Thu, 12 Feb 2004 16:42:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: Roland McGrath , Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: remote protocol support for TARGET_OBJECT_AUXV References: <200402120211.i1C2Bw7f011025@magilla.sf.frob.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00126.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. The numbers showing if the user can see a problem, and if so where it is. Without that we're needlessly micro-optimizing in a fog. >> 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. Ok. > Here is proposed wording for a protocol based on your comments. > I have the implementation ready to go as well. Given the above, here: > +The following table shows the @var{object} keywords in use so far. > + > +@table @code > +@item auxv spell out the entire packet vis: @item @code{qPart}:@code{auxv}:@code{read}::@var{offset},@var{length} so that its' clear that the annex is required to be empty. Eli fyi, The @var{NN} was picked up from other parts, and the lack of definition of @var{nn} is a long standing problem. Roland suggest defining "@var{nn}" as "errno", we'll leave it to later to more formally define it as the host/target's errno (I suspect that it is the target). And E00 for a syntax error. Andrew > +@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 > Andrew