[MI] Extending -list-thread-groups --available to show cores

[MI] Extending -list-thread-groups --available to show cores

[Vladimir Prus]

Current GDB has a MI command -list-thread-groups to nagivate
the hierarchy of the debugged thing. This command also the the
--available option that cause GDB to report the processes that
can be attached to, as opposed to processes currently being
debugged.

We were recently asked to slightly extend the returned information
to include the core where each thread runs. Such information is
of little use for typical Linux application, since threads are
migrated between cores. However, it's useful for both custom 
Linux applications that specifically pin threads to specific cores,
and for embedded systems. Therefore, I plan to add a new field
to the thread information that is output by 
-list-thread-groups --available, named 'core' that will give the
number of the core. E.g.

	-list-thread-groups
	^done,groups=[{id="17",type="process",pid="yyy",num_children="2",cores=[1,2]}]
	-list-thread-groups 17
	^done,threads=[{id="2",target-id="Thread 0xb7e14b90 (LWP 21257)",cores=[1]
	   frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",args=[]},state="running"},

Related to that, it would be somewhat inefficient to issue -list-thread-groups
for every avaialable process to discover the full list of threads on specific
core, so it would be nice to pass several thread groups, like so:

	-list-thread-groups 17 18
	^done,groups=[{id="17", types="process", ..., 
                   threads=[{id="2",target-id="Thread 0xb7e14b90 (LWP 21257)",cores=[1]}]},
			      {id="18", types="process", ..., 

Finally, we were asked to make the *stopped notification to report the core on which
the stop has happened, as additional field.

While those changes seem relatively minor and in line with previous MI developments,
I wanted to pass them here. If there are no objections, I'll work in implementation
during coming weeks.

Thanks,
Volodya

RE: [MI] Extending -list-thread-groups --available to show cores

[Marc Khouzam]

 

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Vladimir Prus
> Sent: Sunday, November 08, 2009 10:05 AM
> To: gdb@sources.redhat.com
> Subject: [MI] Extending -list-thread-groups --available to show cores
> 
> 
> Current GDB has a MI command -list-thread-groups to nagivate
> the hierarchy of the debugged thing. This command also the the
> --available option that cause GDB to report the processes that
> can be attached to, as opposed to processes currently being
> debugged.
> 
> We were recently asked to slightly extend the returned information
> to include the core where each thread runs. Such information is
> of little use for typical Linux application, since threads are
> migrated between cores. However, it's useful for both custom 
> Linux applications that specifically pin threads to specific cores,
> and for embedded systems. Therefore, I plan to add a new field
> to the thread information that is output by 
> -list-thread-groups --available, named 'core' that will give the
> number of the core. E.g.

I assume you didn't mean to restrict this output to the "--available"
form of "-list-thread-groups", but meant to say that it would affect
all forms of "-list-thread-groups", right?


> 	-list-thread-groups
> 	
> ^done,groups=[{id="17",type="process",pid="yyy",num_children="
> 2",cores=[1,2]}]

Nice.

> 	-list-thread-groups 17
> 	^done,threads=[{id="2",target-id="Thread 0xb7e14b90 
> (LWP 21257)",cores=[1]
> frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",ar
> gs=[]},state="running"},

Also nice.
 	   
 
> Related to that, it would be somewhat inefficient to issue 
> -list-thread-groups
> for every avaialable process to discover the full list of 
> threads on specific
> core, so it would be nice to pass several thread groups, like so:
> 
> 	-list-thread-groups 17 18
> 	^done,groups=[{id="17", types="process", ..., 
>                    threads=[{id="2",target-id="Thread 
> 0xb7e14b90 (LWP 21257)",cores=[1]}]},
> 			      {id="18", types="process", ..., 

This is unclear to me.
I see that you are adding the details of the processes before each
process's list of threads.  I guess this is necessary because a
frontend will need to know which process the list of threads belong to,
since the will be multiple list of threads.
But how will that affect the ouput of 
-list-thread-groups 17
which currently does not show the details of the process?  I assume
it will also include the process info?
(BTW, is "types" in that output meant to be "type")


> Finally, we were asked to make the *stopped notification to 
> report the core on which
> the stop has happened, as additional field.

Valuable.

Interesting stuff!

Thanks

Marc

Re: [MI] Extending -list-thread-groups --available to show cores

[Vladimir Prus]

On Monday 09 November 2009 Marc Khouzam wrote:

> 
> > -----Original Message-----
> > From: gdb-owner@sourceware.org 
> > [mailto:gdb-owner@sourceware.org] On Behalf Of Vladimir Prus
> > Sent: Sunday, November 08, 2009 10:05 AM
> > To: gdb@sources.redhat.com
> > Subject: [MI] Extending -list-thread-groups --available to show cores
> > 
> > 
> > Current GDB has a MI command -list-thread-groups to nagivate
> > the hierarchy of the debugged thing. This command also the the
> > --available option that cause GDB to report the processes that
> > can be attached to, as opposed to processes currently being
> > debugged.
> > 
> > We were recently asked to slightly extend the returned information
> > to include the core where each thread runs. Such information is
> > of little use for typical Linux application, since threads are
> > migrated between cores. However, it's useful for both custom 
> > Linux applications that specifically pin threads to specific cores,
> > and for embedded systems. Therefore, I plan to add a new field
> > to the thread information that is output by 
> > -list-thread-groups --available, named 'core' that will give the
> > number of the core. E.g.
> 
> I assume you didn't mean to restrict this output to the "--available"
> form of "-list-thread-groups", but meant to say that it would affect
> all forms of "-list-thread-groups", right?

I actually did mean to restrict to --available ;-) But if 'core'
will be beneficial for ordinary '-list-thread-group', please assume
it's there.


> > Related to that, it would be somewhat inefficient to issue 
> > -list-thread-groups
> > for every avaialable process to discover the full list of 
> > threads on specific
> > core, so it would be nice to pass several thread groups, like so:
> > 
> > 	-list-thread-groups 17 18
> > 	^done,groups=[{id="17", types="process", ..., 
> >                    threads=[{id="2",target-id="Thread 
> > 0xb7e14b90 (LWP 21257)",cores=[1]}]},
> > 			      {id="18", types="process", ..., 
> 
> This is unclear to me.
> I see that you are adding the details of the processes before each
> process's list of threads.  I guess this is necessary because a
> frontend will need to know which process the list of threads belong to,
> since the will be multiple list of threads.
> But how will that affect the ouput of 
> -list-thread-groups 17
> which currently does not show the details of the process?  I assume
> it will also include the process info?
> (BTW, is "types" in that output meant to be "type")

Yes, "types" should be "type". Basically, we have a compatibility issue
here. Now, -list-thread-groups 17 prints only threads in that process.
And if we make '-list -thread-groups 17 18' print only threads in one
list, there will be no way to figure what process each thread belongs to.
We can either:

- add 'process' parent link to each thread
- show groups, with threads inside them, as the above output shows

The second approach seems easier for frontend, since it won't be required
to group threads itself. But it makes the output for '17' and '17 18'
cases be different in structure, so a frontend should be prepared to
both outputs. Does not seem like we can do much better?

Well, we probably can declare that -list-thread-groups is so new that
we can break backward compatibility -- what do you think?

- Volodya

RE: [MI] Extending -list-thread-groups --available to show cores

[Marc Khouzam]

 

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Vladimir Prus
> Sent: Monday, November 09, 2009 9:39 AM
> To: Marc Khouzam
> Cc: 'gdb@sources.redhat.com'
> Subject: Re: [MI] Extending -list-thread-groups --available 
> to show cores
> 
> On Monday 09 November 2009 Marc Khouzam wrote:
> 
> > 
> > > -----Original Message-----
> > > From: gdb-owner@sourceware.org 
> > > [mailto:gdb-owner@sourceware.org] On Behalf Of Vladimir Prus
> > > Sent: Sunday, November 08, 2009 10:05 AM
> > > To: gdb@sources.redhat.com
> > > Subject: [MI] Extending -list-thread-groups --available 
> to show cores
> > > 
> > > 
> > > Current GDB has a MI command -list-thread-groups to nagivate
> > > the hierarchy of the debugged thing. This command also the the
> > > --available option that cause GDB to report the processes that
> > > can be attached to, as opposed to processes currently being
> > > debugged.
> > > 
> > > We were recently asked to slightly extend the returned information
> > > to include the core where each thread runs. Such information is
> > > of little use for typical Linux application, since threads are
> > > migrated between cores. However, it's useful for both custom 
> > > Linux applications that specifically pin threads to 
> specific cores,
> > > and for embedded systems. Therefore, I plan to add a new field
> > > to the thread information that is output by 

Is there currently thread information in the output of "--available"?

> > > -list-thread-groups --available, named 'core' that will give the
> > > number of the core. E.g.
> > 
> > I assume you didn't mean to restrict this output to the 
> "--available"
> > form of "-list-thread-groups", but meant to say that it would affect
> > all forms of "-list-thread-groups", right?
> 
> I actually did mean to restrict to --available ;-) But if 'core'
> will be beneficial for ordinary '-list-thread-group', please assume
> it's there.

It is just that in the original email, the examples you gave were
not for the "--available" case :-)

	-list-thread-groups
	^done,groups=[{id="17",type="process",pid="yyy",num_children="2",cores=[1,2]}]
	-list-thread-groups 17
	^done,threads=[{id="2",target-id="Thread 0xb7e14b90 (LWP 21257)",cores=[1]
	   frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",args=[]},state="running"},

> > > Related to that, it would be somewhat inefficient to issue 
> > > -list-thread-groups
> > > for every avaialable process to discover the full list of 
> > > threads on specific
> > > core, so it would be nice to pass several thread groups, like so:
> > > 
> > > 	-list-thread-groups 17 18
> > > 	^done,groups=[{id="17", types="process", ..., 
> > >                    threads=[{id="2",target-id="Thread 
> > > 0xb7e14b90 (LWP 21257)",cores=[1]}]},
> > > 			      {id="18", types="process", ..., 
> > 
> > This is unclear to me.
> > I see that you are adding the details of the processes before each
> > process's list of threads.  I guess this is necessary because a
> > frontend will need to know which process the list of 
> threads belong to,
> > since the will be multiple list of threads.
> > But how will that affect the ouput of 
> > -list-thread-groups 17
> > which currently does not show the details of the process?  I assume
> > it will also include the process info?
> > (BTW, is "types" in that output meant to be "type")
> 
> Yes, "types" should be "type". Basically, we have a 
> compatibility issue
> here. Now, -list-thread-groups 17 prints only threads in that process.
> And if we make '-list -thread-groups 17 18' print only threads in one
> list, there will be no way to figure what process each thread 
> belongs to.
> We can either:
> 
> 1- add 'process' parent link to each thread
> 2- show groups, with threads inside them, as the above output shows
> 
> The second approach seems easier for frontend, since it won't 
> be required
> to group threads itself. But it makes the output for '17' and '17 18'
> cases be different in structure, so a frontend should be prepared to
> both outputs. Does not seem like we can do much better?

What about #1 and having multiple "threads=", one for each process?
 Something like:

	-list-thread-groups 17 18
	^done,threads=[{id="2",group="17", target-id="Thread 0xb7e14b90 (LWP 21257)",cores=[1]
	   frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",args=[]},state="running"}}],
		threads=[{id="3",group="18", target-id="Thread 0xb7e14b90 (LWP 21257)",cores=[1]
	   frame={level="0",addr="0xfffff410",func="__kernel_vsyscall",args=[]},state="running"}}] 

This would make "-list-thread-groups 17" only get new backwards-compatible fields,
while allowing "-list-thread-groups 17 18" to show threads as part of a grouping.
Does this go against the rules of MI? 

> Well, we probably can declare that -list-thread-groups is so new that
> we can break backward compatibility -- what do you think?

This is tempting.  However, even if no other frontend is using this now,
if a frontend wants to support GDB 7.0 and the next GDB, they would 
need to code for both outputs.  Keeping the output backwards compatible 
will allow future frontends that don't want to use mutliple parameters
to -list-thread-groups to have one way of parsing the output.

Marc

Re: [MI] Extending -list-thread-groups --available to show cores

[Vladimir Prus]

On Monday 09 November 2009 Marc Khouzam wrote:

> > > > We were recently asked to slightly extend the returned information
> > > > to include the core where each thread runs. Such information is
> > > > of little use for typical Linux application, since threads are
> > > > migrated between cores. However, it's useful for both custom 
> > > > Linux applications that specifically pin threads to 
> > specific cores,
> > > > and for embedded systems. Therefore, I plan to add a new field
> > > > to the thread information that is output by 
> 
> Is there currently thread information in the output of "--available"?

No.

> > > > -list-thread-groups --available, named 'core' that will give the
> > > > number of the core. E.g.
> > > 
> > > I assume you didn't mean to restrict this output to the 
> > "--available"
> > > form of "-list-thread-groups", but meant to say that it would affect
> > > all forms of "-list-thread-groups", right?
> > 
> > I actually did mean to restrict to --available ;-) But if 'core'
> > will be beneficial for ordinary '-list-thread-group', please assume
> > it's there.
> 
> It is just that in the original email, the examples you gave were
> not for the "--available" case :-)
> 
> 	-list-thread-groups
> 	^done,groups=[{id="17",type="process",pid="yyy",num_children="2",cores=[1,2]}]
> 	-list-thread-groups 17
> 	^done,threads=[{id="2",target-id="Thread 0xb7e14b90 (LWP 21257)",cores=[1]
> 	   frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",args=[]},state="running"},

I've accidentally left out --available; it should be there.

> > Yes, "types" should be "type". Basically, we have a 
> > compatibility issue
> > here. Now, -list-thread-groups 17 prints only threads in that process.
> > And if we make '-list -thread-groups 17 18' print only threads in one
> > list, there will be no way to figure what process each thread 
> > belongs to.
> > We can either:
> > 
> > 1- add 'process' parent link to each thread
> > 2- show groups, with threads inside them, as the above output shows
> > 
> > The second approach seems easier for frontend, since it won't 
> > be required
> > to group threads itself. But it makes the output for '17' and '17 18'
> > cases be different in structure, so a frontend should be prepared to
> > both outputs. Does not seem like we can do much better?
> 
> What about #1 and having multiple "threads=", one for each process?
>  Something like:
> 
> 	-list-thread-groups 17 18
> 	^done,threads=[{id="2",group="17", target-id="Thread 0xb7e14b90 (LWP 21257)",cores=[1]
> 	   frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",args=[]},state="running"}}],
> 		threads=[{id="3",group="18", target-id="Thread 0xb7e14b90 (LWP 21257)",cores=[1]
> 	   frame={level="0",addr="0xfffff410",func="__kernel_vsyscall",args=[]},state="running"}}] 
> 
> This would make "-list-thread-groups 17" only get new backwards-compatible fields,
> while allowing "-list-thread-groups 17 18" to show threads as part of a grouping.
> Does this go against the rules of MI? 

While there's no explicit rule that names of fields are unique, having them
non-unique sounds a bit hacky to me. E.g. KDevelop parser would not even
be able to access such fields.

> > Well, we probably can declare that -list-thread-groups is so new that
> > we can break backward compatibility -- what do you think?
> 
> This is tempting.  However, even if no other frontend is using this now,
> if a frontend wants to support GDB 7.0 and the next GDB, they would 
> need to code for both outputs.  Keeping the output backwards compatible 
> will allow future frontends that don't want to use mutliple parameters
> to -list-thread-groups to have one way of parsing the output.

Then, maybe we should trick to the output I have originally suggested.
It looks like having the frontend recognize both 'groups' and 'threads'
as top-level element in response is just as good as having duplicate
field names. What do you think?

- Volodya


> 
> Marc
> 
> 

RE: [MI] Extending -list-thread-groups --available to show cores

[Marc Khouzam]

> -----Original Message-----
> From: Vladimir Prus [mailto:vladimir@codesourcery.com] 
> Sent: Monday, November 09, 2009 11:29 AM
> To: Marc Khouzam
> Cc: 'gdb@sources.redhat.com'
> Subject: Re: [MI] Extending -list-thread-groups --available 
> to show cores
> 
> On Monday 09 November 2009 Marc Khouzam wrote:
> 
> > > > > We were recently asked to slightly extend the 
> returned information
> > > > > to include the core where each thread runs. Such 
> information is
> > > > > of little use for typical Linux application, since threads are
> > > > > migrated between cores. However, it's useful for both custom 
> > > > > Linux applications that specifically pin threads to 
> > > specific cores,
> > > > > and for embedded systems. Therefore, I plan to add a new field
> > > > > to the thread information that is output by 
> > 
> > Is there currently thread information in the output of 
> "--available"?
> 
> No.

Sorry, I had not understood from the spec that you would be adding
thread information to the output to "--availabe"

> > > > > -list-thread-groups --available, named 'core' that 
> will give the
> > > > > number of the core. E.g.
> > > > 
> > > > I assume you didn't mean to restrict this output to the 
> > > "--available"
> > > > form of "-list-thread-groups", but meant to say that it 
> would affect
> > > > all forms of "-list-thread-groups", right?
> > > 
> > > I actually did mean to restrict to --available ;-) But if 'core'
> > > will be beneficial for ordinary '-list-thread-group', 
> please assume
> > > it's there.
> > 
> > It is just that in the original email, the examples you gave were
> > not for the "--available" case :-)
> > 
> > 	-list-thread-groups
> > 	
> ^done,groups=[{id="17",type="process",pid="yyy",num_children="
> 2",cores=[1,2]}]
> > 	-list-thread-groups 17
> > 	^done,threads=[{id="2",target-id="Thread 0xb7e14b90 
> (LWP 21257)",cores=[1]
> > 	   
> frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",ar
> gs=[]},state="running"},
> 
> I've accidentally left out --available; it should be there.

Ok.
But that means you are also proposing to support:
-list-thread-groups --available [group]

I'm just clarifying 'cause that is not suported today.
If fact, you are also suggesting
-list-thread-groups --available [group1] [group2] ...
right?
are you also suggesting 
-list-thread-groups [group1] [group2] ...
or not?
 
> > > Yes, "types" should be "type". Basically, we have a 
> > > compatibility issue
> > > here. Now, -list-thread-groups 17 prints only threads in 
> that process.
> > > And if we make '-list -thread-groups 17 18' print only 
> threads in one
> > > list, there will be no way to figure what process each thread 
> > > belongs to.
> > > We can either:
> > > 
> > > 1- add 'process' parent link to each thread
> > > 2- show groups, with threads inside them, as the above 
> output shows
> > > 
> > > The second approach seems easier for frontend, since it won't 
> > > be required
> > > to group threads itself. But it makes the output for '17' 
> and '17 18'
> > > cases be different in structure, so a frontend should be 
> prepared to
> > > both outputs. Does not seem like we can do much better?
> > 
> > What about #1 and having multiple "threads=", one for each process?
> >  Something like:
> > 
> > 	-list-thread-groups 17 18
> > 	^done,threads=[{id="2",group="17", target-id="Thread 
> 0xb7e14b90 (LWP 21257)",cores=[1]
> > 	   
> frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",ar
> gs=[]},state="running"}}],
> > 		threads=[{id="3",group="18", target-id="Thread 
> 0xb7e14b90 (LWP 21257)",cores=[1]
> > 	   
> frame={level="0",addr="0xfffff410",func="__kernel_vsyscall",ar
> gs=[]},state="running"}}] 
> > 
> > This would make "-list-thread-groups 17" only get new 
> backwards-compatible fields,
> > while allowing "-list-thread-groups 17 18" to show threads 
> as part of a grouping.
> > Does this go against the rules of MI? 
> 
> While there's no explicit rule that names of fields are 
> unique, having them
> non-unique sounds a bit hacky to me. E.g. KDevelop parser 
> would not even
> be able to access such fields.

But even if a frontend does not support this format now, 
it is still a  backwards compatible solution since having
non-unique fields would only occur in this case when using
the new multiple-arg form of -list-thread-groups.

Would it be hard to have this concept supported by KDevelop?
I didn't try it in DSF-GDB, but since we loop over all fields,
each field, unique or not, should eventually be accessed, so it
should work quite easily.

One could argue that if a frontend cannot handle non-unique
fields, it should limit itself to issuing multiple
-list-thread-groups <group>
and not use the new
-list-thread-groups <group> ...

> > > Well, we probably can declare that -list-thread-groups is 
> so new that
> > > we can break backward compatibility -- what do you think?
> > 
> > This is tempting.  However, even if no other frontend is 
> using this now,
> > if a frontend wants to support GDB 7.0 and the next GDB, they would 
> > need to code for both outputs.  Keeping the output 
> backwards compatible 
> > will allow future frontends that don't want to use mutliple 
> parameters
> > to -list-thread-groups to have one way of parsing the output.
> 
> Then, maybe we should trick to the output I have originally suggested.
> It looks like having the frontend recognize both 'groups' and 
> 'threads'
> as top-level element in response is just as good as having duplicate
> field names. What do you think?

The reason I prefer duplicate field names is that I don't really like
the idea of having
-list-thread-groups group1
have a different output format than
-list-thread-groups group1 group2

In my opinion, if it is possible, the two should have the same format,
as long as backwards-compatibility can be preserved.

But maybe that is just me?

Marc

RE: [MI] Extending -list-thread-groups --available to show cores

[Marc Khouzam]

 

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Marc Khouzam
> Sent: Monday, November 09, 2009 12:15 PM
> To: 'Vladimir Prus'
> Cc: 'gdb@sources.redhat.com'
> Subject: RE: [MI] Extending -list-thread-groups --available 
> to show cores
> 
> 
> > -----Original Message-----
> > From: Vladimir Prus [mailto:vladimir@codesourcery.com] 
> > Sent: Monday, November 09, 2009 11:29 AM
> > To: Marc Khouzam
> > Cc: 'gdb@sources.redhat.com'
> > Subject: Re: [MI] Extending -list-thread-groups --available 
> > to show cores
> > 
> > On Monday 09 November 2009 Marc Khouzam wrote:
> > 
> > > > > > We were recently asked to slightly extend the 
> > returned information
> > > > > > to include the core where each thread runs. Such 
> > information is
> > > > > > of little use for typical Linux application, since 
> threads are
> > > > > > migrated between cores. However, it's useful for 
> both custom 
> > > > > > Linux applications that specifically pin threads to 
> > > > specific cores,
> > > > > > and for embedded systems. Therefore, I plan to add 
> a new field
> > > > > > to the thread information that is output by 
> > > 
> > > Is there currently thread information in the output of 
> > "--available"?
> > 
> > No.
> 
> Sorry, I had not understood from the spec that you would be adding
> thread information to the output to "--availabe"

I just thought that the -list-thread-group --availabe output is already
very large; if we add threads, it will be huge.  What about adding an option
to indicate if threads should be listed or not?  Like
-list-thread-groups --available [print-details]
where 'print-details' could be different values that would
indicate what kinds of detail level was requested (like 'threads')?

> 
> > > > > > -list-thread-groups --available, named 'core' that 
> > will give the
> > > > > > number of the core. E.g.
> > > > > 
> > > > > I assume you didn't mean to restrict this output to the 
> > > > "--available"
> > > > > form of "-list-thread-groups", but meant to say that it 
> > would affect
> > > > > all forms of "-list-thread-groups", right?
> > > > 
> > > > I actually did mean to restrict to --available ;-) But if 'core'
> > > > will be beneficial for ordinary '-list-thread-group', 
> > please assume
> > > > it's there.
> > > 
> > > It is just that in the original email, the examples you gave were
> > > not for the "--available" case :-)
> > > 
> > > 	-list-thread-groups
> > > 	
> > ^done,groups=[{id="17",type="process",pid="yyy",num_children="
> > 2",cores=[1,2]}]
> > > 	-list-thread-groups 17
> > > 	^done,threads=[{id="2",target-id="Thread 0xb7e14b90 
> > (LWP 21257)",cores=[1]
> > > 	   
> > frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",ar
> > gs=[]},state="running"},
> > 
> > I've accidentally left out --available; it should be there.
> 
> Ok.
> But that means you are also proposing to support:
> -list-thread-groups --available [group]
> 
> I'm just clarifying 'cause that is not suported today.
> If fact, you are also suggesting
> -list-thread-groups --available [group1] [group2] ...
> right?
> are you also suggesting 
> -list-thread-groups [group1] [group2] ...
> or not?
>  
> > > > Yes, "types" should be "type". Basically, we have a 
> > > > compatibility issue
> > > > here. Now, -list-thread-groups 17 prints only threads in 
> > that process.
> > > > And if we make '-list -thread-groups 17 18' print only 
> > threads in one
> > > > list, there will be no way to figure what process each thread 
> > > > belongs to.
> > > > We can either:
> > > > 
> > > > 1- add 'process' parent link to each thread
> > > > 2- show groups, with threads inside them, as the above 
> > output shows
> > > > 
> > > > The second approach seems easier for frontend, since it won't 
> > > > be required
> > > > to group threads itself. But it makes the output for '17' 
> > and '17 18'
> > > > cases be different in structure, so a frontend should be 
> > prepared to
> > > > both outputs. Does not seem like we can do much better?
> > > 
> > > What about #1 and having multiple "threads=", one for 
> each process?
> > >  Something like:
> > > 
> > > 	-list-thread-groups 17 18
> > > 	^done,threads=[{id="2",group="17", target-id="Thread 
> > 0xb7e14b90 (LWP 21257)",cores=[1]
> > > 	   
> > frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",ar
> > gs=[]},state="running"}}],
> > > 		threads=[{id="3",group="18", target-id="Thread 
> > 0xb7e14b90 (LWP 21257)",cores=[1]
> > > 	   
> > frame={level="0",addr="0xfffff410",func="__kernel_vsyscall",ar
> > gs=[]},state="running"}}] 
> > > 
> > > This would make "-list-thread-groups 17" only get new 
> > backwards-compatible fields,
> > > while allowing "-list-thread-groups 17 18" to show threads 
> > as part of a grouping.
> > > Does this go against the rules of MI? 
> > 
> > While there's no explicit rule that names of fields are 
> > unique, having them
> > non-unique sounds a bit hacky to me. E.g. KDevelop parser 
> > would not even
> > be able to access such fields.
> 
> But even if a frontend does not support this format now, 
> it is still a  backwards compatible solution since having
> non-unique fields would only occur in this case when using
> the new multiple-arg form of -list-thread-groups.
> 
> Would it be hard to have this concept supported by KDevelop?
> I didn't try it in DSF-GDB, but since we loop over all fields,
> each field, unique or not, should eventually be accessed, so it
> should work quite easily.
> 
> One could argue that if a frontend cannot handle non-unique
> fields, it should limit itself to issuing multiple
> -list-thread-groups <group>
> and not use the new
> -list-thread-groups <group> ...
> 
> > > > Well, we probably can declare that -list-thread-groups is 
> > so new that
> > > > we can break backward compatibility -- what do you think?
> > > 
> > > This is tempting.  However, even if no other frontend is 
> > using this now,
> > > if a frontend wants to support GDB 7.0 and the next GDB, 
> they would 
> > > need to code for both outputs.  Keeping the output 
> > backwards compatible 
> > > will allow future frontends that don't want to use mutliple 
> > parameters
> > > to -list-thread-groups to have one way of parsing the output.
> > 
> > Then, maybe we should trick to the output I have originally 
> suggested.
> > It looks like having the frontend recognize both 'groups' and 
> > 'threads'
> > as top-level element in response is just as good as having duplicate
> > field names. What do you think?
> 
> The reason I prefer duplicate field names is that I don't really like
> the idea of having
> -list-thread-groups group1
> have a different output format than
> -list-thread-groups group1 group2
> 
> In my opinion, if it is possible, the two should have the same format,
> as long as backwards-compatibility can be preserved.
> 
> But maybe that is just me?
> 
> Marc
> 
> 

Re: [MI] Extending -list-thread-groups --available to show cores

[Vladimir Prus]

On Monday 09 November 2009 20:14:43 Marc Khouzam wrote:

> 
> > -----Original Message-----
> > From: Vladimir Prus [mailto:vladimir@codesourcery.com] 
> > Sent: Monday, November 09, 2009 11:29 AM
> > To: Marc Khouzam
> > Cc: 'gdb@sources.redhat.com'
> > Subject: Re: [MI] Extending -list-thread-groups --available 
> > to show cores
> > 
> > On Monday 09 November 2009 Marc Khouzam wrote:
> > 
> > > > > > We were recently asked to slightly extend the 
> > returned information
> > > > > > to include the core where each thread runs. Such 
> > information is
> > > > > > of little use for typical Linux application, since threads are
> > > > > > migrated between cores. However, it's useful for both custom 
> > > > > > Linux applications that specifically pin threads to 
> > > > specific cores,
> > > > > > and for embedded systems. Therefore, I plan to add a new field
> > > > > > to the thread information that is output by 
> > > 
> > > Is there currently thread information in the output of 
> > "--available"?
> > 
> > No.
> 
> Sorry, I had not understood from the spec that you would be adding
> thread information to the output to "--availabe"

I'll posted an updated spec later today; it should be more clear.
 
> > ^done,groups=[{id="17",type="process",pid="yyy",num_children="
> > 2",cores=[1,2]}]
> > > 	-list-thread-groups 17
> > > 	^done,threads=[{id="2",target-id="Thread 0xb7e14b90 
> > (LWP 21257)",cores=[1]
> > > 	   
> > frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",ar
> > gs=[]},state="running"},
> > 
> > I've accidentally left out --available; it should be there.
> 
> Ok.
> But that means you are also proposing to support:
> -list-thread-groups --available [group]
> 
> I'm just clarifying 'cause that is not suported today.
> If fact, you are also suggesting
> -list-thread-groups --available [group1] [group2] ...
> right?
> are you also suggesting 
> -list-thread-groups [group1] [group2] ...
> or not?

It seems to me that all of above should be supported. On the other, including
thread information in output of

	-list-thread-groups --available

might be time consuming, so an option to control that behaviour would
be nice.

> > > What about #1 and having multiple "threads=", one for each process?
> > >  Something like:
> > > 
> > > 	-list-thread-groups 17 18
> > > 	^done,threads=[{id="2",group="17", target-id="Thread 
> > 0xb7e14b90 (LWP 21257)",cores=[1]
> > > 	   
> > frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",ar
> > gs=[]},state="running"}}],
> > > 		threads=[{id="3",group="18", target-id="Thread 
> > 0xb7e14b90 (LWP 21257)",cores=[1]
> > > 	   
> > frame={level="0",addr="0xfffff410",func="__kernel_vsyscall",ar
> > gs=[]},state="running"}}] 
> > > 
> > > This would make "-list-thread-groups 17" only get new 
> > backwards-compatible fields,
> > > while allowing "-list-thread-groups 17 18" to show threads 
> > as part of a grouping.
> > > Does this go against the rules of MI? 
> > 
> > While there's no explicit rule that names of fields are 
> > unique, having them
> > non-unique sounds a bit hacky to me. E.g. KDevelop parser 
> > would not even
> > be able to access such fields.
> 
> But even if a frontend does not support this format now, 
> it is still a  backwards compatible solution since having
> non-unique fields would only occur in this case when using
> the new multiple-arg form of -list-thread-groups.
> 
> Would it be hard to have this concept supported by KDevelop?
> I didn't try it in DSF-GDB, but since we loop over all fields,
> each field, unique or not, should eventually be accessed, so it
> should work quite easily.

It's certainly possible to support, it's a computer after all. However,
the idea of tuple with duplicated fields seems confusing at best.

> 
> One could argue that if a frontend cannot handle non-unique
> fields, it should limit itself to issuing multiple
> -list-thread-groups <group>
> and not use the new
> -list-thread-groups <group> ...
> 
> > > > Well, we probably can declare that -list-thread-groups is 
> > so new that
> > > > we can break backward compatibility -- what do you think?
> > > 
> > > This is tempting.  However, even if no other frontend is 
> > using this now,
> > > if a frontend wants to support GDB 7.0 and the next GDB, they would 
> > > need to code for both outputs.  Keeping the output 
> > backwards compatible 
> > > will allow future frontends that don't want to use mutliple 
> > parameters
> > > to -list-thread-groups to have one way of parsing the output.
> > 
> > Then, maybe we should trick to the output I have originally suggested.
> > It looks like having the frontend recognize both 'groups' and 
> > 'threads'
> > as top-level element in response is just as good as having duplicate
> > field names. What do you think?
> 
> The reason I prefer duplicate field names is that I don't really like
> the idea of having
> -list-thread-groups group1
> have a different output format than
> -list-thread-groups group1 group2

Well, it looks like the options are:

1. Different output from the above commands. It's backward compatible, and 
not
hard to support. Also, if you're asking for details on 20 processes, and a couple
of them have disappeared, you have a place to report that processes are no longer.

2. Multiple thread= if details for multiple processes are requested. As I say above,
this is somewhat unclean.

3. Always output groups=[], even for 1-process case. 

In fact, option (3) does not seem too bad. Does any frontend available in the
wild make use of thread groups? And 'support 7.0 and later' issue is easily solved
by accepting both groups=[] and threads= in output of 1-process -list-thread-groups.
In fact, we can even put text in the manual to suggest this.

- Volodya

Re: [MI] Extending -list-thread-groups --available to show cores

[Vladimir Prus]

On Monday 16 November 2009 11:28:38 Vladimir Prus wrote:

> 1. Different output from the above commands. It's backward compatible, and 
> not
> hard to support. Also, if you're asking for details on 20 processes, and a couple
> of them have disappeared, you have a place to report that processes are no longer.
> 
> 2. Multiple thread= if details for multiple processes are requested. As I say above,
> this is somewhat unclean.
> 
> 3. Always output groups=[], even for 1-process case. 
> 
> In fact, option (3) does not seem too bad. Does any frontend available in the
> wild make use of thread groups? And 'support 7.0 and later' issue is easily solved
> by accepting both groups=[] and threads= in output of 1-process -list-thread-groups.
> In fact, we can even put text in the manual to suggest this.

While updating the spec, I have realized that (1) is actually not a problem. We already
have different outputs for different -list-thread-groups. If you pass nothing, you
get groups=[] output. If you pass a single group, you get threads= output. Then,
it seems not so bad to make '-list-thread-groups g1 g2' output be the same as
'-list-thread-groups' -- the latter uses groups=[] on top-level exactly because it has
to report several groups.

- Volodya

Re: [MI] Extending -list-thread-groups --available to show cores

[Vladimir Prus]

[-- Attachment #1: Type: Text/Plain, Size: 565 bytes --]

On Sunday 08 November 2009 18:04:31 you wrote:

> 
> Current GDB has a MI command -list-thread-groups to nagivate
> the hierarchy of the debugged thing. This command also the the
> --available option that cause GDB to report the processes that
> can be attached to, as opposed to processes currently being
> debugged.
...
> While those changes seem relatively minor and in line with previous MI developments,
> I wanted to pass them here. If there are no objections, I'll work in implementation
> during coming weeks.

Here's the updated spec. Comments?

- Volodya

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


Core awareness
==============

This document specifies MI extensions to inform the client about cores on
which threads are executed. 

While the mapping from thread to core is volatile for traditional Linux
applications, it can be fixed for Linux application that specifically
pin threads, and is often fixed for embedded systems, and for those cases,
making frontend aware of the mapping would be nice.

The proposed changes affect the 'thread groups' interface, and are as
follows:

1. The output of the --list-thread-groups command will include a new
field, 'cores'. For the 'process' thread group it will a list of all
cores on which threads in that group are currently running. For leafs,
that field should be a list with a single element. The new field will
be output regardless of whether the --available option is specified.

Example:

   -list-thread-groups --available
   ^done,groups=[{id="17",type="process",pid="yyy",num_children="2",cores=[1,2]}]

2. To cut down on the number of roundtrips, the --list-thread-groups without
parameters may optionally recurse into the thread hierarchy. New option, 
'--recurse N' will be used to control that. Originally, N will be required 
to be 1. The --recurse option can be used independelty from the --available
option.

Example:

   -list-thread-groups --available --recurse 1
    ^done,groups=[{id="17", types="process",pid="yyy",num_children="2",cores=[1,2],
                   threads=[{id="1",target-id="Thread 0xb7e14b90",cores=[1]},
                            {id="2",target-id="Thread 0xb7e14b90",cores=[2]}]}]

Note that in case of --available, recursing into thread groups may not be
supported on a given target. In that case, the 'threads' field will be
skipped.

[CONSIDER: Shall -list-target-features report if --available + recurse works?]

3. It will be possible to pass several group ids to --list-thread-groups. In
that case, the output will be identical to that of '-list-thread-groups'
without parameters, except that thread groups that were not listed as
parameters will not be output.

Example:

   -list-thread-groups --available --recurse 1 17 18
    ^done,groups=[{id="17", types="process",pid="yyy",num_children="2",cores=[1,2],
                   threads=[{id="1",target-id="Thread 0xb7e14b90",cores=[1]},
                            {id="2",target-id="Thread 0xb7e14b90",cores=[2]}]}]

4. The *stopped notification will include a new field 'core', giving the core
number on which the breakpoint is hit. This field will only be present if
possible.

RE: [MI] Extending -list-thread-groups --available to show cores

[Marc Khouzam]

 

> -----Original Message-----
> From: Vladimir Prus [mailto:vladimir@codesourcery.com] 
> Sent: Monday, November 16, 2009 5:22 AM
> To: 'gdb@sources.redhat.com'; Marc Khouzam
> Subject: Re: [MI] Extending -list-thread-groups --available 
> to show cores
> 
> On Sunday 08 November 2009 18:04:31 you wrote:
> 
> > 
> > Current GDB has a MI command -list-thread-groups to nagivate
> > the hierarchy of the debugged thing. This command also the the
> > --available option that cause GDB to report the processes that
> > can be attached to, as opposed to processes currently being
> > debugged.
> ...
> > While those changes seem relatively minor and in line with 
> previous MI developments,
> > I wanted to pass them here. If there are no objections, 
> I'll work in implementation
> > during coming weeks.
> 
> Here's the updated spec. Comments?
> 
> Core awareness
> ==============
> 
> This document specifies MI extensions to inform the client about cores on
> which threads are executed. 
> 
> While the mapping from thread to core is volatile for traditional Linux
> applications, it can be fixed for Linux application that specifically
> pin threads, and is often fixed for embedded systems, and for those cases,
> making frontend aware of the mapping would be nice.
> 
> The proposed changes affect the 'thread groups' interface, and are as
> follows:
> 
> 1. The output of the --list-thread-groups command will include a new
> field, 'cores'. For the 'process' thread group it will a list of all
> cores on which threads in that group are currently running. For leafs,
> that field should be a list with a single element. The new field will
> be output regardless of whether the --available option is specified.
> 
> Example:
> 
>    -list-thread-groups --available
>    ^done,groups=[{id="17",type="process",pid="yyy",num_children="2",cores=[1,2]}]

Great.

> 2. To cut down on the number of roundtrips, the --list-thread-groups without
> parameters may optionally recurse into the thread hierarchy. New option, 
> '--recurse N' will be used to control that. Originally, N will be required 
> to be 1. The --recurse option can be used independelty from the --available
> option.
> 
> Example:
> 
>    -list-thread-groups --available --recurse 1
>     ^done,groups=[{id="17", types="process",pid="yyy",num_children="2",cores=[1,2],
>                    threads=[{id="1",target-id="Thread 0xb7e14b90",cores=[1]},
>                             {id="2",target-id="Thread 0xb7e14b90",cores=[2]}]}]

Very nice and forward thinking.

> Note that in case of --available, recursing into thread groups may not be
> supported on a given target. In that case, the 'threads' field will be
> skipped.

The doc should indicate that a frontend should not assume the presence of "threads="
even when using --recurse.


> [CONSIDER: Shall -list-target-features report if --available + recurse works?]

Say a target does not support this, do you forsee a performance impact if the 
frontend still uses --recurse in this case?  If not, then a frontend could
figure out if this is supported by looking at the result of the command.  I think
that would be enough.  

In fact, if there is a performance impact, a frontend could stop using "--recurse"
when it first noticed the missing "thread=" from the output.  But in that case, 
using -list-target-features would be more elegant.

That being say, it won't hurt any FEs if -list-target-features did report this
anyway.  (In Eclipse, we don't use -list-target-features yet because we've focused
on Linux targets, but I think we should improved the support of other targets by 
using -list-target-features.)
 
> 3. It will be possible to pass several group ids to --list-thread-groups. In
> that case, the output will be identical to that of '-list-thread-groups'
> without parameters, except that thread groups that were not listed as
> parameters will not be output.

For clarity, there should be a point 2.5 which says that the --available option
will now be allowed for --list-thread-groups with parameters.  I like this
addition which will allow to get information about an individual process without
having to list all available processes.

As for the output format, you have convinced me.
However, I suggest the doc clearly indicates that when using the single-parameter 
form of --list-thread-groups the output will not contain the "group=" field.
I think this could become an FAQ kind of FE problem :-)
 
> Example:
> 
>    -list-thread-groups --available --recurse 1 17 18
>     ^done,groups=[{id="17", types="process",pid="yyy",num_children="2",cores=[1,2],
>                    threads=[{id="1",target-id="Thread 0xb7e14b90",cores=[1]},
>                             {id="2",target-id="Thread 0xb7e14b90",cores=[2]}]}]

Above it says that "--recurse" is for -list-thread-groups without parameters.
I guess the example should be 
-list-thread-groups --available 17 18
Would using --recurse here cause an error, or be ignored?

> 4. The *stopped notification will include a new field 'core', giving the core
> number on which the breakpoint is hit. This field will only be present if
> possible.

My favorite :-)

Good stuff!

Thanks

Marc

Re: [MI] Extending -list-thread-groups --available to show cores

[Vladimir Prus]

[-- Attachment #1: Type: Text/Plain, Size: 6093 bytes --]

On Monday 16 November 2009 17:51:36 Marc Khouzam wrote:

> 
> > -----Original Message-----
> > From: Vladimir Prus [mailto:vladimir@codesourcery.com] 
> > Sent: Monday, November 16, 2009 5:22 AM
> > To: 'gdb@sources.redhat.com'; Marc Khouzam
> > Subject: Re: [MI] Extending -list-thread-groups --available 
> > to show cores
> > 
> > On Sunday 08 November 2009 18:04:31 you wrote:
> > 
> > > 
> > > Current GDB has a MI command -list-thread-groups to nagivate
> > > the hierarchy of the debugged thing. This command also the the
> > > --available option that cause GDB to report the processes that
> > > can be attached to, as opposed to processes currently being
> > > debugged.
> > ...
> > > While those changes seem relatively minor and in line with 
> > previous MI developments,
> > > I wanted to pass them here. If there are no objections, 
> > I'll work in implementation
> > > during coming weeks.
> > 
> > Here's the updated spec. Comments?
> > 
> > Core awareness
> > ==============
> > 
> > This document specifies MI extensions to inform the client about cores on
> > which threads are executed. 
> > 
> > While the mapping from thread to core is volatile for traditional Linux
> > applications, it can be fixed for Linux application that specifically
> > pin threads, and is often fixed for embedded systems, and for those cases,
> > making frontend aware of the mapping would be nice.
> > 
> > The proposed changes affect the 'thread groups' interface, and are as
> > follows:
> > 
> > 1. The output of the --list-thread-groups command will include a new
> > field, 'cores'. For the 'process' thread group it will a list of all
> > cores on which threads in that group are currently running. For leafs,
> > that field should be a list with a single element. The new field will
> > be output regardless of whether the --available option is specified.
> > 
> > Example:
> > 
> >    -list-thread-groups --available
> >    ^done,groups=[{id="17",type="process",pid="yyy",num_children="2",cores=[1,2]}]
> 
> Great.
> 
> > 2. To cut down on the number of roundtrips, the --list-thread-groups without
> > parameters may optionally recurse into the thread hierarchy. New option, 
> > '--recurse N' will be used to control that. Originally, N will be required 
> > to be 1. The --recurse option can be used independelty from the --available
> > option.
> > 
> > Example:
> > 
> >    -list-thread-groups --available --recurse 1
> >     ^done,groups=[{id="17", types="process",pid="yyy",num_children="2",cores=[1,2],
> >                    threads=[{id="1",target-id="Thread 0xb7e14b90",cores=[1]},
> >                             {id="2",target-id="Thread 0xb7e14b90",cores=[2]}]}]
> 
> Very nice and forward thinking.
> 
> > Note that in case of --available, recursing into thread groups may not be
> > supported on a given target. In that case, the 'threads' field will be
> > skipped.
> 
> The doc should indicate that a frontend should not assume the presence of "threads="
> even when using --recurse.

Sure.

> > [CONSIDER: Shall -list-target-features report if --available + recurse works?]
> 
> Say a target does not support this, do you forsee a performance impact if the 
> frontend still uses --recurse in this case?  If not, then a frontend could
> figure out if this is supported by looking at the result of the command.  I think
> that would be enough.  
> 
> In fact, if there is a performance impact, a frontend could stop using "--recurse"
> when it first noticed the missing "thread=" from the output.  But in that case, 
> using -list-target-features would be more elegant.
> 
> That being say, it won't hurt any FEs if -list-target-features did report this
> anyway.  (In Eclipse, we don't use -list-target-features yet because we've focused
> on Linux targets, but I think we should improved the support of other targets by 
> using -list-target-features.)

I don't think that there's any perfomance impact for getting --recurse when
it's not supported. And on the other hand, there's some trickery involved
in reporting --recurse support, specifically over a remote connection.
I'm gonna skip this for now, unless a real need to test for this up-front
will surface.

>  
> > 3. It will be possible to pass several group ids to --list-thread-groups. In
> > that case, the output will be identical to that of '-list-thread-groups'
> > without parameters, except that thread groups that were not listed as
> > parameters will not be output.
> 
> For clarity, there should be a point 2.5 which says that the --available option
> will now be allowed for --list-thread-groups with parameters.  I like this
> addition which will allow to get information about an individual process without
> having to list all available processes.

I've added this clarification to (3)

> 
> As for the output format, you have convinced me.
> However, I suggest the doc clearly indicates that when using the single-parameter 
> form of --list-thread-groups the output will not contain the "group=" field.
> I think this could become an FAQ kind of FE problem :-)

I've added a note to that effect in the spec.
>  
> > Example:
> > 
> >    -list-thread-groups --available --recurse 1 17 18
> >     ^done,groups=[{id="17", types="process",pid="yyy",num_children="2",cores=[1,2],
> >                    threads=[{id="1",target-id="Thread 0xb7e14b90",cores=[1]},
> >                             {id="2",target-id="Thread 0xb7e14b90",cores=[2]}]}]
> 
> Above it says that "--recurse" is for -list-thread-groups without parameters.
> I guess the example should be 
> -list-thread-groups --available 17 18
> Would using --recurse here cause an error, or be ignored?

In fact, I did not meant to prohibit --available + --recurse + several groups. I've
adjust the wording above.

> > 4. The *stopped notification will include a new field 'core', giving the core
> > number on which the breakpoint is hit. This field will only be present if
> > possible.
> 
> My favorite :-)

Not mine, implementation-wize, but well ;-)

Here's a new revision.

- Volodya


> 
> Good stuff!
> 
> Thanks
> 
> Marc
> 

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


Core awareness
==============

This document specifies MI extensions to inform the client about cores on
which threads are executed. 

While the mapping from thread to core is volatile for traditional Linux
applications, it can be fixed for Linux application that specifically
pin threads, and is often fixed for embedded systems, and for those cases,
making frontend aware of the mapping would be nice.

The proposed changes affect the 'thread groups' interface, and are as
follows:

1. The output of the --list-thread-groups command will include a new
field, 'cores'. For the 'process' thread group it will a list of all
cores on which threads in that group are currently running. For leafs,
that field should be a list with a single element. The new field will
be output regardless of whether the --available option is specified.

Example:

   -list-thread-groups --available
   ^done,groups=[{id="17",type="process",pid="yyy",num_children="2",cores=[1,2]}]

2. To cut down on the number of roundtrips, the --list-thread-groups without
parameters may optionally recurse into the thread hierarchy. New option, 
'--recurse N' will be used to control that. Originally, N will be required 
to be 1. The --recurse option can be used independelty from the --available
option.

Example:

   -list-thread-groups --available --recurse 1
    ^done,groups=[{id="17", types="process",pid="yyy",num_children="2",cores=[1,2],
                   threads=[{id="1",target-id="Thread 0xb7e14b90",cores=[1]},
                            {id="2",target-id="Thread 0xb7e14b90",cores=[2]}]}]

Note that when --available is specified together with --recurse, some targets
may not be able to honor the request. In that case, the 'threads' field will be
absent from the output. The frontend should be prepared to handle this situation.

[CONSIDER: Shall -list-target-features report if --available + recurse works?]

3. It will be possible to pass several group ids to --list-thread-groups. In
that case, the output will be identical to that of '-list-thread-groups'
without parameters, except that thread groups that were not listed as
parameters will not be output. This will be allowed both with and without
--available and --recurse.

Example:

   -list-thread-groups --available --recurse 1 17 18
    ^done,groups=[{id="17", types="process",pid="yyy",num_children="2",cores=[1,2],
                   threads=[{id="1",target-id="Thread 0xb7e14b90",cores=[1]},
                            {id="2",target-id="Thread 0xb7e14b90",cores=[2]}]}]


[NOTE: explicitly mention in the manual that output when either no thread
group is specified, or >1 thread group is specified has 'groups' as top-level
element, while output when one group is specified has just 'threads' element
at the top level]

4. The *stopped notification will include a new field 'core', giving the core
number on which the breakpoint is hit. This field will only be present if
possible.

RE: [MI] Extending -list-thread-groups --available to show cores

[Marc Khouzam]

 

> -----Original Message-----
> From: Vladimir Prus [mailto:vladimir@codesourcery.com] 
> Sent: Tuesday, November 17, 2009 2:44 AM
>

[...]

> > > [CONSIDER: Shall -list-target-features report if 
> --available + recurse works?]
> > 
> > Say a target does not support this, do you forsee a 
> performance impact if the 
> > frontend still uses --recurse in this case?  If not, then a 
> frontend could
> > figure out if this is supported by looking at the result of 
> the command.  I think
> > that would be enough.  
> > 
> > In fact, if there is a performance impact, a frontend could 
> stop using "--recurse"
> > when it first noticed the missing "thread=" from the 
> output.  But in that case, 
> > using -list-target-features would be more elegant.
> > 
> > That being say, it won't hurt any FEs if 
> -list-target-features did report this
> > anyway.  (In Eclipse, we don't use -list-target-features 
> yet because we've focused
> > on Linux targets, but I think we should improved the 
> support of other targets by 
> > using -list-target-features.)
> 
> I don't think that there's any perfomance impact for getting 
> --recurse when
> it's not supported. And on the other hand, there's some 
> trickery involved
> in reporting --recurse support, specifically over a remote connection.
> I'm gonna skip this for now, unless a real need to test for 
> this up-front will surface.

Sounds good to me.

[...]

> > > Example:
> > > 
> > >    -list-thread-groups --available --recurse 1 17 18
> > >     ^done,groups=[{id="17", 
> types="process",pid="yyy",num_children="2",cores=[1,2],
> > >                    threads=[{id="1",target-id="Thread 
> 0xb7e14b90",cores=[1]},
> > >                             {id="2",target-id="Thread 
> 0xb7e14b90",cores=[2]}]}]
> > 
> > Above it says that "--recurse" is for -list-thread-groups 
> without parameters.
> > I guess the example should be 
> > -list-thread-groups --available 17 18
> > Would using --recurse here cause an error, or be ignored?
> 
> In fact, I did not meant to prohibit --available + --recurse 
> + several groups. I've adjust the wording above.

So, all combinations are allowed.  That is great.
My last comment on the new revision.  It stills says:
"2. To cut down on the number of roundtrips, the 
    --list-thread-groups without parameters may optionally 
                         ^^^^^^^^^^^^^^^^^^
    recurse into the thread hierarchy"

It shouldn't say "without parameters", since --recurse
will be allowed all the time.

Thanks

Marc