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

[Vladimir Prus <vladimir@codesourcery.com>]

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