This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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: core-mi.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]