From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59646 invoked by alias); 22 Jan 2016 17:35:09 -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 59617 invoked by uid 89); 22 Jan 2016 17:35:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1709, vCont, vcont X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 22 Jan 2016 17:35:07 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 75119C6596; Fri, 22 Jan 2016 17:35:06 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0MHZ5tH011129; Fri, 22 Jan 2016 12:35:05 -0500 Message-ID: <56A26849.9070206@redhat.com> Date: Fri, 22 Jan 2016 17:35:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Fix fail in gdb.base/interrupt-noterm.exp References: <1453480183-5131-1-git-send-email-yao.qi@linaro.org> <56A25D13.2080608@redhat.com> <86twm5r0yp.fsf@gmail.com> In-Reply-To: <86twm5r0yp.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-01/txt/msg00579.txt.bz2 On 01/22/2016 05:14 PM, Yao Qi wrote: > Pedro Alves writes: > >> Can you expand the rationale some more? >> >> E.g., why is this not a gdbserver bug? Instintively I'd say it is. > > The interaction between GDB and GDBserver is like this, > > 1. GDB sends vCont;c and doesn't wait for the stop reply because > "continue &" is background command, > 2. GDBserver receives vCont;c, enables the async i/o (by > enable_async_io) and resumes the inferior. > 3. GDB sends interrupt packet, > > #1 happens before #2 and #3, but the order of #2 and #3 is not > determined. If #2 happens before #3, it is fine, otherwise, the > GDBserver doesn't know the interrupt from GDB. If 1. is followed by 3., then the \\003 is always read by gdb after the vCont;c. We call enable_async_io before reaching mywait. Since we're in all-stop, that means we'll block inside mywait -> waitpid, all the while \\003 is already available to read in the socket. Since we're blocked in waitpid, we won't see the \\003 until after the next time the program happens to stop. Agree? It still seems to me like a gdbserver bug. I think that after calling enable_async_io, we need to check whether input is already pending from GDB, and if so, process it immediately -- we know the only input coming from GDB at this point is a \\003. IOW, I think we need to call input_interrupt after calling enable_async_io. input_interrupt already uses select before reading, so it handles the case of there being no input available without blocking. However, we need to be careful, because a SIGIO can race with calling input_interrupt from mainline code... Thanks, Pedro Alves