Re: [Simulavr-devel] simulavr + Eclipse

[Petr Hluzín]

2011/4/15 Сергей Смирнов <address@hidden>:
>> What version of GDB are you using?
>> Does have "set remotetimeout 10000" any effect?
>
> I'm using gdb 6.8
> Command "set remotetimeout 10000" doesn't have any effect.

In file gdb_remotelogfile.txt:
w $qSupported#37
r +$PacketSize=800;qXfer:features:read+#a3
w +$qXfer:features:read:target.xml:0,7fb#4a
r <Timeout: 2 seconds>

Here GDB times-out for some reason. I would like to see the files when
"set remote timeout 10000" is set.

w $qXfer:features:read:target.xml:0,7fb#4a
r +$l<?xml version="1.0"?>\n<!DOCTYPE target SYSTEM
"gdb-target.dtd">\n<target version="1.0">\n
<architecture>avr</architecture>\n</target>\n#84

GDB resends after timeout and receives ACK for the first attempt and
reply to the first attempt.

w ++$?#3f

GDB sends ACK for the simulavr's reply. Then sends another ACK for no
reason. Then GDB asks "$? - Indicate the reason the target halted".
Simulavr still has reply to the seccond "$qXfer:features:read" command
in TCP buffers.

r +$l<?xml version="1.0"?>\n<!DOCTYPE target SYSTEM
"gdb-target.dtd">\n<target version="1.0">\n
<architecture>avr</architecture>\n</target>\n#84

GDB receives reply to the seccond "$qXfer:features:read" command (and
its ACK). Interrestingly reports no parse error. Now there is pending
reply to "$?" in TCP buffers.

w +$Hc-1#09
r +$S05#b8

GDB receives reply to "$?" and again does not report parse error. (Now
empty response "$#00" to "$Hc-1" is in TCP buffers.)

w +$qC#b4
r +$#00

GDB receives the empty response "$#00" to "$Hc-1". (Now empty response
"$#00" to "$qC" is in TCP buffers.)

w +$qOffsets#4b
r +$#00

GDB receives the empty response "$#00" to "$qC".  (Now empty response
"$#00" to "$qOffsets" is in TCP buffers.)

w +

GDB sends ACK to the last received response and does not send any
further commands.

r +$#00

GDB receives reply to "$qOffsets" (and preceded by an ACK). Now GDB
must be confused since it received a reply to a command but it thinks
(I guess, based on this dump) it did not send any command.

w +

Now GDB acknoledges the received response.

My diagnosis:

GDB experiences a timeout for some reason. This is bad but should not be fatal.
I do not know why GDB sends the extra '+' after timeout.
Then GDB receives mismatched replies which it fails to report.
Therefore GDB fails to resynchronize after the timeout.

I do not understand why it diagnoses "warning: Invalid remote reply".
It reports this after $qOffsets and other commands where the mismatch
is detectable. (However it is true that "l<?xml version=..." would be
invalid reply to "$?" but GDB could have diagnosed it earlier.)

If the "$qXfer:features:read" command or its response were actually
lost (impossible on TCP) then the desynchronization would not happen.


Our GDB 6.8 differences:

How did you get your avr-gdb.exe?
Yours gdb 6.8 is compiled without XML support.
I have gdb 6.8 from WinAVR-20100110 and it has XML support.

(Note to self: to reproduce exactly I must delay simulavr before it
sends gdb_send_ack().)

Your GDB sends $qOffsets after "$qC".
My GDB sends $Hg0 after "$qC".

I use:
(gdb) show version
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-mingw32 --target=avr".

On my XP box
$ md5sum.exe /cygdrive/c/Program\ Files/WinAVR-20100110/bin/avr-gdb.exe
bf4b6a6998579bc133b2688cf8e217ac */cygdrive/c/Program
Files/WinAVR-20100110/bin/avr-gdb.exe

On my W7 box
$ md5sum.exe /.../Desktop/avr-gdb.exe
1e6b6915fb3d7cb4f5ca60783d77a2b8 */cygdrive/c/.../Desktop/avr-gdb.exe

The same reported version. Difference on two places, total 6 six bytes. Strange.

> Also, I've included simulavr.exe, that I've compiled from source code. Can 
> You send to me your simulavr.exe?

The difference is likely to be in gdb.exe. Interestingly I have two
different binaries, both from WinAVR-20100110. I do not know what is
going on.

-- 
Petr Hluzin