This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Remote protocol: Z-packets


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]