From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27507 invoked by alias); 3 Oct 2012 20:14:02 -0000 Received: (qmail 27447 invoked by uid 22791); 3 Oct 2012 20:14:00 -0000 X-SWARE-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from elasmtp-masked.atl.sa.earthlink.net (HELO elasmtp-masked.atl.sa.earthlink.net) (209.86.89.68) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Oct 2012 20:13:56 +0000 Received: from [68.96.200.16] (helo=macbook2.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TJVKM-0005pl-UT; Wed, 03 Oct 2012 16:13:55 -0400 Message-ID: <506C9C7D.50806@earthlink.net> Date: Wed, 03 Oct 2012 20:14:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dmitry Kozlov CC: gdb@sourceware.org, Vladimir Prus , Luis Machado , "'Stan_Shebs@mentor.com'" , Marc Khouzam Subject: Re: question on trace-stop-notes implementation References: <506C3395.8010701@mentor.com> In-Reply-To: <506C3395.8010701@mentor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da94021014c45b467e69b3977e90cb21710a7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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: 2012-10/txt/msg00036.txt.bz2 On 10/3/12 5:46 AM, Dmitry Kozlov wrote: > Hello, > I noticed that trace-stop-notes being set by set trace-stop-notes > command are not shown in trace status until tracing is actually > stopped by tstop command. Similar start notes (set by set trace-notes > command) are shown every time in trace status. This provides > difficulties for IDE integration: for exampe IDE can't know that stop > notes changed without explicit quering gdb by show stop-notes. From > IDE prospective it is easier and more consistent to show stop notes in > separate field in trace status output, just like this is done for > start notes. > Are there any objections if I fix it? As the manual suggests, the set command mostly exists so that you can fix up or expand on a stop note that was supplied with tstop. Tracing running semi-autonomously as it does, you may find yourself typing the tstop command (or hitting a stop button) rather hastily, and only after that would you realize that maybe you ought to add some more explanation, contact info, etc, particularly if you just stopped somebody else's trace run. I considered making the set command finicky and not even allow it until after a trace run is stopped, but that seemed excessive, plus it seemed like there might be use cases where a script might want to pre-set for some reason. It seems like it would be massively confusing to ever display a stop note before the trace actually stopped; you'd have to do some linguistic gymnastics to explain the situation: the trace is still running, but if it were to stop, it would say "trace buffer filled up, choking the VM!", unless you had supplied a different argument to tstop However, I don't see any problem with always supplying it in MI output; then it's up to the IDE to display in a clear way. Stan stan@codesourcery.com