Re: remote protocol support for TARGET_OBJECT_AUXV

Andrew Cagney
2004-02-06T17:02:00Z

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