2011/4/15 Сергей Смирнов <[email protected]>: >> 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 _______________________________________________ Simulavr-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/simulavr-devel
