<div dir="ltr">Thanks Greg!<div><br></div><div>Adding the "thread" pair and uncompressing the register values did the trick.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 8:11 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Jan 23, <a href="tel:2013" value="+9722013">2013</a>, at 9:24 AM, Benjamin Kemper <<a href="mailto:kemperbenny@gmail.com">kemperbenny@gmail.com</a>> wrote:<br>
<br>
> Hi Greg,<br>
><br>
> Thanks, this seems like a very plausible reason.<br>
><br>
> Two questions:<br>
> 1. Do I need to implement all the stop reply packet extensions (In the description it says that they are good for performance but no necessary) or just qThreadStopInfo?<br>
<br>
</div>The stop reply packet and qThreadStopInfo return the exact same data. The stop reply packet is basically the qThreadStopInfo for the most important thread that stopped for a reason (or any thread that stops for a reason, LLDB doesn't care).<br>
<br>
The shortcoming in the GDB remote protocol is the idea that one and only one thread stops for a reason at any given time. This simply isn't try on darwin, and probably not true for many other systems.<br>
<div class="im"><br>
><br>
> 2. I've looked at the ? command in my logs and saw that I'm receiving something different than T00, is this value Ok or also bad?<br>
><br>
> The log:<br>
> < 5> send packet: $?#3f<br>
> size_t GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote &, uint32_t): Read (buffer, (sizeof(buffer), timeout_usec = 0xf4240, status = success, error = (null)) => bytes_read = 1<br>
> < 1> read packet: +<br>
> size_t GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote &, uint32_t): Read (buffer, (sizeof(buffer), timeout_usec = 0xf4240, status = success, error = (null)) => bytes_read = 52<br>
> < 52> read packet: $T0206:0*,;07:f08a5851ff7f0* ;10:2880276eff7f0* ;#67<br>
> < 1> send packet: +<br>
<br>
</div>LLDB doesn't currently handle the '*' in the expedited register values.<br>
<br>
You also have issues with your stop reply packet:<br>
1 - "06:0*,;" has a comma in the value? This seems wrong.<br>
2 - there is an extra space which shouldn't be there ("07:f08a5851ff7f0* ;" and "10:2880276eff7f0* ;"<br>
3 - there is no "thread" key value pair to say which thread this data is for. This hex thread ID value must be in the packet or the packet doesn't make much sense.<br>
<br>
Here is a sample from the LLDB debugserver:<br>
<br>
$T11thread:1c03;qaddr:a0;threads:1c03;02:0000000000000000;03:0000000000000000;04:0000000000000000;05:0000000000000000;06:0000000000000000;07:e8f7bf5fff7f0000;08:0000000000000000;09:0000000000000000;10:2810c05fff7f0000;11:0002000000000000;metype:5;mecount:2;medata:10003;medata:11;#00<br>
<br>
A few things to note:<br>
<br>
"thread:1c03;" is specified first<br>
"qaddr" is not needed on non-darwin platforms<br>
"threads:1c03;" is a key/value pair that can supply all the thread IDs for all threads so we don't have to send the "qfThreadInfo" and "qsThreadInfo" packets/<br>
All registers are expanded to full width. Feel free to file a bugzilla bug to have LLDB Support the '*' feature.<br>
"metype", "mecount", and "medata" key value pairs are only needed for mach kernels.<br>
<br>
<br>
So to get LLDB happy with your packets:<br>
- add a "thread" to every stop reply packet/qThreadStopInfo<br>
- use the same output for stop reply packets and qThreadStopInfo<br>
- expand your register values (don't use the '*')<br>
- Fix your register values to omit extra spaces and commas<br>
- if you return T00, be sure to add a "reason" key/value pair if the thread is stopping for a reason that isn't actually signal related.<br>
<br>
<br>
> Thanks for the help,<br>
<br>
Let me know if you have any questions.<br>
<span class="HOEnZb"><font color="#888888"><br>
Greg<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> Benjamin.<br>
><br>
><br>
> On Tue, Jan 22, <a href="tel:2013" value="+9722013">2013</a> at 7:53 PM, Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br>
> 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:<br>
><br>
> svn cat <a href="http://llvm.org/svn/llvm-project/lldb/trunk/docs/lldb-gdb-remote.txt" target="_blank">http://llvm.org/svn/llvm-project/lldb/trunk/docs/lldb-gdb-remote.txt</a><br>
><br>
> 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.<br>
><br>
> Can you enable GDB packet logging and send me the output? I will be able to tell more from the log.<br>
><br>
> To enable this logging:<br>
><br>
> (lldb) log enable -f /tmp/packets.txt gdb-remote packets<br>
> (lldb) … < connect to remote process > …<br>
> (lldb) quit<br>
><br>
> Then attach and send the packet.txt file.<br>
><br>
> Greg<br>
><br>
> On Jan 22, <a href="tel:2013" value="+9722013">2013</a>, at 6:55 AM, Benjamin Kemper <<a href="mailto:kemperbenny@gmail.com">kemperbenny@gmail.com</a>> wrote:<br>
><br>
> > ProcessGDBRemote::UpdateThreadList (pid = 1799)<br>
> > 0x7fe2aa2268b0: ThreadGDBRemote::ThreadGDBRemote (pid = 1799, tid = 0x0707)<br>
> > < 22> send packet: $qThreadStopInfo707#99<br>
> > size_t GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote &, uint32_t): Read (buffer, (sizeof(buffer), timeout_usec = 0xf4240, status = success, error = (null)) => bytes_read = 1<br>
> > < 1> read packet: +<br>
> > size_t GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote &, uint32_t): Read (buffer, (sizeof(buffer), timeout_usec = 0xf4240, status = success, error = (null)) => bytes_read = 4<br>
> > < 4> read packet: $#00<br>
> > < 1> send packet: +<br>
> > error: failed to get response for 'qThreadStopInfo707'<br>
> > ProcessGDBRemote::Resume()<br>
> > ProcessGDBRemote::AsyncThread (arg = 0x7fe2ab00d000, pid = 1799) Got an event of type: 1...<br>
> > ProcessGDBRemote::AsyncThread (arg = 0x7fe2ab00d000, pid = 1799) got eBroadcastBitAsyncContinue: vCont;c:0707<br>
> > GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse ()<br>
> > GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () sending continue packet: vCont;c:0707<br>
> > < 16> send packet: $vCont;c:0707#b0<br>
> > size_t GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote &, uint32_t): Read (buffer, (sizeof(buffer), timeout_usec = 0xf4240, status = success, error = (null)) => bytes_read = 1<br>
> > < 1> read packet: +<br>
> > GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () WaitForPacket(vCont;c:0707)<br>
> > size_t GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote &, uint32_t): Read (buffer, (sizeof(buffer), timeout_usec = 0xffffffff, status = success, error = (null)) => bytes_read = 7<br>
> > < 7> read packet: $W00#b7<br>
> > < 1> send packet: +<br>
> > GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () got packet: W00<br>
> > GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse () => exited<br>
> > ProcessGDBRemote::AsyncThread (arg = 0x7fe2ab00d000, pid = 1799) thread exiting...<br>
> ><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>