lib/56370: libedit change from 2017 kills history in gdb

[tg%mirbsd.org@localhost]

>Number:         56370
>Category:       lib
>Synopsis:       libedit change from 2017 kills history in gdb
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Aug 21 06:00:01 +0000 2021
>Originator:     mirabilos
>Release:        NetBSD-current as of 2021-07-07
>Organization:
MirBSD
>Environment:
MirBSD tglase-bsd.lan.tarent.de 10 Kv#10uB9-20210130 GENERIC#1570 i386

>Description:
The changes from src/lib/libedit/readline.c r1.142 break gdb?s history.

This can be seen in a gdb built with libedit: after entering a command like ?info r?, both Cur↑ and Esc+x+?history list?+Enter don?t show a thing.

Further debugging unveils that the readline.c-global ?h? pointer differs between each command line. It shows that gdb?s display_gdb_prompt() in event-top.c does?

  if (async_command_editing_p)
    {
      rl_callback_handler_remove ();
      rl_callback_handler_install (new_prompt, input_handler);
    }

? (or the equivalent in gdb 10.x which I quickly looked at, but I run 6.3.50.20050707 as last GPLv2 version). Given that latest gdb still does this, it doesn?t look like an accident.

christos@ changed rl_callback_handler_remove to call el_end(e); in?

   Revision [237]1.142 / ([238]download) - [239]annotate - [240][select for diffs], Fri Sep 1 10:19:10 2017
   UTC (3 years, 11 months ago) by christos
   Branch: [241]MAIN
   Changes since 1.141: +38 -6 lines
   Diff to previous [242]1.141 ([243]colored)
PR/51517: Jay West: Tty settings not restored on exit
PR/51518: Jay West: prompt is interleaved with client output

Both these issues are caused by rl_restore_handler not DTRT; fix
it so that it kills the internal libedit state completely. This is
inefficient, but it works.

Also fix:
1. add append_history()/H_NSAVE_FP
2. call the rl_startup_hook before printing the first prompt as documented.
   callint it from rl_initialize breaks python, because the callback ends
   up being invoked before the readline module is installed, and we end up
   dereferencing a NULL pointer.   
3. add el_resize_terminal.

With those changes, s/lreadline/ledit/g in python works.

? referring https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=52518 and https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=52517 but this is problematic: el_end causes e to be NULL?d, so the next function (rightfully) calls rl_initialize(), which proceeds to drop the entire history then create a new one.

The actual patch committed tackles at least four if not five issues at once, but it differs largely from the patches proposed in those PRs. I?m not sure if that was intended, or if it just looked to fix the python problem so it was decided to use the smaller(?) change.
>How-To-Repeat:
gdb /bin/sh <enter> info r <enter> <cursor-up>
>Fix:
When I apply the patch originally shown, my problem goes away. Not sure if it introduces any others?

Index: readline.c
===================================================================
RCS file: /cvs/src/lib/libedit/readline.c,v
retrieving revision 1.8
diff -u -p -r1.8 readline.c
--- readline.c	7 Jul 2021 05:12:27 -0000	1.8
+++ readline.c	21 Aug 2021 05:56:28 -0000
@@ -2067,6 +2067,7 @@ rl_callback_read_char(void)
 	const char *buf = el_gets(e, &count);
 	char *wbuf;
 
+	el_set(e, EL_UNBUFFERED, 1);
 	if (buf == NULL || count-- <= 0)
 		return;
 	if (count == 0 && buf[0] == e->el_tty.t_c[TS_IO][C_EOF])
@@ -2082,7 +2083,6 @@ rl_callback_read_char(void)
 		} else
 			wbuf = NULL;
 		(*(void (*)(const char *))rl_linefunc)(wbuf);
-		el_set(e, EL_UNBUFFERED, 1);
 	}
 }
 
@@ -2100,9 +2100,8 @@ rl_callback_handler_install(const char *
 void
 rl_callback_handler_remove(void)
 {
+	el_set(e, EL_UNBUFFERED, 0);
 	rl_linefunc = NULL;
-	el_end(e);
-	e = NULL;
 }
 
 void