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

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

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.

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'm not sure which would be best.

grace


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