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

Vladimir Prus vladimir@codesourcery.com
Thu Nov 19 06:44:00 GMT 2009


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

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.



More information about the Gdb mailing list