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] |
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.
+The following table shows the @var{object} keywords in use so far. + +@table @code +@item auxv
+@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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |