On Feb 17, 2012, at 4:19 PM, Jim Ingham wrote: > > On Feb 17, 2012, at 2:55 PM, Filipe Cabecinhas wrote: >> >> ----------------------------------------------- >> >> With the lldb I built, I get: >> ----------------------------------------------- >> >> [~]% ./dev/lldb/build/Debug/lldb --version >> LLDB-115 >> >> >> [~]% ./dev/lldb/build/Debug/lldb ./tests >> (lldb) log enable gdb-remote all >> (lldb) run >> >> >> >> (snip) >> >> <lldb.process.gdb-remote.async> >> GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () >> sending continue packet: vAttach;2265 >> <lldb.process.gdb-remote.async> send packet: $vAttach;2265#00 >> <lldb.process.gdb-remote.async> >> GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () >> WaitForPacket(vAttach;2265) >> <lldb.process.gdb-remote.async> size_t >> GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote >> &, uint32_t): Read (buffer, (sizeof(buffer), timeout_usec = 0xffffffff, >> status = success, error = (null)) => bytes_read = 7 >> <lldb.process.gdb-remote.async> read packet: $E01#00 >> <lldb.process.gdb-remote.async> >> GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () got >> packet: E01 >> <lldb.process.gdb-remote.async> >> GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () => >> invalid What do things look like on the debugserver side? Run debugserver like so:
debugserver -gv -ldnb.log <host>:<port> <program> I've attached what I get here. It looks like task_for_pid() is actually succeeding, but at some point the port becomes nulled out--at least, that's what happens to me. Chip
dnb.log
Description: Binary data
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
