[MI] Extending -list-thread-groups --available to show cores
Marc Khouzam
marc.khouzam@ericsson.com
Thu Nov 19 07:11:00 GMT 2009
> -----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
More information about the Gdb
mailing list