From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1915 invoked by alias); 14 Mar 2006 02:15:32 -0000 Received: (qmail 1904 invoked by uid 22791); 14 Mar 2006 02:15:31 -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; Tue, 14 Mar 2006 02:15:29 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FIz4I-0000Gr-Jl for gdb@sourceware.org; Mon, 13 Mar 2006 21:15:26 -0500 Date: Tue, 14 Mar 2006 02:15:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: [remote] Checking for supported packets Message-ID: <20060314021526.GA802@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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-03/txt/msg00059.txt.bz2 I've been working, for the last couple of months, on a wide variety of projects that involve new remote protocol packets. I'm planning to submit each and every one of them; I've just been busy, and also some of them aren't quite fully baked yet. Before I start doing that, though, I'd like to trigger a little conversation about a topic that's been bothering me. When we connect to a target, there's a number of packets that we need to send right away, to find out if they're supported or to get information about the target's current state. Here's a current sample: Sending packet: $Hc-1#09...Ack Packet received: Sending packet: $qC#b4...Ack Packet received: Sending packet: $qOffsets#4b...Ack Packet received: Sending packet: $?#3f...Ack Packet received: S00 Sending packet: $Hg0#df...Ack Packet received: Sending packet: $pf#d6...Ack Packet received: 00000000 Packet p (fetch-register) is supported Sending packet: $m0,4#fd...Ack Packet received: 1000ffe7 qC and qOffsets are both probes. [Hc/Hg we don't even notice that the target has failed to support, so we keep sending them. That's unrelated.] I've got at least two more packets on my list that would have to be probed for at connect: one to read available features (the XML bits on my branch, which are coming along well), and another very useful probe that asks the target how big of a packet it can handle. That's a huge performance help on any link with latency measurable in respect to its bandwidth; it's especially useful over TCP, whether to a local system or to one far away. Every new packet of this type has to be probed for on each new target connection. This takes a noticeable amount of time. So, I'm wondering, can we cut that number down, and should we? Something like this: -> qPackets? <- qPackets,qPacketSize+,qOffsets-,qPart:available+,qC- "I support the qPacketSize and qPart:available queries, but don't bother probing for qOffsets or qC, they won't work". This isn't the most useful as it is. There's a lot of possible alternatives, for instance: 1. If qPackets is not present, assume new packets are not supported; i.e. require the stub to respond to qPackets before trying qPart:available. 2. If the qPackets response does not mention a packet, assume it is not supported. 3. Or, if the qPackets response does not mention a packet, probe for it. I'm guessing that the most useful interpretation would be something like 1 && 2, but I mention 3 because implementing #2 could prove to be a problem for some designs of remote stub (with separate halves for the protocol bits and the controlling hardware bits). Anyone think this is likely to be a problem in practice? Other possible approaches? -- Daniel Jacobowitz CodeSourcery