From: Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
To: Simon Marchi <simon.marchi@polymtl.ca>, gdb-patches@sourceware.org
Subject: Re: [PATCH][gdb/testsuite] Dump /proc/cpuinfo into gdb.log
Date: Fri, 24 Sep 2021 00:06:34 +0200 [thread overview]
Message-ID: <bf294433-4a48-8294-1082-0870cacdfb10@suse.de> (raw)
In-Reply-To: <671f08cc-cc93-f36e-563d-20f2be20488e@polymtl.ca>
[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]
On 9/23/21 4:32 PM, Simon Marchi wrote:
>
>
> On 2021-09-21 4:01 a.m., Tom de Vries via Gdb-patches wrote:
>> 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.
>
> I think in the gdb.testsuite directory is fine.
>
Ack (still leaving the comment in the log message though).
> I like the idea. I even think it would be useful to dump more things
> about the system, like:
>
> - "--version" output of compilers used for testing
> - "lsb_release -a" output (if lsb_release is available)
> - "uname -a" output (if uname is available)
I've added the latter two (and renamed the test-case to
dump-system-info.exp).
I'm not sure about compiler version, ISTM we already have that
information in the log (though you may have to grep for it).
> Can you think of more?
>
Atm not, no. I guess we can add if and when we think of something else.
At least this gives us a place to add it to.
I'll commit tomorrow unless there are further comments.
Thanks,
- Tom
> Simon
>
[-- Attachment #2: 0002-gdb-testsuite-Add-gdb.testsuite-dump-system-info.exp.patch --]
[-- Type: text/x-patch, Size: 3014 bytes --]
[gdb/testsuite] Add gdb.testsuite/dump-system-info.exp
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, as well as lsb_release -a
and uname -a.
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
could be put into a new gdb.info directory, since the test-case doesn't
actually test the testsuite. ]
Tested on x86_64-linux.
---
gdb/testsuite/gdb.testsuite/dump-system-info.exp | 48 ++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/gdb/testsuite/gdb.testsuite/dump-system-info.exp b/gdb/testsuite/gdb.testsuite/dump-system-info.exp
new file mode 100644
index 00000000000..bf181469bd5
--- /dev/null
+++ b/gdb/testsuite/gdb.testsuite/dump-system-info.exp
@@ -0,0 +1,48 @@
+# 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 <http://www.gnu.org/licenses/>.
+
+# The purpose of this test-case is to dump /proc/cpuinfo and similar system
+# info 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"
+}
+
+set res [remote_exec target "lsb_release -a"]
+set status [lindex $res 0]
+set output [lindex $res 1]
+
+if { $status == 0 } {
+ verbose -log "lsb_release -a availabe, dumping:\n$output"
+} else {
+ verbose -log "lsb_release -a not available"
+}
+
+set res [remote_exec target "uname -a"]
+set status [lindex $res 0]
+set output [lindex $res 1]
+
+if { $status == 0 } {
+ verbose -log "uname -a availabe, dumping:\n$output"
+} else {
+ verbose -log "uname -a not available"
+}
next prev parent reply other threads:[~2021-09-23 22:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-21 8:01 Tom de Vries via Gdb-patches
2021-09-23 14:32 ` Simon Marchi via Gdb-patches
2021-09-23 22:06 ` Tom de Vries via Gdb-patches [this message]
2021-09-24 12:21 ` Pedro Alves
2021-09-24 12:48 ` Tom de Vries via Gdb-patches
2021-09-24 13:10 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bf294433-4a48-8294-1082-0870cacdfb10@suse.de \
--to=gdb-patches@sourceware.org \
--cc=simon.marchi@polymtl.ca \
--cc=tdevries@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox