This is the mail archive of the gdb@sourceware.cygnus.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]

Re: Z-protocol errors and limts




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



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