From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17369 invoked by alias); 10 Jun 2008 19:42:38 -0000 Received: (qmail 17361 invoked by uid 22791); 10 Jun 2008 19:42:37 -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; Tue, 10 Jun 2008 19:42:09 +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 m5AJg7eA026812 for ; Tue, 10 Jun 2008 12:42:07 -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); Tue, 10 Jun 2008 12:42:07 -0700 Received: from [147.11.233.84] ([147.11.233.84]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 12:42:08 -0700 Message-ID: <484ED90D.2010602@windriver.com> Date: Tue, 10 Jun 2008 19:42:00 -0000 From: Pawel Piech User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: Re: Multiprocess MI extensions References: <200806102323.48023.vladimir@codesourcery.com> In-Reply-To: <200806102323.48023.vladimir@codesourcery.com> 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/msg00082.txt.bz2 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. > -> 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. > -> 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. Cheers, Pawel