mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-12-15 04:31:49 +08:00
91395d97d9
This commit replaces an earlier commit that worked around the issues reported in bug PR gdb/28833. The previous commit just implemented a work around in order to avoid the worst results of the bug, but was not a complete solution. The full solution was considered too risky to merge close to branching GDB 12. This improved fix has been applied after GDB 12 branched. See this thread for more details: https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html This commit replaces this earlier commit: commit 74a159a420d4b466cc81061c16d444568e36740c Date: Fri Mar 11 14:44:03 2022 +0000 gdb: work around prompt corruption caused by bracketed-paste-mode Please read that commit for a full description of the bug, and why is occurs. In this commit I extend GDB to use readline's rl_deprep_term_function hook to call a new function gdb_rl_deprep_term_function. From this new function we can now print the 'quit' message, this replaces the old printing of 'quit' in command_line_handler. Of course, we only print 'quit' in gdb_rl_deprep_term_function when we are handling EOF, but thanks to the previous commit (to readline) we now know when this is. There are two aspects of this commit that are worth further discussion, the first is in the new gdb_rl_deprep_term_function function. In here I have used a scoped_restore_tmpl to disable the readline global variable rl_eof_found. The reason for this is that, in rl_deprep_terminal, readline will print an extra '\n' character before printing the escape sequence to leave bracketed paste mode. You might then think that in the gdb_rl_deprep_term_function function, we could simply print "quit" and rely on rl_deprep_terminal to print the trailing '\n'. However, rl_deprep_terminal only prints the '\n' when bracketed paste mode is on. If the user has turned this feature off, no '\n' is printed. This means that in gdb_rl_deprep_term_function we need to print "quit" when bracketed paste mode is on, and "quit\n" when bracketed paste mode is off. We could absolutely do that, no problem, but given we know how rl_deprep_terminal is implemented, it's easier (I think) to just temporarily clear rl_eof_found, this prevents the '\n' being printed from rl_deprep_terminal, and so in gdb_rl_deprep_term_function, we can now always print "quit\n" and this works for all cases. The second issue that should be discussed is backwards compatibility with older versions of readline. GDB can be built against the system readline, which might be older than the version contained within GDB's tree. If this is the case then the system readline might not contain the fixes needed to support correctly printing the 'quit' string. To handle this situation I have retained the existing code in command_line_handler for printing 'quit', however, this code is only used now if the version of readline we are using doesn't not include the required fixes. And so, if a user is using an older version of readline, and they have bracketed paste mode on, then they will see the 'quit' sting printed on the line below the prompt, like this: (gdb) quit I think this is the best we can do when someone builds GDB against an older version of readline. Using a newer version of readline, or the patched version of readline that is in-tree, will now give a result like this in all cases: (gdb) quit Which is what we want. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833 |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
contrib | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gdbserver | ||
gdbsupport | ||
gnulib | ||
gold | ||
gprof | ||
gprofng | ||
include | ||
intl | ||
ld | ||
libbacktrace | ||
libctf | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
ar-lib | ||
ChangeLog | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
COPYING | ||
COPYING3 | ||
COPYING3.LIB | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
lt~obsolete.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
MAINTAINERS | ||
Makefile.def | ||
Makefile.in | ||
Makefile.tpl | ||
makefile.vms | ||
missing | ||
mkdep | ||
mkinstalldirs | ||
move-if-change | ||
multilib.am | ||
README | ||
README-maintainer-mode | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
test-driver | ||
ylwrap |
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.