Re: remote protocol support for TARGET_OBJECT_AUXV

[Andrew Cagney <cagney@gnu.org>]

> 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