Message ID | m3vam527qh.fsf@oc1027705133.ibm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 74855 invoked by alias); 2 Aug 2017 17:35:30 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 74812 invoked by uid 89); 2 Aug 2017 17:35:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=H*o:Research, colored X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 Aug 2017 17:35:27 +0000 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v72HYMsh114386 for <gdb-patches@sourceware.org>; Wed, 2 Aug 2017 13:35:26 -0400 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0a-001b2d01.pphosted.com with ESMTP id 2c3e4vrubc-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for <gdb-patches@sourceware.org>; Wed, 02 Aug 2017 13:35:25 -0400 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <gdb-patches@sourceware.org> from <arnez@linux.vnet.ibm.com>; Wed, 2 Aug 2017 18:35:23 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 Aug 2017 18:35:20 +0100 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v72HZKBI17563950 for <gdb-patches@sourceware.org>; Wed, 2 Aug 2017 17:35:20 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7EF8442047 for <gdb-patches@sourceware.org>; Wed, 2 Aug 2017 18:32:24 +0100 (BST) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 659EA42041 for <gdb-patches@sourceware.org>; Wed, 2 Aug 2017 18:32:24 +0100 (BST) Received: from oc1027705133.ibm.com (unknown [9.152.212.202]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTPS for <gdb-patches@sourceware.org>; Wed, 2 Aug 2017 18:32:24 +0100 (BST) From: Andreas Arnez <arnez@linux.vnet.ibm.com> To: gdb-patches@sourceware.org Subject: [PATCH] GDB testsuite: Suppress GCC's colored output Date: Wed, 02 Aug 2017 19:35:18 +0200 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 x-cbid: 17080217-0012-0000-0000-0000056A5797 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17080217-0013-0000-0000-000018E00F40 Message-Id: <m3vam527qh.fsf@oc1027705133.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-02_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708020284 X-IsSubscribed: yes |
Commit Message
Andreas Arnez
Aug. 2, 2017, 5:35 p.m. UTC
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 (gdb_compile): Suppress GCC's coloring of messages. --- gdb/testsuite/lib/gdb.exp | 3 +++ 1 file changed, 3 insertions(+)
Comments
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.