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


>>>>> "Quality" == Quality Quorum <qqi@world.std.com> writes:
>> 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.).

Quality> It seems to me that we can start interpreting error codes
Quality> from Z-protocol up (it is absolutely new addition) with no
Quality> backward compatibility issues. I am thinking about E00 - type
Quality> not supported, E01 - bad address, E02 - bad length, E03 - out
Quality> of resources. So, gdb can print a meaningful error message.

I have no problems with this.  I imagine that it depends on how others
have interpreted "draft" in the specification.  My interpretation is
that anything marked draft is subject to change, and that anyone who
uses it is responsible for handling changes in the specification when
and if it becomes a standard part of the protocol.

Nailing down error codes is a rather innocuous change as well.  The
worst that could happen is that GDB misidentifies the reason a
breakpoint could not be inserted or removed.

>> I picked 32 breakpoints out of thin air.  Based on my experiences,
>> 32 seemed like more than enough.

Quality> I was thinking about something like 1K, who knows how how gdb
Quality> is going to be used.

In many cases you do have some sort of an idea how GDB is going to be
used because the debug stub is embedded in a "system" of your design.
You simply scale the number of breakpoints available to the size and
scope of your application.  

In in other cases, for example when a stub is serving as the target's
monitor and arbitrary code is being loaded, the number of breakpoints
that may be required is uncertain.  I would factor that uncertainty
into my decision of how many breakpoints to support.  But considering
the fact that many traditional ROM monitors support a similar or even
fewer number of breakpoints, I'm not sure that I would increase the
number of breakpoints.

The point I'm trying to make is that the protocol should not define 
a maximum number of breakpoints.  For my application, I think 32 is
enough.  You're more comfortable with 1K.  The protocol should not
preclude either.

But after writing this, the protocol might want to require, or perhaps
strongly suggest, a minimum number of breakpoints to support.  My best
guess for this would be 8 breakpoints.

>> and if it turned out too be too small, I could always re-compile
>> the debug agent with a larger number.

Quality> It is not that easy in my view: once stub is burned into prom
Quality> it is forever.

I guess I come from a world where everything is field programmable.
Nothing is forever.

>> I'm addressing this, and many other shortcomings, in a replacement
>> protocol I've been designing the last month or so.

Quality> Did you see my attempt to clean up existing protocol at
Quality> http://www.std.com/qqi/ftp/protocol.txt ?

I have, and I've commented on it in the past.

My new protocol is intended to address problems that I feel cannot be
addressed within the existing protocol.  I hope to be ready to post a 
first draft sometime in the next week.

        --jtc

-- 
J.T. Conklin
RedBack Networks

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