[Lldb-commits] [lldb] r246004 - In SendContinuePacketAndWaitForResponse there is a special bit of

[Pavel Labath via lldb-commits]

On 26 August 2015 at 05:07, Jason Molenda via lldb-commits
<lldb-commits at lists.llvm.org> wrote:
> There's a timeout where we wait to get this second stop reply packet
> in SendContinuePacketAndWaitForResponse, currently 1ms.  For a slow
> remote target, it may take longer than that to send the second stop
> reply packet.  If that happens, then lldb will use that second stop
> reply packet as the response for the next packet request it makes
> to the remote stub.  The two will be out of sync by one packet for
> the rest of the debug session and it's going to go badly from then on.


Hi,

this does not concern your change directly, but I have been looking at
this code lately (checking how hard it would be to change the format
of the stop-reply), and I have a question/suggestion about this piece
of code.

I am not sure if debugserver is correct in sending the second stop
reply packet here. The gdb-remote documentation
<https://sourceware.org/gdb/onlinedocs/gdb/Interrupts.html#Interrupts>
says that "Interrupts received while the program is stopped are
discarded". To me this means that in this corner case (interrupting a
process while it comes to a stop naturally) the server should send
just one stop-reply, and the client does not need do to anything fancy
here. In fact, LLGS behaves this way already, so this part of code is
not needed for LLGS. If we could fix the debugserver to behave the
same way, then this whole hack could go away. (*)

(*) Unless we need to maintain backwards compatibility with old
debugserver or other remote stubs. But even if that is true, I think
it would be worth fixing the debugserver, if we agree the bug is
there. Based on my investigations it should be easy: just removing the
extra send command in HandlePacket_stop_process  (RNBRemote.cpp:4429)
seemed to do the trick. The tests  did not seem to be affected in any
way...

What do you think?

pl