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 <[email protected]> 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
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to