This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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,

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]