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.

>> -> 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"?

Good question.  In the past GDB has encountered situtations where it 
needed to differentiate between the questions:
	- operation not supported
	- error during supported operation
for instance, with breakpoints, with the current protocol there's no 
well defined mechanism for determining if:
	-> Z2,0,0     or -> Z2
	<- E00
(insert watchpoint,addr,len) fails because:
	- 0,0 is an illegal addr,len
	- Z2 is, in that stub, considered an illegal Z packet
	- the operation is legal, but the hardware failed
The proposal is to fix it with:
	-> Z2?
	<- OK
so that GDB can explictly differentiate between:
	- hardware watchpoints not supported
	- error inserting hardware watchpoint
consequently, since then, care as been taken to define a "supported" 
query with new packets.

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".

>> 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.

Should additional parameters be needed, it might help. However, yes, 
simply specifying a new packet is easier.

Andrew

PS: A contraction would be 'qPart:...".