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

[Paul Schlie]

The "target byte order" of register DATA, not command strings, etc.
and likely only relevant when manipulating multi-byte value locations.

I believe that if you simply try my simple fix and print out
to the error port the result of the integer values received in
p command requests from gdb, I believe you find things work;
although acknowledge that squirrelly things remain, as I haven't
yet been successful in getting everything to work, which may be
related to endian related en/decoding bugs.

When I run gdb with simulavr with my fix I get with debugging on:

Sending packet: $p0000001e#26...Ack, simulavr: read reg: 30
Packet received: 0c
Sending packet: $P1e=0e#b8...Ack
Packet received: OK
Sending packet: $p00000022#f4...Ack, simulavr: read reg: 34
Packet received: 00000000
Sending packet: $p00000021#f3...Ack, sinulavr: read reg: 33
Packet received: 0000
(gdb) print $r30 
Sending packet: $p0000001e#26...Ack, simulavr: read reg: 30
Packet received: 0e
$16 = 14 '\016'
(gdb) 

Therefore sense that what you've proposed as a general solution is likely
incorrect given where and how the function is used in the present code.

But at least I think were looking at the correct issues.

Thanks again, -paul-

> From: "Theodore A. Roth" <address@hidden>
> Date: Tue, 19 Oct 2004 14:58:50 -0700 (PDT)
> To: Paul Schlie <address@hidden>
> Cc: <address@hidden>
> Subject: Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu
> m(...) bug fix (for more recent gdb versions)
> 
> 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