This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


 

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Vladimir Prus
> Sent: Monday, November 09, 2009 9:39 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:
> 
> > 
> > > -----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 

Is there currently thread information in the output of "--available"?

> > > -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"},

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

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

Marc


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]