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

[Marc Khouzam <marc dot khouzam at ericsson dot com>]

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