From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ApJhDZqRSWE7KAAAWB0awg (envelope-from ) for ; Tue, 21 Sep 2021 04:02:34 -0400 Received: by simark.ca (Postfix, from userid 112) id 0873A1EE25; Tue, 21 Sep 2021 04:02:33 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id D061D1EDF7 for ; Tue, 21 Sep 2021 04:02:24 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A3F493858421 for ; Tue, 21 Sep 2021 08:02:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A3F493858421 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1632211342; bh=bSed9hzVr1BnTI6JK1baWMLsyWbDL6UCDx7ZqGG9Ok8=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=vsJJyy1efWA1vmoz8KG/Vm2mpEWJCAXkIvxC/4xtRiB1SP8J507y5rWsYNsw8M+YB +Gb2sJgC1Xtu06Rz6vgamsRYk8APVTsP2JoouO60BHqSjjfjiR7gbWzh2NPOw4bdy7 dEi/77hjPZVaXy3UowhBpK//ngsFwVw6dn4tNwRU= Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id BD7233858C3A for ; Tue, 21 Sep 2021 08:02:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BD7233858C3A Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id BA81322098 for ; Tue, 21 Sep 2021 08:02:00 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id A65F013B9C for ; Tue, 21 Sep 2021 08:02:00 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id j6GAJ3iRSWHvFgAAMHmgww (envelope-from ) for ; Tue, 21 Sep 2021 08:02:00 +0000 Date: Tue, 21 Sep 2021 10:01:59 +0200 To: gdb-patches@sourceware.org Subject: [PATCH][gdb/testsuite] Dump /proc/cpuinfo into gdb.log Message-ID: <20210921080157.GA18967@delia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Tom de Vries via Gdb-patches Reply-To: Tom de Vries Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi, When interpreting the testsuite results, it's often relevant what kind of machine the testsuite ran on. On a local machine one can just do /proc/cpuinfo, but in case of running tests using a remote system that distributes test runs to other remote systems that are not directly accessible, that's not possible. Fix this by dumping /proc/cpuinfo into the gdb.log. We could do this at the start of each test run, by putting it into unix.exp or some such. However, this might be too verbose, so we choose to put it into its own test-case, such that it get triggered in a full testrun, but not when running one or a subset of tests. We put the test-case into the gdb.testsuite directory, which is currently the only place in the testsuite where we do not test gdb. Though perhaps this should be put into a new gdb.info directory, since the test-case doesn't actually test the testsuite. Tested on x86_64-linux. Any comments? Thanks, - Tom [gdb/testsuite] Dump /proc/cpuinfo into gdb.log --- gdb/testsuite/gdb.testsuite/dump-cpuinfo.exp | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/gdb/testsuite/gdb.testsuite/dump-cpuinfo.exp b/gdb/testsuite/gdb.testsuite/dump-cpuinfo.exp new file mode 100644 index 00000000000..ee94aa1ae32 --- /dev/null +++ b/gdb/testsuite/gdb.testsuite/dump-cpuinfo.exp @@ -0,0 +1,27 @@ +# Copyright 2021 Free Software Foundation, Inc. +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +# The purpose of this test-case is to dump /proc/cpuinfo into gdb.log. + +# Check if /proc/cpuinfo is available. +set res [remote_exec target "test -r /proc/cpuinfo"] +set status [lindex $res 0] +set output [lindex $res 1] + +if { $status == 0 && $output == "" } { + verbose -log "Cpuinfo available, dumping:" + remote_exec target "cat /proc/cpuinfo" +} else { + verbose -log "Cpuinfo not available" +}