From patchwork Fri Oct 10 13:48:18 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 3187 Received: (qmail 17251 invoked by alias); 10 Oct 2014 13:52:30 -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 17238 invoked by uid 89); 10 Oct 2014 13:52:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL, BAYES_00 autolearn=ham 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; Fri, 10 Oct 2014 13:52:27 +0000 Received: from svr-orw-fem-02x.mgc.mentorg.com ([147.34.96.206] helo=SVR-ORW-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XcacI-00007s-PE from Yao_Qi@mentor.com ; Fri, 10 Oct 2014 06:52:22 -0700 Received: from GreenOnly (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.3.181.6; Fri, 10 Oct 2014 06:52:22 -0700 From: Yao Qi To: Pedro Alves CC: Subject: Re: [PATCH 3/3] Use command "monitor set debug 0" to check the connection References: <543404EF.4010306@redhat.com> <1412749679-27076-1-git-send-email-yao@codesourcery.com> <1412749679-27076-4-git-send-email-yao@codesourcery.com> <543547FC.30306@redhat.com> <87zjd6rlof.fsf@codesourcery.com> <5437A902.6040701@redhat.com> Date: Fri, 10 Oct 2014 21:48:18 +0800 In-Reply-To: <5437A902.6040701@redhat.com> (Pedro Alves's message of "Fri, 10 Oct 2014 10:38:10 +0100") Message-ID: <87lhooox25.fsf@codesourcery.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-IsSubscribed: yes Pedro Alves writes: > So I think we should do "set remote trace-status-packet on" before > the "tstatus". > Sure. > I know that the test originally didn't use "tstatus", > but it's really the packet we should be testing for exercising > that remote_get_trace_status's exception swallowing code, > which was very much related to the original bug this test covered, > see: > > https://sourceware.org/bugzilla/show_bug.cgi?id=15275 > > https://sourceware.org/ml/gdb-patches/2013-03/msg00691.html Thanks for the information. I remember the first half of the story, but forget the second half. How about the patch below? diff --git a/gdb/testsuite/gdb.server/server-kill.exp b/gdb/testsuite/gdb.server/server-kill.exp index 83c11f2..53d8e9a 100644 --- a/gdb/testsuite/gdb.server/server-kill.exp +++ b/gdb/testsuite/gdb.server/server-kill.exp @@ -52,6 +52,11 @@ if {$server_pid == "" } { remote_exec target "kill -9 $server_pid" +# Enable trace status packet which is disabled after the connection +# if the remote target doesn't support tracepoint at all. Otherwise, +# no RSP packet is sent out. +gdb_test_no_output "set remote trace-status-packet on" + # Force GDB to talk with GDBserver, so that we can get the # "connection closed" error. gdb_test "tstatus" {Remote connection closed|Remote communication error\. Target disconnected\.: Connection reset by peer\.}