Remote protocol: Z-packets

[Andrew Cagney]

>> Hmm, would you have an example of this code in action; and any notes on 
>> what protocol changes would be needed?
>> 
>> At present the protocol says nothing about how to probe for sub-packet 
>> support.
>> 
>> Andrew
>> 
> 
> 
> The function sends a bad packet, and gets an error back -- s we know
> that the stub is parsing the packet, and it is supported, if it
> returns the empty string the packet isn't supported.
> 
> an example:
> 
> (gdb) hbreak main
> Sending packet: $Z1,1,#14...Ack
> Packet received: E02
> Hardware assisted breakpoint 1 at 0xa00209bc: file main.c, line 15.
> (gdb) hbreak function 
> Hardware assisted breakpoint 2 at 0xa0020994: file main.c, line 7.
> (gdb) c        
> Continuing.
> Sending packet: $Z1,a00209bc,4#38...Ack
> Packet received: OK
> Sending packet: $Z1,a0020994,4#e0...Ack
> Packet received: OK
> Sending packet: $Hc0#db...Ack

Ah!  Outch!  An existing target in the field :-(

At least a bit of formalization of this will be needed as I don't know 
that the above probe is really that robust.

For instance, depending on the order that the target checks things, it 
might return:

"Enn" when it doesn't support the packet. It spots the syntax error 
before it spots the breakpoint type.

"" when it does support the packet.  It assumes that the syntax error is 
due to a packet it doesn't support.

"OK" because it defaulted the empty field and inserted something

 > This could also be done with a new Z-packet, something like Z?, that
 > does the same thing.

Hmm!  That would mean that:

/* Returns non-zero if we can set a hardware watchpoint of type TYPE. 
TYPE is one of bp_hardware_watchpoint, bp_read_watchpoint, 
bp_write_watchpoint, or bp_hardware_breakpoint.  CNT is the number of 
such watchpoints used so far (including this one?).  OTHERTYPE is who 
knows what...  */

#ifndef TARGET_CAN_USE_HARDWARE_WATCHPOINT
#define TARGET_CAN_USE_HARDWARE_WATCHPOINT(TYPE,CNT,OTHERTYPE) \
  (*current_target.to_can_use_hw_breakpoint) (TYPE, CNT, OTHERTYPE);
#endif

could be mapped directly onto:

	Z?,TYPE,CNT(includingthisone),OTHERTYPE(whateverthatis)

with responses to indicate things like ok, not supported, unknown 
packet, out-of-resources, et.al.

eg:

	-> Z?,1,1,0
	<- OK

Yes, I think that is much better!

I guess, if ``Z?'' isn't recognized, code could fall back to trying a 
Ztype probe.  That would also need to be documented though.

> The protocol changes I was thinking of would be to return different
> error codes for different errors; i.e.
> E01 -- bad address
> E02 -- exhausted resources
> (empty string) -- syntax error.

Yes, something.  Defining the error numbers is long overdue!  Perhaphs 
<errno.h> is a good source for definitions?  Otherwize we could define 
our own in include/gdb/*.h.

> The error packets could also contain a string describing the error; so
> they would have the form Enn,STRING where STRING is a hex string that
> can be printed as an error message.

I think this has been discussed before.  Is there anything in the 
archives indicating consensus?

Is there anything in the protocol that could mistake ``E00,STRING'' for 
a valid response?

enjoy,
Andrew