Page MenuHomePhabricator

[MIPS] Debug bare-iron targets lacking support for qC /qfThreadInfo
ClosedPublic

Authored by jaydeep on Sep 14 2015, 11:35 PM.

Details

Reviewers
clayborg
Summary

Refer to http://lists.llvm.org/pipermail/lldb-dev/2015-August/008024.html for discussion on this topic.

Bare-iron target like YAMON gdb-stub does not support qProcessInfo, qC, qfThreadInfo, Hg and Hc packets. Reply from ‘?’ packet is as simple as ‘S05’. There is no packet which gives us process or threads information. In such cases, assume pid=tid=1.

Diff Detail

Repository
rL LLVM

Event Timeline

jaydeep updated this revision to Diff 34786.Sep 14 2015, 11:35 PM
jaydeep retitled this revision from to [MIPS] Debug bare-iron targets lacking support for qC /qfThreadInfo.
jaydeep updated this object.
jaydeep added a reviewer: clayborg.
jaydeep set the repository for this revision to rL LLVM.
jaydeep added subscribers: lldb-commits, bhushan, slthakur and 2 others.
clayborg accepted this revision.Sep 15 2015, 2:02 PM
clayborg edited edge metadata.

Looks good.

This revision is now accepted and ready to land.Sep 15 2015, 2:02 PM
labath added a subscriber: labath.Sep 16 2015, 3:33 AM

Hi, this commit has caused failure on all remote tests using lldb-server. I have reverted it while I investigate what is happening.

labath added inline comments.Sep 16 2015, 4:07 AM
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
3579

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?

labath added inline comments.Sep 16 2015, 4:15 AM
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
3579

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?

jaydeep added inline comments.Sep 16 2015, 4:46 AM
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
3579

Response from the target is "$#00". I think we should check for IsUnsupportedResponse().

labath added inline comments.Sep 16 2015, 4:56 AM
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
3579

If IsUnsupportedResponse will do the trick for you then I have no objections, and this can go in straight away.

If "qfThreadInfo" responds with OK, it seems to imply "this is a supported packet, but I have no threads to report". So it seems like we should assume that there are no threads in this case. If we got $#00 back, then it would mean that qfThreadInfo ins't supported. So if we get "OK" back from "qfThreadInfo", we should stop searching and assume there are no threads (don't try to send a stop reply, etc).

Changed "!response.IsNormalResponse()" to "response.IsUnsupportedResponse()" by commit http://reviews.llvm.org/rL247968