[lldb-dev] LLDB sends continue right after connection (gdb-remote)

[Greg Clayton]

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 <kemperbenny at gmail.com> 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...
>