mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-25 21:41:47 +08:00
8900d71e38
In readline 6.3, the semantics of SIGWINCH handling has changed. When a SIGWINCH signal is raised, readline's rl_sigwinch_handler() now does not immediately call rl_resize_terminal(). Instead it sets a flag that is checked by RL_CHECK_SIGNALS() at a point where readline has control, and calls rl_resize_terminal() if said flag is set. This change is item (c) in https://cnswww.cns.cwru.edu/php/chet/readline/CHANGES c. Fixed a bug that caused readline to try and run code to modify its idea of the screen size in a signal handler context upon receiving a SIGWINCH. This change in behavior is important to us because TUI's tui_sigwinch_handler() relies on the assumption that by the time it's called, readline will have updated its knowledge of the terminal dimensions via rl_resize_terminal(). Since this assumption no longer holds true, TUI's SIGWINCH handling does not work correctly with readline 6.3. To fix this issue this patch makes TUI explicitly call rl_resize_terminal() in tui_async_resize_screen() at the point where current terminal dimensions are needed. (We could call it in tui_sigwinch_handler too, but since readline avoids doing it, we are probably safer off avoiding to call it in signal handler context as well.) After this change, SIGWINCH handling continues to work properly with both readline 6.2 and 6.3. Since we no longer need it, we could now explicitly disable readline's SIGWINCH handler by setting rl_catch_sigwinch to zero early on in the program startup but I can't seem to find a good spot to place this assignment (the first call to rl_initialize() occurs in tui_initialize_readline() so the assignment should occur before then), and the handler is harmless anyway. gdb/ChangeLog: * tui/tui-win.c (tui_async_resize_screen): Call rl_resize_terminal().
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.