From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12048 invoked by alias); 11 Jun 2008 16:40:29 -0000 Received: (qmail 12037 invoked by uid 22791); 11 Jun 2008 16:40:28 -0000 X-Spam-Check-By: sourceware.org Received: from mail.windriver.com (HELO mail.wrs.com) (147.11.1.11) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 11 Jun 2008 16:40:06 +0000 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m5BGdW4f014914; Wed, 11 Jun 2008 09:39:32 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 09:39:31 -0700 Received: from [147.11.233.14] ([147.11.233.14]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 09:39:31 -0700 Message-ID: <484FFFC3.5000806@windriver.com> Date: Wed, 11 Jun 2008 16:40:00 -0000 From: Pawel Piech User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: Vladimir Prus CC: gdb@sources.redhat.com Subject: Re: Multiprocess MI extensions References: <200806102323.48023.vladimir@codesourcery.com> <484ED90D.2010602@windriver.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00096.txt.bz2 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=[],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? > > 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 >