multi-proc: info processes?

multi-proc: info processes?

[Michael Snyder]

Hey Pedro,

For your multi-process work, are you planning anything
analogous to the "info threads" command, eg. "info 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?

Appologies if you've already discussed this...

Michael

Re: multi-proc: info processes?

[Stan Shebs]

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

Stan

Re: multi-proc: info processes?

[Vladimir Prus]

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

FWIW, MI '-list-thread-groups --available' will do just that. The patch itself
needs some work, but should be posted this week.

- Volodya

Re: multi-proc: info processes?

[Michael Snyder]

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.

I'm not sure how desireable it is, but it could save you
from having to go over to the remote target and typing "ps"...

By the way, what about remote attach?  Is that in the plan?

Re: multi-proc: info processes?

[Pedro Alves]

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.  :-)

> 
> I'm not sure how desireable it is, but it could save you
> from having to go over to the remote target and typing "ps"...
> 
> By the way, what about remote attach?  Is that in the plan?

The extended remote protocol has had that for long now, in
the form of vAttach;pid.  What do you mean exactly?

-- 
Pedro Alves

Re: multi-proc: info processes?

[Michael Snyder]

Pedro Alves wrote:
> On Wednesday 12 November 2008 21:21:59, Michael Snyder wrote:
>> I'm not sure how desireable it is, but it could save you
>> from having to go over to the remote target and typing "ps"...
>>
>> By the way, what about remote attach?  Is that in the plan?
> 
> The extended remote protocol has had that for long now, in
> the form of vAttach;pid.  What do you mean exactly?

That's probably what I meant.  Thanks!

Re: multi-proc: info processes?

[Michael Snyder]

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

Re: multi-proc: info processes?

[Daniel Jacobowitz]

On Wed, Nov 12, 2008 at 05:47:38PM -0800, Michael Snyder wrote:
> Hmmm, isn't the formatting of xml a little heavy-weight for a stub?

Nope.  *Parsing* XML is a bit heavy-weight, but generating it requires
only a tiny routine to escape characters if you support arbitrary
names in the generated XML; you can generate it textually, not
via a DOM.  gdbserver does this, for instance, and I'd guess it's just
a couple hundred bytes of code.  No more than it would take for a
qfThreadInfo analogue.

-- 
Daniel Jacobowitz
CodeSourcery

Re: multi-proc: info processes?

[EBo]

Just in case you guys need to get into parsing XML I would mention Spirit++ (a
C++ functional template library which replaces most of the functionality of
LEX and YACC -- see http://spirit.sourceforge.net/ for more info). IIRC,
Spirit++ has a XML parser library suite.  I do not know if this is appropriate
for the problem, but is a nice tool in the shed when needed.

  EBo --

Daniel Jacobowitz <drow@false.org> said:

> On Wed, Nov 12, 2008 at 05:47:38PM -0800, Michael Snyder wrote:
> > Hmmm, isn't the formatting of xml a little heavy-weight for a stub?
> 
> Nope.  *Parsing* XML is a bit heavy-weight, but generating it requires
> only a tiny routine to escape characters if you support arbitrary
> names in the generated XML; you can generate it textually, not
> via a DOM.  gdbserver does this, for instance, and I'd guess it's just
> a couple hundred bytes of code.  No more than it would take for a
> qfThreadInfo analogue.
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery

Re: multi-proc: info processes?

[Vladimir Prus]

EBo wrote:

> Just in case you guys need to get into parsing XML I would mention Spirit++ (a
> C++ functional template library which replaces most of the functionality of
> LEX and YACC -- see http://spirit.sourceforge.net/ for more info). IIRC,
> Spirit++ has a XML parser library suite.  I do not know if this is appropriate
> for the problem, but is a nice tool in the shed when needed.

We have a solution for parsing XML already and parse XML in a number of places. 
Besides, GDB is not written in C++, and although I hope it will be converted to C++ 
someday, I do not think it will ever make use of Spirit. (The reasons why are 
offtopic here, you can catch me in #gdb or #boost if you really want to know).

- Volodya

Re: multi-proc: info processes?

[Michael Snyder]

Daniel Jacobowitz wrote:
> On Wed, Nov 12, 2008 at 05:47:38PM -0800, Michael Snyder wrote:
>> Hmmm, isn't the formatting of xml a little heavy-weight for a stub?
> 
> Nope.  *Parsing* XML is a bit heavy-weight, but generating it requires
> only a tiny routine to escape characters if you support arbitrary
> names in the generated XML; you can generate it textually, not
> via a DOM.  gdbserver does this, for instance, and I'd guess it's just
> a couple hundred bytes of code.  No more than it would take for a
> qfThreadInfo analogue.

OK.  Could I maybe get a preview of what you have in mind?
I'm working on something similar, might as well try to be
compatible.