From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6209 invoked by alias); 10 Jun 2008 19:24:20 -0000 Received: (qmail 6198 invoked by uid 22791); 10 Jun 2008 19:24:19 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 10 Jun 2008 19:24:01 +0000 Received: (qmail 9355 invoked from network); 10 Jun 2008 19:23:59 -0000 Received: from unknown (HELO 172.16.unknown.plus.ru) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Jun 2008 19:23:59 -0000 From: Vladimir Prus To: gdb@sources.redhat.com Subject: Multiprocess MI extensions Date: Tue, 10 Jun 2008 19:24:00 -0000 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_ETtTIfPfvCdOyhu" Message-Id: <200806102323.48023.vladimir@codesourcery.com> 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/msg00080.txt.bz2 --Boundary-00=_ETtTIfPfvCdOyhu Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 243 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 --Boundary-00=_ETtTIfPfvCdOyhu Content-Type: text/plain; charset="utf-8"; name="multiprocess-mi.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="multiprocess-mi.txt" Content-length: 3312 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. -> 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? -> Should we have just =created and =exited notifications, used for threads and processes and what not? --Boundary-00=_ETtTIfPfvCdOyhu--