This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: remote protocol support for TARGET_OBJECT_AUXV


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]