This is the mail archive of the
mailing list for the GDB project.
Re: multi-proc: info processes?
Pedro Alves wrote:
On Wednesday 12 November 2008 21:21:59, Michael Snyder wrote:
Stan Shebs wrote:
Michael Snyder wrote:
Hey Pedro,Look at "info inferiors". It's just the processes (or whatever) that are
currently being controlled by GDB.
For your multi-process work, are you planning anything
analogous to the "info threads" command, eg. "info processes"?
That would be somewhat ambitious, especially for a remote target - I
think you'd need a new packet just to return the list of processes...
What might that look like, in your model? Would it list,
say, just the processes that gdb is attached to? Or would
you want something analogous to "ps", that would list all
of the processes that are available to be attached?
Sure -- by analogy with qfThreadInfo/qsThreadInfo, it could
be implemented as an iterator.
Yeah, there are many ways to implement that. Both Vladimir and
I ended up doing that independently but similarly, by querying a new
enum target_object and having the stub formatting the list of
processes as xml. Vladimir has the ball on merging those
currently --- let's see what comes out, might even pop out something
totally different. :-)
Hmmm, isn't the formatting of xml a little heavy-weight for a stub?
Stubs are traditionally sort of light-weight entities. I realize
we're really talking about a gdbserver-type entity here...
Just for yuks, what about something like this, again by
analogy to info threads?
Query: qfProcInfo (f for 'first')
Query: qsProcInfo (s for... umm, 'next')
Reply: m<pid>, or 'l' if this is the 'last' reply.
Of course, then you might want some analog of "ExtraInfo"...