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
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
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
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
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
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
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
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
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
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
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
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
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>
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~
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~
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~
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~
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~
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
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
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>
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(-)
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