Re: multi-proc: info processes?

Michael Snyder
2008-11-13T01:48:33Z

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"...