From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16922 invoked by alias); 3 Apr 2003 23:49:07 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 16915 invoked from network); 3 Apr 2003 23:49:07 -0000 Received: from unknown (HELO sun.netezza.com) (209.113.240.37) by sources.redhat.com with SMTP; 3 Apr 2003 23:49:07 -0000 Received: from astral (host20 [192.168.0.20]) by sun.netezza.com (8.11.6+Sun/8.11.6) with SMTP id h33Nn7j05745 for ; Thu, 3 Apr 2003 18:49:07 -0500 (EST) Message-ID: <00ab01c2fa3b$9d6a7790$1400a8c0@astral> Reply-To: "John S. Yates, Jr." From: "John S. Yates, Jr." To: "gdb" Subject: retrieving registers in the face of low bandwidth and long latency Date: Thu, 03 Apr 2003 23:49:00 -0000 Organization: Netezza Corporation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SW-Source: 2003-04/txt/msg00040.txt.bz2 I am just getting my feet wet in the gdb remote stub world. Our application is a small embedded PowerPC (MPC855T) which we need to access over dialup lines. We already have an instance of connecting from Boston, MA to Bristol, UK. This tends to point up issues with numerous round-trips in the protocol and excess data transmission. For now I would like to focus on how the register state is retrieved. Today all bits of every register are transferred. In our case this particularly painful. Today, after a break or step we respond to the 'g' query with the contents of 32 non-existent 64-bit FP registers, nearly tripling the amount of register state. Reading the code I first thought that the new 'x' value scheme was intended to address this problem. That is that a missing register could be represented by a single 'x'. Closer reading of the code indicated that that is not the case -- every nibble of a non-existent register is represented by a separate 'x'. :-) Next I discovered the expedited target status response ('T'). That looked promising. It even calls strtol() to collect the register number and so does not insist on leading zeros. But here again every nibble must be conveyed. I have prototyped an upward compatible variant of the 'T' register collection code that allows leading zero nibbles to be omitted. There is no requirement that register values be conveyed in a even number of nibbles, or even that a single nibble be supplied for a register that is truly zero. I am running this between a little endian x86 host and big endian ppc remote. I believe that the scheme is insensitive to byte order at either end. Here is my variant of hex2bin(). Since it consumes a variable number of bytes of input text it returns the position of the next unconsumed byte, rather than the number of binary bytes accumulated. static char* lowhex2bin (char *hex, char *bin, unsigned bytes) { char* p; unsigned n; int i; /* zero all bytes of the supplied buffer */ for (i = 0; i < bytes; i++) *bin++ = 0; /* count hex digits in supplied value */ n = 0; p = hex; for (;;) { char a = *p; if ( ! ((a >= '0' && a <= '9') || (a >= 'a' && a <= 'f') || (a >= 'A' && a <= 'F')) ) break; ++p; ++n; } /* validate the number of digits */ if (n > 2*bytes) error("Too many hex digits for field."); /* backwards conversion to binary */ for (i = 0; i < n; i++) { unsigned h; unsigned a = *--p; if (a >= '0' && a <= '9') h = a - '0'; else if (a >= 'a' && a <= 'f') h = a - 'a' + 10; else h = a - 'A' + 10; if ((i & 1) == 0) *--bin = h; else *bin |= h << 4; } return hex+n; } And here is the call site. #if 1 p = lowhex2bin (p, regs, REGISTER_RAW_SIZE (reg->regnum)); #else fieldsize = hex2bin (p, regs, REGISTER_RAW_SIZE (reg->regnum)); p += 2 * fieldsize; if (fieldsize < REGISTER_RAW_SIZE (reg->regnum)) warning ("Remote reply is too short: %s", buf); #endif supply_register (reg->regnum, regs); /john -- John S. Yates, Jr. 508 665-6897 (voice) Netezza Inc 508 665-6811 (fax) 200 Crossing Blvd. Framingham, MA 01701