Re: Patch to add breakpoint extension to remote protocol

[Andrew Cagney <ac131313@cygnus.com>]

"J.T. Conklin" wrote:

> cagney> Could I encourage you to take the oportunity to investigate
> cagney> this.  An excert of a patch I've been playing with is below
> cagney> (please ignore the stub_supports_P -> stub_supports_P_packet
> cagney> rename):
>
> Are you asking me to integrate this into my patch?  Do you want a
> patch with only the stub_supports_P_packet changes first?

I'm not worried.  If you're able test/debug both P and B changes and submit a
singe patch I'll be more than grateful.

> cagney> Re: sprintf (buf, "B%x,%lx,%lx", type + 2, (long) addr, len);
>
> cagney> Have a look at remote_write_bytes() and
> cagney> remote_address_masked().  It handles addresses of up to 64
> cagney> bits.
>
> Will do.
>
> cagney> Re: general
> cagney> (I'm probably rambling) Should there be a `set remote*'
> cagney> command to control the use of the B and P packets?  Just in
> cagney> case we find that we really do/don't want GDB using either of
> cagney> these protocol extensions?
>
> Although new variables that control whether B and P packets should be
> used wouldn't be difficult to add, I can't see a situation that would
> require them given a robust protocol (which we have) and implement-
> ation (which GDB has, and any stub should provide).

True.  I can however see the situtation where GDB encounters a target that has
a broken implementation which we don't want to use.


> Back to the statefullness issue I mentioned earlier.
>
> Although I'm currently using GDB over fairly reliable serial links;
> there is nothing that guarentees that a reply will be munged and a
> command (like insert breakpoint) be executed twice.  There doesn't
> seem to be a solution to this problem other than to add sequence
> numbers to the protocol.  Unfortunately, the current specification of
> sequence numbers in the protocol is inadequate to protect against
> duplicated packets.

Yes, the current protocol makes the assumption that the only transmition error
that can occure is data overrun (and an ack ("+" or "-") can't overrun a
buffer.  Suprisingly this assumption holds up very well.

Should the semantics for the set/clear breakpoint commands include an
idenpotent clause?  I can't see any problems with doing this.  (It won't help
other commands such as RUN but it does at least tie this one down better).

> This, plus changes like adding thread stuff into the 'q' escape
> instead of making threads `first class objects' in the protocol;
> adding 'X' for binary memory write instead of a true binary packet
> mode; etc. has me thinking that it's time to re-design the remote
> protocol from the ground up.

Just FYI, I believe that part of the rationale behind the X packet was:

    o    only memory transfers impose a significant overhead

    o    it is strongly preferable to have a protocol based on ASCII (snooping,
debugging...)


> Here are some characteristics I think a new protocol/implementation
> should contain, in no particular order.
>
> * Able to sit on top of both datagram and stream based transport layers.
>   The least common denominator being a small datagram.  Protocol should
>   be able negotiate a larger packet size to minimize overhead for bulk
>   transfers.

Yes, this is an important problem.

> Sorry for rambling, but I'd be interested in your thoughts nonetheless.

My memory from the last time this was discussed is that there were two schools
of thought (aren't there always :-):

    o    The existing GDB protocol works.
        Lets just evolve it a little, spac filler here, sand paper there, ...

    o    The existing protocol should be frozen and we should start again from
scratch.
        What we need is a new protocol for a new century, ...

Technically the latter has much merit.  I think most older GDB engineers
reconise each of the problems you identified.
If it was me doing the work, however, I'd actually prefer the former!  Mainly
because I think that there are other areas of GDB that could do with more
immediate attention :-(

    enjoy,

        Andrew