From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16393 invoked by alias); 12 Nov 2008 21:07:37 -0000 Received: (qmail 16120 invoked by uid 22791); 12 Nov 2008 21:07:30 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout4.012.net.il (HELO mtaout4.012.net.il) (84.95.2.10) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 12 Nov 2008 21:06:45 +0000 Received: from conversion-daemon.i_mtaout4.012.net.il by i_mtaout4.012.net.il (HyperSendmail v2004.12) id <0KA800B00NTHN600@i_mtaout4.012.net.il> for gdb-patches@sources.redhat.com; Wed, 12 Nov 2008 23:08:33 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.205.49]) by i_mtaout4.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KA800FVHO1ZGCN0@i_mtaout4.012.net.il>; Wed, 12 Nov 2008 23:08:33 +0200 (IST) Date: Thu, 13 Nov 2008 04:15:00 -0000 From: Eli Zaretskii Subject: Re: [RFC] MI non-stop and multiprocess docs. In-reply-to: <200811122320.28714.vladimir@codesourcery.com> X-012-Sender: halo1@inter.net.il To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Reply-to: Eli Zaretskii Message-id: References: <200811042214.51102.vladimir@codesourcery.com> <200811122020.33905.vladimir@codesourcery.com> <200811122320.28714.vladimir@codesourcery.com> X-IsSubscribed: yes 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/msg00254.txt.bz2 > 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"? > > > I think they are very similar from frontend point of view -- in that frontend > > > does only minimal processing of those notification, and won't break if they > > > are not emitted. > > > > That's okay, but it looks to me that after listing 3 items, it is best > > to have 3 @items, not 2. > > I'm confused. There are 3 @items in that @itemize block. What change do you > want to me do? Never mind, the last revision is OK. > > > > > +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. > > 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, ^^^