From patchwork Tue Jan 26 09:58:58 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 10628 Received: (qmail 56785 invoked by alias); 26 Jan 2016 09:59:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 56698 invoked by uid 89); 26 Jan 2016 09:59:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2443, msg00057html, msg00057.html, unattended X-HELO: mail-pf0-f196.google.com Received: from mail-pf0-f196.google.com (HELO mail-pf0-f196.google.com) (209.85.192.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 26 Jan 2016 09:59:10 +0000 Received: by mail-pf0-f196.google.com with SMTP id n128so8020977pfn.3 for ; Tue, 26 Jan 2016 01:59:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=zLVNBONiDiXqvc+oi/UO/UsxkfhUOHRufTKNXSOuNyM=; b=ewm+7gZVERTc8mVs5pY2eZfCcHRJKzoFJJKkQ4VpQnS62AEzuDpaQExz3+1/GnOUAc c5jZ4hI/Ql4Cpn0pkCcSnVjUfOPyw0zca205xCjL3A8KnqjHeQyeaIsWpGypSvlFCAMu NzHQjpf4lTdPBI9GydfKAfcWsvoXkuEQo/CJR0vf6OkqOYwWPLfadSi1kvxc8ZWQNird aSQo6IieKv4Konl5R8rs6YXMrteRzYyqgD7r4YP5ATCeUdVQypJa8LIthviXHgDX1XKy n4koJqXvvzBLJAhYmsgNWM85QaHd4KXgNRm6aGdaQzmfAzDH4LKkHUYzNMpc2KdFRXpI /SVw== X-Gm-Message-State: AG10YOS0vwj6KZPsZj6BgAFeknlGUpSHLbADPkGsasFK48zaONlL8SDxu2TEyWCqJM61FA== X-Received: by 10.98.0.86 with SMTP id 83mr25848577pfa.84.1453802348532; Tue, 26 Jan 2016 01:59:08 -0800 (PST) Received: from E107787-LIN.cambridge.arm.com (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id 83sm900187pft.44.2016.01.26.01.59.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Jan 2016 01:59:07 -0800 (PST) From: Yao Qi X-Google-Original-From: Yao Qi To: gdb-patches@sourceware.org Subject: [PATCH 1/2] [GDBserver] Check input interrupt after reading in a packet Date: Tue, 26 Jan 2016 09:58:58 +0000 Message-Id: <1453802339-20401-2-git-send-email-yao.qi@linaro.org> In-Reply-To: <1453802339-20401-1-git-send-email-yao.qi@linaro.org> References: <86powqqa57.fsf@gmail.com> <1453802339-20401-1-git-send-email-yao.qi@linaro.org> X-IsSubscribed: yes GDBserver may read some packet together with '\003' in one go. We've already checked '\003' first when reading packet by my patch, Check input interrupt first when reading packet https://sourceware.org/ml/gdb-patches/2016-01/msg00057.html but if we don't check '\003' *after* each packet, the interrupt will be processed next time GDBserver reads from the buffer, so that the interrupt isn't processed in time. For example, GDB sends vCont;c and interrupt (see gdb.base/interrupt-noterm.exp), we'll resume the inferior and wait once packet vCont;c is seen. If we don't check the interrupt character after vCont;c packet, interrupt character will stay in the buffer unattended until GDBserver returns from the wait, which may take a while. Note that since we've read '\003' from file descriptor, SIGIO signal handler input_interrupt doesn't help either. This issue can be exposed by hacking the end of getpkt like @@ -1041,6 +1050,9 @@ getpkt (char *buf) } } + if (readchar_bufcnt > 0) + gdb_assert (*readchar_bufp != '\003'); + return bp - buf; } and this can trigger internal error, (gdb) PASS: gdb.base/interrupt-noterm.exp: interrupt Remote connection closed^M (gdb) FAIL: gdb.base/interrupt-noterm.exp: inferior received SIGINT Remote debugging from host 10.2.206.40^M /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/remote-utils.c:1054: A problem internal to GDBserver has been detected.^M getpkt: Assertion `*readchar_bufp != '\003'' failed.^M This patch is to peek the buffer, if it is '\003', consume it and call *the_target->request_interrupt. gdb/gdbserver: 2016-01-26 Yao Qi * remote-utils.c (getpkt): If the buffer isn't empty, and the first character is '\003', call *the_target->request_interrupt. --- gdb/gdbserver/remote-utils.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/gdb/gdbserver/remote-utils.c b/gdb/gdbserver/remote-utils.c index 292197a..000457d 100644 --- a/gdb/gdbserver/remote-utils.c +++ b/gdb/gdbserver/remote-utils.c @@ -1041,6 +1041,15 @@ getpkt (char *buf) } } + /* The '\003' may appear after some packet, and check it in the buffer, + so that we can process the interrupt in time. */ + if (readchar_bufcnt > 0 && *readchar_bufp == '\003') + { + /* Consume the interrupt character in the buffer. */ + readchar (); + (*the_target->request_interrupt) (); + } + return bp - buf; }