Multiprocess MI extensions

Multiprocess MI extensions

[Vladimir Prus]

[-- Attachment #1: Type: text/plain, Size: 243 bytes --]


Attached is the draft of the proposed MI changes to support multi-process
debugging. I think the changes are fairly small, and are generic enough
to support, in future, any hierarchy of processes/cores/boards/universes.
Comments?

- Volodya


[-- Attachment #2: multiprocess-mi.txt --]
[-- Type: text/plain, Size: 3312 bytes --]


Functional requirements
=======================

1. Attaching and detaching to processes

2. Listing available processes

3. Listing attached processes

4. Listing threads in all processes (or in a specific process?)

5. Process termination report.

Discussion
==========

We want frontend changes to be minimal. Towards this goal, we can treat
multi-process session as merely a collection of threads, with processes
presented just as named group of threads without much smarts. Specifically:

- There will be global numbering of threads across all processes
- There will be no notion of current process. The current thread
will be global to a session, as opposed to having a current thread
per each process.

We want to have a flexible grouping of threads, as there might be, in
future, different levels of organization than processes, both more higher
level (systems) and more low level (individual cores). To that end, we'll
introduce a notion of 'thread group', that has identifier, and can contain
either futher groups or individual threads.

Design
======

1. Obtaining hierarchy.

New command -list-thread-groups will be introduced, that returns either
returns the list of top-level thread groups, or the list of thread groups
that are children of a specified group. The output is:

  ^done,result={threads=[<thread>],groups=[<group>]}

where each thread group is like this:

   {id="xxx",type="process",pid="yyy",num_children="1"}

The id of a thread group should be considered an opaque string.

-> Should we just dump the entire tree in one go, without requiring
that frontend traverses the entire hierarchy? Maybe not, since on
multi-board configuration, getting the list of all process might be
slow.

2. Whenever printing a thread, if that thread is part of some group,
a 'parent' field will be printed, with value been the id of the thread
group.

3. The -exec-continue and -exec-interrupt commands, as part of non-stop
work, got the --all parameter to tell them to act on all threads. To
allow interruping just one process, they will get a --thread-group
option. The value of this option is either an id of a thread group,
or a special value 'all'. For now, no other commands seem to need
this option, but such a need might arise in future -- for example,
to set per-process breakpoints.

4. The -list-thread-groups will accept the '--available' option that tells
it to list all thread groups, including those that are not attached to yet.
There will be a --thread-group-attach command, accept an id of a thread
group, and attaches to it.  There will be --thread-group-detach command,
acceping an id of a thread group and detaching from said thread group.

-> Should we allow to attach a specific process using pid, assuming user
has some magic way to get at pid? Probably yes, so that a frontend is
not forced to implement searching through gdb-reported process list.

5. The *running and *stopped notifications, instead of 'thread' field,
may include 'thread-group' field.

-> How to report process exit? Should we overload =thread-exited, introduce
=thread-group-exited, or what? 

-> Should we auto-attach to newly forked processes? Should we have
 =new-thread-group notificatin, if so?

-> Should we have just =created and =exited notifications, used for threads
and processes and what not?

Re: Multiprocess MI extensions

[Pawel Piech]

Thank you Vladimir, the proposal seems very reasonable :-) and 
considerate of backward compatibility,
Couple of comments below:

Vladimir Prus wrote:
> Attached is the draft of the proposed MI changes to support multi-process
> debugging. I think the changes are fairly small, and are generic enough
> to support, in future, any hierarchy of processes/cores/boards/universes.
> Comments?
>
> - Volodya
>
>   
> ------------------------------------------------------------------------
>
>
> Functional requirements
> =======================
>
> 1. Attaching and detaching to processes
>
> 2. Listing available processes
>
> 3. Listing attached processes
>
> 4. Listing threads in all processes (or in a specific process?)
>
> 5. Process termination report.
>
> Discussion
> ==========
>
> We want frontend changes to be minimal. Towards this goal, we can treat
> multi-process session as merely a collection of threads, with processes
> presented just as named group of threads without much smarts. Specifically:
>
> - There will be global numbering of threads across all processes
> - There will be no notion of current process. The current thread
> will be global to a session, as opposed to having a current thread
> per each process.
>
> We want to have a flexible grouping of threads, as there might be, in
> future, different levels of organization than processes, both more higher
> level (systems) and more low level (individual cores). To that end, we'll
> introduce a notion of 'thread group', that has identifier, and can contain
> either futher groups or individual threads.
>
> Design
> ======
>
> 1. Obtaining hierarchy.
>
> New command -list-thread-groups will be introduced, that returns either
> returns the list of top-level thread groups, or the list of thread groups
> that are children of a specified group. The output is:
>
>   ^done,result={threads=[<thread>],groups=[<group>]}
>
> where each thread group is like this:
>
>    {id="xxx",type="process",pid="yyy",num_children="1"}
>
> The id of a thread group should be considered an opaque string.
>
> -> Should we just dump the entire tree in one go, without requiring
> that frontend traverses the entire hierarchy? Maybe not, since on
> multi-board configuration, getting the list of all process might be
> slow.
>
> 2. Whenever printing a thread, if that thread is part of some group,
> a 'parent' field will be printed, with value been the id of the thread
> group.
>
> 3. The -exec-continue and -exec-interrupt commands, as part of non-stop
> work, got the --all parameter to tell them to act on all threads. To
> allow interruping just one process, they will get a --thread-group
> option. The value of this option is either an id of a thread group,
> or a special value 'all'. For now, no other commands seem to need
> this option, but such a need might arise in future -- for example,
> to set per-process breakpoints.
>
> 4. The -list-thread-groups will accept the '--available' option that tells
> it to list all thread groups, including those that are not attached to yet.
> There will be a --thread-group-attach command, accept an id of a thread
> group, and attaches to it.  There will be --thread-group-detach command,
> acceping an id of a thread group and detaching from said thread group.
>
> -> Should we allow to attach a specific process using pid, assuming user
> has some magic way to get at pid? Probably yes, so that a frontend is
> not forced to implement searching through gdb-reported process list.
>
> 5. The *running and *stopped notifications, instead of 'thread' field,
> may include 'thread-group' field.
>   
I would suggest to reserve the thread field to indicate the triggering 
thread, even if the whole process stops.
> -> How to report process exit? Should we overload =thread-exited, introduce
> =thread-group-exited, or what? 
>
> -> Should we auto-attach to newly forked processes? Should we have
>  =new-thread-group notificatin, if so?
>   
Auto attach should probably be an option, but if there is an auto 
attach, a notification should definitely be generated.
> -> Should we have just =created and =exited notifications, used for threads
> and processes and what not?
>   
I don't think it makes much difference whether the same event is used or 
not as long as a parent-id field is included in the event.

Cheers,
Pawel

Re: Multiprocess MI extensions

[Vladimir Prus]

Pawel Piech wrote:

> Thank you Vladimir, the proposal seems very reasonable :-) and
> considerate of backward compatibility,
> Couple of comments below:
> 
> Vladimir Prus wrote:
>> Attached is the draft of the proposed MI changes to support multi-process
>> debugging. I think the changes are fairly small, and are generic enough
>> to support, in future, any hierarchy of processes/cores/boards/universes.
>> Comments?
>>
>> - Volodya
>>
>>   
>> ------------------------------------------------------------------------
>>
>>
>> Functional requirements
>> =======================
>>
>> 1. Attaching and detaching to processes
>>
>> 2. Listing available processes
>>
>> 3. Listing attached processes
>>
>> 4. Listing threads in all processes (or in a specific process?)
>>
>> 5. Process termination report.
>>
>> Discussion
>> ==========
>>
>> We want frontend changes to be minimal. Towards this goal, we can treat
>> multi-process session as merely a collection of threads, with processes
>> presented just as named group of threads without much smarts. Specifically:
>>
>> - There will be global numbering of threads across all processes
>> - There will be no notion of current process. The current thread
>> will be global to a session, as opposed to having a current thread
>> per each process.
>>
>> We want to have a flexible grouping of threads, as there might be, in
>> future, different levels of organization than processes, both more higher
>> level (systems) and more low level (individual cores). To that end, we'll
>> introduce a notion of 'thread group', that has identifier, and can contain
>> either futher groups or individual threads.
>>
>> Design
>> ======
>>
>> 1. Obtaining hierarchy.
>>
>> New command -list-thread-groups will be introduced, that returns either
>> returns the list of top-level thread groups, or the list of thread groups
>> that are children of a specified group. The output is:
>>
>>   ^done,result={threads=[<thread>],groups=[<group>]}
>>
>> where each thread group is like this:
>>
>>    {id="xxx",type="process",pid="yyy",num_children="1"}
>>
>> The id of a thread group should be considered an opaque string.
>>
>> -> Should we just dump the entire tree in one go, without requiring
>> that frontend traverses the entire hierarchy? Maybe not, since on
>> multi-board configuration, getting the list of all process might be
>> slow.
>>
>> 2. Whenever printing a thread, if that thread is part of some group,
>> a 'parent' field will be printed, with value been the id of the thread
>> group.
>>
>> 3. The -exec-continue and -exec-interrupt commands, as part of non-stop
>> work, got the --all parameter to tell them to act on all threads. To
>> allow interruping just one process, they will get a --thread-group
>> option. The value of this option is either an id of a thread group,
>> or a special value 'all'. For now, no other commands seem to need
>> this option, but such a need might arise in future -- for example,
>> to set per-process breakpoints.
>>
>> 4. The -list-thread-groups will accept the '--available' option that tells
>> it to list all thread groups, including those that are not attached to yet.
>> There will be a --thread-group-attach command, accept an id of a thread
>> group, and attaches to it.  There will be --thread-group-detach command,
>> acceping an id of a thread group and detaching from said thread group.
>>
>> -> Should we allow to attach a specific process using pid, assuming user
>> has some magic way to get at pid? Probably yes, so that a frontend is
>> not forced to implement searching through gdb-reported process list.
>>
>> 5. The *running and *stopped notifications, instead of 'thread' field,
>> may include 'thread-group' field.
>>   
> I would suggest to reserve the thread field to indicate the triggering
> thread, even if the whole process stops.

It's possible. Are you going to use the triggered thread id to select it
in UI?

>> -> How to report process exit? Should we overload =thread-exited, introduce
>> =thread-group-exited, or what?
>>
>> -> Should we auto-attach to newly forked processes? Should we have
>>  =new-thread-group notificatin, if so?
>>   
> Auto attach should probably be an option, but if there is an auto
> attach, a notification should definitely be generated.

OK.

>> -> Should we have just =created and =exited notifications, used for threads
>> and processes and what not?
>>   
> I don't think it makes much difference whether the same event is used or
> not as long as a parent-id field is included in the event.

Just to make sure we're on the same page -- if we use one notification for everything,
it will either have a 'thread' field -- when a thread is created/exited, or 'thread-group'
field, when  process is created/exited. Is that OK?

- Volodya

Re: Multiprocess MI extensions

[Pawel Piech]

Vladimir Prus wrote:
> Pawel Piech wrote:
>
>   
>> Thank you Vladimir, the proposal seems very reasonable :-) and
>> considerate of backward compatibility,
>> Couple of comments below:
>>
>> Vladimir Prus wrote:
>>     
>>> Attached is the draft of the proposed MI changes to support multi-process
>>> debugging. I think the changes are fairly small, and are generic enough
>>> to support, in future, any hierarchy of processes/cores/boards/universes.
>>> Comments?
>>>
>>> - Volodya
>>>
>>>   
>>> ------------------------------------------------------------------------
>>>
>>>
>>> Functional requirements
>>> =======================
>>>
>>> 1. Attaching and detaching to processes
>>>
>>> 2. Listing available processes
>>>
>>> 3. Listing attached processes
>>>
>>> 4. Listing threads in all processes (or in a specific process?)
>>>
>>> 5. Process termination report.
>>>
>>> Discussion
>>> ==========
>>>
>>> We want frontend changes to be minimal. Towards this goal, we can treat
>>> multi-process session as merely a collection of threads, with processes
>>> presented just as named group of threads without much smarts. Specifically:
>>>
>>> - There will be global numbering of threads across all processes
>>> - There will be no notion of current process. The current thread
>>> will be global to a session, as opposed to having a current thread
>>> per each process.
>>>
>>> We want to have a flexible grouping of threads, as there might be, in
>>> future, different levels of organization than processes, both more higher
>>> level (systems) and more low level (individual cores). To that end, we'll
>>> introduce a notion of 'thread group', that has identifier, and can contain
>>> either futher groups or individual threads.
>>>
>>> Design
>>> ======
>>>
>>> 1. Obtaining hierarchy.
>>>
>>> New command -list-thread-groups will be introduced, that returns either
>>> returns the list of top-level thread groups, or the list of thread groups
>>> that are children of a specified group. The output is:
>>>
>>>   ^done,result={threads=[<thread>],groups=[<group>]}
>>>
>>> where each thread group is like this:
>>>
>>>    {id="xxx",type="process",pid="yyy",num_children="1"}
>>>
>>> The id of a thread group should be considered an opaque string.
>>>
>>> -> Should we just dump the entire tree in one go, without requiring
>>> that frontend traverses the entire hierarchy? Maybe not, since on
>>> multi-board configuration, getting the list of all process might be
>>> slow.
>>>
>>> 2. Whenever printing a thread, if that thread is part of some group,
>>> a 'parent' field will be printed, with value been the id of the thread
>>> group.
>>>
>>> 3. The -exec-continue and -exec-interrupt commands, as part of non-stop
>>> work, got the --all parameter to tell them to act on all threads. To
>>> allow interruping just one process, they will get a --thread-group
>>> option. The value of this option is either an id of a thread group,
>>> or a special value 'all'. For now, no other commands seem to need
>>> this option, but such a need might arise in future -- for example,
>>> to set per-process breakpoints.
>>>
>>> 4. The -list-thread-groups will accept the '--available' option that tells
>>> it to list all thread groups, including those that are not attached to yet.
>>> There will be a --thread-group-attach command, accept an id of a thread
>>> group, and attaches to it.  There will be --thread-group-detach command,
>>> acceping an id of a thread group and detaching from said thread group.
>>>
>>> -> Should we allow to attach a specific process using pid, assuming user
>>> has some magic way to get at pid? Probably yes, so that a frontend is
>>> not forced to implement searching through gdb-reported process list.
>>>
>>> 5. The *running and *stopped notifications, instead of 'thread' field,
>>> may include 'thread-group' field.
>>>   
>>>       
>> I would suggest to reserve the thread field to indicate the triggering
>> thread, even if the whole process stops.
>>     
>
> It's possible. Are you going to use the triggered thread id to select it
> in UI?
>
>   
That's correct. 
>>> -> How to report process exit? Should we overload =thread-exited, introduce
>>> =thread-group-exited, or what?
>>>
>>> -> Should we auto-attach to newly forked processes? Should we have
>>>  =new-thread-group notificatin, if so?
>>>   
>>>       
>> Auto attach should probably be an option, but if there is an auto
>> attach, a notification should definitely be generated.
>>     
>
> OK.
>
>   
>>> -> Should we have just =created and =exited notifications, used for threads
>>> and processes and what not?
>>>   
>>>       
>> I don't think it makes much difference whether the same event is used or
>> not as long as a parent-id field is included in the event.
>>     
>
> Just to make sure we're on the same page -- if we use one notification for everything,
> it will either have a 'thread' field -- when a thread is created/exited, or 'thread-group'
> field, when  process is created/exited. Is that OK?
>
>   
Yes, that's fine.  A more forward looking alternative would be to have a 
consistent id field and a type field which would indicate whether it's a 
group, thread, etc.

Cheers,
Pawel

> - Volodya
>   

Re: Multiprocess MI extensions

[Vladimir Prus]

On Wednesday 11 June 2008 20:39:31 you wrote:

> > Just to make sure we're on the same page -- if we use one notification for everything,
> > it will either have a 'thread' field -- when a thread is created/exited, or 'thread-group'
> > field, when  process is created/exited. Is that OK?
> >
> >   
> Yes, that's fine.  A more forward looking alternative would be to have a 
> consistent id field and a type field which would indicate whether it's a 
> group, thread, etc.

Hopefully, the thread-group concept of so general that we'll only even need to
introduce new types of thread groups. IOW, instead of having id and type
in all notifications, we'll have id pointing at thread group, and the type
will be part of thread group.

- Volodya

RE: Re: Multiprocess MI extensions

[Marc Khouzam]

> >> -> How to report process exit? Should we overload 
> =thread-exited, introduce
> >> =thread-group-exited, or what?
> >>
> >> -> Should we auto-attach to newly forked processes? Should we have
> >>  =new-thread-group notificatin, if so?
> >>   
> > Auto attach should probably be an option, but if there is an auto
> > attach, a notification should definitely be generated.
> 
> OK.
> 
> >> -> Should we have just =created and =exited notifications, 
> used for threads
> >> and processes and what not?
> >>   
> > I don't think it makes much difference whether the same 
> event is used or
> > not as long as a parent-id field is included in the event.
> 
> Just to make sure we're on the same page -- if we use one 
> notification for everything,
> it will either have a 'thread' field -- when a thread is 
> created/exited, or 'thread-group'
> field, when  process is created/exited. Is that OK?


Currently, when the inferior exits, there is an event that looks like:
*stopped,reason="exited-normally"
or some other variant.

I gather this is not a considered option for multi-process?
It probably would have helped with backwards compatibility.

What notification would be used for single-process, after the
multi-process changes?  Still *stopped... or will it be made in-line
with multi-process?

Thanks

marc

Re: Multiprocess MI extensions

[Vladimir Prus]

On Friday 13 June 2008 21:34:23 Marc Khouzam wrote:
> > >> -> How to report process exit? Should we overload 
> > =thread-exited, introduce
> > >> =thread-group-exited, or what?
> > >>
> > >> -> Should we auto-attach to newly forked processes? Should we have
> > >>  =new-thread-group notificatin, if so?
> > >>   
> > > Auto attach should probably be an option, but if there is an auto
> > > attach, a notification should definitely be generated.
> > 
> > OK.
> > 
> > >> -> Should we have just =created and =exited notifications, 
> > used for threads
> > >> and processes and what not?
> > >>   
> > > I don't think it makes much difference whether the same 
> > event is used or
> > > not as long as a parent-id field is included in the event.
> > 
> > Just to make sure we're on the same page -- if we use one 
> > notification for everything,
> > it will either have a 'thread' field -- when a thread is 
> > created/exited, or 'thread-group'
> > field, when  process is created/exited. Is that OK?
> 
> 
> Currently, when the inferior exits, there is an event that looks like:
> *stopped,reason="exited-normally"
> or some other variant.
> 
> I gather this is not a considered option for multi-process?
> It probably would have helped with backwards compatibility.

I don't know, honestly. Is extending *stopped with thread-group field really
much better for backward compatibility that new notification?

> What notification would be used for single-process, after the
> multi-process changes?  Still *stopped... or will it be made in-line
> with multi-process?

I think we have to keep *stopped for single-process. Changing that will
break everything.

- Volodya

RE: Multiprocess MI extensions

[Marc Khouzam]

> > Currently, when the inferior exits, there is an event that 
> looks like:
> > *stopped,reason="exited-normally"
> > or some other variant.
> > 
> > I gather this is not a considered option for multi-process?
> > It probably would have helped with backwards compatibility.
> 
> I don't know, honestly. Is extending *stopped with 
> thread-group field really
> much better for backward compatibility that new notification?

I had imagined to make multi-process debugging the only variant, which
would makes a single-process session actually be a multi-process one
with a single process (or thread-group).
But what we can do is look for both the new notification for process exit
and the *stopped one, which ever _one_ we see, will be the trigger.
So, as long as we get one or the other but not both at the same time,
it should be fine.

On another point for multi-process, I was wondering if there will be a need
to select a thread-group before issuing commands affecting a entire
group?  Something similar to what we have with -thread-select.  
I was thinking that a command affecting a group would apply to the group
to which the current thread belongs.

This would allow for any command currently applicable to the single process
or inferior, to be applied in the same way.  To be honnest, I'm not entirely
sure this is a good idea.

Did you guys discuss this?

Thanks

Marc

Re: Multiprocess MI extensions

[Vladimir Prus]

On Tuesday 17 June 2008 22:32:06 Marc Khouzam wrote:
> 
> > > Currently, when the inferior exits, there is an event that 
> > looks like:
> > > *stopped,reason="exited-normally"
> > > or some other variant.
> > > 
> > > I gather this is not a considered option for multi-process?
> > > It probably would have helped with backwards compatibility.
> > 
> > I don't know, honestly. Is extending *stopped with 
> > thread-group field really
> > much better for backward compatibility that new notification?
> 
> I had imagined to make multi-process debugging the only variant, which
> would makes a single-process session actually be a multi-process one
> with a single process (or thread-group).

This is the ultimate goal.

> But what we can do is look for both the new notification for process exit
> and the *stopped one, which ever _one_ we see, will be the trigger.
> So, as long as we get one or the other but not both at the same time,
> it should be fine.

I need to think about this more -- I just don't know what's the right thing here.
 
> On another point for multi-process, I was wondering if there will be a need
> to select a thread-group before issuing commands affecting a entire
> group?  Something similar to what we have with -thread-select.  
> I was thinking that a command affecting a group would apply to the group
> to which the current thread belongs.
> 
> This would allow for any command currently applicable to the single process
> or inferior, to be applied in the same way.  To be honnest, I'm not entirely
> sure this is a good idea.
> 
> Did you guys discuss this?

Not so much as "discuss". I personally try to avoid introducing more state in MI,
at all costs. That's why for commands wishing to operate on a given thread group,
the --thread-group option will be required. Presently, only -exec-continue and
-exec-interrupt seem to need this, though.

- Volodya

RE: Multiprocess MI extensions

[Marc Khouzam]

> > On another point for multi-process, I was wondering if 
> there will be a need
> > to select a thread-group before issuing commands affecting a entire
> > group?  Something similar to what we have with -thread-select.  
> > I was thinking that a command affecting a group would apply 
> to the group
> > to which the current thread belongs.
> > 
> > This would allow for any command currently applicable to 
> the single process
> > or inferior, to be applied in the same way.  To be honnest, 
> I'm not entirely
> > sure this is a good idea.
> > 
> > Did you guys discuss this?
> 
> Not so much as "discuss". I personally try to avoid 
> introducing more state in MI,
> at all costs. That's why for commands wishing to operate on a 
> given thread group,
> the --thread-group option will be required. Presently, only 
> -exec-continue and
> -exec-interrupt seem to need this, though.

There are a couple of enviroment variables that may apply to a
given thread-group.  I admit that these commands bring
up other questions about how to deal with multi-process
debugging and that I may be bringing this up a little early.
I'll list the commands anyway, but it is just to start the ball
rolling (although I'm sure the ball is rolling already :-))

-file-exec-and-symbols (and the like)
-exec-arguments (DSF uses '-gdb-set args' instead)
-environment-cd
-inferior-tty-set (although this can apply to all inferiors
as we discussed with Dan in a recent thread)
-exec-abort (or kill)

The question of exit code also comes up, although I'm not very
familiar with it, so I don't know how it applies.

This does not look too bad, now that I see it listed :-)

Marc

RE: Re: Multiprocess MI extensions

[Marc Khouzam]

> >> 4. The -list-thread-groups will accept the '--available' 
> option that tells
> >> it to list all thread groups, including those that are not 
> attached to yet.

I assume this will list all top-level thread groups, but not their
chidren, right?

Marc

RE: Re: Multiprocess MI extensions

[Marc Khouzam]

Sorry, I was too quick on this one.

> > >> 4. The -list-thread-groups will accept the '--available' 
> > option that tells
> > >> it to list all thread groups, including those that are not 
> > attached to yet.
> 
> I assume this will list all top-level thread groups, but not their
> chidren, right?

Actually, is the behavior going to be like this:

/*
 *    -list-thread-groups [--available] [GROUP]
 *
 * With no arguments, produces a list of the top-level thread groups to which GDB 
 * is attached.
 * If a group id is specified, produces a list of groups to which GDB is attached
 * and that are children of the specified group.
 * With --available, same as above, but produces a list of all thread groups 
 * instead of only the ones GDB is attached to.
 */

Marc

Re: Multiprocess MI extensions

[Vladimir Prus]

On Tuesday 17 June 2008 23:33:49 Marc Khouzam wrote:
> Sorry, I was too quick on this one.
> 
> > > >> 4. The -list-thread-groups will accept the '--available' 
> > > option that tells
> > > >> it to list all thread groups, including those that are not 
> > > attached to yet.
> > 
> > I assume this will list all top-level thread groups, but not their
> > chidren, right?
> 
> Actually, is the behavior going to be like this:
> 
> /*
>  *    -list-thread-groups [--available] [GROUP]
>  *
>  * With no arguments, produces a list of the top-level thread groups to which GDB 
>  * is attached.
>  * If a group id is specified, produces a list of groups to which GDB is attached
>  * and that are children of the specified group.
>  * With --available, same as above, but produces a list of all thread groups 
>  * instead of only the ones GDB is attached to.
>  */

Right, that's what I meant.

- Volodya

RE: Multiprocess MI extensions

[Marc Khouzam]

As for the output of -list-thread-groups 

>   ^done,result={threads=[<thread>],groups=[<group>]}
> where each thread group is like this:
>   {id="xxx",type="process",pid="yyy",num_children="1"}

I'm not clear on the "threads" part of the output.
Will that part only be filled if we issue 
-list-thread-groups GROUP
where GROUP is a process and therefore only has threads as children?

If that is the case, then "threads" and "groups" cannot both
have content at the same time, right?

Further, I guess this would mean we can use -list-thread-groups
all the time, and no longer use -thread-list-ids?

Is this what you meant?

Thanks

marc


> -----Original Message-----
> From: Vladimir Prus [mailto:vladimir@codesourcery.com]
> Sent: Tuesday, June 17, 2008 3:50 PM
> To: Marc Khouzam
> Cc: gdb@sources.redhat.com
> Subject: Re: Multiprocess MI extensions
> 
> 
> On Tuesday 17 June 2008 23:33:49 Marc Khouzam wrote:
> > Sorry, I was too quick on this one.
> > 
> > > > >> 4. The -list-thread-groups will accept the '--available' 
> > > > option that tells
> > > > >> it to list all thread groups, including those that are not 
> > > > attached to yet.
> > > 
> > > I assume this will list all top-level thread groups, but not their
> > > chidren, right?
> > 
> > Actually, is the behavior going to be like this:
> > 
> > /*
> >  *    -list-thread-groups [--available] [GROUP]
> >  *
> >  * With no arguments, produces a list of the top-level 
> thread groups to which GDB 
> >  * is attached.
> >  * If a group id is specified, produces a list of groups to 
> which GDB is attached
> >  * and that are children of the specified group.
> >  * With --available, same as above, but produces a list of 
> all thread groups 
> >  * instead of only the ones GDB is attached to.
> >  */
> 
> Right, that's what I meant.
> 
> - Volodya
> 

Re: Multiprocess MI extensions

[Vladimir Prus]

On Wednesday 18 June 2008 00:19:06 Marc Khouzam wrote:
> As for the output of -list-thread-groups 
> 
> >   ^done,result={threads=[<thread>],groups=[<group>]}
> > where each thread group is like this:
> >   {id="xxx",type="process",pid="yyy",num_children="1"}
> 
> I'm not clear on the "threads" part of the output.
> Will that part only be filled if we issue 
> -list-thread-groups GROUP
> where GROUP is a process and therefore only has threads as children?
> 
> If that is the case, then "threads" and "groups" cannot both
> have content at the same time, right?

I don't know, and the spec intentionally does not disallow that.
For now, we have only one level of thread groups -- which are processes.
So, in practice, you'll either get 'threads' or 'groups' field. But
I don't know how one might want to group threads in future.

> Further, I guess this would mean we can use -list-thread-groups
> all the time, and no longer use -thread-list-ids?

Yes, this is the intention. In order to support older GDB, you might
want to have fallback code that uses -thread-list-ids.

- Volodya