From: Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
To: Pedro Alves <pedro@palves.net>,
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 14:48:16 +0200 [thread overview]
Message-ID: <76702685-e072-813e-07b5-9f3ab4878b94@suse.de> (raw)
In-Reply-To: <c7acde93-bec1-364d-4c82-745a76046381@palves.net>
[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]
On 9/24/21 2:21 PM, Pedro Alves wrote:
> On 2021-09-23 11:06 p.m., Tom de Vries via Gdb-patches wrote:
>
>> 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]
>
Hi,
thanks for the review.
> OOC, why "test -r" -> "cat" instead of "cat" straight away, which
> is basically what is done for the other dumps?
>
The other cases are commands without file argument, this is a command
with file argument. So, I was trying to not cause errors due to missing
file.
But you're right, it's not really necesssary.
> Consider factoring out a proc, like (untested, written in email):
>
Copied from mail, and done ... which also fixes the typo you reported.
I'll commit this unless there are further comments.
Thanks,
- Tom
[-- Attachment #2: 0002-gdb-testsuite-Factor-out-dump_info-in-gdb.testsuite-dump-system-info.exp.patch --]
[-- Type: text/x-patch, Size: 2020 bytes --]
[gdb/testsuite] Factor out dump_info in gdb.testsuite/dump-system-info.exp
Factor out new proc dump_info, and in the process:
- fix a few typos
- remove unnecessary "test -r /proc/cpuinfo"
Tested on x86_64-linux.
Co-Authored-By: Pedro Alves <pedro@palves.net>
---
gdb/testsuite/gdb.testsuite/dump-system-info.exp | 42 +++++++++---------------
1 file changed, 16 insertions(+), 26 deletions(-)
diff --git a/gdb/testsuite/gdb.testsuite/dump-system-info.exp b/gdb/testsuite/gdb.testsuite/dump-system-info.exp
index bf181469bd5..1831479265c 100644
--- a/gdb/testsuite/gdb.testsuite/dump-system-info.exp
+++ b/gdb/testsuite/gdb.testsuite/dump-system-info.exp
@@ -15,34 +15,24 @@
# 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]
+proc dump_info {cmd {what ""}} {
-if { $status == 0 } {
- verbose -log "lsb_release -a availabe, dumping:\n$output"
-} else {
- verbose -log "lsb_release -a not available"
-}
+ if {$what == ""} {
+ set what $cmd
+ }
-set res [remote_exec target "uname -a"]
-set status [lindex $res 0]
-set output [lindex $res 1]
+ set res [remote_exec target $cmd]
+ 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"
+ if { $status == 0 } {
+ verbose -log "$what available, dumping:\n$output"
+ } else {
+ verbose -log "$what not available"
+ }
}
+
+dump_info "cat /proc/cpuinfo" "Cpuinfo"
+dump_info "uname -a"
+dump_info "lsb_release -a"
next prev parent reply other threads:[~2021-09-24 12:48 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
2021-09-24 12:21 ` Pedro Alves
2021-09-24 12:48 ` Tom de Vries via Gdb-patches [this message]
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=76702685-e072-813e-07b5-9f3ab4878b94@suse.de \
--to=gdb-patches@sourceware.org \
--cc=pedro@palves.net \
--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