This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Z-protocol errors and limts
- To: "J.T. Conklin" <jtc at redback dot com>
- Subject: Re: Z-protocol errors and limts
- From: Quality Quorum <qqi at world dot std dot com>
- Date: Thu, 27 Jan 2000 17:35:37 -0500 (EST)
- cc: gdb at sourceware dot cygnus dot com
On 27 Jan 2000, J.T. Conklin wrote:
> >>>>> "Quality" == Quality Quorum <qqi@world.std.com> writes:
> Quality> I have a few questions related to Z-protocol on implmentation
> Quality> on the stub side:
> Quality>
> Quality> 1. How many soft break point has to be supported ?
> Quality>
> Quality> 2. How stub tells gdb that it run out of soft break points ?
> Quality>
> Quality> 3. If stub supports soft break points but does not support
> Quality> hw (or some of hw break points), how it tells gdb about it?
>
> You point out weaknesses in the Z/z specification.
>
> In the debug stub I wrote, I reserved 32 nodes to store breakpoints of
> all types and returned a 'EXX' code on all failures (out of breakpoint
> nodes, unable to insert breakpoint, etc.).
It seems to me that we can start interpreting error codes from Z-protocol
up (it is absolutely new addition) with no backward compatibility
issues. I am thinking about E00 - type not supported, E01 - bad address,
E02 - bad length, E03 - out of resources. So, gdb can print a meaningful
error message.
> I picked 32 breakpoints out of thin air. Based on my experiences, 32
> seemed like more than enough.
I was thinking about something like 1K, who knows how how gdb is
going to be uised.
> And if it turned out too be too small,
> I could always re-compile the debug agent with a larger number.
It is not that easy in my view: once stub is burned into prom it is
forever.
> When my stub only supported software breakpoints, it returned a 'EXX'
> code for hardware breakpoint and watchpoints. GDB's remote.c handles
> such a response as an error (ie. remote_insert_watchpoint(), etc. will
> return -1), but I'm not sure this will result in an error message a
> user will be able to interpret correctly
>
> In retrospect, I should have given unique error codes for each
> possible error so that GDB could handle errors more inteligently.
>
> I'm addressing this, and many other shortcomings, in a replacement
> protocol I've been designing the last month or so.
Did you see my attempt to clean up existing protocol at
http://www.std.com/qqi/ftp/protocol.txt ?
> --jtc
Thanks,
Aleksey