Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions)

[Theodore A. Roth]

On Tue, 19 Oct 2004, Paul Schlie wrote:

> Unless I'm mistaken, all values transmitted across the link are independent
> of endian-ness, as they are serialized as a logical sequence of ascii
> encoded hex characters from significant logical nibble first to least
> significant, independently of host/client platform's endian-ness;
> correspondingly a shift operation in C arithmetically/logically shifts the
> value of an integer transparently of it's storage format, so I don't
> understand why you think you need to do what you've done? Can you give an
> example?

>From the gdb user manual:

`p'HEX NUMBER OF REGISTER -- read register packet
     *Note read registers packet::, for a description of how the
     returned register value is encoded.

     Reply:
    `XX...'
          the register's value

    `ENN'
          for an error

    `'
          Indicating an unrecognized QUERY.

`P'N...`='R... -- write register
     Write register N... with value R..., which contains two hex digits
     for each byte in the register (target byte order).

     Reply:
    `OK'
          for success

    `ENN'
          for an error


The key here being "target byte order". The target is the AVR device
which is little endian. We don't know anything else about byte ordering
(gdb may be running on a big endian system and simulavr may be running
on a little endian system). Gdb can never assume that the target's byte
ordering is the same as that of the gdb itself.

So, here the protocol stream that simulavr sees:

  Recv: "$p22000000#f4"
   Ack -> gdb
  Sent: $00000000#80
   gdb -> Ack

  Recv: "$p21000000#f3"
   Ack -> gdb
  Sent: $0000#c0
   gdb -> Ack

The first is gdb asking the sim for the program counter's value
(register 0x22), the second is gdb asking for the stack pointer
(register 0x21).

If you parse the "22000000" string and simply shift bytes into the num
value as they come in, you will end up with 0x22000000 as the requested
register number instead the correct 0x22.

So to use Frost's example, if gdb sent this packet:

  Recv: "$pABCDEFGH#XX"

Then the result value in sim memory, should be:

  0xGHEF_CDAB

I tested the patch I submitted against the latest gdb from cvs and it
worked as I expected.

Older versions of gdb didn't seem to pad out the value so endianess was
not an issue. I have no idea when this change was made to gdb, but it
will have to be dealt with when the upcoming gdb-6.3 release is made or
simulavr will be broken.

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: address@hidden