From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18724 invoked by alias); 19 Jan 2006 02:00:43 -0000 Received: (qmail 18377 invoked by uid 22791); 19 Jan 2006 02:00:42 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 19 Jan 2006 02:00:41 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EzP6K-0006B4-Vo for gdb@sourceware.org; Wed, 18 Jan 2006 21:00:37 -0500 Date: Thu, 19 Jan 2006 02:03:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: to_xfer_partial, qPart, and EOF Message-ID: <20060119020036.GA23692@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org References: <20060118231837.GA17726@nevyn.them.org> <8f2776cb0601181718ybb52db4pc5c3aca9bf00adfe@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f2776cb0601181718ybb52db4pc5c3aca9bf00adfe@mail.gmail.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00185.txt.bz2 On Wed, Jan 18, 2006 at 05:18:49PM -0800, Jim Blandy wrote: > This, and a few other remote protocol wrinkles, are consequences of > the mis-layering of the GDB protocol. The protocol should simply > specify that the entire block of data gets transmitted, and let lower > layers handle retransmission and fragmentation. > > I recognize it's probably not practical to fix this today, and maybe > it never will be. But I keep running into instances of this when I > work on the remote protocol --- tracepoint definition packets needing > to be broken up into pieces to avoid long packets; breakpoint packets > needing to be idempotent, because they might be retransmitted; and so > on --- so I wanted to mention it. Perhaps someone will have a flash > of super-coder powers some weekend. I suspect we will need to redesign the protocol rather than just layering on top of it, eventually. Maybe not. I don't know; I'm not feeling that ambitious right now. The two things I most often hear about as fundamental problems with the existing protocol are: - multiple "channels" for output to/from the host, especially asynchronous channels (logging without stopping the target) - other asynchronous communication, e.g. collecting tracepoints or reading memory without stopping the target, where supported > > Any comments on either of these plans? Otherwise I will probably implement > > them in the next couple of days. I'm doing a lot of work in this area > > at present. > > Sounds great to me. Thanks. -- Daniel Jacobowitz CodeSourcery