[PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Patrick Palka]

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.

Have I missed anything?  What else should be done in order to sync our
copy of readline?  Unlike the last sync from 5.1 to 6.2, this sync to
6.3 is quite minor and hopefully painless.

Because the commit is so big and so mechanical I elected to create a
branch users/ppalka/readline-6.3-update where you can view/test the
change.

readline/ChangeLog.gdb:

	Import readline 6.3 and upstream patches 1-8.
	* configure: Regenerate.
	* examples/rlfe/configure: Regenerate.
	* complete.c: Reapply previous change.
---
 readline/CHANGELOG                  |  129 ++
 readline/CHANGES                    |  139 ++
 readline/ChangeLog.gdb              |    7 +
 readline/INSTALL                    |    2 +-
 readline/MANIFEST                   |    9 +-
 readline/Makefile.in                |   63 +-
 readline/NEWS                       |   66 +-
 readline/README                     |   11 +-
 readline/aclocal.m4                 |   34 +-
 readline/bind.c                     |  208 +-
 readline/callback.c                 |   44 +-
 readline/chardefs.h                 |    2 +-
 readline/colors.c                   |  251 +++
 readline/colors.h                   |  122 ++
 readline/complete.c                 |  378 +++-
 readline/config.h.in                |   19 +-
 readline/configure                  |  208 +-
 readline/configure.ac               |  303 +++
 readline/configure.in               |  304 ---
 readline/display.c                  |  347 ++--
 readline/doc/Makefile.in            |    3 +
 readline/doc/history.3              |   15 +-
 readline/doc/history.texi           |   26 +-
 readline/doc/hstech.texi            |    4 +-
 readline/doc/hsuser.texi            |   34 +-
 readline/doc/readline.3             |   89 +-
 readline/doc/rlman.texi             |   27 +-
 readline/doc/rltech.texi            |  210 +-
 readline/doc/rluser.texi            |  228 ++-
 readline/doc/rluserman.texi         |   27 +-
 readline/doc/texi2dvi               |    4 +-
 readline/doc/texi2html              |    6 +-
 readline/doc/version.texi           |   12 +-
 readline/emacs_keymap.c             |    6 -
 readline/examples/Makefile.in       |   33 +-
 readline/examples/excallback.c      |    7 +-
 readline/examples/hist_erasedups.c  |  121 ++
 readline/examples/hist_purgecmd.c   |  151 ++
 readline/examples/readlinebuf.h     |    6 +-
 readline/examples/rl-callbacktest.c |   87 +
 readline/examples/rlfe/config.h.in  |    6 +-
 readline/examples/rlfe/configure    | 3862 +++++++++++++----------------------
 readline/examples/rlfe/configure.in |    6 +-
 readline/examples/rlfe/extern.h     |    2 +-
 readline/examples/rlfe/os.h         |    8 +-
 readline/examples/rlfe/rlfe.c       |    9 +-
 readline/examples/rlptytest.c       |    6 +-
 readline/funmap.c                   |    5 +-
 readline/histexpand.c               |   70 +-
 readline/histfile.c                 |   62 +-
 readline/history.c                  |    8 +-
 readline/history.h                  |    2 +-
 readline/input.c                    |   71 +-
 readline/isearch.c                  |  128 +-
 readline/macro.c                    |   38 +-
 readline/mbutil.c                   |   11 +-
 readline/misc.c                     |   41 +-
 readline/nls.c                      |   35 +-
 readline/parse-colors.c             |  440 ++++
 readline/parse-colors.h             |   46 +
 readline/patchlevel                 |    2 +-
 readline/posixdir.h                 |   14 +-
 readline/posixjmp.h                 |    2 +
 readline/readline.c                 |  153 +-
 readline/readline.h                 |   36 +-
 readline/rlconf.h                   |   12 +-
 readline/rldefs.h                   |   10 +-
 readline/rlmbutil.h                 |    9 +
 readline/rlprivate.h                |   35 +-
 readline/rlstdc.h                   |   12 +
 readline/rltty.c                    |   10 +-
 readline/rltypedefs.h               |   11 +-
 readline/search.c                   |   91 +-
 readline/shell.c                    |   46 +-
 readline/shlib/Makefile.in          |   81 +-
 readline/signals.c                  |  122 +-
 readline/support/config.guess       |  587 +++---
 readline/support/config.rpath       |    0
 readline/support/config.sub         |  332 ++-
 readline/support/mkdist             |   15 +-
 readline/support/shlib-install      |    9 +-
 readline/support/shobj-conf         |   71 +-
 readline/terminal.c                 |   57 +-
 readline/text.c                     |    7 +-
 readline/undo.c                     |   45 +-
 readline/util.c                     |   83 +-
 readline/vi_keymap.c                |    1 -
 readline/vi_mode.c                  |  133 +-
 readline/xfree.c                    |    7 -
 readline/xmalloc.h                  |    3 -
 90 files changed, 6578 insertions(+), 4016 deletions(-)
 create mode 100644 readline/colors.c
 create mode 100644 readline/colors.h
 create mode 100644 readline/configure.ac
 delete mode 100644 readline/configure.in
 create mode 100644 readline/examples/hist_erasedups.c
 create mode 100644 readline/examples/hist_purgecmd.c
 create mode 100644 readline/examples/rl-callbacktest.c
 create mode 100644 readline/parse-colors.c
 create mode 100644 readline/parse-colors.h
 mode change 100755 => 100644 readline/support/config.guess
 mode change 100755 => 100644 readline/support/config.rpath
 mode change 100755 => 100644 readline/support/config.sub
 mode change 100755 => 100644 readline/support/shobj-conf

Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Patrick Palka]

On Wed, May 13, 2015 at 8:12 PM, Patrick Palka <patrick@parcs.ath.cx> 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.

Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Pedro Alves]

On 05/14/2015 01:12 AM, 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.
> 
> Have I missed anything?  What else should be done in order to sync our
> copy of readline?  Unlike the last sync from 5.1 to 6.2, this sync to
> 6.3 is quite minor and hopefully painless.
> 
> Because the commit is so big and so mechanical I elected to create a
> branch users/ppalka/readline-6.3-update where you can view/test the
> change.

(I haven't looked at the branch,) but it all sounds great to me.

Many thanks for doing all this.

Thanks,
Pedro Alves

Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Doug Evans]

On Wed, May 13, 2015 at 5:12 PM, Patrick Palka <patrick@parcs.ath.cx> 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.
>
> Have I missed anything?  What else should be done in order to sync our
> copy of readline?  Unlike the last sync from 5.1 to 6.2, this sync to
> 6.3 is quite minor and hopefully painless.
>
> Because the commit is so big and so mechanical I elected to create a
> branch users/ppalka/readline-6.3-update where you can view/test the
> change.
>
> readline/ChangeLog.gdb:
>
>         Import readline 6.3 and upstream patches 1-8.
>         * configure: Regenerate.
>         * examples/rlfe/configure: Regenerate.
>         * complete.c: Reapply previous change.

Hi.

How does one easily audit whether all local patches are still present?
Looking at ChangeLog.gdb I'm left wondering.

I'm not saying you've missed anything.
Rather, IWBN to have, after all your efforts,
a *simple* record of what's still local.

One thought was to just nuke all of the old entries
in ChangeLog.gdb.  If you say there's only one local change
present then it should be a really small file.
[IOW, when we import a new readline from upstream,
reset ChangeLog.gdb.]

Another thought, for those that have an aversion to
emptying out ChangeLog.gdb and starting over,
is to just add a line that says something like
"everything below this line is just
for the archive, ignore it otherwise", and copy up entries
for local patches that are still local.

If the number of local patches is small (as it should be)
I like starting over with each new import.
But the high order bit for me is to be able to easily
audit/track/find local patches.

Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Patrick Palka]

On Fri, May 15, 2015 at 9:00 PM, Doug Evans <dje@google.com> wrote:
> On Wed, May 13, 2015 at 5:12 PM, Patrick Palka <patrick@parcs.ath.cx> 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.
>>
>> Have I missed anything?  What else should be done in order to sync our
>> copy of readline?  Unlike the last sync from 5.1 to 6.2, this sync to
>> 6.3 is quite minor and hopefully painless.
>>
>> Because the commit is so big and so mechanical I elected to create a
>> branch users/ppalka/readline-6.3-update where you can view/test the
>> change.
>>
>> readline/ChangeLog.gdb:
>>
>>         Import readline 6.3 and upstream patches 1-8.
>>         * configure: Regenerate.
>>         * examples/rlfe/configure: Regenerate.
>>         * complete.c: Reapply previous change.
>
> Hi.
>
> How does one easily audit whether all local patches are still present?
> Looking at ChangeLog.gdb I'm left wondering.
>
> I'm not saying you've missed anything.
> Rather, IWBN to have, after all your efforts,
> a *simple* record of what's still local.
>
> One thought was to just nuke all of the old entries
> in ChangeLog.gdb.  If you say there's only one local change
> present then it should be a really small file.
> [IOW, when we import a new readline from upstream,
> reset ChangeLog.gdb.]
>
> Another thought, for those that have an aversion to
> emptying out ChangeLog.gdb and starting over,
> is to just add a line that says something like
> "everything below this line is just
> for the archive, ignore it otherwise", and copy up entries
> for local patches that are still local.
>
> If the number of local patches is small (as it should be)
> I like starting over with each new import.
> But the high order bit for me is to be able to easily
> audit/track/find local patches.

Another option is that the commit responsible for syncing readline
should mention which local commits have been reapplied in the commit
message and also mention it in the ChangeLog.gdb entry.  So the local
commits at any point in time would be all the commits that occurred
after the latest readline import plus the earlier commits (if any)
referenced in that readline import.

I like that idea and the idea of trimming the ChangeLog.gdb file at
each import too.

Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Doug Evans]

On Sat, May 16, 2015 at 7:58 AM, Patrick Palka <patrick@parcs.ath.cx> wrote:
> On Fri, May 15, 2015 at 9:00 PM, Doug Evans <dje@google.com> wrote:
>> On Wed, May 13, 2015 at 5:12 PM, Patrick Palka <patrick@parcs.ath.cx> 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.
>>>
>>> Have I missed anything?  What else should be done in order to sync our
>>> copy of readline?  Unlike the last sync from 5.1 to 6.2, this sync to
>>> 6.3 is quite minor and hopefully painless.
>>>
>>> Because the commit is so big and so mechanical I elected to create a
>>> branch users/ppalka/readline-6.3-update where you can view/test the
>>> change.
>>>
>>> readline/ChangeLog.gdb:
>>>
>>>         Import readline 6.3 and upstream patches 1-8.
>>>         * configure: Regenerate.
>>>         * examples/rlfe/configure: Regenerate.
>>>         * complete.c: Reapply previous change.
>>
>> Hi.
>>
>> How does one easily audit whether all local patches are still present?
>> Looking at ChangeLog.gdb I'm left wondering.
>>
>> I'm not saying you've missed anything.
>> Rather, IWBN to have, after all your efforts,
>> a *simple* record of what's still local.
>>
>> One thought was to just nuke all of the old entries
>> in ChangeLog.gdb.  If you say there's only one local change
>> present then it should be a really small file.
>> [IOW, when we import a new readline from upstream,
>> reset ChangeLog.gdb.]
>>
>> Another thought, for those that have an aversion to
>> emptying out ChangeLog.gdb and starting over,
>> is to just add a line that says something like
>> "everything below this line is just
>> for the archive, ignore it otherwise", and copy up entries
>> for local patches that are still local.
>>
>> If the number of local patches is small (as it should be)
>> I like starting over with each new import.
>> But the high order bit for me is to be able to easily
>> audit/track/find local patches.
>
> Another option is that the commit responsible for syncing readline
> should mention which local commits have been reapplied in the commit
> message and also mention it in the ChangeLog.gdb entry.  So the local
> commits at any point in time would be all the commits that occurred
> after the latest readline import plus the earlier commits (if any)
> referenced in that readline import.
>
> I like that idea and the idea of trimming the ChangeLog.gdb file at
> each import too.

Another thought is that IWBN if the reapplication of local patches was
a separate commit.
Even better if each local patch was its own commit, but depending on
the quantity that may be too onerous (I don't think it is, I do this
for every major gdb release in our own tree, but I'm not the one doing
the work here:-)).
I realize this is more work, but IWBN to "see" a local patch with
minimal effort.

Thoughts?

Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Jan Kratochvil]

On Sat, 16 May 2015 17:23:23 +0200, Doug Evans wrote:
> Another thought is that IWBN if the reapplication of local patches was
> a separate commit.

IIUC this would break git bisect.


Jan

Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Patrick Palka]

On Sat, May 16, 2015 at 11:25 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Sat, 16 May 2015 17:23:23 +0200, Doug Evans wrote:
>> Another thought is that IWBN if the reapplication of local patches was
>> a separate commit.
>
> IIUC this would break git bisect.

Unless the local patch fixes a major issue (or perhaps a build error),
I don't think separately reapplying local patches would "break" git
bisect but it would possibly introduce temporary readline-related
testsuite regressions which are not relevant unless you're already
bisecting a readline-related issue.  I haven't used git bisect so I
may be wrong...  But if that's the case then IMO it's worth the
"breakage".

Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Doug Evans]

On Sat, May 16, 2015 at 8:25 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Sat, 16 May 2015 17:23:23 +0200, Doug Evans wrote:
>> Another thought is that IWBN if the reapplication of local patches was
>> a separate commit.
>
> IIUC this would break git bisect.

It might.  Bleah.

What's the "git" way to do this (*1) that doesn't involve a lot of
manual effort?
---
(*1): "this" being extracting out individual local patches later in
time (say a year from now).

Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Jan Kratochvil]

On Sat, 16 May 2015 17:50:14 +0200, Patrick Palka wrote:
> On Sat, May 16, 2015 at 11:25 AM, Jan Kratochvil
> <jan.kratochvil@redhat.com> wrote:
> > On Sat, 16 May 2015 17:23:23 +0200, Doug Evans wrote:
> >> Another thought is that IWBN if the reapplication of local patches was
> >> a separate commit.
> >
> > IIUC this would break git bisect.
> 
> Unless the local patch fixes a major issue (or perhaps a build error),

I wrote it in general.  When I read now that the only remaining patch is some
MS-Windows-specific one I agree it is safe; I doubt anyone would bisect on
MS-Windows or that it is too important.


Jan

Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Patrick Palka]

On Wed, May 13, 2015 at 9:40 PM, Patrick Palka <patrick@parcs.ath.cx> wrote:
> On Wed, May 13, 2015 at 8:12 PM, Patrick Palka <patrick@parcs.ath.cx> 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:

Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Patrick Palka]

On Mon, 18 May 2015, Patrick Palka wrote:

> On Wed, May 13, 2015 at 9:40 PM, Patrick Palka <patrick@parcs.ath.cx> wrote:
>> On Wed, May 13, 2015 at 8:12 PM, Patrick Palka <patrick@parcs.ath.cx> 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
      #
-- 
2.4.0.194.gc518059

Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Pedro Alves]

On 05/16/2015 04:51 PM, Doug Evans wrote:
> On Sat, May 16, 2015 at 8:25 AM, Jan Kratochvil
> <jan.kratochvil@redhat.com> wrote:
>> On Sat, 16 May 2015 17:23:23 +0200, Doug Evans wrote:
>>> Another thought is that IWBN if the reapplication of local patches was
>>> a separate commit.
>>
>> IIUC this would break git bisect.
> 
> It might.  Bleah.
> 
> What's the "git" way to do this (*1) that doesn't involve a lot of
> manual effort?
> ---
> (*1): "this" being extracting out individual local patches later in
> time (say a year from now).

I guess that would be a git merge of the branch that contains
the local patches.  We don't allow merge commits in our
repo though.

I think that easiest next best is to put the unsquashed application
of the local patches in a branch (just like users/ppalka/readline-6.3-update),
and apply the squashed version to master.  For the next update, we can
find the initial local patches in the branch.

Thanks,
Pedro Alves

Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Pedro Alves]

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

Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Doug Evans]

On Thu, Jun 18, 2015 at 5:39 AM, Pedro Alves <palves@redhat.com> wrote:
> On 05/16/2015 04:51 PM, Doug Evans wrote:
>> On Sat, May 16, 2015 at 8:25 AM, Jan Kratochvil
>> <jan.kratochvil@redhat.com> wrote:
>>> On Sat, 16 May 2015 17:23:23 +0200, Doug Evans wrote:
>>>> Another thought is that IWBN if the reapplication of local patches was
>>>> a separate commit.
>>>
>>> IIUC this would break git bisect.
>>
>> It might.  Bleah.
>>
>> What's the "git" way to do this (*1) that doesn't involve a lot of
>> manual effort?
>> ---
>> (*1): "this" being extracting out individual local patches later in
>> time (say a year from now).
>
> I guess that would be a git merge of the branch that contains
> the local patches.  We don't allow merge commits in our
> repo though.
>
> I think that easiest next best is to put the unsquashed application
> of the local patches in a branch (just like users/ppalka/readline-6.3-update),
> and apply the squashed version to master.  For the next update, we can
> find the initial local patches in the branch.

fwiw, I'm not comfortable with needing to rely on personal branches
for pretty much anything.

Can we make an official readline merging branch?
[assuming using a branch is how we want to solve this]

Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Pedro Alves]

On 06/18/2015 02:47 PM, Doug Evans wrote:
> On Thu, Jun 18, 2015 at 5:39 AM, Pedro Alves <palves@redhat.com> wrote:
>> On 05/16/2015 04:51 PM, Doug Evans wrote:
>>> On Sat, May 16, 2015 at 8:25 AM, Jan Kratochvil
>>> <jan.kratochvil@redhat.com> wrote:
>>>> On Sat, 16 May 2015 17:23:23 +0200, Doug Evans wrote:
>>>>> Another thought is that IWBN if the reapplication of local patches was
>>>>> a separate commit.
>>>>
>>>> IIUC this would break git bisect.
>>>
>>> It might.  Bleah.
>>>
>>> What's the "git" way to do this (*1) that doesn't involve a lot of
>>> manual effort?
>>> ---
>>> (*1): "this" being extracting out individual local patches later in
>>> time (say a year from now).
>>
>> I guess that would be a git merge of the branch that contains
>> the local patches.  We don't allow merge commits in our
>> repo though.
>>
>> I think that easiest next best is to put the unsquashed application
>> of the local patches in a branch (just like users/ppalka/readline-6.3-update),
>> and apply the squashed version to master.  For the next update, we can
>> find the initial local patches in the branch.
> 
> fwiw, I'm not comfortable with needing to rely on personal branches
> for pretty much anything.
> 
> Can we make an official readline merging branch?
> [assuming using a branch is how we want to solve this]

Don't see why not.  Is there more to it than picking a name?

Thanks,
Pedro Alves

Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8

[Doug Evans]

On Thu, Jun 18, 2015 at 9:07 AM, Pedro Alves <palves@redhat.com> wrote:
> On 06/18/2015 02:47 PM, Doug Evans wrote:
>> On Thu, Jun 18, 2015 at 5:39 AM, Pedro Alves <palves@redhat.com> wrote:
>>> On 05/16/2015 04:51 PM, Doug Evans wrote:
>>>> On Sat, May 16, 2015 at 8:25 AM, Jan Kratochvil
>>>> <jan.kratochvil@redhat.com> wrote:
>>>>> On Sat, 16 May 2015 17:23:23 +0200, Doug Evans wrote:
>>>>>> Another thought is that IWBN if the reapplication of local patches was
>>>>>> a separate commit.
>>>>>
>>>>> IIUC this would break git bisect.
>>>>
>>>> It might.  Bleah.
>>>>
>>>> What's the "git" way to do this (*1) that doesn't involve a lot of
>>>> manual effort?
>>>> ---
>>>> (*1): "this" being extracting out individual local patches later in
>>>> time (say a year from now).
>>>
>>> I guess that would be a git merge of the branch that contains
>>> the local patches.  We don't allow merge commits in our
>>> repo though.
>>>
>>> I think that easiest next best is to put the unsquashed application
>>> of the local patches in a branch (just like users/ppalka/readline-6.3-update),
>>> and apply the squashed version to master.  For the next update, we can
>>> find the initial local patches in the branch.
>>
>> fwiw, I'm not comfortable with needing to rely on personal branches
>> for pretty much anything.
>>
>> Can we make an official readline merging branch?
>> [assuming using a branch is how we want to solve this]
>
> Don't see why not.  Is there more to it than picking a name?

Can't think of anything.