From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26616 invoked by alias); 21 Dec 2013 12:50:52 -0000 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 Received: (qmail 26606 invoked by uid 89); 21 Dec 2013 12:50:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_00,GARBLED_BODY autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 21 Dec 2013 12:50:50 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VuM10-0005tS-VY from Yao_Qi@mentor.com ; Sat, 21 Dec 2013 04:50:47 -0800 Received: from SVR-ORW-FEM-05.mgc.mentorg.com ([147.34.97.43]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 21 Dec 2013 04:50:46 -0800 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.2.247.3; Sat, 21 Dec 2013 04:50:05 -0800 Message-ID: <52B58E3C.6050705@codesourcery.com> Date: Sat, 21 Dec 2013 12:50:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Pedro Alves CC: Subject: Re: [PATCH 0/4 V7] MI notification on trace started/stopped References: <1386856184-16519-1-git-send-email-yao@codesourcery.com> <52B1AC87.8070409@redhat.com> <52B296BB.3070406@codesourcery.com> <52B44CB5.7040009@redhat.com> In-Reply-To: <52B44CB5.7040009@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00857.txt.bz2 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 (¬if_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, ¬if_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 (齐尧)