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

Matthew Gardiner mg11 at csr.com
Mon May 12 06:35:37 PDT 2014


Matthew Gardiner 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
>
>
> To report this email as spam click 
> https://www.mailcontrol.com/sr/1WqnrEJPKhrGX2PQPOmvUmkxeMeR4!FmImKX97+QpHjLCq2QeVly7xayiF08kgVBnOaHevKbN4oYNBM7q0TQEQ== 
> .

I've had a quick look at some code, and it looks like somewhere between 
the call to ConnectToDebugserver and m_gdb_comm.GetCurrentProcessID we 
omit to send the "qC" request, and that seems to result in 
GetCurrentProcessID == LLDB_INVALID_PROCESS_ID.

Is this omission by design or is it a bug?

The code I ended up looking at is below:

ProcessGDBRemote::DoConnectRemote (Stream *strm, const char *remote_url)
{
     Error error (WillLaunchOrAttach ());

     if (error.Fail())
         return error;

     error = ConnectToDebugserver (remote_url);

     if (error.Fail())
         return error;
     StartAsyncThread ();

     lldb::pid_t pid = m_gdb_comm.GetCurrentProcessID ();
     if (pid == LLDB_INVALID_PROCESS_ID)
     {
         // We don't have a valid process ID, so note that we are connected
         // and could now request to launch or attach, or get remote 
process
         // listings...
         SetPrivateState (eStateConnected);
     }
     else
     {
         // We have a valid process
         SetID (pid);
         GetThreadList();
         if (m_gdb_comm.SendPacketAndWaitForResponse("?", 1, 
m_last_stop_packet, false) == GDBRemoteCommunication::PacketResult::Success)
         {
             if (!m_target.GetArchitecture().IsValid())

thanks
Matt




More information about the lldb-dev mailing list