[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(
From: |
Paul Schlie |
Subject: |
Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions) |
Date: |
Tue, 19 Oct 2004 20:29:15 -0400 |
User-agent: |
Microsoft-Entourage/11.1.0.040913 |
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
- Re: [Simulavr-devel] Windows port of simulavrxx, (continued)
- Re: [Simulavr-devel] Windows port of simulavrxx, Bill, 2004/10/21
- Re: [Simulavr-devel] Windows port of simulavrxx, E. Weddington, 2004/10/22
- Re: [Simulavr-devel] Windows port of simulavrxx, Bill, 2004/10/22
- Re: [Simulavr-devel] Windows port of simulavrxx, E. Weddington, 2004/10/22
- Re: [Simulavr-devel] Windows port of simulavrxx, Bill, 2004/10/22
Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions), Paul Schlie, 2004/10/19
- Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions), Paul Schlie, 2004/10/19
- Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions), Theodore A. Roth, 2004/10/19
- Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions), Paul Schlie, 2004/10/19
- Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions), Theodore A. Roth, 2004/10/19
- Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions),
Paul Schlie <=
- Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions), Theodore A. Roth, 2004/10/19
- Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions), Paul Schlie, 2004/10/19
- Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions), Theodore A. Roth, 2004/10/19
- Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions), Paul Schlie, 2004/10/19
- Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions), Paul Schlie, 2004/10/19
- Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions), Theodore A. Roth, 2004/10/19