Re: remote protocol support for TARGET_OBJECT_AUXV

Andrew Cagney
2004-02-12T16:42:04Z

> 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