Re: remote protocol support for TARGET_OBJECT_AUXV

[Roland McGrath <roland@redhat.com>]

> > 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