Re: remote protocol support for TARGET_OBJECT_AUXV

[Roland McGrath <roland at redhat dot com>]

> I think it would be better to specify something that accomodates this 
> (to my suprise) rapidly expanding interface.
> Otherwize, in a month or so, we'll find ourselves discussing the exact 
> saome problem for "unwind-table", "wcookie", "avr", and "kod".

In the gdb-patches thread, I suggested such an idea as well.  The details
of transmitting offset/length and getting back data/eof is something we
should decide once and do the same for all new cases, whether they are
technically the same query or not.

> I also think that the protocol semantics should reflect this interfaces 
> semantics (or a superset of it).

That seems reasonable to me, hence my prior similar suggestion.  However, I
also sympathize with the opinion Dan expressed.  I will paraphrase that as
that the stub's job should be kept simple whenever possible.  The stubs are
after all, stubs (i.e. small things), and there are many of them, whereas
gdb is big and hairy and so extra layers of well-organizedness are good in
gdb but sometimes bad for stubs.

> (technical nit "+" can't be used.

Right!  Thanks.  It's been a long time since I was in the habit of typing
gdb remote protocol by hand, so I'd forgotten what is and isn't encoded how.
Your having reminded me, I went and re-read the elisp I used to do that.

> -> qPartial:<obj>:read:<x-annex>:<x-offset>,<x-length>
> 	<- OK -- implicit zero length returned EOF
> 	<- <x-data> -- must contain the byte @<x-offset>
> 	<- "" -- packet not recognized
> 	<- Enn - something wrong with the request
> 
> -> qPartial:<obj>:write:<x-annex>:<x-offset>:<x-data>
> 	<- <x-be-length> -- number of bytes actially written
> 	<- "" -- packet not recognized
> 	<- Enn -- something wrong with the request

This looks fine to me, basically.  But I do think it is worth starting out
with the one more wrinkle of EOF reporting along with data return.  With
this simpler protocol, there are necessarily two request/reply transactions
for every time you want to read "all the data", even if there is as little
as one byte of it to read.  That seems unnecessary and undesireable.
(Perhaps I've spent too long doing serial debugging when serial ports were
slower than they usually are these days.  But all the remote protocol
traffic adds up to slow sessions hacking kernels.)

This is only worthwhile if the target_read_partial usage conventions are
able to express it.  But I think that is a change worth making as well.
This goes to the issue with target_auxv_read that you cited.  If it must
make additional target_read_partial requests until one returns zero, then
all target implementations necessarily have their analogues of the remote
protocol's extra packet here.  To wit, the Linux implementation would do
open+read+close+open+lseek+read+close instead of just open+read+close.
That can obviously be internally optimized to make the worst case be
open+pread+pread+close, but that is still one more system call than is
really required to answer the whole question the caller of
target_read_partial is asking.

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.  

> -> qPartial:<obj>?
> 	<- OK -- queries of type <obj> are supported
> 	<- "" -- queries of type <obj> are not supported

What does "supported" here mean exactly?  A stub will e.g. support reading
but not writing, and a very constrained range of "annex" values.  If an OK
response to "qPartial:foo?" just means that you have some chance if you try
some particular read/write query, is there a particular benefit to that
over just trying the first query you wanted and taking the empty reply as
"not supported"?

> a variation being something like:
> qPartial:obj=<obj>:op=write[:annex=<x-annex>]:offset=<x-offset>:data=<x-data>
> which makes it more extensible.

That is not really any more extensible, I'd say.  You can just define new
tokens after the first or second : to change the details later.  This is
just more verbose, unless it's free form as to the order of parameters.
Being free form is less desireable because it requires hairy parsing in the
stub instead of just matching fixed leading strings for the few particular
requests that are actually supported.


Thanks,
Roland