From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31448 invoked by alias); 12 Nov 2008 21:17:01 -0000 Received: (qmail 31383 invoked by uid 22791); 12 Nov 2008 21:17:00 -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; Wed, 12 Nov 2008 21:16:23 +0000 Received: (qmail 19819 invoked from network); 12 Nov 2008 21:16:21 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Nov 2008 21:16:21 -0000 From: Vladimir Prus To: Eli Zaretskii Subject: Re: [RFC] MI non-stop and multiprocess docs. Date: Thu, 13 Nov 2008 05:31:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sources.redhat.com References: <200811042214.51102.vladimir@codesourcery.com> <200811122320.28714.vladimir@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811130016.20863.vladimir@codesourcery.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00256.txt.bz2 On Thursday 13 November 2008 00:06:39 Eli Zaretskii wrote: > > From: Vladimir Prus > > Date: Wed, 12 Nov 2008 23:20:28 +0300 > > Cc: gdb-patches@sources.redhat.com > > > > > > > Finally, this chapter seems to be not on design of MI, but more about > > > > > advice to frontend implementors. So I think it should be renamed > > > > > accordingly, and some introductory text added to its beginning saying > > > > > this is the intent of the chapter. > > > > > > > > I don't quite agree. These section describes the main building blocks and > > > > concepts of GDB/MI, and is necessary to understand anything in GDB/MI > > > > docs. > > > > > > Right, but IMO that isn't "MI design", either. > > > > Ok, what title would you suggest? > > "General Aspects of Interacting with GDB/MI"? That's heavy, I think. If you object to "design" then what about: - "GDB/MI General Overview", or - "GDB/MI General Concepts", > > > > > > +that even commands that operate on global state (like global > > > > > > +variables, or breakpoints), still access the target in the context of > > > > > > +a specific thread > > > > > > > > > > What do you mean by "global variables" here? As written, the text > > > > > seems to say that global variables and breakpoints are commands, or > > > > > maybe global state, which doesn't sound right to me. "Breakpoints" > > > > > could be replaced with "breakpoint commands", but I don't know what > > > > > replacement to suggest for "global variables". > > > > > > > > global variables, and breakpoints, are examples of the "global state" > > > > that GDB commands can operate on. > > > > > > What GDB commands operate on global variables? > > > > Say, 'print' and 'set' can operate on global variables. > > Then how about > > even commands that operate on global state, such as @code{print}, > @code{set}, and breakpoint commands, still access the target in the > context of a specific thread. Changed. > > > The new version is fine, except that there are still instances of only > > > one space after a period that ends a sentence. > > > > I've just went though MI section with a regexp, fixing this issue. > > Thanks. One instance still got through: > > > +To allow the user to discover such grouping, and to support arbitrary > > +hierarchy of machines/cores/processes, MI introduces the concept of a > > +@dfn{thread group}. Thread group is a collection of threads and other > > +thread groups. A thread group always has a string identifier, a type, Fixed. - Volodya