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

Todd, Greg, Thanks for thrashing this one out, guys. Glad we are in agreeable about maintaining backward compatibility with gdbserver here. As previously stated any new stubs to implement qProcessInfo. thanks Matt Member of the CSR plc group of companies. CSR plc registered in England and

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

Thanks Todd! > On May 13, 2014, at 5:23 PM, Todd Fiala wrote: > > This change is in at r208741. ___ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

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

> On May 13, 2014, at 4:38 PM, Todd Fiala wrote: > > I should rephrase since we need context here: > > 1. TOT lldb <=> current debugserver/llgs > > Will use qProcessInfo and get the process id. > > 2. TOT lldb <=> older debugserver > > Will use qProcessINfo and get the process id. > > 3. TO

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

> On May 13, 2014, at 4:25 PM, Todd Fiala wrote: > > You realize that qC's response is not stable as a pseudo pid, right? So > anything that asks for it, thinks they have it, and then asks again for it > can get a different result depending on what the gdb remote thinks is the > current thre

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

> On May 13, 2014, at 7:56 AM, Todd Fiala wrote: > > Hey Matthew, > > > However is there any real need to restrict the fallback case to just > > Apple/iOS? > > Keep in mind that qC in gdbserver does implement the protocol correctly and > returns the thread id, not the proc id. On Linux the

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

Todd Fiala wrote: This is a change I made. qC is supposed to return the thread id, not the process id. qProcessInfo is being used now to collect the process id. We added a fallback so that if the process info request fails, on Apple/iOS we fall back to the older qC (which, as indicated befor

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

Greg Clayton wrote: 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.00

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

Todd Fiala wrote: > I'll look for #2. I just scanned through the gdbremote protocol docs here . I may have missed it, but searching process-id, "process id", and pid in the packets and didn't see any way to query for the process

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

Todd Fiala wrote: Okay, looking back at your packet log: 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

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

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: $qProce

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

Is this omission by design or is it a bug? I've now found that GDBRemoteCommunicationClient::GetCurrentProcessID() has been reworked recently, and that it what has caused the breakage I've witnessed. Matt Member of the CSR plc group of companies. CSR plc registered in England and Wales,

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

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:", is now broken ./lldb ~/src/play/c/simp/simp-x64 Traceback (most recent call last): Fi

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

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:", is now broken ./lldb ~/src/play/c/simp/simp-x64 Traceback (most recent call last): File "", line 1, in Import