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

Marc Khouzam
2009-11-09T14:25:48Z

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