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

[Vladimir Prus <vladimir@codesourcery.com>]

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