[Qemu-discuss] sigsegv - but where is it coming from?

[Paulo Matos]

Hi,

I am setting up some cross platform testing with qemu-3.1.0 for the
Racket Programming Language under https://gitlab.com/racket/racket.

I have a job building qemu-3.1.0 using the configure line:
$ configure --static --disable-kvm --disable-xen --disable-spice
--target-list='i386-linux-user aarch64-linux-user arm-linux-user
mips-linux-user mipsel-linux-user mips64el-linux-user s390x-linux-user
ppc64le-linux-user riscv64-linux-user' --prefix=$INSTALL_DIR

Initially I didn't know how to do this but then I found about qemu user
targets and debian chroots. So now the idea is that I create a debian
chroot for each platform and call the compiled qemu static binary for
the correct platform.

Here's a run for qemu-arm64:
https://gitlab.com/LinkiTools/racket/-/jobs/178198272

that ends with:
make[8]: Entering directory
'/builds/LinkiTools/racket/racket/src/build/racket'
10:38:48 O: ./racket3m -cqu ../../racket/mksystem.rkt system.rktd "gcc
-E -I. -I../../racket/include -I../../racket/src -g -O2
-DUSE_SENORA_GC    ../../racket/src/systype.c" "" machine "./racket3m"
"./racket3m"
10:38:48 O: SIGSEGV MAPERR si_code 1 fault on addr 0x40018675c8
10:38:48 E: qemu: uncaught target signal 6 (Aborted) - core dumped
10:38:48 E: Aborted (core dumped)

I thought, wow, I am already getting results but I spoke too soon
because soon I noticed that other targets fail in the same place like
* armel : https://gitlab.com/LinkiTools/racket/-/jobs/178198273
* armhf : https://gitlab.com/LinkiTools/racket/-/jobs/178198274

mips' fail on the following compilation step:
* mips : https://gitlab.com/LinkiTools/racket/-/jobs/178198276
* mipsel : https://gitlab.com/LinkiTools/racket/-/jobs/178198277

In any case they always fail running the racket compiled for the target
platform. i386 works so that's not bad.

My question is, could this be a qemu sigsegv or is it definitely a
racket on the guest segfault?

I then tried the same on an armv7l (rpi3):
armv7l : https://gitlab.com/LinkiTools/racket/-/jobs/178198271

and it succeeds to compile racket so I am worried that this might be
because I somehow screwed up configuring qemu.

Regarding the arch names, I have a case in my script that translates the
arch I asked for (which is the name of the debian port) to the qemu arch
that should be used. It looks like this:
    case ${ARCH} in
        "amd64")
            QEMU_ARCH="x86_64"
            ;;
        "arm64")
            QEMU_ARCH="aarch64"
            ;;
        "armel"|"armhf"|"armv7l")
            QEMU_ARCH="arm"
            ;;
        "i386"|"mips"|"mipsel"|"mips64el"|"s390x"|"x86_64")
            QEMU_ARCH=${ARCH}
            ;;
        "ppc64el")
            QEMU_ARCH="ppc64le"
            ;;
        *)
            echo "Unknown architecture ${ARCH}"
            echo "Available archs: amd64, arm64, armel, armhf, armv7l, i386,
mips, mipsel, mips64el, s390x, ppc64el"
            echo "These are the official names for the debian ports available
listed at:"
            echo "https://www.debian.org/ports/";
            echo "NOTE: we also accept x86_64 as an alias for amd64"
            exit 1
            ;;
    esac


So, for ppc64el debian port, we'll use the qemu-ppc64le static binary.

I am looking for suggestions to understanding if this is a qemu problem,
a racket problem or more likely my problem configuring qemu.

-- 
Paulo Matos