From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23847 invoked by alias); 10 Jun 2008 19:53:14 -0000 Received: (qmail 23835 invoked by uid 22791); 10 Jun 2008 19:53:12 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 10 Jun 2008 19:52:53 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1K69th-00066M-OT for gdb@sources.redhat.com; Tue, 10 Jun 2008 19:52:49 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Jun 2008 19:52:49 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Jun 2008 19:52:49 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: Multiprocess MI extensions Date: Tue, 10 Jun 2008 19:53:00 -0000 Message-ID: References: <200806102323.48023.vladimir@codesourcery.com> <484ED90D.2010602@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00084.txt.bz2 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=[],groups=[]} >> >> 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