This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] GDB testsuite: Suppress GCC's colored output


On 2017-08-08 20:28, Andreas Arnez wrote:
On Fri, Aug 04 2017, 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.

Hm, what scenario are you referring to?  It *does* work with
"--target_board=native-gdbserver", at least on the system I've tested it
on.  And a cross-target config should work as well, right?

I believe Yao meant "host" in the build/host/target sense. The debugger and compiler you are producing run on the host machine, doing some compiling/debugging about the target architecture. Let's say you're working on x86, cross-compiling a GDB that should run on ARM to debug native programs on ARM. You have

build: x86
host: arm
target: arm

When you run the GDB testsuite, it's on your x86 machine, but the GDB you built has to run on an ARM board, therefore you will have a remote host. You would then most likely specify the same host and target (though they could be different), with --host_board=my-arm-board --target_board=my-arm-board. The compilation of test cases also happens on the host, which means it will also be remote. And that's where unsetting the GCC_COLORS environment variable on the build machine doesn't help.

How about passing option -fno-color-diagnostics to compiler which
supports that option?  Both gcc (4.9 and later) and clang has this
option.

Actually, clang only, AFAIK.  And I don't know that there is a
compatible option between GCC and clang for disabling colored
diagnostics.  Clang's manual page (1) mentions

  -f[no-]color-diagnostics

whereas GCC has

  -fdiagnostics-color[=WHEN]
  -fno-diagnostics-color

So unless I missed something, we have to handle clang and GCC
separately.

See below for an alternative patch that tries the GCC option
"-fdiagnostics-color=never".  We could possibly enrich this and try
clang's "-fno-color-diagnostics" if that fails.

clang actually supports -fdiagnostics-color=never from what I saw, even though it may not be documented. So we can rely on that.

* (1) https://clang.llvm.org/docs/UsersManual.html

--
Andreas


Subject: [PATCH v2] GDB testsuite: Suppress GCC's colored output

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.

gdb/testsuite/ChangeLog:

	* lib/gdb.exp (universal_compile_options): New caching proc.
	(gdb_compile): Suppress GCC's coloring of messages.
---
 gdb/testsuite/lib/gdb.exp | 30 +++++++++++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 3d3eaab..51bf848 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -3368,6 +3368,34 @@ proc gdb_wrapper_init { args } {
     set gdb_wrapper_target [current_target_name]
 }

+# Determine options that we always want to pass to the compiler.
+gdb_caching_proc universal_compile_options {
+    set me "universal_compile_options"
+    set options {}
+
+    set src [standard_temp_file ccopts[pid].c]
+    set obj [standard_temp_file ccopts[pid].o]
+
+    gdb_produce_source $src {
+	int foo(void) { return 0; }
+    }
+
+    # Try an option for disabling colored diagnostics.  Some compilers
+ # yield colored diagnostics by default (when run from a tty) unless
+    # such an option is specified.
+    set opt "additional_flags=-fdiagnostics-color=never"
+    set lines [target_compile $src $obj object [list "quiet" $opt]]
+    if [string match "" $lines] then {
+	# Seems to have worked; use the option.
+	lappend options $opt
+    }
+    file delete $src
+    file delete $obj
+
+    verbose "$me:  returning $options" 2
+    return $options
+}
+
# Some targets need to always link a special object in. Save its path here.
 global gdb_saved_set_unbuffered_mode_obj
 set gdb_saved_set_unbuffered_mode_obj ""
@@ -3419,7 +3447,7 @@ proc gdb_compile {source dest type options} {

# Add platform-specific options if a shared library was specified using
     # "shlib=librarypath" in OPTIONS.
-    set new_options ""
+    set new_options [universal_compile_options]
     set shlib_found 0
     set shlib_load 0
     foreach opt $options {

I have not tried it yet, but at first glance it seems on the right path.

Thanks,

Simon


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]