[lldb-dev] gdb-remote command broken in TOT

Mon May 12 11:18:06 PDT 2014

LLDB was incorrectly using the "qC" packet to get the process info. From your old working log:

127.000.000.001.43202-127.000.000.001.07778: $qC#b4
127.000.000.001.07778-127.000.000.001.43202: $QC359b#97

It now uses the qProcessInfo packet: 

> 127.000.000.001.43138-127.000.000.001.07778: $qProcessInfo#dc
> 127.000.000.001.07778-127.000.000.001.43138: $#00
> 127.000.000.001.43138-127.000.000.001.07778: $qProcessInfo#dc
> 127.000.000.001.07778-127.000.000.001.43138: $#00

You should add support for this packet. Here is a sample:

send packet: $qProcessInfo#00
read packet: $pid:42a8;parent-pid:42bf;real-uid:ecf;real-gid:b;effective-uid:ecf;effective-gid:b;cputype:7;cpusubtype:3;ostype:macosx;vendor:apple;endian:little;ptrsize:4;#00

Omit and key value pairs that don't make sense for your target (parent-pid, real-uid, real-gid, effective-uid, effective-gid, cputype, cpusubtype), but do try to at least add the following key/value pairs:

pid
triple (with values like: x86_64-apple-macosx, i386-unknown-unknown (for raw binary debugging with no OS like a bare board))
endian
ptrsize

You can omit the "vendor" and "ostype" if you supply the triple.

> On May 12, 2014, at 5:00 AM, Matthew Gardiner <mg11 at csr.com> wrote:
> 
> Hi all,
> 
> I have just synced up to the top-of-tree for llvm, clang and lldb, and rebuilt for 64-bit linux. I've found that the implementation of the command  "gdb-remote localhost:<port>", is now broken
> 
> ./lldb ~/src/play/c/simp/simp-x64
> Traceback (most recent call last):
>  File "<string>", line 1, in <module>
> ImportError: No module named lldb.embedded_interpreter
> Current executable set to '/home/mg11/src/play/c/simp/simp-x64' (x86_64).
> (lldb) gdb-remote localhost:7778
> Process 0 connected
> 
> error: Process 0 is currently being debugged, kill the process before connecting.
> (lldb) bt
> error: invalid thread
> 
> It seems the client-side is not collecting the process and thread information correctly from the server. The GDB-RSP (server=7778) is as follows:
> 
> 127.000.000.001.43138-127.000.000.001.07778: +
> 127.000.000.001.43138-127.000.000.001.07778: $QStartNoAckMode#b0
> 127.000.000.001.07778-127.000.000.001.43138: +
> 127.000.000.001.07778-127.000.000.001.43138: $OK#9a
> 127.000.000.001.43138-127.000.000.001.07778: +
> 127.000.000.001.43138-127.000.000.001.07778: $QThreadSuffixSupported#e4
> 127.000.000.001.07778-127.000.000.001.43138: $#00
> 127.000.000.001.43138-127.000.000.001.07778: $QListThreadsInStopReply#21
> 127.000.000.001.07778-127.000.000.001.43138: $#00
> 127.000.000.001.43138-127.000.000.001.07778: $qHostInfo#9b
> 127.000.000.001.07778-127.000.000.001.43138: $#00
> 127.000.000.001.43138-127.000.000.001.07778: $vCont?#49
> 127.000.000.001.07778-127.000.000.001.43138: $vCont;c;C;s;S;t;r#be
> 127.000.000.001.43138-127.000.000.001.07778: $qVAttachOrWaitSupported#38
> 127.000.000.001.07778-127.000.000.001.43138: $#00
> 127.000.000.001.43138-127.000.000.001.07778: $qProcessInfo#dc
> 127.000.000.001.07778-127.000.000.001.43138: $#00
> 127.000.000.001.43138-127.000.000.001.07778: $qProcessInfo#dc
> 127.000.000.001.07778-127.000.000.001.43138: $#00
> 
> This functionality was working (almost) properly about a month ago. Here is a run using that binary and a trace.
> 
> ./lldb ~/src/play/c/simp/simp-x64
> Traceback (most recent call last):
>  File "<string>", line 1, in <module>
> ImportError: No module named lldb.embedded_interpreter
> Current executable set to '/home/mg11/src/play/c/simp/simp-x64' (x86_64).
> (lldb) gdb-remote localhost:7778
> Process 13723 stopped
> * thread #1: tid = 13723, , stop reason = signal SIGTRAP
>    frame #0:
> 
> 127.000.000.001.43202-127.000.000.001.07778: +
> 127.000.000.001.43202-127.000.000.001.07778: $QStartNoAckMode#b0
> 127.000.000.001.07778-127.000.000.001.43202: +
> 127.000.000.001.07778-127.000.000.001.43202: $OK#9a
> 127.000.000.001.43202-127.000.000.001.07778: +
> 127.000.000.001.43202-127.000.000.001.07778: $QThreadSuffixSupported#e4
> 127.000.000.001.07778-127.000.000.001.43202: $#00
> 127.000.000.001.43202-127.000.000.001.07778: $QListThreadsInStopReply#21
> 127.000.000.001.07778-127.000.000.001.43202: $#00
> 127.000.000.001.43202-127.000.000.001.07778: $qHostInfo#9b
> 127.000.000.001.07778-127.000.000.001.43202: $#00
> 127.000.000.001.43202-127.000.000.001.07778: $vCont?#49
> 127.000.000.001.07778-127.000.000.001.43202: $vCont;c;C;s;S;t;r#be
> 127.000.000.001.43202-127.000.000.001.07778: $qVAttachOrWaitSupported#38
> 127.000.000.001.07778-127.000.000.001.43202: $#00
> 127.000.000.001.43202-127.000.000.001.07778: $qC#b4
> 127.000.000.001.07778-127.000.000.001.43202: $QC359b#97
> 127.000.000.001.43202-127.000.000.001.07778: $?#3f
> 127.000.000.001.07778-127.000.000.001.43202: $T0506:0*,;07:a0e1f*"7f0* ;10:f011a075360*";thread:359b;core:5;#d9
> 127.000.000.001.43202-127.000.000.001.07778: $qRegisterInfo0#72
> 127.000.000.001.07778-127.000.000.001.43202: $#00
> 127.000.000.001.43202-127.000.000.001.07778: $qProcessInfo#dc
> 127.000.000.001.07778-127.000.000.001.43202: $#00
> 127.000.000.001.43202-127.000.000.001.07778: $p0#a0
> 127.000.000.001.07778-127.000.000.001.43202: $#00
> 127.000.000.001.43202-127.000.000.001.07778: $qRegisterInfo0#72
> 127.000.000.001.07778-127.000.000.001.43202: $#00
> 127.000.000.001.43202-127.000.000.001.07778: $qProcessInfo#dc
> 127.000.000.001.07778-127.000.000.001.43202: $#00
> 127.000.000.001.43202-127.000.000.001.07778: $qProcessInfo#dc
> 127.000.000.001.07778-127.000.000.001.43202: $#00
> 127.000.000.001.43202-127.000.000.001.07778: $qShlibInfoAddr#6a
> 127.000.000.001.07778-127.000.000.001.43202: $#00
> 127.000.000.001.43202-127.000.000.001.07778: $qfThreadInfo#bb
> 127.000.000.001.07778-127.000.000.001.43202: $m359b#70
> 127.000.000.001.43202-127.000.000.001.07778: $qsThreadInfo#c8
> 127.000.000.001.07778-127.000.000.001.43202: $l#6c
> 
> Part of the problem, it seems, is that the new build does not send "qC" (get current thread id).
> 
> Is there anyone currently working in this area? Or is it a bug I should start to look at?
> 
> thanks
> Matthew Gardiner
> 
> 
> 
> 
> 
> Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
> More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc.
> New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev