From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 763693857C7D for ; Tue, 12 Jul 2022 13:49:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 763693857C7D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id A3F4F302AB2C; Tue, 12 Jul 2022 15:49:15 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 0141D400B8BD; Tue, 12 Jul 2022 15:49:14 +0200 (CEST) Message-ID: <4e51d3d6f9f1671bac7549c88318bc68a7c4034e.camel@klomp.org> Subject: Re: patch testsuite - verbose logging From: Mark Wielaard To: "Frank Ch. Eigler" , dwz@sourceware.org Date: Tue, 12 Jul 2022 15:49:14 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00, GIT_PATCH_0, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: dwz@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dwz mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2022 13:49:19 -0000 Hi Frank, On Wed, 2022-07-06 at 13:25 -0400, Frank Ch. Eigler via Dwz wrote: > The following patch puts "sh -x" tracing data into the dwz.log file. I agree it would be good to have a bit more information in the dwz.log file. But -x is very verbose. I might get lost. But maybe others think it is fine. I am not against it. But I think just capturing stdout and verbose log it is fine. We can add some extra echos in the tests. > Accidentally, this makes debuginfod-involving tests pass, since their > stderr DEBUGINFOD_PRGRESS traffic show up in stdout rather than > stderr > (which is recorded as a fail). I think that is a reason to not do the 2>@ redirection. We did recently find an issue with gdb-add-index because it had error output. And I think we would like to know if the tests accidentially triggered debuginfod because that really isn't supposed to happen. So if it does I think we want the testcase to fail so we can investigate why debuginfod is trying to fetch something when it shouldn't. Cheers, Mark > diff --git a/testsuite/dwz.tests/dwz-tests.exp > b/testsuite/dwz.tests/dwz-tests.exp > index 811767f57918..73fe73716302 100644 > --- a/testsuite/dwz.tests/dwz-tests.exp > +++ b/testsuite/dwz.tests/dwz-tests.exp > @@ -116,7 +116,8 @@ foreach test $tests { > exec mkdir $dir > =20 > cd $dir > - if { [catch { exec sh -e $test } msg] } { > + if { [catch { exec sh -x -e $test 2>@ stdout } msg] } { > + verbose -log "$msg" > if { [lindex $::errorCode 0] =3D=3D "CHILDSTATUS" && \ > [lindex $::errorCode 2] =3D=3D 77 } { > unsupported "$test" > @@ -126,6 +127,7 @@ foreach test $tests { > fail "$test" > } > } else { > + verbose -log "$msg" > if { [file exists dwz.info ] } { > set info [exec cat dwz.info] > verbose -log "$test:" 1