[Lldb-commits] [PATCH] D12876: [MIPS] Debug bare-iron targets lacking support for qC /qfThreadInfo

[Pavel Labath via lldb-commits]

labath added inline comments.

================
Comment at: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:3579
@@ +3578,3 @@
+        */
+        if (!response.IsNormalResponse() && thread_ids.size() == 0 && IsConnected())
+        {
----------------
labath wrote:
> The problem behind the failures seems to be this: when we connect to the remote lldb-server, it should not have any processes or threads running (we will start those with the A packet later). We verify this in ProcessGDBRemote.cpp:837. This translates to a qfThreadInfo packet, to which our stub responds with OK.
> 
> This sounds like a bug in the stub, as the protocol does not mention that as a possibility. I will prepare a patch for that shortly. Could you please wait with this patch a bit until the bugfix lands?
> 
> Also, this got me thinking.. What is the response of your stub to the qfThreadInfo packet. If it is something like '?', then we could check for `response.IsUnsupportedResponse()` and we will avoid an overly broad check for your corner case. What do you think?
> The problem behind the failures seems to be this: when we connect to the remote lldb-server, it should not have any processes or threads running (we will start those with the A packet later). We verify this in ProcessGDBRemote.cpp:837. This translates to a qfThreadInfo packet, to which our stub responds with OK.

Hmm.. the debugserver seems to have this behavior as well. Greg, what do you think should be the right response to this packet when we have no process running? My feeling is that we should just send a "l" packet as if we have just reached the end of the list. What do you think?


Repository:
  rL LLVM

http://reviews.llvm.org/D12876