This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: remote protocol support for TARGET_OBJECT_AUXV
- From: Andrew Cagney <cagney at gnu dot org>
- To: Roland McGrath <roland at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 06 Feb 2004 12:01:55 -0500
- Subject: Re: remote protocol support for TARGET_OBJECT_AUXV
- References: <200402060249.i162nP8R009810@magilla.sf.frob.com>
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:...".