This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Multiprocess MI extensions
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?
>> -> 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?
- Volodya