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