Re: Multiprocess MI extensions

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

Vladimir Prus wrote:
> Pawel Piech wrote:
>
>   
>> 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.
>>     
>
> It's possible. Are you going to use the triggered thread id to select it
> in UI?
>
>   
That's correct. 
>>> -> 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.
>>     
>
> OK.
>
>   
>>> -> 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.
>>     
>
> Just to make sure we're on the same page -- if we use one notification for everything,
> it will either have a 'thread' field -- when a thread is created/exited, or 'thread-group'
> field, when  process is created/exited. Is that OK?
>
>   
Yes, that's fine.  A more forward looking alternative would be to have a 
consistent id field and a type field which would indicate whether it's a 
group, thread, etc.

Cheers,
Pawel

> - Volodya
>