Re: Z-protocol errors and limts

[jtc at redback dot com (J.T. Conklin)]

>>>>> "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.).

I picked 32 breakpoints out of thin air.  Based on my experiences, 32
seemed like more than enough.  And if it turned out too be too small,
I could always re-compile the debug agent with a larger number.

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.


        --jtc

-- 
J.T. Conklin
RedBack Networks