[TCWG CI] Regression caused by binutils: [gdb/testsuite] Add gdb.testsuite/dump-system-info.exp: commit b4e4386a2e58ba6ce8d02b952f1bc6ceb8fc95d1 Author: Tom de Vries tdevries@suse.de
[gdb/testsuite] Add gdb.testsuite/dump-system-info.exp
Results regressed to # reset_artifacts: -10 # build_abe binutils: -9 # build_abe stage1 -- --set gcc_override_configure=--disable-libsanitizer --set gcc_override_configure=--disable-multilib --set gcc_override_configure=--with-cpu=cortex-m4 --set gcc_override_configure=--with-mode=thumb --set gcc_override_configure=--with-float=hard: -8 # build_abe newlib: -6 # build_abe stage2 -- --patch linaro-local/vect-metric-branch --set gcc_override_configure=--disable-libsanitizer --set gcc_override_configure=--disable-multilib --set gcc_override_configure=--with-cpu=cortex-m4 --set gcc_override_configure=--with-mode=thumb --set gcc_override_configure=--with-float=hard: -5 # true: 0 # benchmark -- -O3_VECT_mthumb artifacts/build-b4e4386a2e58ba6ce8d02b952f1bc6ceb8fc95d1/results_id: 1
from # reset_artifacts: -10 # build_abe binutils: -9 # build_abe stage1 -- --set gcc_override_configure=--disable-libsanitizer --set gcc_override_configure=--disable-multilib --set gcc_override_configure=--with-cpu=cortex-m4 --set gcc_override_configure=--with-mode=thumb --set gcc_override_configure=--with-float=hard: -8 # build_abe newlib: -6 # build_abe stage2 -- --patch linaro-local/vect-metric-branch --set gcc_override_configure=--disable-libsanitizer --set gcc_override_configure=--disable-multilib --set gcc_override_configure=--with-cpu=cortex-m4 --set gcc_override_configure=--with-mode=thumb --set gcc_override_configure=--with-float=hard: -5 # true: 0 # benchmark -- -O3_VECT_mthumb artifacts/build-baseline/results_id: 1
THIS IS THE END OF INTERESTING STUFF. BELOW ARE LINKS TO BUILDS, REPRODUCTION INSTRUCTIONS, AND THE RAW COMMIT.
This commit has regressed these CI configurations: - tcwg_bmk_gnu_eabi_stm32/gnu_eabi-master-arm_eabi-coremark-O3_VECT
First_bad build: https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eab... Last_good build: https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eab... Baseline build: https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eab... Even more details: https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eab...
Reproduce builds: <cut> mkdir investigate-binutils-b4e4386a2e58ba6ce8d02b952f1bc6ceb8fc95d1 cd investigate-binutils-b4e4386a2e58ba6ce8d02b952f1bc6ceb8fc95d1
# Fetch scripts git clone https://git.linaro.org/toolchain/jenkins-scripts
# Fetch manifests and test.sh script mkdir -p artifacts/manifests curl -o artifacts/manifests/build-baseline.sh https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eab... --fail curl -o artifacts/manifests/build-parameters.sh https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eab... --fail curl -o artifacts/test.sh https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eab... --fail chmod +x artifacts/test.sh
# Reproduce the baseline build (build all pre-requisites) ./jenkins-scripts/tcwg_bmk-build.sh @@ artifacts/manifests/build-baseline.sh
# Save baseline build state (which is then restored in artifacts/test.sh) mkdir -p ./bisect rsync -a --del --delete-excluded --exclude /bisect/ --exclude /artifacts/ --exclude /binutils/ ./ ./bisect/baseline/
cd binutils
# Reproduce first_bad build git checkout --detach b4e4386a2e58ba6ce8d02b952f1bc6ceb8fc95d1 ../artifacts/test.sh
# Reproduce last_good build git checkout --detach 3814a9e1fe77c01c7e872c25afa198537d4ac780 ../artifacts/test.sh
cd .. </cut>
Full commit (up to 1000 lines): <cut> commit b4e4386a2e58ba6ce8d02b952f1bc6ceb8fc95d1 Author: Tom de Vries tdevries@suse.de Date: Fri Sep 24 12:39:14 2021 +0200
[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" +} </cut>
This is a fluke in bare-metal benchmark. Investigating.
Sorry for the noise.
-- Maxim Kuvyrkov https://www.linaro.org
On 27 Sep 2021, at 12:56, ci_notify@linaro.org wrote:
[TCWG CI] Regression caused by binutils: [gdb/testsuite] Add gdb.testsuite/dump-system-info.exp: commit b4e4386a2e58ba6ce8d02b952f1bc6ceb8fc95d1 Author: Tom de Vries tdevries@suse.de
[gdb/testsuite] Add gdb.testsuite/dump-system-info.exp
Results regressed to # reset_artifacts: -10 # build_abe binutils: -9 # build_abe stage1 -- --set gcc_override_configure=--disable-libsanitizer --set gcc_override_configure=--disable-multilib --set gcc_override_configure=--with-cpu=cortex-m4 --set gcc_override_configure=--with-mode=thumb --set gcc_override_configure=--with-float=hard: -8 # build_abe newlib: -6 # build_abe stage2 -- --patch linaro-local/vect-metric-branch --set gcc_override_configure=--disable-libsanitizer --set gcc_override_configure=--disable-multilib --set gcc_override_configure=--with-cpu=cortex-m4 --set gcc_override_configure=--with-mode=thumb --set gcc_override_configure=--with-float=hard: -5 # true: 0 # benchmark -- -O3_VECT_mthumb artifacts/build-b4e4386a2e58ba6ce8d02b952f1bc6ceb8fc95d1/results_id: 1
from # reset_artifacts: -10 # build_abe binutils: -9 # build_abe stage1 -- --set gcc_override_configure=--disable-libsanitizer --set gcc_override_configure=--disable-multilib --set gcc_override_configure=--with-cpu=cortex-m4 --set gcc_override_configure=--with-mode=thumb --set gcc_override_configure=--with-float=hard: -8 # build_abe newlib: -6 # build_abe stage2 -- --patch linaro-local/vect-metric-branch --set gcc_override_configure=--disable-libsanitizer --set gcc_override_configure=--disable-multilib --set gcc_override_configure=--with-cpu=cortex-m4 --set gcc_override_configure=--with-mode=thumb --set gcc_override_configure=--with-float=hard: -5 # true: 0 # benchmark -- -O3_VECT_mthumb artifacts/build-baseline/results_id: 1
THIS IS THE END OF INTERESTING STUFF. BELOW ARE LINKS TO BUILDS, REPRODUCTION INSTRUCTIONS, AND THE RAW COMMIT.
This commit has regressed these CI configurations:
- tcwg_bmk_gnu_eabi_stm32/gnu_eabi-master-arm_eabi-coremark-O3_VECT
First_bad build: https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eab... Last_good build: https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eab... Baseline build: https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eab... Even more details: https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eab...
Reproduce builds:
<cut> mkdir investigate-binutils-b4e4386a2e58ba6ce8d02b952f1bc6ceb8fc95d1 cd investigate-binutils-b4e4386a2e58ba6ce8d02b952f1bc6ceb8fc95d1
# Fetch scripts git clone https://git.linaro.org/toolchain/jenkins-scripts
# Fetch manifests and test.sh script mkdir -p artifacts/manifests curl -o artifacts/manifests/build-baseline.sh https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eab... --fail curl -o artifacts/manifests/build-parameters.sh https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eab... --fail curl -o artifacts/test.sh https://ci.linaro.org/job/tcwg_bmk_ci_gnu_eabi-bisect-tcwg_bmk_stm32-gnu_eab... --fail chmod +x artifacts/test.sh
# Reproduce the baseline build (build all pre-requisites) ./jenkins-scripts/tcwg_bmk-build.sh @@ artifacts/manifests/build-baseline.sh
# Save baseline build state (which is then restored in artifacts/test.sh) mkdir -p ./bisect rsync -a --del --delete-excluded --exclude /bisect/ --exclude /artifacts/ --exclude /binutils/ ./ ./bisect/baseline/
cd binutils
# Reproduce first_bad build git checkout --detach b4e4386a2e58ba6ce8d02b952f1bc6ceb8fc95d1 ../artifacts/test.sh
# Reproduce last_good build git checkout --detach 3814a9e1fe77c01c7e872c25afa198537d4ac780 ../artifacts/test.sh
cd ..
</cut>
Full commit (up to 1000 lines):
<cut> commit b4e4386a2e58ba6ce8d02b952f1bc6ceb8fc95d1 Author: Tom de Vries <tdevries@suse.de> Date: Fri Sep 24 12:39:14 2021 +0200
[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"
+}
</cut>
linaro-toolchain@lists.linaro.org