| Message ID | m3vam527qh.fsf@oc1027705133.ibm.com |
|---|---|
| State | New |
| Headers | show |
On 2017-08-02 19:35, Andreas Arnez wrote: > Newer GCC versions yield colored diagnostic messages by default, which > may > be useful when executing GDB interactively from a terminal. But when > run > from a GDB test case, the compiler output is written into gdb.log, > where > such escape sequences are usually more inhibiting than helpful to the > evaluation of test results. So this patch suppresses that. That's because you are not using the right viewer :). Try "less -R gdb.log", you should see the rainbow. > > gdb/testsuite/ChangeLog: > > * lib/gdb.exp (gdb_compile): Suppress GCC's coloring of messages. > --- > gdb/testsuite/lib/gdb.exp | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp > index 3d3eaab..9a5c27f 100644 > --- a/gdb/testsuite/lib/gdb.exp > +++ b/gdb/testsuite/lib/gdb.exp > @@ -3552,6 +3552,9 @@ proc gdb_compile {source dest type options} { > } > } > > + # Stop the compiler from producing colored output. > + setenv GCC_COLORS "" > + > set result [target_compile $source $dest $type $options] > > # Prune uninteresting compiler (and linker) output. I was wondering why GCC showed colors even though it's not invoked "interactively". Dejagnu uses expect's spawn to spawn processes, including the compiler. spawn allocates a tty for the subprocess, which is what GCC checks to determine whether or not to enable colors. You patch LGTM, but please leave the patch for review for a few days, then push it if nobody says anything. Thanks! Simon
On Wed, Aug 02 2017, Simon Marchi wrote: > On 2017-08-02 19:35, Andreas Arnez wrote: >> Newer GCC versions yield colored diagnostic messages by default, which >> may >> be useful when executing GDB interactively from a terminal. But when >> run >> from a GDB test case, the compiler output is written into gdb.log, where >> such escape sequences are usually more inhibiting than helpful to the >> evaluation of test results. So this patch suppresses that. > > That's because you are not using the right viewer :). Try "less -R > gdb.log", you should see the rainbow. Right... That's why I wrote "usually". Such as when using "grep", loading the file into an editor, pasting the error message into an e-Mail, etc. > >> >> gdb/testsuite/ChangeLog: >> >> * lib/gdb.exp (gdb_compile): Suppress GCC's coloring of messages. >> --- >> gdb/testsuite/lib/gdb.exp | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp >> index 3d3eaab..9a5c27f 100644 >> --- a/gdb/testsuite/lib/gdb.exp >> +++ b/gdb/testsuite/lib/gdb.exp >> @@ -3552,6 +3552,9 @@ proc gdb_compile {source dest type options} { >> } >> } >> >> + # Stop the compiler from producing colored output. >> + setenv GCC_COLORS "" >> + >> set result [target_compile $source $dest $type $options] >> >> # Prune uninteresting compiler (and linker) output. > > I was wondering why GCC showed colors even though it's not invoked > "interactively". Dejagnu uses expect's spawn to spawn processes, > including the compiler. spawn allocates a tty for the subprocess, which > is what GCC checks to determine whether or not to enable colors. Right. If spawn used a pipe instead of a pseudo-tty, then GCC wouldn't show colors. > You patch LGTM, but please leave the patch for review for a few days, then > push it if nobody says anything. OK. -- Andreas
Andreas Arnez <arnez@linux.vnet.ibm.com> writes: Hi Andreas, > + # Stop the compiler from producing colored output. > + setenv GCC_COLORS "" > + This doesn't work for remote host. How about passing option -fno-color-diagnostics to compiler which supports that option? Both gcc (4.9 and later) and clang has this option.
On 2017-08-04 13:06, Yao Qi wrote: > Andreas Arnez <arnez@linux.vnet.ibm.com> writes: > > Hi Andreas, > >> + # Stop the compiler from producing colored output. >> + setenv GCC_COLORS "" >> + > > This doesn't work for remote host. How about passing option > -fno-color-diagnostics to compiler which supports that option? Both > gcc > (4.9 and later) and clang has this option. My gcc (5.4) doesn't recognize it: $ gcc -fno-color-diagnostics test.c gcc: error: unrecognized command line option ‘-fno-color-diagnostics’ It knows about -fdiagnostics-color=never however, which clang seems to recognize as well. It would be nice however not to restrict the compiler version used for testing just for this. Can we write a small proc that checks if the compiler recognizes that flag and only include it if it does? Simon
Simon Marchi <simon.marchi@polymtl.ca> writes: > My gcc (5.4) doesn't recognize it: > > $ gcc -fno-color-diagnostics test.c > gcc: error: unrecognized command line option ‘-fno-color-diagnostics’ > Ah, sorry. What I meant is -fdiagnostics-color=never. > It knows about -fdiagnostics-color=never however, which clang seems to > recognize as well. It would be nice however not to restrict the > compiler version used for testing just for this. Can we write a small > proc that checks if the compiler recognizes that flag and only include > it if it does? Yes, we can do that, but be careful on the recursive calls here. We want to pass -fdiagnostics-color=never to compiler during compilation, but we need to check whether compiler understands this option or not. When we test compiler, we may pass -fdiagnostics-color=never to compiler to try to compile something again to see if compiler understands.
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 3d3eaab..9a5c27f 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -3552,6 +3552,9 @@ proc gdb_compile {source dest type options} { } } + # Stop the compiler from producing colored output. + setenv GCC_COLORS "" + set result [target_compile $source $dest $type $options] # Prune uninteresting compiler (and linker) output.