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

[Paul Schlie]

Might "target" refer to in the link protocol docs mean the target of the
serial link, which for us is the same machine, as the serial protocol target
is the simulator process complied and running on the same physical host
(which it need not be) therefore of the same endian-ness by default,
although it happens to be pretending to an avr?


> From: Paul Schlie <address@hidden>
> Date: Tue, 19 Oct 2004 20:53:13 -0400
> To: "Theodore A. Roth" <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)
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> Simulavr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/simulavr-devel