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: Multiprocess MI extensions


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



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