This is the mail archive of the gdb@sources.redhat.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]
Other format: [Raw text]

retrieving registers in the face of low bandwidth and long latency


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


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