Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Patrick Palka <patrick@parcs.ath.cx>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	       Jan Kratochvil <jan.kratochvil@redhat.com>
Subject: Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8
Date: Thu, 18 Jun 2015 10:41:00 -0000	[thread overview]
Message-ID: <5582A04C.2090502@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1505180740110.11036@idea>

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


  reply	other threads:[~2015-06-18 10:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-14  0:12 Patrick Palka
2015-05-14  1:40 ` Patrick Palka
2015-05-18 11:38   ` Patrick Palka
2015-05-18 11:41     ` Patrick Palka
2015-06-18 10:41       ` Pedro Alves [this message]
2015-05-14  9:29 ` Pedro Alves
2015-05-16  1:00 ` Doug Evans
2015-05-16 14:59   ` Patrick Palka
2015-05-16 15:23     ` Doug Evans
2015-05-16 15:25       ` Jan Kratochvil
2015-05-16 15:50         ` Patrick Palka
2015-05-16 16:06           ` Jan Kratochvil
2015-05-16 15:51         ` Doug Evans
2015-06-18 10:39           ` Pedro Alves
2015-06-18 13:47             ` Doug Evans
2015-06-18 14:08               ` Pedro Alves
2015-06-18 14:20                 ` Doug Evans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5582A04C.2090502@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=patrick@parcs.ath.cx \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox