e7b430724d
While working on another patch I noticed that if I disable a single
style with, for example:
set style filename background none
set style filename foreground none
set style filename intensity normal
Then in some places escape characters are still injected into the
output stream. This is a bit of an edge case, and I can't think when
this would actually cause problems, but it still felt like a bit of an
annoyance.
One place where this does impact is in testing, where it becomes
harder to write tight test patterns if it is not obvious when GDB will
decide to inject escape sequences.
It's especially annoying because depending on how something is printed
then GDB might, or might not, add escape characters. So this would
not add escape characters if the filename style was disabled:
fprintf_filtered (file, "%ps",
styled_string (file_name_style.style (),
"This is a test"));
But this would add escape characters:
fprintf_styled (file, file_name_style.style (),
"%s", "This is a test");
I tracked this down to some calls to set_output_style in utils.c.
Currently some calls to set_output_style (in utils.c) are guarded like
this:
if (!STYLE.is_default ())
set_output_style (stream, STYLE);
But some calls are not. It is the calls that are NOT guarded that
cause the extra escape sequences to be emitted.
My initial proposal to resolve this issue was simply to ensure that
all calls to set_output_style were guarded. The patch I posted for
this can be found here:
https://sourceware.org/pipermail/gdb-patches/2021-January/175096.html
The feedback on this proposal was that it might be better to guard
against the escape sequences being emitted at a later lever, right
down at emit_style_escape.
So this is what this version does. In emit_style_escape we already
track the currently applied style, so if the style we are being asked
to switch to is the same as the currently applied style then no escape
sequence needs to be emitted.
Making this change immediately exposed some issues in
fputs_maybe_filtered related to line wrapping. The best place to start
to understand what's going on with the styling and wrapping is look at
the test:
gdb.base/style.exp: all styles enabled: frame when width=20
If you run this test and then examine the output in an editor so the
escape sequences can be seen you'll see the duplicate escape sequences
that are emitted before this patch, the compare to after this patch
you'll see the set of escape sequences should be the minimum required.
In order to test these changes I have rewritten the gdb.base/style.exp
test script. The core of the script is now run multiple times. The
first time the test is run things are as they were before, all styles
are on.
After that the test is rerun multiple times. Each time through a
single style is disabled using the 3 explicit set calls listed above.
I then repeat all the tests, however, I arrange so that the patterns
for the disabled style now require no escape sequences.
gdb/ChangeLog:
* utils.c (emit_style_escape): Only emit an escape sequence if the
requested style is different than the current applied style.
(fputs_maybe_filtered): Adjust the juggling of the wrap_style, and
current applied_style.
(fputs_styled): Remove is_default check.
(fputs_styled_unfiltered): Likewise.
(vfprintf_styled_no_gdbfmt): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/style.exp (limited_style): New proc.
(clean_restart_and_disable): New proc.
(run_style_tests): New proc. Most of the old tests from this file
are now in this proc.
(test_startup_version_string): New proc. Reamining test from the
old file is in this proc.
|
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| contrib | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gdbserver | ||
| gdbsupport | ||
| gnulib | ||
| gold | ||
| gprof | ||
| include | ||
| intl | ||
| ld | ||
| libctf | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| zlib | ||
| .cvsignore | ||
| .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.