I believe we have a bug where if you attach and the stop reply packet that we send immediately after the attach (the '?' packet) comes back with a T00 (meaning the thread stopped with signal 0, or no signal), we end up resuming the process. We normally get a T11 (SIGSTOP) when we first attach on MacOSX. This gives LLDB a reason for why the process stopped. It is also helpful if you add the stop reply packet extensions we have documented in the "lldb-gdb-remote.txt" file in our SVN repository:
svn cat http://llvm.org/svn/llvm-project/lldb/trunk/docs/lldb-gdb-remote.txt See the section labeled "Stop reply packet extensions". The standard stop reply packet is really UNIX centric and it assumes every stop reason can be explained by a signal. We extended the contents of the key/value pairs that are returned to provide more complete information. Can you enable GDB packet logging and send me the output? I will be able to tell more from the log. To enable this logging: (lldb) log enable -f /tmp/packets.txt gdb-remote packets (lldb) … < connect to remote process > … (lldb) quit Then attach and send the packet.txt file. Greg On Jan 22, 2013, at 6:55 AM, Benjamin Kemper <[email protected]> wrote: > ProcessGDBRemote::UpdateThreadList (pid = 1799) > 0x7fe2aa2268b0: ThreadGDBRemote::ThreadGDBRemote (pid = 1799, tid = 0x0707) > < 22> send packet: $qThreadStopInfo707#99 > size_t > GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote > &, uint32_t): Read (buffer, (sizeof(buffer), timeout_usec = 0xf4240, status > = success, error = (null)) => bytes_read = 1 > < 1> read packet: + > size_t > GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote > &, uint32_t): Read (buffer, (sizeof(buffer), timeout_usec = 0xf4240, status > = success, error = (null)) => bytes_read = 4 > < 4> read packet: $#00 > < 1> send packet: + > error: failed to get response for 'qThreadStopInfo707' > ProcessGDBRemote::Resume() > ProcessGDBRemote::AsyncThread (arg = 0x7fe2ab00d000, pid = 1799) Got an event > of type: 1... > ProcessGDBRemote::AsyncThread (arg = 0x7fe2ab00d000, pid = 1799) got > eBroadcastBitAsyncContinue: vCont;c:0707 > GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () > GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () sending > continue packet: vCont;c:0707 > < 16> send packet: $vCont;c:0707#b0 > size_t > GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote > &, uint32_t): Read (buffer, (sizeof(buffer), timeout_usec = 0xf4240, status > = success, error = (null)) => bytes_read = 1 > < 1> read packet: + > GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () > WaitForPacket(vCont;c:0707) > size_t > GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote > &, uint32_t): Read (buffer, (sizeof(buffer), timeout_usec = 0xffffffff, > status = success, error = (null)) => bytes_read = 7 > < 7> read packet: $W00#b7 > < 1> send packet: + > GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () got > packet: W00 > GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () => > exited > ProcessGDBRemote::AsyncThread (arg = 0x7fe2ab00d000, pid = 1799) thread > exiting... > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
