From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6603 invoked by alias); 18 May 2015 11:38:50 -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 6578 invoked by uid 89); 18 May 2015 11:38:49 -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-ob0-f181.google.com Received: from mail-ob0-f181.google.com (HELO mail-ob0-f181.google.com) (209.85.214.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 18 May 2015 11:38:47 +0000 Received: by obcus9 with SMTP id us9so120053134obc.2 for ; Mon, 18 May 2015 04:38:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fCNV89iLgTDNCx6UJ9xsE3k+mbzKg98G4U/gE8g9VyA=; b=BnOPl8Jutjw50+5x47mMwSFo6UYk66Y9xrO7fKCqkz84eBTnlNvqzavv/qE5VAGV2L /iGhR33h6trSfsRvDqiP2DDGbjTIELV9pb4BIprMb4QtozFG7syl8AuW5Y/ucWOv05Zu HhXgaSE5yp/z3cw8tw5iApYuNHOTRmVty72AtWZK8Qjav82BDdsj6g9JBHQ6SL+XL4X9 vbdlohSsTz7+OY2RbjE+TIrfoG6+gDhdi1xLFhWri3mKbRgpfPaIetjMV+ipGRZnJUpN idE0gjmOvtLQyAwyjGRiSTH6nA8lZop9j5fdrDuZKPd6yFrFE+al+02nLjvBHOm07Tri FeAw== X-Gm-Message-State: ALoCoQlBzCDYT/CtlAFVMXaN+Y2yAFwd685P91vaKwgVgm7WDOp2f5HGmHsDMabtfYxTqTcl+/LY X-Received: by 10.202.93.4 with SMTP id r4mr18753118oib.92.1431949125958; Mon, 18 May 2015 04:38:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.243.232 with HTTP; Mon, 18 May 2015 04:38:25 -0700 (PDT) In-Reply-To: References: <1431562331-20448-1-git-send-email-patrick@parcs.ath.cx> From: Patrick Palka Date: Mon, 18 May 2015 11:38:00 -0000 Message-ID: Subject: Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8 To: "gdb-patches@sourceware.org" Cc: Jan Kratochvil , Patrick Palka Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-05/txt/msg00458.txt.bz2 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: