This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8
- From: Pedro Alves <palves at redhat dot com>
- To: Patrick Palka <patrick at parcs dot ath dot cx>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Date: Thu, 18 Jun 2015 11:41:16 +0100
- Subject: Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8
- Authentication-results: sourceware.org; auth=none
- References: <1431562331-20448-1-git-send-email-patrick at parcs dot ath dot cx> <CA+C-WL_OvEvjLQ685YCGrQuTddrfK-t7pFav9beF5uxyiyMR1g at mail dot gmail dot com> <CA+C-WL_n9GV1tN0SW+MMy1idGoc-gbUTJWevmnAjFwgjEWsPyA at mail dot gmail dot com> <alpine dot DEB dot 2 dot 11 dot 1505180740110 dot 11036 at 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