Re: Multiprocess MI extensions

[Pawel Piech <pawel.piech@windriver.com>]

Thank you Vladimir, the proposal seems very reasonable :-) and 
considerate of backward compatibility,
Couple of comments below:

Vladimir Prus wrote:
> Attached is the draft of the proposed MI changes to support multi-process
> debugging. I think the changes are fairly small, and are generic enough
> to support, in future, any hierarchy of processes/cores/boards/universes.
> Comments?
>
> - Volodya
>
>   
> ------------------------------------------------------------------------
>
>
> Functional requirements
> =======================
>
> 1. Attaching and detaching to processes
>
> 2. Listing available processes
>
> 3. Listing attached processes
>
> 4. Listing threads in all processes (or in a specific process?)
>
> 5. Process termination report.
>
> Discussion
> ==========
>
> We want frontend changes to be minimal. Towards this goal, we can treat
> multi-process session as merely a collection of threads, with processes
> presented just as named group of threads without much smarts. Specifically:
>
> - There will be global numbering of threads across all processes
> - There will be no notion of current process. The current thread
> will be global to a session, as opposed to having a current thread
> per each process.
>
> We want to have a flexible grouping of threads, as there might be, in
> future, different levels of organization than processes, both more higher
> level (systems) and more low level (individual cores). To that end, we'll
> introduce a notion of 'thread group', that has identifier, and can contain
> either futher groups or individual threads.
>
> Design
> ======
>
> 1. Obtaining hierarchy.
>
> New command -list-thread-groups will be introduced, that returns either
> returns the list of top-level thread groups, or the list of thread groups
> that are children of a specified group. The output is:
>
>   ^done,result={threads=[<thread>],groups=[<group>]}
>
> where each thread group is like this:
>
>    {id="xxx",type="process",pid="yyy",num_children="1"}
>
> The id of a thread group should be considered an opaque string.
>
> -> Should we just dump the entire tree in one go, without requiring
> that frontend traverses the entire hierarchy? Maybe not, since on
> multi-board configuration, getting the list of all process might be
> slow.
>
> 2. Whenever printing a thread, if that thread is part of some group,
> a 'parent' field will be printed, with value been the id of the thread
> group.
>
> 3. The -exec-continue and -exec-interrupt commands, as part of non-stop
> work, got the --all parameter to tell them to act on all threads. To
> allow interruping just one process, they will get a --thread-group
> option. The value of this option is either an id of a thread group,
> or a special value 'all'. For now, no other commands seem to need
> this option, but such a need might arise in future -- for example,
> to set per-process breakpoints.
>
> 4. The -list-thread-groups will accept the '--available' option that tells
> it to list all thread groups, including those that are not attached to yet.
> There will be a --thread-group-attach command, accept an id of a thread
> group, and attaches to it.  There will be --thread-group-detach command,
> acceping an id of a thread group and detaching from said thread group.
>
> -> Should we allow to attach a specific process using pid, assuming user
> has some magic way to get at pid? Probably yes, so that a frontend is
> not forced to implement searching through gdb-reported process list.
>
> 5. The *running and *stopped notifications, instead of 'thread' field,
> may include 'thread-group' field.
>   
I would suggest to reserve the thread field to indicate the triggering 
thread, even if the whole process stops.
> -> How to report process exit? Should we overload =thread-exited, introduce
> =thread-group-exited, or what? 
>
> -> Should we auto-attach to newly forked processes? Should we have
>  =new-thread-group notificatin, if so?
>   
Auto attach should probably be an option, but if there is an auto 
attach, a notification should definitely be generated.
> -> Should we have just =created and =exited notifications, used for threads
> and processes and what not?
>   
I don't think it makes much difference whether the same event is used or 
not as long as a parent-id field is included in the event.

Cheers,
Pawel