Re: multi-proc: info processes?

[Michael Snyder <msnyder@vmware.com>]

Pedro Alves wrote:
> On Wednesday 12 November 2008 21:21:59, Michael Snyder wrote:
>> Stan Shebs wrote:
>>> Michael Snyder wrote:
>>>> Hey Pedro,
>>>>
>>>> For your multi-process work, are you planning anything
>>>> analogous to the "info threads" command, eg. "info processes"?
>>> Look at "info inferiors". It's just the processes (or whatever) that are 
>>> currently being controlled by GDB.
>>>> 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?
>>> 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...
>> 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')
Reply:  m<pid>
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"...