From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105464 invoked by alias); 29 Sep 2015 14:41:20 -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 105444 invoked by uid 89); 29 Sep 2015 14:41:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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; Tue, 29 Sep 2015 14:41:17 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id A0B87A37EB; Tue, 29 Sep 2015 14:41:16 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8TEfErg022733; Tue, 29 Sep 2015 10:41:15 -0400 Message-ID: <560AA30A.6080202@redhat.com> Date: Tue, 29 Sep 2015 14:41:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sandra Loosemore , gdb-patches Subject: Re: [patch, testsuite] fix problems in gdb.base/paginate-bg-execution.exp References: <55FC6B86.8090700@codesourcery.com> In-Reply-To: <55FC6B86.8090700@codesourcery.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-09/txt/msg00637.txt.bz2 On 09/18/2015 08:52 PM, Sandra Loosemore wrote: > This patch addresses a couple of problems in > gdb.base/paginate-bg-execution.exp: > > (1) A different "Quit" message can appear in some cases, e.g. if GDB > thinks the terminal doesn't support job control -- see the definition of > quit in utils.c. The specific situation where I tripped over this was > running GDB in a CMD.EXE shell on a remote Windows host via ssh -T. Seems to me that suggesting to "expect signal SIGINT when the program is resumed" is bogus in this case. That can happen when you ctrl-c the terminal, because a SIGINT ends up queued in both the inferior and gdb, but I'm not seeing why that would happen in response to the user typing "q" on a pagination prompt. I think prompt_for_continue should call throw_quit("Quit") directly instead of quit(). > > (2) The test was sending a ^C interrupt without testing whether the > target had the nointerrupts property set. Odd that almost no other ctrl-c test checks this: $ git grep "\\\003" testsuite/ testsuite/gdb.base/completion.exp: send_gdb "\003" testsuite/gdb.base/completion.exp: send_gdb "\003" testsuite/gdb.base/double-prompt-target-event-error.exp: send_gdb "\003p 1\n" testsuite/gdb.base/interrupt.exp: send_gdb "\003" testsuite/gdb.base/interrupt.exp: send_gdb "\003" testsuite/gdb.base/paginate-after-ctrl-c-running.exp: send_gdb "\003" testsuite/gdb.base/paginate-bg-execution.exp: send_gdb "\003" testsuite/gdb.base/paginate-execution-startup.exp: send_gdb "\003" testsuite/gdb.base/printcmds.exp: gdb_test "p ctable1\[3\]" " = 3 '\\\\003'" testsuite/gdb.base/printcmds.exp: " = \\(unsigned char \\*\\) \"\\\\001\\\\002\\\\003\\\\004\\\\005\\\\006\\\\a\\\\b\"..." testsuite/gdb.base/random-signal.exp:after 500 {send_gdb "\003"} testsuite/gdb.base/range-stepping.exp: send_gdb "\003" testsuite/gdb.cp/annota2.exp:send_gdb "\003" testsuite/gdb.cp/annota3.exp:send_gdb "\003" testsuite/gdb.gdb/selftest.exp: send_gdb "\003" testsuite/gdb.threads/continue-pending-status.exp: send_gdb "\003" testsuite/gdb.threads/leader-exit.exp:send_gdb "\003" testsuite/gdb.threads/manythreads.exp: send_gdb "\003" testsuite/gdb.threads/pthreads.exp: send_gdb "\003" testsuite/gdb.threads/schedlock.exp: after 1000 {send_gdb "\003"} testsuite/gdb.threads/sigthread.exp:after 500 {send_gdb "\003"} $ git grep nointerrupts testsuite/gdb.base/interrupt.exp:if [target_info exists gdb,nointerrupts] { testsuite/gdb.base/interrupt.exp: verbose "Skipping interrupt.exp because of nointerrupts." What's going on? > > OK to commit? (I'm not sure this one qualifies as obvious.) I don't think it is obvious. Thanks, Pedro Alves