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

[Matthew Gardiner]

Todd Fiala wrote:
> > 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.
Yeah, I had a look through my docs. Looks as the old gdb people make no 
hard distinction better threads and processes. I think that qC is asking 
"give me the id of what stopped and I assuming that pids and thread-ids 
come from the same number pool". Well that's my guess, at least...

>
> 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.
Sure, I'm on my way with qProcessInfo (for my stub)...

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.