From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5290 invoked by alias); 29 Apr 2010 17:54:40 -0000 Received: (qmail 5282 invoked by uid 22791); 29 Apr 2010 17:54:39 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Apr 2010 17:54:34 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L1N00D00GB9DV00@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Thu, 29 Apr 2010 20:54:31 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.127.125.239]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L1N007N0GET1CF0@a-mtaout20.012.net.il>; Thu, 29 Apr 2010 20:54:30 +0300 (IDT) Date: Thu, 29 Apr 2010 17:54:00 -0000 From: Eli Zaretskii Subject: Re: [RFC] Observer mode In-reply-to: <4BD9C057.9090805@codesourcery.com> To: Stan Shebs Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <834oiuxhyh.fsf@gnu.org> References: <4BD9C057.9090805@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: 2010-04/txt/msg00962.txt.bz2 > Date: Thu, 29 Apr 2010 10:22:31 -0700 > From: Stan Shebs > > + @node Observation Mode > + @subsection Observation Mode A suitable index entry would be good here. > + When all of these are set to @code{off}, then @value{GDBN} is said > + to be @dfn{observation mode}. "in observation mode", I presume. Also, the above sentence is ambiguous: it took me a while to understand that "all of these" refer to the settings described in this section. Please say that explicitly. > + combinations of these settings. For instance, if you have enabled ^^ Need two spaces here (and in a few other places in the patch). > + @itemx set may-write-memory off > + This controls whether @value{GDBN} will attempt to alter the contents > + of memory, such as with assignment expressions in @code{print}. This is also relevant to setting breakpoints, right? If so, I suggest to mention them. > + Otherwise, any sort of write attempt will result in an error."), Is this useful behavior? I'd assume that setting these to off would silently fail the operation. Otherwise, how would these settings be useful? They exist to allow uninterrupted program run, don't they? > + error ("No tracepoints downloaded, not starting trace"); No _() around a message here. Thanks.