[PATCH for 6.0-rc2 v2 00/11] various fixes, pre-PR (check-tcg, gdbstub, gitlab)

[PATCH for 6.0-rc2 v2 00/11] various fixes, pre-PR (check-tcg, gdbstub, gitlab)

[Alex Bennée]

Hi,

A few more patches have been added:

  - gdbstub documentation
  - tweak the gdbstub sha1 test
  - tweaks for gitlab

as well as fixing the i386-linux-user cross compile case (including
detecting the support for -no-pie for cross compilers). Other than
that it's just review tags. I plan to cut the PR from this post on the
morning of the 6th in time for rc2.

The following remain un-reviewed:

 - tests/tcg: relax the next step precision of the gdb sha1 test
 - tests/tcg/i386: force -fno-pie for test-i386
 - tests/tcg/configure.sh: make sure we pick up x86_64 cross compilers
 - tests/tcg: add concept of container_hosts

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

[PATCH v2 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>
---
 tests/tcg/configure.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

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

[PATCH v2 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.

Reviewed-by: Willian Rampazzo <willianr@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 tests/docker/Makefile.include | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

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

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

[Alex Bennée]

While docker is nominally multarch 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>
---
 configure              |  2 +-
 tests/tcg/configure.sh | 27 +++++++++++++++++++++++++--
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 535e6a9269..7df7750a14 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

[PATCH v2 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>
---
 tests/tcg/configure.sh | 5 +++++
 1 file changed, 5 insertions(+)

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

[PATCH v2 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.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 tests/tcg/i386/system/kernel.ld | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

[PATCH v2 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>
---
 tests/tcg/configure.sh         |  6 ++++++
 tests/tcg/i386/Makefile.target | 16 +++++++++++++---
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/tests/tcg/configure.sh b/tests/tcg/configure.sh
index 90fd81f506..46bc8634bb 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 -no-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

[PATCH v2 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>
---
 tests/tcg/multiarch/gdbstub/sha1.py | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

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

[PATCH v2 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>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210325175023.13838-2-peter.maydell@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 docs/system/gdb.rst | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

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

[PATCH v2 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>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210325175023.13838-3-peter.maydell@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 docs/system/gdb.rst | 55 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

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

[PATCH v2 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>
Message-Id: <20210331073316.2965928-1-thuth@redhat.com>
---
 .gitlab-ci.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

[PATCH v2 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>
Reviewed-by: Willian Rampazzo <willianr@redhat.com>
Message-Id: <20210331160351.3071279-1-thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 .gitlab-ci.yml                          | 2 +-
 tests/docker/dockerfiles/centos8.docker | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

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: [PATCH v2 10/11] gitlab-ci.yml: Fix the filtering for the git submodules

[Willian Rampazzo]

On Thu, Apr 1, 2021 at 7:25 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> 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>
> Message-Id: <20210331073316.2965928-1-thuth@redhat.com>
> ---
>  .gitlab-ci.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Missing my review from the original patch, anyway:

Reviewed-by: Willian Rampazzo <willianr@redhat.com>

Re: [PATCH v2 03/11] tests/tcg: add concept of container_hosts

[Richard Henderson]

On 4/1/21 3:25 AM, Alex Bennée wrote:
> While docker is nominally multarch 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>
> ---
>   configure              |  2 +-
>   tests/tcg/configure.sh | 27 +++++++++++++++++++++++++--
>   2 files changed, 26 insertions(+), 3 deletions(-)

I'm not really keen on this, but I can't think of anything else. At least the 
dockerfile contents are also under our control, and this is only matching that.


Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~

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

[Richard Henderson]

On 4/1/21 3:25 AM, Alex Bennée wrote:
> 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>
> ---
>   tests/tcg/configure.sh | 5 +++++
>   1 file changed, 5 insertions(+)

Dunno why only these 3 hosts, but what you have matches the data in 
packages.debian.org.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH v2 06/11] tests/tcg/i386: force -fno-pie for test-i386

[Richard Henderson]

On 4/1/21 3:25 AM, Alex Bennée wrote:
> +                -Werror -fno-pie -no-pie -o $TMPE $TMPC; then

What is -no-pie?  That isn't a compiler option, afaik.

r~

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

[Richard Henderson]

On 4/1/21 3:25 AM, Alex Bennée wrote:
>       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

This double next seems just as fragile.  Why don't you just set the breakpoint 
where you want, which appears to be sha1.c:138?


r~

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

[Richard Henderson]

On 4/2/21 9:41 AM, Richard Henderson wrote:
> On 4/1/21 3:25 AM, Alex Bennée wrote:
>>       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
> 
> This double next seems just as fragile.  Why don't you just set the breakpoint 
> where you want, which appears to be sha1.c:138?

That said, make check-tcg has passed, completely, on my laptop for the first 
time in a year.  So,

Tested-by: Richard Henderson <richard.henderson@linaro.org>

r~

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

[Alex Bennée]

Richard Henderson <richard.henderson@linaro.org> writes:

> On 4/1/21 3:25 AM, Alex Bennée wrote:
>>       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
>
> This double next seems just as fragile.  Why don't you just set the
> breakpoint where you want, which appears to be sha1.c:138?

Ideally I'd want an unambiguous label that gdb would understand lest it
got broken by someone tweaking the sha1.c code. I thought a function
header would be better but it appears only marginally so. 

>
>
> r~


-- 
Alex Bennée

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

[Alex Bennée]

Richard Henderson <richard.henderson@linaro.org> writes:

> On 4/1/21 3:25 AM, Alex Bennée wrote:
>> 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>
>> ---
>>   tests/tcg/configure.sh | 5 +++++
>>   1 file changed, 5 insertions(+)
>
> Dunno why only these 3 hosts, but what you have matches the data in
> packages.debian.org.

I did try and convince the packagers to build all the cross gcc's for
all the arches but they did point out (reasonably) that it would be
quite an explosion of binary size in the repos. But at least mainline
arches are getting better support in other mainline arches.

>
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
>
> r~


-- 
Alex Bennée

Re: [PATCH v2 01/11] tests/tcg: update the defaults for x86 compilers

[Philippe Mathieu-Daudé]

On 4/1/21 12:25 PM, Alex Bennée wrote:
> 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>
> ---
>  tests/tcg/configure.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>

Re: [PATCH v2 03/11] tests/tcg: add concept of container_hosts

[Philippe Mathieu-Daudé]

On 4/1/21 12:25 PM, Alex Bennée wrote:
> While docker is nominally multarch these days it doesn't mean our

Typo "multiarch"

> 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>
> ---
>  configure              |  2 +-
>  tests/tcg/configure.sh | 27 +++++++++++++++++++++++++--
>  2 files changed, 26 insertions(+), 3 deletions(-)

Re: [PATCH v2 06/11] tests/tcg/i386: force -fno-pie for test-i386

[Alex Bennée]

Richard Henderson <richard.henderson@linaro.org> writes:

> On 4/1/21 3:25 AM, Alex Bennée wrote:
>> +                -Werror -fno-pie -no-pie -o $TMPE $TMPC; then
>
> What is -no-pie?  That isn't a compiler option, afaik.

No it's a c&p error from the main test in configure:

  # Check we support --no-pie first; we will need this for building ROMs.
  if compile_prog "-Werror -fno-pie" "-no-pie"; then
    CFLAGS_NOPIE="-fno-pie"
  fi

dropping it now.

>
> r~


-- 
Alex Bennée