From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14599 invoked by alias); 27 Sep 2012 03:16:35 -0000 Received: (qmail 14591 invoked by uid 22791); 27 Sep 2012 03:16:34 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 27 Sep 2012 03:16:20 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1TH4aJ-0000Qb-FV from Yao_Qi@mentor.com ; Wed, 26 Sep 2012 20:16:19 -0700 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); Wed, 26 Sep 2012 20:16:19 -0700 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.1.289.1; Wed, 26 Sep 2012 20:16:18 -0700 Message-ID: <5063C4FC.40404@codesourcery.com> Date: Thu, 27 Sep 2012 03:16:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Pedro Alves CC: Subject: Re: [RFC 0/2, gdbserver] Set linux target in async mode in default References: <1347961672-18495-1-git-send-email-yao@codesourcery.com> <5061DA66.6020106@redhat.com> In-Reply-To: <5061DA66.6020106@redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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: 2012-09/txt/msg00613.txt.bz2 On 09/26/2012 12:23 AM, Pedro Alves wrote: > Please explain better why this is necessary (probably with an example). > What exactly doesn't work if you don't do this change? It sounds as though Hi, Pedro, When we have a notification, we'll queue it and call 'async_file_mark'. Then, notification can be sent in async handler 'handle_target_event' later, which is done by my later patch posted here, mainly in server.c:handle_target_event, [PATCH 3/6] de-couple %Stop from notification: gdbserver http://sourceware.org/ml/gdb-patches/2012-09/msg00480.html The whole process is identical to all notifications, including %Stop. Actually, this process is generalized from %Stop. For example, we need a notification on 'trace status', and GDBserver will send it once trace is stopped due to some reasons, such as tracebuffer is full. We can add some code below to trigger event-loop, so that such notification can be sent later (it doesn't compile, just to show why do we need async for sending notification). diff --git a/gdb/gdbserver/tracepoint.c b/gdb/gdbserver/tracepoint.c index 201a25b..1135f53 100644 --- a/gdb/gdbserver/tracepoint.c +++ b/gdb/gdbserver/tracepoint.c @@ -3472,6 +3472,10 @@ stop_tracing (void) } unpause_all (1); + +#ifndef IN_PROCESS_AGENT + QUEUE_enque (notif_p, notif_queue, ¬if_trace); + async_file_mark (); +#endif } static int Otherwise, when/how should we send notification in GDBserver? > this could make gdbserver push notifications down to GDB in all-stop > mode even when it isn't waiting for server replies? I am assuming that 'it' means GDB', so answer is 'yes'. If I understand 'non-stop for remote target' stuff correctly, %Stop notification is sent to GDB in non-stop mode even when GDB isn't waiting for server replies. Then, what I am trying to achieve is 'notifications are sent to GDB in all-stop or non-stop mode even when GDB isn't waiting for server replies'. -- Yao