From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20517 invoked by alias); 15 Mar 2010 18:46:16 -0000 Received: (qmail 20506 invoked by uid 22791); 15 Mar 2010 18:46:15 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Mar 2010 18:46:09 +0000 Received: (qmail 15740 invoked from network); 15 Mar 2010 18:46:07 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Mar 2010 18:46:07 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Stan Shebs Subject: Re: [MI tracepoints 4/9] -trace-start/end/status Date: Mon, 15 Mar 2010 18:46:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-19-generic; KDE/4.3.2; x86_64; ; ) Cc: Vladimir Prus References: <201003141154.07272.vladimir@codesourcery.com> In-Reply-To: <201003141154.07272.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201003151846.05739.pedro@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-03/txt/msg00553.txt.bz2 On Sunday 14 March 2010 08:54:07, Vladimir Prus wrote: > (start_tracing, stop_traceing, trace_status_mi): Declare. Typo: stop_traceing. > +/* Report the trace status to uiout, in a way suitable for MI, and not > + suitable for CLI. If ON_STOP is true, suppress a few fields that Double space after period. > + are not meaningful in -trace-stop response. "the -trace-stop response" > + > + The implementation is essentially parallel to trace_status_command, but > + merging them will result in unreadable code. > + */ */ at end of comment, not in new line: "... in unreadable code. */" > + /** Unlike CLI, do not show the state of 'disconnected-tracing' variable. s,/**,/* : /* Unlike CLI, > + Given that frontend gets the status either on -trace-stop, or from "the frontend gets" > + -trace-status after re-connection, it does not seem like this > + information is necessary for anything. It is not necessary for either > + figuring the vital state of the target nor for navigation of trace > + frames. If the frontend wants to show the current state is some > + configure dialog, it can request the value when such dialog is > + invoked by the user. */ Double space after period everywhere please. + ui_out_field_int (uiout, "buffer-size", (int) ts->buffer_size); + ui_out_field_int (uiout, "buffer-free", (int) ts->buffer_free); When these optional fields aren't reported by the target, this will print -1. I don't see that mentioned in the manual. Is this intended? I would have expected optional fields to just not be present, as is common in MI. trace_status_command does that too. Hmmm, I don't see any of the qTStatus optional fields described anywhere in manual. Stan? Am I just looking at the wrong place? -- Pedro Alves