[PULL 00/11] rc2 fixes (check-tcg, gitlab, gdbstub)

[PULL 00/11] rc2 fixes (check-tcg, gitlab, gdbstub)

[Alex Bennée]

The following changes since commit 109918d24a3bb9ed3d05beb34ea4ac6be443c138:

  Merge remote-tracking branch 'remotes/nvme/tags/nvme-fixes-for-6.0-pull-request' into staging (2021-04-05 22:15:38 +0100)

are available in the Git repository at:

  https://github.com/stsquad/qemu.git tags/pull-6.0-rc2-fixes-060421-1

for you to fetch changes up to a2e5bbf0c407a572d9b687adaecf9995f66b4cd9:

  gitlab-ci.yml: Test the dtrace backend in one of the jobs (2021-04-06 15:04:50 +0100)

----------------------------------------------------------------
Testing updates:

  - fix x86_64 cross compilers
  - don't use registry for non-x86 containers
  - add valid host types for given cross compile containers
  - clean up i386 code16 test with explicit -no-pie
  - relax sha1.py gdbstub test
  - add more gdbstub documentation
  - remove annoying warning on gitlab
  - test dtrace backend in gitlab

----------------------------------------------------------------
Alex Bennée (7):
      tests/tcg: update the defaults for x86 compilers
      tests/docker: don't set DOCKER_REGISTRY on non-x86_64
      tests/tcg: add concept of container_hosts
      tests/tcg/configure.sh: make sure we pick up x86_64 cross compilers
      tests/tcg/i386: expand .data sections for system tests
      tests/tcg/i386: force -fno-pie for test-i386
      tests/tcg: relax the next step precision of the gdb sha1 test

Peter Maydell (2):
      docs/system/gdb.rst: Add some more heading structure
      docs/system/gdb.rst: Document how to debug multicore machines

Thomas Huth (2):
      gitlab-ci.yml: Fix the filtering for the git submodules
      gitlab-ci.yml: Test the dtrace backend in one of the jobs

 docs/system/gdb.rst                     | 63 ++++++++++++++++++++++++++++++++-
 configure                               |  2 +-
 .gitlab-ci.yml                          |  4 +--
 tests/docker/Makefile.include           |  5 ++-
 tests/docker/dockerfiles/centos8.docker |  1 +
 tests/tcg/configure.sh                  | 42 +++++++++++++++++++---
 tests/tcg/i386/Makefile.target          | 16 +++++++--
 tests/tcg/i386/system/kernel.ld         |  2 +-
 tests/tcg/multiarch/gdbstub/sha1.py     |  5 ++-
 9 files changed, 126 insertions(+), 14 deletions(-)

-- 
2.20.1

[PULL 01/11] tests/tcg: update the defaults for x86 compilers

[Alex Bennée]

You don't usually notice this is broken on developer system on x86 as
we use the normal host compiler. However on other systems the -pc was
extraneous. Also for 32 bit only i686 packages exist now so we should
use those when available.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210401102530.12030-2-alex.bennee@linaro.org>

diff --git a/tests/tcg/configure.sh b/tests/tcg/configure.sh
index ce304f4933..af4aecf14e 100755
--- a/tests/tcg/configure.sh
+++ b/tests/tcg/configure.sh
@@ -52,7 +52,7 @@ fi
 : ${cross_cc_hexagon="hexagon-unknown-linux-musl-clang"}
 : ${cross_cc_cflags_hexagon="-mv67 -O2 -static"}
 : ${cross_cc_hppa="hppa-linux-gnu-gcc"}
-: ${cross_cc_i386="i386-pc-linux-gnu-gcc"}
+: ${cross_cc_i386="i686-linux-gnu-gcc"}
 : ${cross_cc_cflags_i386="-m32"}
 : ${cross_cc_m68k="m68k-linux-gnu-gcc"}
 : $(cross_cc_mips64el="mips64el-linux-gnuabi64-gcc")
@@ -69,7 +69,7 @@ fi
 : ${cross_cc_cflags_sparc="-m32 -mv8plus -mcpu=ultrasparc"}
 : ${cross_cc_sparc64="sparc64-linux-gnu-gcc"}
 : ${cross_cc_cflags_sparc64="-m64 -mcpu=ultrasparc"}
-: ${cross_cc_x86_64="x86_64-pc-linux-gnu-gcc"}
+: ${cross_cc_x86_64="x86_64-linux-gnu-gcc"}
 : ${cross_cc_cflags_x86_64="-m64"}
 
 for target in $target_list; do
-- 
2.20.1

[PULL 02/11] tests/docker: don't set DOCKER_REGISTRY on non-x86_64

[Alex Bennée]

Currently our gitlab registry is x86_64 only so attempting to pull an
image from it on something else will end in tears.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Willian Rampazzo <willianr@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20210401102530.12030-3-alex.bennee@linaro.org>

diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index 7cab761bf5..9f464cb92c 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -16,7 +16,10 @@ DOCKER_IMAGES := $(sort $(notdir $(basename $(wildcard $(DOCKER_FILES_DIR)/*.doc
 DOCKER_TARGETS := $(patsubst %,docker-image-%,$(DOCKER_IMAGES))
 # Use a global constant ccache directory to speed up repetitive builds
 DOCKER_CCACHE_DIR := $$HOME/.cache/qemu-docker-ccache
-DOCKER_REGISTRY := $(if $(REGISTRY),$(REGISTRY),registry.gitlab.com/qemu-project/qemu)
+ifeq ($(HOST_ARCH),x86_64)
+DOCKER_DEFAULT_REGISTRY := registry.gitlab.com/qemu-project/qemu
+endif
+DOCKER_REGISTRY := $(if $(REGISTRY),$(REGISTRY),$(DOCKER_DEFAULT_REGISTRY))
 
 DOCKER_TESTS := $(notdir $(shell \
 	find $(SRC_PATH)/tests/docker/ -name 'test-*' -type f))
-- 
2.20.1

[PULL 03/11] tests/tcg: add concept of container_hosts

[Alex Bennée]

While docker is nominally multiarch these days it doesn't mean our
distros actually package all cross compilers for all architectures.
The upcoming Debian bullseye release will improve things further. At
least for now we can get things like the 32 bit ARM compiler on it's
64 bit cousin.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20210401102530.12030-4-alex.bennee@linaro.org>

diff --git a/configure b/configure
index 8275df1506..4f374b4889 100755
--- a/configure
+++ b/configure
@@ -6299,7 +6299,7 @@ done
 (for i in $cross_cc_vars; do
   export $i
 done
-export target_list source_path use_containers
+export target_list source_path use_containers ARCH
 $source_path/tests/tcg/configure.sh)
 
 # temporary config to build submodules
diff --git a/tests/tcg/configure.sh b/tests/tcg/configure.sh
index af4aecf14e..87a9f24b20 100755
--- a/tests/tcg/configure.sh
+++ b/tests/tcg/configure.sh
@@ -108,79 +108,98 @@ for target in $target_list; do
   case $target in
     aarch64-*)
       # We don't have any bigendian build tools so we only use this for AArch64
+      container_hosts="x86_64 aarch64"
       container_image=debian-arm64-test-cross
       container_cross_cc=aarch64-linux-gnu-gcc-10
       ;;
     alpha-*)
+      container_hosts=x86_64
       container_image=debian-alpha-cross
       container_cross_cc=alpha-linux-gnu-gcc
       ;;
     arm-*)
       # We don't have any bigendian build tools so we only use this for ARM
+      container_hosts="x86_64 aarch64"
       container_image=debian-armhf-cross
       container_cross_cc=arm-linux-gnueabihf-gcc
       ;;
     cris-*)
+      container_hosts=x86_64
       container_image=fedora-cris-cross
       container_cross_cc=cris-linux-gnu-gcc
       ;;
     hppa-*)
+      container_hosts=x86_64
       container_image=debian-hppa-cross
       container_cross_cc=hppa-linux-gnu-gcc
       ;;
     i386-*)
+      container_hosts=x86_64
       container_image=fedora-i386-cross
       container_cross_cc=gcc
       ;;
     m68k-*)
+      container_hosts=x86_64
       container_image=debian-m68k-cross
       container_cross_cc=m68k-linux-gnu-gcc
       ;;
     mips64el-*)
+      container_hosts=x86_64
       container_image=debian-mips64el-cross
       container_cross_cc=mips64el-linux-gnuabi64-gcc
       ;;
     mips64-*)
+      container_hosts=x86_64
       container_image=debian-mips64-cross
       container_cross_cc=mips64-linux-gnuabi64-gcc
       ;;
     mipsel-*)
+      container_hosts=x86_64
       container_image=debian-mipsel-cross
       container_cross_cc=mipsel-linux-gnu-gcc
       ;;
     mips-*)
+      container_hosts=x86_64
       container_image=debian-mips-cross
       container_cross_cc=mips-linux-gnu-gcc
       ;;
     ppc-*|ppc64abi32-*)
+      container_hosts=x86_64
       container_image=debian-powerpc-cross
       container_cross_cc=powerpc-linux-gnu-gcc
       ;;
     ppc64-*)
+      container_hosts=x86_64
       container_image=debian-ppc64-cross
       container_cross_cc=powerpc64-linux-gnu-gcc
       ;;
     ppc64le-*)
+      container_hosts=x86_64
       container_image=debian-ppc64el-cross
       container_cross_cc=powerpc64le-linux-gnu-gcc
       ;;
     riscv64-*)
+      container_hosts=x86_64
       container_image=debian-riscv64-cross
       container_cross_cc=riscv64-linux-gnu-gcc
       ;;
     s390x-*)
+      container_hosts=x86_64
       container_image=debian-s390x-cross
       container_cross_cc=s390x-linux-gnu-gcc
       ;;
     sh4-*)
+      container_hosts=x86_64
       container_image=debian-sh4-cross
       container_cross_cc=sh4-linux-gnu-gcc
       ;;
     sparc64-*)
+      container_hosts=x86_64
       container_image=debian-sparc64-cross
       container_cross_cc=sparc64-linux-gnu-gcc
       ;;
     xtensa*-softmmu)
+      container_hosts=x86_64
       container_image=debian-xtensa-cross
 
       # default to the dc232b cpu
@@ -265,7 +284,11 @@ for target in $target_list; do
   done
 
   if test $got_cross_cc = no && test "$container" != no && test -n "$container_image"; then
-    echo "DOCKER_IMAGE=$container_image" >> $config_target_mak
-    echo "DOCKER_CROSS_CC_GUEST=$container_cross_cc" >> $config_target_mak
+      for host in $container_hosts; do
+          if test "$host" = "$ARCH"; then
+              echo "DOCKER_IMAGE=$container_image" >> $config_target_mak
+              echo "DOCKER_CROSS_CC_GUEST=$container_cross_cc" >> $config_target_mak
+          fi
+      done
   fi
 done
-- 
2.20.1

[PULL 04/11] tests/tcg/configure.sh: make sure we pick up x86_64 cross compilers

[Alex Bennée]

While it's hard to find cross compilers packaged for arches other than
x86_64 the same cannot be said for the x86_64 compiler which is
available on Debians i386, arm64 and ppc64el release architectures.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20210401102530.12030-5-alex.bennee@linaro.org>

diff --git a/tests/tcg/configure.sh b/tests/tcg/configure.sh
index 87a9f24b20..90fd81f506 100755
--- a/tests/tcg/configure.sh
+++ b/tests/tcg/configure.sh
@@ -198,6 +198,11 @@ for target in $target_list; do
       container_image=debian-sparc64-cross
       container_cross_cc=sparc64-linux-gnu-gcc
       ;;
+    x86_64-*)
+      container_hosts="aarch64 ppc64el x86_64"
+      container_image=debian-amd64-cross
+      container_cross_cc=x86_64-linux-gnu-gcc
+      ;;
     xtensa*-softmmu)
       container_hosts=x86_64
       container_image=debian-xtensa-cross
-- 
2.20.1

[PULL 05/11] tests/tcg/i386: expand .data sections for system tests

[Alex Bennée]

Newer compilers might end up putting some data in .data.rel.local
which was getting skipped resulting in hilarious confusion on some
tests. Fix that.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20210401102530.12030-6-alex.bennee@linaro.org>

diff --git a/tests/tcg/i386/system/kernel.ld b/tests/tcg/i386/system/kernel.ld
index 92de525e93..27ea5bbe04 100644
--- a/tests/tcg/i386/system/kernel.ld
+++ b/tests/tcg/i386/system/kernel.ld
@@ -12,7 +12,7 @@ SECTIONS {
 	}
 
 	.data : {
-		*(.data)
+		*(.data*)
 		__load_en = .;
 	}
 
-- 
2.20.1

[PULL 06/11] tests/tcg/i386: force -fno-pie for test-i386

[Alex Bennée]

The containerised compiler defaults to no-pie anyway but if we are
relying on the users installed cross compiler we need to check it
works for building 16 bit code first.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20210401102530.12030-7-alex.bennee@linaro.org>

diff --git a/tests/tcg/configure.sh b/tests/tcg/configure.sh
index 90fd81f506..fa1a4261a4 100755
--- a/tests/tcg/configure.sh
+++ b/tests/tcg/configure.sh
@@ -281,6 +281,12 @@ for target in $target_list; do
                 echo "CROSS_CC_HAS_POWER8_VECTOR=y" >> $config_target_mak
             fi
         ;;
+        i386-linux-user)
+            if do_compiler "$target_compiler" $target_compiler_cflags \
+                -Werror -fno-pie -o $TMPE $TMPC; then
+                echo "CROSS_CC_HAS_I386_NOPIE=y" >> $config_target_mak
+            fi
+        ;;
     esac
 
     enabled_cross_compilers="$enabled_cross_compilers $target_compiler"
diff --git a/tests/tcg/i386/Makefile.target b/tests/tcg/i386/Makefile.target
index c4a6f91966..f7efaab918 100644
--- a/tests/tcg/i386/Makefile.target
+++ b/tests/tcg/i386/Makefile.target
@@ -27,13 +27,23 @@ run-plugin-test-i386-bmi2-%: QEMU_OPTS += -cpu max
 hello-i386: CFLAGS+=-ffreestanding
 hello-i386: LDFLAGS+=-nostdlib
 
-#
-# test-386 includes a couple of additional objects that need to be linked together
-#
+# test-386 includes a couple of additional objects that need to be
+# linked together, we also need a no-pie capable compiler due to the
+# non-pic calls into 16-bit mode
+ifneq ($(DOCKER_IMAGE)$(CROSS_CC_HAS_I386_NOPIE),)
+test-i386: CFLAGS += -fno-pie
 
 test-i386: test-i386.c test-i386-code16.S test-i386-vm86.S test-i386.h test-i386-shift.h test-i386-muldiv.h
 	$(CC) $(CFLAGS) $(LDFLAGS) $(EXTRA_CFLAGS) -o $@ \
 	   $(<D)/test-i386.c $(<D)/test-i386-code16.S $(<D)/test-i386-vm86.S -lm
+else
+test-i386:
+	$(call skip-test, "BUILD of $@", "missing -no-pie compiler support")
+run-test-i386:
+	$(call skip-test, "RUN of test-i386", "not built")
+run-plugin-test-i386-with-%:
+	$(call skip-test, "RUN of test-i386 ($*)", "not built")
+endif
 
 ifeq ($(SPEED), slow)
 
-- 
2.20.1

[PULL 07/11] tests/tcg: relax the next step precision of the gdb sha1 test

[Alex Bennée]

Depending on the version of gdb we may not execute the first line of
SHA1Init when executing the first "next" command - instead just
stepping over the preamble. As we don't actually care about the
position of the PC after the steps and want to be sure the
context->state[] has been loaded before we inspect it do a double next
at the start.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20210401102530.12030-8-alex.bennee@linaro.org>

diff --git a/tests/tcg/multiarch/gdbstub/sha1.py b/tests/tcg/multiarch/gdbstub/sha1.py
index 2bfde49633..423b720e6d 100644
--- a/tests/tcg/multiarch/gdbstub/sha1.py
+++ b/tests/tcg/multiarch/gdbstub/sha1.py
@@ -40,7 +40,10 @@ def run_test():
 
     check_break("SHA1Init")
 
-    # check step and inspect values
+    # Check step and inspect values. We do a double next after the
+    # breakpoint as depending on the version of gdb we may step the
+    # preamble and not the first actual line of source.
+    gdb.execute("next")
     gdb.execute("next")
     val_ctx = gdb.parse_and_eval("context->state[0]")
     exp_ctx = 0x67452301
-- 
2.20.1

[PULL 08/11] docs/system/gdb.rst: Add some more heading structure

[Alex Bennée]

From: Peter Maydell <peter.maydell@linaro.org>

We're about to add a new section to gdb.rst. In
preparation, add some more headings so it isn't just
one huge run-on section.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210325175023.13838-2-peter.maydell@linaro.org>
Message-Id: <20210401102530.12030-9-alex.bennee@linaro.org>

diff --git a/docs/system/gdb.rst b/docs/system/gdb.rst
index 72b1e68f4e..0bb1bedf1b 100644
--- a/docs/system/gdb.rst
+++ b/docs/system/gdb.rst
@@ -45,7 +45,11 @@ Here are some useful tips in order to use gdb on system code:
 3. Use ``set architecture i8086`` to dump 16 bit code. Then use
    ``x/10i $cs*16+$eip`` to dump the code at the PC position.
 
-Advanced debugging options:
+Advanced debugging options
+==========================
+
+Changing single-stepping behaviour
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The default single stepping behavior is step with the IRQs and timer
 service routines off. It is set this way because when gdb executes a
@@ -88,6 +92,8 @@ three commands you can query and set the single step behavior:
       sending: "qemu.sstep=0x5"
       received: "OK"
 
+Examining physical memory
+^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Another feature that QEMU gdbstub provides is to toggle the memory GDB
 works with, by default GDB will show the current process memory respecting
-- 
2.20.1

[PULL 09/11] docs/system/gdb.rst: Document how to debug multicore machines

[Alex Bennée]

From: Peter Maydell <peter.maydell@linaro.org>

Document how multicore machines appear to GDB when debugged
via the debug stub. This is particularly non-intuitive for
the "multiple heterogenous clusters" case, but unfortunately
as far as I know there is no way with the remote protocol
for the stub to tell gdb "I have 2 inferiors, please connect
to both", so the user must set it all up manually.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210325175023.13838-3-peter.maydell@linaro.org>
Message-Id: <20210401102530.12030-10-alex.bennee@linaro.org>

diff --git a/docs/system/gdb.rst b/docs/system/gdb.rst
index 0bb1bedf1b..144d083df3 100644
--- a/docs/system/gdb.rst
+++ b/docs/system/gdb.rst
@@ -45,6 +45,61 @@ Here are some useful tips in order to use gdb on system code:
 3. Use ``set architecture i8086`` to dump 16 bit code. Then use
    ``x/10i $cs*16+$eip`` to dump the code at the PC position.
 
+Debugging multicore machines
+============================
+
+GDB's abstraction for debugging targets with multiple possible
+parallel flows of execution is a two layer one: it supports multiple
+"inferiors", each of which can have multiple "threads". When the QEMU
+machine has more than one CPU, QEMU exposes each CPU cluster as a
+separate "inferior", where each CPU within the cluster is a separate
+"thread". Most QEMU machine types have identical CPUs, so there is a
+single cluster which has all the CPUs in it.  A few machine types are
+heterogenous and have multiple clusters: for example the ``sifive_u``
+machine has a cluster with one E51 core and a second cluster with four
+U54 cores. Here the E51 is the only thread in the first inferior, and
+the U54 cores are all threads in the second inferior.
+
+When you connect gdb to the gdbstub, it will automatically
+connect to the first inferior; you can display the CPUs in this
+cluster using the gdb ``info thread`` command, and switch between
+them using gdb's usual thread-management commands.
+
+For multi-cluster machines, unfortunately gdb does not by default
+handle multiple inferiors, and so you have to explicitly connect
+to them. First, you must connect with the ``extended-remote``
+protocol, not ``remote``::
+
+    (gdb) target extended-remote localhost:1234
+
+Once connected, gdb will have a single inferior, for the
+first cluster. You need to create inferiors for the other
+clusters and attach to them, like this::
+
+  (gdb) add-inferior
+  Added inferior 2
+  (gdb) inferior 2
+  [Switching to inferior 2 [<null>] (<noexec>)]
+  (gdb) attach 2
+  Attaching to process 2
+  warning: No executable has been specified and target does not support
+  determining executable automatically.  Try using the "file" command.
+  0x00000000 in ?? ()
+
+Once you've done this, ``info threads`` will show CPUs in
+all the clusters you have attached to::
+
+  (gdb) info threads
+    Id   Target Id         Frame
+    1.1  Thread 1.1 (cortex-m33-arm-cpu cpu [running]) 0x00000000 in ?? ()
+  * 2.1  Thread 2.2 (cortex-m33-arm-cpu cpu [halted ]) 0x00000000 in ?? ()
+
+You probably also want to set gdb to ``schedule-multiple`` mode,
+so that when you tell gdb to ``continue`` it resumes all CPUs,
+not just those in the cluster you are currently working on::
+
+  (gdb) set schedule-multiple on
+
 Advanced debugging options
 ==========================
 
-- 
2.20.1

[PULL 10/11] gitlab-ci.yml: Fix the filtering for the git submodules

[Alex Bennée]

From: Thomas Huth <thuth@redhat.com>

Commit 7d7dbf9dc15be6e introduced a new line starting with
"GIT_SUBMODULES_ACTION=" in the config-host.mak file. The grep that
tries to determine the submodules in the gitlab-ci.yml file matches
this new line, too, causing a warning message when updating the modules:

 warn: ignoring non-existent submodule GIT_SUBMODULES_ACTION=update

Fix it by matching the "GIT_SUBMODULES=..." line only.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Willian Rampazzo <willianr@redhat.com>
Message-Id: <20210331073316.2965928-1-thuth@redhat.com>
Message-Id: <20210401102530.12030-11-alex.bennee@linaro.org>

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 3480d79db3..85b8e10b84 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -42,7 +42,7 @@ include:
   image: $CI_REGISTRY_IMAGE/qemu/$IMAGE:latest
   script:
     - scripts/git-submodule.sh update
-        $(grep GIT_SUBMODULES build/config-host.mak | sed 's/GIT_SUBMODULES=//')
+        $(sed -n '/GIT_SUBMODULES=/ s/.*=// p' build/config-host.mak)
     - cd build
     - find . -type f -exec touch {} +
     # Avoid recompiling by hiding ninja with NINJA=":"
-- 
2.20.1

[PULL 11/11] gitlab-ci.yml: Test the dtrace backend in one of the jobs

[Alex Bennée]

From: Thomas Huth <thuth@redhat.com>

We are using the dtrace backend in downstream RHEL, so testing this
in the CentOS 8 task seems to be a good fit.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Willian Rampazzo <willianr@redhat.com>
Message-Id: <20210331160351.3071279-1-thuth@redhat.com>
Message-Id: <20210401102530.12030-12-alex.bennee@linaro.org>

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 85b8e10b84..52d65d6c04 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -223,7 +223,7 @@ build-system-centos:
   variables:
     IMAGE: centos8
     CONFIGURE_ARGS: --disable-nettle --enable-gcrypt --enable-fdt=system
-                    --enable-modules
+                    --enable-modules --enable-trace-backends=dtrace
     TARGETS: ppc64-softmmu or1k-softmmu s390x-softmmu
       x86_64-softmmu rx-softmmu sh4-softmmu nios2-softmmu
     MAKE_CHECK_ARGS: check-build
diff --git a/tests/docker/dockerfiles/centos8.docker b/tests/docker/dockerfiles/centos8.docker
index a763d55730..a8c6c528b0 100644
--- a/tests/docker/dockerfiles/centos8.docker
+++ b/tests/docker/dockerfiles/centos8.docker
@@ -29,6 +29,7 @@ ENV PACKAGES \
     rdma-core-devel \
     spice-glib-devel \
     spice-server \
+    systemtap-sdt-devel \
     tar \
     zlib-devel
 
-- 
2.20.1

Re: [PULL 00/11] rc2 fixes (check-tcg, gitlab, gdbstub)

[Peter Maydell]

On Tue, 6 Apr 2021 at 16:00, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> The following changes since commit 109918d24a3bb9ed3d05beb34ea4ac6be443c138:
>
>   Merge remote-tracking branch 'remotes/nvme/tags/nvme-fixes-for-6.0-pull-request' into staging (2021-04-05 22:15:38 +0100)
>
> are available in the Git repository at:
>
>   https://github.com/stsquad/qemu.git tags/pull-6.0-rc2-fixes-060421-1
>
> for you to fetch changes up to a2e5bbf0c407a572d9b687adaecf9995f66b4cd9:
>
>   gitlab-ci.yml: Test the dtrace backend in one of the jobs (2021-04-06 15:04:50 +0100)
>
> ----------------------------------------------------------------
> Testing updates:
>
>   - fix x86_64 cross compilers
>   - don't use registry for non-x86 containers
>   - add valid host types for given cross compile containers
>   - clean up i386 code16 test with explicit -no-pie
>   - relax sha1.py gdbstub test
>   - add more gdbstub documentation
>   - remove annoying warning on gitlab
>   - test dtrace backend in gitlab
>
> ----------------------------------------------------------------

The merge for this failed in gitlab CI with a weird state:

https://gitlab.com/qemu-project/qemu/-/pipelines/282228325

 * marked "failed"
 * but has a "cancel" button
 * has no "retry" button
 * has an "error" tag whose hover-over text reads "Pipeline job activity
   limit exceeded!"

Not being sure whether this is gitlab CI being flaky again or a problem
with something in the pullreq, I've not applied it for rc2; we can
figure out what happened and maybe try again for rc3.

thanks
-- PMM

Re: [PULL 00/11] rc2 fixes (check-tcg, gitlab, gdbstub)

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Tue, 6 Apr 2021 at 16:00, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> The following changes since commit 109918d24a3bb9ed3d05beb34ea4ac6be443c138:
>>
>>   Merge remote-tracking branch 'remotes/nvme/tags/nvme-fixes-for-6.0-pull-request' into staging (2021-04-05 22:15:38 +0100)
>>
>> are available in the Git repository at:
>>
>>   https://github.com/stsquad/qemu.git tags/pull-6.0-rc2-fixes-060421-1
>>
>> for you to fetch changes up to a2e5bbf0c407a572d9b687adaecf9995f66b4cd9:
>>
>>   gitlab-ci.yml: Test the dtrace backend in one of the jobs (2021-04-06 15:04:50 +0100)
>>
>> ----------------------------------------------------------------
>> Testing updates:
>>
>>   - fix x86_64 cross compilers
>>   - don't use registry for non-x86 containers
>>   - add valid host types for given cross compile containers
>>   - clean up i386 code16 test with explicit -no-pie
>>   - relax sha1.py gdbstub test
>>   - add more gdbstub documentation
>>   - remove annoying warning on gitlab
>>   - test dtrace backend in gitlab
>>
>> ----------------------------------------------------------------
>
> The merge for this failed in gitlab CI with a weird state:
>
> https://gitlab.com/qemu-project/qemu/-/pipelines/282228325
>
>  * marked "failed"
>  * but has a "cancel" button
>  * has no "retry" button
>  * has an "error" tag whose hover-over text reads "Pipeline job activity
>    limit exceeded!"
>
> Not being sure whether this is gitlab CI being flaky again or a problem
> with something in the pullreq, I've not applied it for rc2; we can
> figure out what happened and maybe try again for rc3.

I think it's GitLab going nuts because:

  https://gitlab.com/stsquad/qemu/-/pipelines/282304522 is all green
  https://gitlab.com/stsquad/qemu/-/pipelines/282619235 is a dumpster fire
  
And they are both the same commit (pull-6.0-rc2-fixes-070421-2)

>
> thanks
> -- PMM


-- 
Alex Bennée

Re: [PULL 00/11] rc2 fixes (check-tcg, gitlab, gdbstub)

[Peter Maydell]

On Wed, 7 Apr 2021 at 18:26, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Tue, 6 Apr 2021 at 16:00, Alex Bennée <alex.bennee@linaro.org> wrote:
> >>
> >> The following changes since commit 109918d24a3bb9ed3d05beb34ea4ac6be443c138:
> >>
> >>   Merge remote-tracking branch 'remotes/nvme/tags/nvme-fixes-for-6.0-pull-request' into staging (2021-04-05 22:15:38 +0100)
> >>
> >> are available in the Git repository at:
> >>
> >>   https://github.com/stsquad/qemu.git tags/pull-6.0-rc2-fixes-060421-1
> >>
> >> for you to fetch changes up to a2e5bbf0c407a572d9b687adaecf9995f66b4cd9:
> >>
> >>   gitlab-ci.yml: Test the dtrace backend in one of the jobs (2021-04-06 15:04:50 +0100)
> >>
> >> ----------------------------------------------------------------
> >> Testing updates:
> >>
> >>   - fix x86_64 cross compilers
> >>   - don't use registry for non-x86 containers
> >>   - add valid host types for given cross compile containers
> >>   - clean up i386 code16 test with explicit -no-pie
> >>   - relax sha1.py gdbstub test
> >>   - add more gdbstub documentation
> >>   - remove annoying warning on gitlab
> >>   - test dtrace backend in gitlab
> >>
> >> ----------------------------------------------------------------
> >
> > The merge for this failed in gitlab CI with a weird state:
> >
> > https://gitlab.com/qemu-project/qemu/-/pipelines/282228325
> >
> >  * marked "failed"
> >  * but has a "cancel" button
> >  * has no "retry" button
> >  * has an "error" tag whose hover-over text reads "Pipeline job activity
> >    limit exceeded!"
> >
> > Not being sure whether this is gitlab CI being flaky again or a problem
> > with something in the pullreq, I've not applied it for rc2; we can
> > figure out what happened and maybe try again for rc3.
>
> I think it's GitLab going nuts because:
>
>   https://gitlab.com/stsquad/qemu/-/pipelines/282304522 is all green
>   https://gitlab.com/stsquad/qemu/-/pipelines/282619235 is a dumpster fire
>
> And they are both the same commit (pull-6.0-rc2-fixes-070421-2)

Should I retry a merge of this pullreq (which is -1), or are you going to
submit a new one ?

thanks
-- PMM

Re: [PULL 00/11] rc2 fixes (check-tcg, gitlab, gdbstub)

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Wed, 7 Apr 2021 at 18:26, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>> > On Tue, 6 Apr 2021 at 16:00, Alex Bennée <alex.bennee@linaro.org> wrote:
>> >>
>> >> The following changes since commit 109918d24a3bb9ed3d05beb34ea4ac6be443c138:
>> >>
>> >>   Merge remote-tracking branch 'remotes/nvme/tags/nvme-fixes-for-6.0-pull-request' into staging (2021-04-05 22:15:38 +0100)
>> >>
>> >> are available in the Git repository at:
>> >>
>> >>   https://github.com/stsquad/qemu.git tags/pull-6.0-rc2-fixes-060421-1
>> >>
>> >> for you to fetch changes up to a2e5bbf0c407a572d9b687adaecf9995f66b4cd9:
>> >>
>> >>   gitlab-ci.yml: Test the dtrace backend in one of the jobs (2021-04-06 15:04:50 +0100)
>> >>
>> >> ----------------------------------------------------------------
>> >> Testing updates:
>> >>
>> >>   - fix x86_64 cross compilers
>> >>   - don't use registry for non-x86 containers
>> >>   - add valid host types for given cross compile containers
>> >>   - clean up i386 code16 test with explicit -no-pie
>> >>   - relax sha1.py gdbstub test
>> >>   - add more gdbstub documentation
>> >>   - remove annoying warning on gitlab
>> >>   - test dtrace backend in gitlab
>> >>
>> >> ----------------------------------------------------------------
>> >
>> > The merge for this failed in gitlab CI with a weird state:
>> >
>> > https://gitlab.com/qemu-project/qemu/-/pipelines/282228325
>> >
>> >  * marked "failed"
>> >  * but has a "cancel" button
>> >  * has no "retry" button
>> >  * has an "error" tag whose hover-over text reads "Pipeline job activity
>> >    limit exceeded!"
>> >
>> > Not being sure whether this is gitlab CI being flaky again or a problem
>> > with something in the pullreq, I've not applied it for rc2; we can
>> > figure out what happened and maybe try again for rc3.
>>
>> I think it's GitLab going nuts because:
>>
>>   https://gitlab.com/stsquad/qemu/-/pipelines/282304522 is all green
>>   https://gitlab.com/stsquad/qemu/-/pipelines/282619235 is a dumpster fire
>>
>> And they are both the same commit (pull-6.0-rc2-fixes-070421-2)
>
> Should I retry a merge of this pullreq (which is -1), or are you going to
> submit a new one ?

I think either is good, the -2 tag was simply a re-base and has at least
one clean run before everything went weird.

>
> thanks
> -- PMM


-- 
Alex Bennée

Re: [PULL 00/11] rc2 fixes (check-tcg, gitlab, gdbstub)

[Peter Maydell]

On Wed, 7 Apr 2021 at 19:42, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Wed, 7 Apr 2021 at 18:26, Alex Bennée <alex.bennee@linaro.org> wrote:
> >>
> >>
> >> Peter Maydell <peter.maydell@linaro.org> writes:
> >>
> >> > On Tue, 6 Apr 2021 at 16:00, Alex Bennée <alex.bennee@linaro.org> wrote:
> >> >>
> >> >> The following changes since commit 109918d24a3bb9ed3d05beb34ea4ac6be443c138:
> >> >>
> >> >>   Merge remote-tracking branch 'remotes/nvme/tags/nvme-fixes-for-6.0-pull-request' into staging (2021-04-05 22:15:38 +0100)
> >> >>
> >> >> are available in the Git repository at:
> >> >>
> >> >>   https://github.com/stsquad/qemu.git tags/pull-6.0-rc2-fixes-060421-1
> >> >>
> >> >> for you to fetch changes up to a2e5bbf0c407a572d9b687adaecf9995f66b4cd9:
> >> >>
> >> >>   gitlab-ci.yml: Test the dtrace backend in one of the jobs (2021-04-06 15:04:50 +0100)
> >> >>
> >> >> ----------------------------------------------------------------
> >> >> Testing updates:
> >> >>
> >> >>   - fix x86_64 cross compilers
> >> >>   - don't use registry for non-x86 containers
> >> >>   - add valid host types for given cross compile containers
> >> >>   - clean up i386 code16 test with explicit -no-pie
> >> >>   - relax sha1.py gdbstub test
> >> >>   - add more gdbstub documentation
> >> >>   - remove annoying warning on gitlab
> >> >>   - test dtrace backend in gitlab
> >> >>
> >> >> ----------------------------------------------------------------
> >> >
> >> > The merge for this failed in gitlab CI with a weird state:
> >> >
> >> > https://gitlab.com/qemu-project/qemu/-/pipelines/282228325
> >> >
> >> >  * marked "failed"
> >> >  * but has a "cancel" button
> >> >  * has no "retry" button
> >> >  * has an "error" tag whose hover-over text reads "Pipeline job activity
> >> >    limit exceeded!"
> >> >
> >> > Not being sure whether this is gitlab CI being flaky again or a problem
> >> > with something in the pullreq, I've not applied it for rc2; we can
> >> > figure out what happened and maybe try again for rc3.
> >>
> >> I think it's GitLab going nuts because:
> >>
> >>   https://gitlab.com/stsquad/qemu/-/pipelines/282304522 is all green
> >>   https://gitlab.com/stsquad/qemu/-/pipelines/282619235 is a dumpster fire
> >>
> >> And they are both the same commit (pull-6.0-rc2-fixes-070421-2)
> >
> > Should I retry a merge of this pullreq (which is -1), or are you going to
> > submit a new one ?
>
> I think either is good, the -2 tag was simply a re-base and has at least
> one clean run before everything went weird.

Yep, it seemed happier on a second run so I've merged this (using the -1
tag; -2 isn't a signed tag).


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/6.0
for any user-visible changes.

-- PMM