This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 0/4 V7] MI notification on trace started/stopped


On 12/20/2013 09:57 PM, Pedro Alves wrote:
> I didn't mean queued behind another _trace_ event.  I meant queued
> behind _other_ events GDB is handling.  Like, gdb handling the %Stop
> or stdin before the %Trace.  Events on the GDB side are
> ultimately handled serially.  So GDB can handle both stdin and
> stop events before the trace event is handled.

You meant notification event is queued in GDB side, instead of
GDBserver, then I get your point.

> 
>> > How about triggering MI trace events
>> > _only_ by %Trace notification?  Even tracing is started or stopped
>> > by commands in CLI, GDBserver still emits %Trace for started or stopped
>> > trace.  In this way, the ordering issue can be resolved.
> Hmm.  I realized one more point to add to the discussion.
> 
> What GDB makes to sure the frontend doesn't get out
> of sync wrt to thread's running state is that stops requests
> are asynchronous, so GDB emits *running on its own (not when
> the target said the resumption is effective), but *stopped is
> only emitted when the target really reports it stopped,
> not when the stop is requested with vCont;t.
> 
> But, unlike "vCont;t", tstop/QTStop requests are synchronous.
> That is, when the target replies OK, the trace is stopped,
> period.  It then worries me that the %Trace event will only
> came later, after the "tstop" command returns.  Hmm^2.

As what we are doing in patch 2/4,

> @@ -3481,6 +3500,14 @@ stop_tracing (void)
>      }
>  
>    unpause_all (1);
> +
> +  if (notif_trace.supported)
> +    {
> +      struct notif_event *event
> +	= xmalloc (sizeof (struct notif_event));
> +
> +      notif_push (&notif_trace, event);
> +    }

%Trace is sent before OK, but is ack'ed after OK.

&"tstop\n"^M
&"Sending packet: $QTStop#4b..."^M
&"  Notification received:
Trace:status:T0;tstop::0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:4ee06fece6180;stoptime:4ee06fece64a4;username:;notes::\n"^M
=trace-stopped\n^M
&"Packet received: OK\n"^M

  This "OK" is the reply to "QTStop".

&"Sending packet: $vTraced#c9..."^M
&"Packet received: OK\n"^M

  This "OK" is the reply to "vTraced".

> So maybe we need to make sure that %Trace stop events
> are flushed/consumed on "tstop"?

Yes, we need to add the following piece of code somewhere
to consume events,

  if (!non_stop)
    remote_notif_process (rs->notif_state, &notif_client_stop);

it is similar to what we did at the beginning of remote_resume.
Looks the end of remote_get_noisy_reply (when the actual reply is got)
is a good place to do so.

> But If we'll ever support traces starting on their own on
> the target, that may add to the complication.  I haven't
> thought this part through, and I have to leave now for a
> bit, but I thought I'd send out the email now anyway.

The ordering issue of MI events is caused by two sources triggering
MI events, CLI and remote target.  If MI notifications are only
triggered by one source, remote target, through %Trace, the ordering of
MI notifications should be consistent with the ordering of %Trace.
AFAICS, starting trace triggered by target doesn't make troubles here.

If all your concerns are cleared (I hope so) in this thread, I'll post
V8 to reflect the results of the discussion.

-- 
Yao (éå)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]