From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49425 invoked by alias); 18 Jun 2015 10:41:21 -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 49415 invoked by uid 89); 18 Jun 2015 10:41:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no 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; Thu, 18 Jun 2015 10:41:19 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 8B8DD2F14BE; Thu, 18 Jun 2015 10:41:18 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5IAfGHj003481; Thu, 18 Jun 2015 06:41:17 -0400 Message-ID: <5582A04C.2090502@redhat.com> Date: Thu, 18 Jun 2015 10: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: Patrick Palka CC: "gdb-patches@sourceware.org" , Jan Kratochvil Subject: Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8 References: <1431562331-20448-1-git-send-email-patrick@parcs.ath.cx> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-06/txt/msg00382.txt.bz2 Hi Patrick, On 05/18/2015 12:41 PM, Patrick Palka wrote: >> So the only regression appears to be >> >> FAIL: gdb.gdb/selftest.exp: send SIGINT signal to child process (timeout) >> Thanks for investigating this. I'm looking forward to get the readline update in. >> 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). Yes, the "signal" command delivers the signal to the inferior. The passed signal is not intercepted. >> 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. Correct. >> 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: >> Seems reasonable to me. Thanks, Pedro Alves