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:
> > > > 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
>
> Is there currently thread information in the output of "--available"?
No.
> > > > -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.
>
> It is just that in the original email, the examples you gave were
> not for the "--available" case :-)
>
> -list-thread-groups
> ^done,groups=[{id="17",type="process",pid="yyy",num_children="2",cores=[1,2]}]
> -list-thread-groups 17
> ^done,threads=[{id="2",target-id="Thread 0xb7e14b90 (LWP 21257)",cores=[1]
> frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",args=[]},state="running"},
I've accidentally left out --available; it should be there.
> > 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:
> >
> > 1- add 'process' parent link to each thread
> > 2- 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?
>
> What about #1 and having multiple "threads=", one for each process?
> Something like:
>
> -list-thread-groups 17 18
> ^done,threads=[{id="2",group="17", target-id="Thread 0xb7e14b90 (LWP 21257)",cores=[1]
> frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",args=[]},state="running"}}],
> threads=[{id="3",group="18", target-id="Thread 0xb7e14b90 (LWP 21257)",cores=[1]
> frame={level="0",addr="0xfffff410",func="__kernel_vsyscall",args=[]},state="running"}}]
>
> This would make "-list-thread-groups 17" only get new backwards-compatible fields,
> while allowing "-list-thread-groups 17 18" to show threads as part of a grouping.
> Does this go against the rules of MI?
While there's no explicit rule that names of fields are unique, having them
non-unique sounds a bit hacky to me. E.g. KDevelop parser would not even
be able to access such fields.
> > Well, we probably can declare that -list-thread-groups is so new that
> > we can break backward compatibility -- what do you think?
>
> This is tempting. However, even if no other frontend is using this now,
> if a frontend wants to support GDB 7.0 and the next GDB, they would
> need to code for both outputs. Keeping the output backwards compatible
> will allow future frontends that don't want to use mutliple parameters
> to -list-thread-groups to have one way of parsing the output.
Then, maybe we should trick to the output I have originally suggested.
It looks like having the frontend recognize both 'groups' and 'threads'
as top-level element in response is just as good as having duplicate
field names. What do you think?
- Volodya
>
> Marc
>
>