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 20:14:43 Marc Khouzam wrote:
>
> > -----Original Message-----
> > From: Vladimir Prus [mailto:vladimir@codesourcery.com]
> > Sent: Monday, November 09, 2009 11:29 AM
> > To: Marc Khouzam
> > Cc: 'gdb@sources.redhat.com'
> > Subject: 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.
>
> Sorry, I had not understood from the spec that you would be adding
> thread information to the output to "--availabe"
I'll posted an updated spec later today; it should be more clear.
> > ^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",ar
> > gs=[]},state="running"},
> >
> > I've accidentally left out --available; it should be there.
>
> Ok.
> But that means you are also proposing to support:
> -list-thread-groups --available [group]
>
> I'm just clarifying 'cause that is not suported today.
> If fact, you are also suggesting
> -list-thread-groups --available [group1] [group2] ...
> right?
> are you also suggesting
> -list-thread-groups [group1] [group2] ...
> or not?
It seems to me that all of above should be supported. On the other, including
thread information in output of
-list-thread-groups --available
might be time consuming, so an option to control that behaviour would
be nice.
> > > 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",ar
> > gs=[]},state="running"}}],
> > > threads=[{id="3",group="18", target-id="Thread
> > 0xb7e14b90 (LWP 21257)",cores=[1]
> > >
> > frame={level="0",addr="0xfffff410",func="__kernel_vsyscall",ar
> > gs=[]},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.
>
> But even if a frontend does not support this format now,
> it is still a backwards compatible solution since having
> non-unique fields would only occur in this case when using
> the new multiple-arg form of -list-thread-groups.
>
> Would it be hard to have this concept supported by KDevelop?
> I didn't try it in DSF-GDB, but since we loop over all fields,
> each field, unique or not, should eventually be accessed, so it
> should work quite easily.
It's certainly possible to support, it's a computer after all. However,
the idea of tuple with duplicated fields seems confusing at best.
>
> One could argue that if a frontend cannot handle non-unique
> fields, it should limit itself to issuing multiple
> -list-thread-groups <group>
> and not use the new
> -list-thread-groups <group> ...
>
> > > > 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?
>
> The reason I prefer duplicate field names is that I don't really like
> the idea of having
> -list-thread-groups group1
> have a different output format than
> -list-thread-groups group1 group2
Well, it looks like the options are:
1. Different output from the above commands. It's backward compatible, and
not
hard to support. Also, if you're asking for details on 20 processes, and a couple
of them have disappeared, you have a place to report that processes are no longer.
2. Multiple thread= if details for multiple processes are requested. As I say above,
this is somewhat unclean.
3. Always output groups=[], even for 1-process case.
In fact, option (3) does not seem too bad. Does any frontend available in the
wild make use of thread groups? And 'support 7.0 and later' issue is easily solved
by accepting both groups=[] and threads= in output of 1-process -list-thread-groups.
In fact, we can even put text in the manual to suggest this.
- Volodya