From patchwork Mon May 18 11:41:29 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Palka X-Patchwork-Id: 6781 Received: (qmail 13428 invoked by alias); 18 May 2015 11:41:45 -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 13419 invoked by uid 89); 18 May 2015 11:41:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-qk0-f179.google.com Received: from mail-qk0-f179.google.com (HELO mail-qk0-f179.google.com) (209.85.220.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 18 May 2015 11:41:43 +0000 Received: by qkgx75 with SMTP id x75so107044127qkg.1 for ; Mon, 18 May 2015 04:41:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; bh=X2GwKx7vxHO284IxHu/ThRGxvnzHGh20z8WrbJkHewY=; b=hgCYow96D9CHgdfQz4D6vPuGTW1ybm+nxzBfTrPV0bJoWGVkNOLk7Z2P6FG/DMxINh e8lEWMHlrB3/MBkKX8tULdWwILdFM3waqCgu8NBZ/+CGgowwU8rNrKUoIcfF6VlfmDFd wPQQpmPWELW48O0ZDvbLmJxHSJUDftXi3u82KSpAdrYrVxCJl6fgPurkP1wprBPgoYdk iJeL+Da4miHJKCkNCXGmTIrv/FeLhXJ63MFo5AdTMy1g8LZp21BePbnhDexZDnXHnhON ill9Pc0cLaRiWl9mir03dg1f6lb5V9jV7quPcbjhk4J2VGwkF89HpkZsofHkQ6PEeoe0 wBKw== X-Gm-Message-State: ALoCoQlx29Jq270xvNVPJ0Mn4d7h+ajgtrIXB/6vVtEluJvmvGwHR4INyzD481bs3gtrp0Sbfm0Q X-Received: by 10.55.21.17 with SMTP id f17mr46885533qkh.41.1431949301059; Mon, 18 May 2015 04:41:41 -0700 (PDT) Received: from [192.168.1.130] (ool-4353acd8.dyn.optonline.net. [67.83.172.216]) by mx.google.com with ESMTPSA id 102sm6818548qgn.37.2015.05.18.04.41.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 May 2015 04:41:40 -0700 (PDT) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Mon, 18 May 2015 07:41:29 -0400 (EDT) To: Patrick Palka cc: "gdb-patches@sourceware.org" , Jan Kratochvil Subject: Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8 In-Reply-To: Message-ID: References: <1431562331-20448-1-git-send-email-patrick@parcs.ath.cx> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 On Mon, 18 May 2015, Patrick Palka wrote: > On Wed, May 13, 2015 at 9:40 PM, Patrick Palka wrote: >> On Wed, May 13, 2015 at 8:12 PM, Patrick Palka wrote: >>> This patch syncs our upstream copy of readline to version 6.3 >>> patchlevel 8. >>> >>> I basically copied what was done when Jan updated to readline 6.2 in >>> 2011: http://sourceware.org/ml/gdb-patches/2011-05/msg00003.html >>> >>> Specifically, I: >>> >>> 1. Extracted the readline 6.3 tarball on top of readline/ >>> 2. Applied patches 1-8 from ftp://ftp.cwru.edu/pub/bash/readline-6.3-patches/ >>> 3. Omitted all the files in doc/ that were intentionally omitted before. >>> 4. Regenerated readline/configure and readline/examples/rlfe/configure >>> using autoconf 2.64. No other configure files needed regenerating. >>> 5. Reapplied the only local patch since the update to readline 6.2 that >>> has not already been applied to readline 6.3, 05942d8a1 ("Fix >>> executable indicator in file name completeion on Windows."). This >>> particular patch has been applied upstream but readline 6.3 does not >>> have it. Whether or not a local patch has already been applied to >>> readline 6.3 was determined via manual inspection. (Wasn't too bad >>> really.) >>> >>> The new files to make it into the tree are: >>> >>> colors.{c,h} >>> configure.ac >>> parse-colors.{c,h} >>> examples/hist_erasedups.c >>> examples/hist_purgecmd.c >>> >>> Deleted files: >>> >>> configure.in >>> >>> I've been using this patch locally for a few months now and I've >>> experienced only a single regression which has already been preemptively >>> fixed by 8900d71e3 ("Explicitly call rl_resize_terminal() in TUI's >>> SIGWINCH handler"). Other than that, no issues in either the CLI or the >>> TUI, or changes in the testsuite. Though I have only been able to test >>> this patch on Linux. >> >> On second inspection it seems I am getting a few anomalous testsuite >> failures. I will take a deeper look. > > So the only regression appears to be > > FAIL: gdb.gdb/selftest.exp: send SIGINT signal to child process (timeout) > > What happens here is that a stopped inferior GDB is resumed using > "signal SIGINT" with the expectation that the parent GDB process will > catch this SIGINT and thus pause the inferior again. But with > readline 6.3 the parent GDB process no longer catches the signal > raised by "signal SIGINT" and so the inferior GDB continues to run > until the test times out. This seems to be caused by the fact that > readline 6.3 makes sure to not have its own signal handlers installed > when readline is not in control, whereas readline 6.2 always has its > signal handlers installed. readline's signal handler basically > installs the applications original signal handler and then calls via > raise (signal). This call to "raise (signal);" in readline's signal > handler is what's responsible for re-stopping the GDB inferior after > it was resumed with "signal SIGINT". The parent GDB process does not > seem to catch the first SIGINT raised by "signal SIGINT" itself > (regardless of what the inferior is). So without readline's signal > handlers installed at the point when the inferior is resumed via > "signal SIGINT", nothing calls "raise (signal)" later on. The parent > GDB process does not catch the initial SIGINT it itself raised and > there is no longer subsequent SIGINT to catch because readline's > signal handler, which calls raise(), is no longer permanently > installed. > > It seems it is expected behavior that resuming an inferior via "raise > SIGINT" does not immediately stop the inferior giving control back to > GDB since interrupt.exp tests for it. Therefore when importing > readline 6.3 I think we should just fix the selftest.exp test to no > longer expect that the inferior GDB will get stopped following "signal > SIGINT". Something like: > Oops, here it is: Subject: [PATCH] Update "signal SIGINT" test --- gdb/testsuite/gdb.gdb/selftest.exp | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/gdb/testsuite/gdb.gdb/selftest.exp b/gdb/testsuite/gdb.gdb/selftest.exp index 9f25a48..6170ac8 100644 --- a/gdb/testsuite/gdb.gdb/selftest.exp +++ b/gdb/testsuite/gdb.gdb/selftest.exp @@ -444,9 +444,26 @@ proc test_with_self { executable } { } set description "send SIGINT signal to child process" - gdb_test "signal SIGINT" \ - "Continuing with signal SIGINT.*" \ - "$description" + gdb_test_multiple "signal SIGINT" "$description" { + -re "^signal SIGINT\r\nContinuing with signal SIGINT.\r\nQuit" { + pass "$description" + } + } + + set description "send ^C to child process again" + send_gdb "\003" + gdb_expect { + -re "Program received signal SIGINT.*$gdb_prompt $" { + pass "$description" + } + -re ".*$gdb_prompt $" { + fail "$description" + } + timeout { + fail "$description (timeout)" + } + } + # get a stack trace #