Re: [MI tracepoints 4/9] -trace-start/end/status

[Pedro Alves <pedro at codesourcery dot com>]

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