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


> 	-list-thread-groups
> 	
> ^done,groups=[{id="17",type="process",pid="yyy",num_children="
> 2",cores=[1,2]}]

Nice.

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

Also nice.
 	   
 
> 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")


> Finally, we were asked to make the *stopped notification to 
> report the core on which
> the stop has happened, as additional field.

Valuable.

Interesting stuff!

Thanks

Marc


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