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

[Todd Fiala]

> I'll look for #2.

I just scanned through the gdbremote protocol docs
here<https://sourceware.org/gdb/onlinedocs/gdb/Packets.html#Packets>.
 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 id using just
what was documented.

It looks possible to get the data indirectly if multiprocess extensions are
enabled and supported by both the stub and the client, in which case some
stop replies can contain the process:{pid} key/value.  Seems like
implementing qProcessInfo is the easier way to go here though since the
multiprocess extensions seem to change behavior of several of the other
packets.

-Todd


-Todd


On Mon, May 12, 2014 at 8:06 AM, Todd Fiala <tfiala at google.com> 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.07778-127.000.000.001.43138: $#00
>
> Couple options here:
>
> 1. implement qProcessInfo in your custom remote monitor.  The only
> key-value pair we're looking for in this case is the pid:{process-id} pair
> as far as retrieving the process id goes.  If you're in control of the
> remote, this will be your fastest option for getting a resolution.
>
> 2. we find the gdbremote command present in the stock gdbremote protocol
> set that gives us the process id (and this is not $qC) and fall back to
> that if qProcessInfo is not supported.
>
> I'll look for #2.  Probably best for you to implement $qProcessInfo if
> it's an option for you.  RNBRemote.cpp has the handler for it in
> debugserver and GDBRemoteCommunicationServer.cpp has it for llgs in that
> other branch from the prior email (soon to go upstream).
>
> Hope that helps!
>
> -Todd
>
>
>
>
> On Mon, May 12, 2014 at 7:44 AM, Todd Fiala <tfiala at google.com> 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 before, used to return the
>> process id erroneously, see the gdb remote documentation).
>>
>> Let me know what path you're not getting the getting process info when
>> you would expect it.  I've got some protocol tests on it in
>> test/tools/lldb-gdbserver where it runs with a @debugserver_test (on
>> MacOSX) and @llgs_test (on the llgs branch here<https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64>).
>>  Sounds like we're maybe missing a case somewhere.
>>
>> Is the context that you're launching new inferior or an attaching to
>> existing inferior?
>>
>> Thanks!
>>
>> -Todd
>>
>>
>> On Mon, May 12, 2014 at 6:47 AM, Matthew Gardiner <mg11 at csr.com> wrote:
>>
>>>
>>>
>>>> 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, 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
>>>
>>
>>
>>
>> --
>>  Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>>
>
>
>
> --
> Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>



-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140512/1ac7d26e/attachment.html>