This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [MI] Extending -list-thread-groups --available to show cores
On Monday 09 November 2009 Marc Khouzam wrote:
>
> > -----Original Message-----
> > From: gdb-owner@sourceware.org
> > [mailto:gdb-owner@sourceware.org] On Behalf Of Vladimir Prus
> > Sent: Sunday, November 08, 2009 10:05 AM
> > To: gdb@sources.redhat.com
> > Subject: [MI] Extending -list-thread-groups --available to show cores
> >
> >
> > 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.
> >
> > We were recently asked to slightly extend the returned information
> > to include the core where each thread runs. Such information is
> > of little use for typical Linux application, since threads are
> > migrated between cores. However, it's useful for both custom
> > Linux applications that specifically pin threads to specific cores,
> > and for embedded systems. Therefore, I plan to add a new field
> > to the thread information that is output by
> > -list-thread-groups --available, named 'core' that will give the
> > number of the core. E.g.
>
> I assume you didn't mean to restrict this output to the "--available"
> form of "-list-thread-groups", but meant to say that it would affect
> all forms of "-list-thread-groups", right?
I actually did mean to restrict to --available ;-) But if 'core'
will be beneficial for ordinary '-list-thread-group', please assume
it's there.
> > Related to that, it would be somewhat inefficient to issue
> > -list-thread-groups
> > for every avaialable process to discover the full list of
> > threads on specific
> > core, so it would be nice to pass several thread groups, like so:
> >
> > -list-thread-groups 17 18
> > ^done,groups=[{id="17", types="process", ...,
> > threads=[{id="2",target-id="Thread
> > 0xb7e14b90 (LWP 21257)",cores=[1]}]},
> > {id="18", types="process", ...,
>
> This is unclear to me.
> I see that you are adding the details of the processes before each
> process's list of threads. I guess this is necessary because a
> frontend will need to know which process the list of threads belong to,
> since the will be multiple list of threads.
> But how will that affect the ouput of
> -list-thread-groups 17
> which currently does not show the details of the process? I assume
> it will also include the process info?
> (BTW, is "types" in that output meant to be "type")
Yes, "types" should be "type". Basically, we have a compatibility issue
here. Now, -list-thread-groups 17 prints only threads in that process.
And if we make '-list -thread-groups 17 18' print only threads in one
list, there will be no way to figure what process each thread belongs to.
We can either:
- add 'process' parent link to each thread
- show groups, with threads inside them, as the above output shows
The second approach seems easier for frontend, since it won't be required
to group threads itself. But it makes the output for '17' and '17 18'
cases be different in structure, so a frontend should be prepared to
both outputs. Does not seem like we can do much better?
Well, we probably can declare that -list-thread-groups is so new that
we can break backward compatibility -- what do you think?
- Volodya