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

[Paul Schlie]

Fully agree something's odd...

[fusion:~] paul% avr-gdb --version
GNU gdb 6.2.50_20041016
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=powerpc-apple-darwin7.5.0 --target=avr".

(if gdb just branched, that would explain the 6.2/6.3 diff, I believe)

-paul-


> From: "Theodore A. Roth" <address@hidden>
> Date: Tue, 19 Oct 2004 17:38:22 -0700 (PDT)
> To: Paul Schlie <address@hidden>
> Cc: "Theodore A. Roth" <address@hidden>, <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:
> 
>> 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.
> 
> What version of gdb are you using?
> 
> address@hidden:~/Calendars$ avr-gdb --version
> GNU gdb 6.3.50_2004-10-19-cvs
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=avr".
> 
> It doesn't make any sense to me that you are seeing big-endian 'p'
> packets and I'm seeing little-endian. I have this nagging feeeling that
> gdb is not doing the right thing. Especially since there's really no
> need for the zero padding anyways (we only have 35 registers).
> 
> ---
> Ted Roth
> PGP Key ID: 0x18F846E9
> Jabber ID: address@hidden