From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from elastic.org (elastic.org [96.126.110.187]) by sourceware.org (Postfix) with ESMTPS id CB4D7385694F for ; Tue, 12 Jul 2022 14:09:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CB4D7385694F Received: from vpn-home.elastic.org ([10.0.0.2] helo=elastic.org) by elastic.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oBGZQ-0003TA-1D; Tue, 12 Jul 2022 14:09:01 +0000 Received: from very.elastic.org ([192.168.1.1]) by elastic.org with esmtp (Exim 4.94.2) (envelope-from ) id 1oBGZQ-000ESH-Tf; Tue, 12 Jul 2022 10:09:00 -0400 Received: from fche by very.elastic.org with local (Exim 4.94.2) (envelope-from ) id 1oBGZQ-007tQC-LF; Tue, 12 Jul 2022 10:09:00 -0400 Date: Tue, 12 Jul 2022 10:09:00 -0400 From: "Frank Ch. Eigler" To: Mark Wielaard Cc: dwz@sourceware.org Subject: Re: patch testsuite - verbose logging Message-ID: References: <4e51d3d6f9f1671bac7549c88318bc68a7c4034e.camel@klomp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4e51d3d6f9f1671bac7549c88318bc68a7c4034e.camel@klomp.org> X-Sender-Verification: "" X-Spam-Status: No, score=-101.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, USER_IN_WELCOMELIST, USER_IN_WHITELIST 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 14:09:03 -0000 Hi - > 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. There is no 'verbose log' content in the .log file possible at the present in the sense of RUNTESTFLAGS=-v. These log files are for helping someone debug failing tests, so normally one does not need to look at them, let alone get lost. > > 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 [...] A simpler cure to that is to have the testuite makefile driver unset $DEBUGINFOD_URLS before invoking dejagnu. - FChE