diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-07-08 13:28:15 +0200 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-07-08 13:28:28 +0200 |
| commit | 5aa276efcbd67f4300ca1a7f809c6e00aadb03da (patch) | |
| tree | 9b8f0e074014cda8d42f5a97a95bc25082d8b764 /results/classifier/zero-shot-user-mode/output/instruction | |
| parent | 1a3c4faf4e0a25ed0b86e8739d5319a634cb9112 (diff) | |
| download | qemu-analysis-5aa276efcbd67f4300ca1a7f809c6e00aadb03da.tar.gz qemu-analysis-5aa276efcbd67f4300ca1a7f809c6e00aadb03da.zip | |
restructure results
Diffstat (limited to 'results/classifier/zero-shot-user-mode/output/instruction')
396 files changed, 0 insertions, 15065 deletions
diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1010484 b/results/classifier/zero-shot-user-mode/output/instruction/1010484 deleted file mode 100644 index 8d53d108b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1010484 +++ /dev/null @@ -1,12 +0,0 @@ -instruction: 0.590 -syscall: 0.222 -runtime: 0.189 - - - -slirp to accept non-local dns server - -current version of slirp doesn't allow feeded dns address to be outside of given network. -in many scenarios you need to provide dns server that isn't local. - -this simple patch removes checking for if dns server isn't in local subnet. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1027 b/results/classifier/zero-shot-user-mode/output/instruction/1027 deleted file mode 100644 index 3d1224f0d..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1027 +++ /dev/null @@ -1,21 +0,0 @@ -instruction: 0.689 -runtime: 0.201 -syscall: 0.109 - - - -Executables should have embedded plist on macOS -Description of problem: -QEMU binaries on macOS should have an embedded property list (`plist`). - -The bundle identifier of an application, as well as many other settings, are usually not set programmatically but through an `Info.plist` file found within the application bundle (`.app`) which is a property list (basically a settings file in XML format). - -When liking a command line binary, you can tell the linker to embed such a property list inside the binary and the system will respect that when loading the binary. Having an embedded `Info.plist` is highly recommended for all macOS applications, even command line tools, as many system features will not work correctly (or are not even possible) unless they have one (not in all places the binary name will work instead of a bundle identifier). - -All you need to do is writing a [plist file by hand](https://docs.transifex.com/formats/apple-plist) (for a list of available keys, see [Apple's documentation](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Introduction/Introduction.html)) and then tell the liker to embed it into the binary: - -``` --sectcreate __TEXT __info_plist YourPlistFile.plist -``` - -This makes it far easier to set app specific settings correctly, as in #334 for example. Also things like sudden termination can be disabled completely that way without a single line of code. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1028 b/results/classifier/zero-shot-user-mode/output/instruction/1028 deleted file mode 100644 index e81773174..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1028 +++ /dev/null @@ -1,40 +0,0 @@ -instruction: 0.438 -runtime: 0.332 -syscall: 0.230 - - - -Assert fail for RISC-V RVV vmv.v.x for e64, vl == vl_max on RV32 guest -Description of problem: -assert message: -qemu/tcg/tcg-op-gvec.c:1714: tcg_gen_gvec_dup_i32: Assertion `vece <= MO_32' failed. - -For a e64 vmv.v.x, in the file trans_rvv.c.inc, function "trans_vmv_v_x", when s->vl_eq_vlmax is true, then "tcg_gen_gvec_dup_tl" (it's defined to tcg_gen_gvec_dup_i32 for RV32) is called. In "tcg_gen_gvec_dup_i32" the assert "tcg_debug_assert(vece <= MO_32) will be triggered, since vece == MO_64 for e64. -Steps to reproduce: -1.enable cfg.Zve64f - -2.Prepare a problem as set e64, vl == vl_max and use vmv.v.x, maybe as below -``` - li t0, -1, - vsetvli x0, t0, e64,m1,tu,mu - li t1, -1 - vmv.v.x v0, t1 -``` -Additional information: -Below is a possible solution if it's appropriate. -``` -#if TARGET_LONG_BITS == 32 - if (s->sew == 3) { - TCGv_i64 s1_i64 = tcg_temp_new_i64(); - tcg_gen_ext_tl_i64(s1_i64, s1); - tcg_gen_gvec_dup_i64(s->sew, vreg_ofs(s, a->rd), - MAXSZ(s), MAXSZ(s), s1_i64); - tcg_temp_free_i64(s1_i64); - } else { -#endif - tcg_gen_gvec_dup_tl(s->sew, vreg_ofs(s, a->rd), - MAXSZ(s), MAXSZ(s), s1); -#if TARGET_LONG_BITS == 32 - } -#endif -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1031920 b/results/classifier/zero-shot-user-mode/output/instruction/1031920 deleted file mode 100644 index 7ecf8c33d..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1031920 +++ /dev/null @@ -1,43 +0,0 @@ -instruction: 0.593 -runtime: 0.266 -syscall: 0.141 - - - -Linux user gdbserver does not respond to remote `Ctrl-C' interrupts - -The bug was reproduce in a recent mainline build for ARM Linux by starting emulation with a gdbserver: - -$ qemu-arm -g 1234 a.out - -and then connecting from gdb: - -(gdb) target remote :1234 -Remote debugging using :1234 -[New Remote target] -[Switching to Remote target] -0x00008ba8 in _start () -(gdb) b main -Breakpoint 1 at 0x8cb0: file hello.c, line 5. -(gdb) cont -Continuing. - -Breakpoint 1, main (argc=1, argv=0xf6fff24c) at hello.c:5 -5 int n = 0; -(gdb) l -1 #include <stdio.h> -2 -3 int main (int argc, char **argv) -4 { -5 int n = 0; -6 -7 for (;;) { -8 printf ("Hello, World!\n"); -9 sleep (5); -10 } -(gdb) cont -Continuing. -^C^CInterrupted while waiting for the program. -Give up (and stop debugging it)? (y or n) y - -Notice that the `Ctrl-C' interrupts are ignored. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1034 b/results/classifier/zero-shot-user-mode/output/instruction/1034 deleted file mode 100644 index aedc23caa..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1034 +++ /dev/null @@ -1,23 +0,0 @@ -instruction: 0.672 -runtime: 0.209 -syscall: 0.119 - - - -Erlang/OTP 25 JIT on AArch64 fails in user mode emulation -Description of problem: -Compiling Erlang/OTP 25 fails with segfault when using user mode (but works in system mode), the Erlang devs have tracked it down in [ErlangForums](https://erlangforums.com/t/otp-25-0-rc3-release-candidate-3-is-released/1317/24) and give this explanation: - -> Thanks, I’ve found a bug in QEMU that explains this. The gist of it is: -> -> Instead of interpreting guest code, QEMU dynamically translates it to the host architecture. When the guest overwrites code for one reason or another, the translation is invalidated and redone if needed. -> -> Our JIT:ed code is mapped in two regions to work in the face of W^X restrictions: one executable but not writable, and one writable but not executable. Both of these regions point to the same physical memory and writes to the writable region are “magically” reflected in the executable one. -> -> I would’ve expected QEMU to honor the IC IVAU / ISB instructions we use to tell the processor that we’ve altered code at a particular address, but for some reason QEMU just ignores them 3 and relies entirely on trapping writes to previously translated code. -> -> In system mode QEMU emulates the MMU and sees that these two regions point at the same memory, and has no problem invalidating the executable region after writing to the writable region. -> -> In user mode it instead calls mprotect(..., PROT_READ) on all code regions it has translated, and invalidates translations in the signal handler. The problem is that we never write to the executable region – just the writable one – so the code doesn’t get invalidated. - -There doesn't seem to a open or closed QEMU bug that actually describes this problem. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1041 b/results/classifier/zero-shot-user-mode/output/instruction/1041 deleted file mode 100644 index 80581b7c8..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1041 +++ /dev/null @@ -1,37 +0,0 @@ -instruction: 0.609 -runtime: 0.268 -syscall: 0.123 - - - -x86_64 Auxillary vector reports platform as i686 which doesn't match the linux kernel -Description of problem: -Based on the kernel source in the auxiliary vector AT_PLATFORM should be `x86_64` (confirmed by running outside qemu). However qemu sets it to `i686`. - -This was originally reported with docker-for-mac, but was reduced on `x86_64` which is why it is pointless -Steps to reproduce: -1. Compile the following for x86_64 (statically if you don't want have an x86_64 dynamic linker) (code originally from https://stackoverflow.com/questions/26520163/accessing-auxiliary-vectors-c) - -``` -#include <stdio.h> -#include <elf.h> - -int main(int argc, char** argv, char* envp[]) { - Elf64_auxv_t *auxv; - while(*envp++ != NULL); - - /*from stack diagram above: *envp = NULL marks end of envp*/ - int i = 0 ; - for (auxv = (Elf64_auxv_t *)envp; auxv->a_type != AT_NULL; auxv++) - /* auxv->a_type = AT_NULL marks the end of auxv */ - { - if( auxv->a_type == AT_PLATFORM) - printf("AT_PLATFORM is: %s\n", ((char*)auxv->a_un.a_val)); - } -} -``` -2. Run with `qemu-x86_64-static` -3. See `AT_PLATFORM is: i686` -4. Compare to "real" x86_64 bit system which gives `AT_PLATFORM is: x86_64` -Additional information: -I think that adding `#define ELF_PLATFORM "x86_64"` [here](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c#L134) should work (but I don't fully understand the code). Otherwise we just end up getting the 32-bit case. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1052857 b/results/classifier/zero-shot-user-mode/output/instruction/1052857 deleted file mode 100644 index ba47af0d8..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1052857 +++ /dev/null @@ -1,21 +0,0 @@ -instruction: 0.613 -syscall: 0.197 -runtime: 0.190 - - - -qemu-user compiled static for ppc fails on 64bit hosts - -On debian I used debootstrap to set up a powerpc chroot. If I then copy in a statically linked qemu-user ppc binary it will work for some commands in the chroot and fail for others. Steps to reproduce: - -host$ mkdir powerpc -host$ sudo debootstrap --arch=powerpc --foreign wheezy powerpc http://ftp.debian.org/debian -host$ sudo cp /usr/bin/qemu-ppc-static powerpc/usr/bin/ -host$ LANG=C sudo chroot powerpc /usr/bin/qemu-ppc-static /bin/bash -I have no name!@guest:/# pwd -/ -I have no name!@guest:/# cd home/ -I have no name!@guest:/home# ls -qemu-ppc-static: /tmp/buildd/qemu-1.1.2+dfsg/linux-user/signal.c:4341: setup_frame: Assertion `({ unsigned long __guest = (unsigned long)(ka->_sa_handler) - guest_base; (__guest < (1ul << 32)) && (!reserved_va || (__guest < reserved_va)); })' failed. - -I have also built this from the git HEAD sources (hash 6b80f7db8a7f84d21e46d01e30c8497733bb23a0) and I get the same result. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1054812 b/results/classifier/zero-shot-user-mode/output/instruction/1054812 deleted file mode 100644 index cf9d4a41c..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1054812 +++ /dev/null @@ -1,11 +0,0 @@ -instruction: 0.601 -syscall: 0.243 -runtime: 0.156 - - - -Configure uses wrong libtool on Darwin - -On Darwin/OS X, there are two versions of libtool: the GNU libtool, and Apple's libtool. Both are installed, but Apple's libtool (libtool) won't build libcacard that Qemu uses, but Gnu's libtool (glibtool) does. I get around using Apple's libtool by passing LIBTOOL=glibtool when configuring; unfortunately this variable isn't preserved so when Qemu's configure changes it's not passed. A simple switch in the configure script could check for Darwin, then if present, use glibtool. Or configure could check the features of libtool, see if they can build libcacard, then look for alternatives like glibtool. - -This bug was probably introduced when libcacard was added to Qemu, and is present in commit 93b6599734f81328ee3d608f57667742cafeea72. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1054831 b/results/classifier/zero-shot-user-mode/output/instruction/1054831 deleted file mode 100644 index d58833e79..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1054831 +++ /dev/null @@ -1,23 +0,0 @@ -instruction: 0.546 -syscall: 0.299 -runtime: 0.155 - - - -qemu-user-static for sparc32plus : bash: fork: Invalid argument - -On Debian x86-64 host system I setup a sparc chroot using: - -host $ mkdir sparc -host $ sudo debootstrap --arch=sparc --foreign wheezy sparc http://ftp.au.debian.org/debian -host $ sudo cp ~/Git/qemu/sparc32plus-linux-user/qemu-sparc32plus sparc/usr/bin/qemu-sparc32plus-static -host $ LANG=C sudo chroot sparc/ /usr/bin/qemu-sparc32plus-static /bin/bash - -When I then run the second stage of debootstrap I get: - -target $ /debootstrap/debootstrap --second-stage -bash: fork: Invalid argument - -The above procedures works perfectly for armhf. - -This is with current git HEAD (commit 93b6599734f81328ee3d608f57667742cafeea72). \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1059 b/results/classifier/zero-shot-user-mode/output/instruction/1059 deleted file mode 100644 index 98147c627..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1059 +++ /dev/null @@ -1,16 +0,0 @@ -instruction: 0.656 -syscall: 0.184 -runtime: 0.160 - - - -qemu: uncaught target signal 6 (Aborted) - core dumped Issue -Description of problem: -When we are trying to use the docker images which is using Qemu internally in mac Os then we are getting the qemu: uncaught target signal 6 (Aborted) - core dumped Issue -Steps to reproduce: -1. https://botfront.io/docs/installation/local-machine install in local machine -2. run bot front run -3. Go to the docker dashboard and open the botfront-rasa. -4.  -Additional information: -Looking forward to get some updates regarding how we can solve this or any hack we can apply here. Thanks in advance. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1066909 b/results/classifier/zero-shot-user-mode/output/instruction/1066909 deleted file mode 100644 index e3360c221..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1066909 +++ /dev/null @@ -1,13 +0,0 @@ -instruction: 0.406 -syscall: 0.406 -runtime: 0.187 - - - -App-level clone emulation for microblaze is broken - -When CLONE_THREAD is used, the new process starts with the program counter pointing to the system call instruction, rather than the instruction immediately following it. This causes an infinite cascade (linear growth, not exponential) of thread creation, which quickly crashes when the threads start running and they're all using the same stack. - -I'm using qemu 1.1.2 packaged with Debian, but I'm not aware of any fixes since then that would address the problem. - -I can provide a test program if needed; a short C program using syscall() directly or an even-shorter asm program can demonstrate the issue without need for debugging around pthread library routines. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1068900 b/results/classifier/zero-shot-user-mode/output/instruction/1068900 deleted file mode 100644 index 83813f7a3..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1068900 +++ /dev/null @@ -1,11 +0,0 @@ -instruction: 0.517 -runtime: 0.364 -syscall: 0.119 - - - -Thread cancellation broken in app-level emulation - -Thread cancellation (and certain other implementation-internal things such as set*id() and timers) are implemented in userspace on Linux by stealing a couple of the realtime signals for internal use by the implementation, leaving them unavailable to applications. Unfortunately, this bites qemu application-level emulation when the application being run uses thread cancellation or other features that need such signals. The signal handler is unable to be set (because sigaction on the host rejects the signal numbers) and attempts to send the signals result in it being received not by the emulated application code, but by the libc/libpthread code on which qemu is running; this in turn seems to cause qemu to crash. - -The best solution I can think of is for qemu to steal one of the realtime signals for its own use, and multiplex signal numbers outside the range SIGRTMIN..SIGRTMAX, as well as the stolen signal itself, on top of this stolen signal. This would both allow cancellation to work, and would allow applications the full range of realtime signals when the guest has more signals than the host (e.g. MIPS running on x86 host). \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1070 b/results/classifier/zero-shot-user-mode/output/instruction/1070 deleted file mode 100644 index b4470b37c..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1070 +++ /dev/null @@ -1,16 +0,0 @@ -instruction: 0.512 -syscall: 0.254 -runtime: 0.234 - - - -gdbstub XML generation for ARM is done for every CPU -Description of problem: -- As arm_cpu_register_gdb_regs_for_features is called from the device - realize stage for each vCPU in user mode we end up uselessly - regenerating the XML for every new thread. Once you get up to 100 - threads this starts exceeding the large maps done for QHT and PageDesc -Steps to reproduce: -See above command line, valgrind picks it up -Additional information: -See also #866, #967 diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1072 b/results/classifier/zero-shot-user-mode/output/instruction/1072 deleted file mode 100644 index 5540f4e6b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1072 +++ /dev/null @@ -1,30 +0,0 @@ -instruction: 0.458 -runtime: 0.360 -syscall: 0.182 - - - -different behavior when remote debugger is used -Description of problem: -I found Qemu shows different behavior when I run Qemu with hello-world (statically linked binary enclosed) directly or run it through remote debugger. I need help to understand the following: - -1. Is this intended behavior? -1. Any way to make the two approaches have consistent behavior (I prefer the behavior shown in the 2nd approach described below) -1. If it is intended behavior, any explanation why or suggestions how to dig further to root cause the difference. - -The corresponding source code is the line 86 in [filedoalloc.c](https://code.woboq.org/userspace/glibc/libio/filedoalloc.c.html#86). It tests if the file (stdout) is char special device (S_ISCHR) -The preprocessed code is as follows: - if (((((st.st_mode)) & 0170000) == (0020000))) - -I then compared two different approaches to run Qemu: - -1. I used the following command line to collect the trace: qemu_aarch64 -strace -plugin $QEMU_ROOT/build/contrib/plugins/libexeclog.so -d plugin hello.a64. This one tests False for S_ISCHR -1. when I used gdb to connect to Qemu and single-step the instructions, S_ISCHR tests True, which is different from running qemu directly (approach 1). - -Thanks! -Steps to reproduce: -1.[hello.a64](/uploads/4b4ccae8c1e4b045c39ceae6a094d55a/hello.a64) -2. -3. -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1075 b/results/classifier/zero-shot-user-mode/output/instruction/1075 deleted file mode 100644 index bcb6e4163..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1075 +++ /dev/null @@ -1,22 +0,0 @@ -instruction: 0.501 -syscall: 0.377 -runtime: 0.122 - - - -Unable to create a cluster using ppc64le specific kind binary on x86 host architecture -Description of problem: - -Steps to reproduce: -1. docker run --rm --privileged multiarch/qemu-user-static --reset -p yes -2. wget https://github.com/kubernetes-sigs/kind/releases/download/v0.14.0/kind-linux-ppc64le -3. chmod u+x kind-linux-ppc64le -4. curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/ppc64le/kubectl -5. chmod +x kubectl -6. sudo cp kubectl /usr/local/bin/ -7. KUBECONFIG="${HOME}/kind-test-config" -8. export KUBECONFIG -9. ./kind-linux-ppc64le create cluster --image quay.io/mayurwaghmode111/node-ppc64le:ppc64le -v=3 --wait 1m --retain -10. ./kind-linux-ppc64le export logs -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1075339 b/results/classifier/zero-shot-user-mode/output/instruction/1075339 deleted file mode 100644 index 1cb7de29e..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1075339 +++ /dev/null @@ -1,9 +0,0 @@ -instruction: 0.595 -runtime: 0.299 -syscall: 0.105 - - - -linux-user emulation of setsockopt ignores optlen - -setsockopt always treats the argument as a 4-byte int. This breaks timeout options (for which it's an 8- or 16-byte timeval structure, depending on word size) and possibly other socket options. int is probably a safe default, but options whose values are other types need special-case conversion code. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1076445 b/results/classifier/zero-shot-user-mode/output/instruction/1076445 deleted file mode 100644 index cef49fc3d..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1076445 +++ /dev/null @@ -1,51 +0,0 @@ -instruction: 0.473 -runtime: 0.285 -syscall: 0.242 - - - -qemu-i386 fails on system(3) with a cross-toolchain from Buildroot - -qemu-i386 fails with small C program containing a system(). -The C program is cross-compiled with a toolchain created by buildroot (http://buildroot.net/), gcc version 4.6.3, uClibc version 0.9.33.2 . -qemu version 1.2.0 (built with http://git.buildroot.net/buildroot/tree/package/qemu/qemu.mk) -host machine : Ubuntu 12.04 LTS on x86_64. - - $ cat sys.c - #include <stdio.h> - #include <stdlib.h> - - int main() - { - int ret = system("echo hello"); - printf("%d\n", ret); - } - - $ ../../host/usr/bin/i686-buildroot-linux-uclibc-gcc -o sys sys.c - $ file sys - sys: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped - $ ../../host/usr/bin/qemu-i386 ./sys - -1 - -same problem with x86_64 : - $ ../../host/usr/bin/x86_64-buildroot-linux-uclibc-gcc -o sys sys.c - $ file sys - sys: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped - $ ../../host/usr/bin/qemu-x86_64 sys - -1 - -works fine with arm : - $ ../../host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -o sys sys.c - $ file sys - sys: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped - $ ../../host/usr/bin/qemu-arm ./sys - hello - 0 - -works fine with mips : - $ ../../host/usr/bin/mips-buildroot-linux-uclibc-gcc -o sys sys.c - $ file sys - sys: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked (uses shared libs), with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70403, not stripped - $ ../../host/usr/bin/qemu-mips sys - hello - 0 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1079080 b/results/classifier/zero-shot-user-mode/output/instruction/1079080 deleted file mode 100644 index 486afa7af..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1079080 +++ /dev/null @@ -1,16 +0,0 @@ -instruction: 0.848 -runtime: 0.112 -syscall: 0.040 - - -ARM instruction "srs" wrong behaviour - -Quote from ARM Architecture Reference Manual ARMv7-A and ARMv7-R : -"Store Return State stores the LR and SPSR of the current mode to the stack of a specified mode" - -Problem: -When executing this instruction, the register stored is CPSR instead of SPSR. - -Context: -Using QEMU 1.2.0 to simulate a Zynq application (processor Cortex-a9 mpcore) with the following command line: -qemu-system-arm -M xilinx-zynq-a9 -m 512 -serial null -serial mon:stdio -dtb /home/vcesson/workspace/xilinx_zynq.dtb -kernel install/tests/io/serial/current/tests/serial2 -S -s -nographic \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1092 b/results/classifier/zero-shot-user-mode/output/instruction/1092 deleted file mode 100644 index 9183533bb..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1092 +++ /dev/null @@ -1,20 +0,0 @@ -instruction: 0.942 -runtime: 0.039 -syscall: 0.019 - - - -PPC: `sraw` instructions does not set `ca` and `ca32` flags. -Description of problem: -The translation of Power PC instruction `sraw` and `sraw.` don't set the `ca` or `ca32` flags although, according to -[PowerISA 3.1b](https://files.openpower.foundation/s/dAYSdGzTfW4j2r2) (page 140), they should. -Additional information: -This gets particular apparent if compared to `srawi` (which does set `ca`, `ca32`). - -**sraw** - -https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L2914 - -**srawi** - -https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L2924 diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1093 b/results/classifier/zero-shot-user-mode/output/instruction/1093 deleted file mode 100644 index bb569fb8f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1093 +++ /dev/null @@ -1,39 +0,0 @@ -instruction: 0.604 -syscall: 0.242 -runtime: 0.154 - - - -RISC-V: signal frame is misaligned in signal handlers -Description of problem: -`qemu-user` misaligns the signal frame (to 4 bytes rather than 16 bytes) on RISC-V 64, e.g causing pointer misalignment diagnostics to be triggered by UBSan. -Steps to reproduce: -1. Create a C file with the following contents: -```c -#include <signal.h> -#include <stdio.h> - -void handler(int sig, siginfo_t *info, void *context) { - printf("signal occurred, info: %p, context: %p\n", info, context); -} - -int main() { - struct sigaction act; - act.sa_flags = SA_SIGINFO; - act.sa_sigaction = handler; - sigaction(SIGINT, &act, NULL); - - // Deliberately misalign the stack - asm volatile ("addi sp, sp, -4"); - - while(1); - // Unreachable -} -``` -2. Compile with an appropriate RISC-V toolchain and run with `qemu-riscv64 ./a.out`. -3. Send a `SIGINT` (e.g by hitting Ctrl-C), and observe that the signal frame will be misaligned: -``` -signal occurred, info: 0x400080025c, context: 0x40008002dc -``` -Additional information: -This issue is alluded to in the source code, see https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/riscv/signal.c#L68-69. It should be sufficient to change that constant to 15. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1095531 b/results/classifier/zero-shot-user-mode/output/instruction/1095531 deleted file mode 100644 index dcc511cdf..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1095531 +++ /dev/null @@ -1,63 +0,0 @@ -instruction: 0.445 -syscall: 0.314 -runtime: 0.241 - - - -sparc32plus (and others?) has x86 code generation errors on 64bit hosts - -On 64bit hosts, the load and store functions compile improperly. The issue is the call to gen_address_mask() under the ld and st functions in target-sparc/translate.c. Below are some snips from the log file. Doing a gdb debug, this results in constant access violation errors which I do not see when debugging qemu in powerpc mode. - --------------- -IN: -0x0000000040804aa8: st %i0, [ %fp + 0x44 ] - -OP: - ---- 0x40804aa8 - ld_i64 tmp1,regwptr,$0xb0 - mov_i64 tmp0,tmp1 - movi_i64 tmp2,$0x44 - add_i64 tmp0,tmp0,tmp2 - ld_i64 tmp2,regwptr,$0x80 - ext32u_i64 tmp0,tmp0 - qemu_st32 tmp2,tmp0,$0x0 - -OUT: [size=345] -0x6032d7f0: mov 0x40(%r14),%rbp -0x6032d7f4: mov 0xb0(%rbp),%rbx -0x6032d7fb: add $0x44,%rbx -0x6032d7ff: mov 0x80(%rbp),%rbp -0x6032d806: mov %ebx,%ebx <- bug -0x6032d808: mov %ebp,%edi -0x6032d80a: bswap %edi -0x6032d80c: mov %edi,(%rbx) - --------------- -IN: -0x0000000040804aec: add %l7, %o7, %l7 -0x0000000040804af0: ld [ %l7 ], %g2 - -OP: - ---- 0x40804aec - ld_i64 tmp1,regwptr,$0x78 - ld_i64 tmp2,regwptr,$0x38 - add_i64 tmp0,tmp1,tmp2 - st_i64 tmp0,regwptr,$0x78 - - ---- 0x40804af0 - ld_i64 tmp1,regwptr,$0x78 - mov_i64 tmp0,tmp1 - ext32u_i64 tmp0,tmp0 - qemu_ld32u g2,tmp0,$0x0 - -OUT: [size=395] -0x6032da80: mov 0x40(%r14),%rbp -0x6032da84: mov 0x78(%rbp),%rbx -0x6032da88: mov 0x38(%rbp),%r12 -0x6032da8c: add %r12,%rbx -0x6032da8f: mov %rbx,0x78(%rbp) -0x6032da93: mov 0x78(%rbp),%rbx -0x6032da97: mov %ebx,%ebx <- bug -0x6032da99: mov (%rbx),%ebx - -In 64bit mode, doing a 32bit operation will result in the top 32bit's being zero'd. I attempted to simply disable the call to gen_address_mask() but that did not fix the issue and actually caused the sparc32plus I was testing to become unusable. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1095857 b/results/classifier/zero-shot-user-mode/output/instruction/1095857 deleted file mode 100644 index d261dbdb6..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1095857 +++ /dev/null @@ -1,17 +0,0 @@ -instruction: 0.970 -runtime: 0.018 -syscall: 0.012 - - - -incorrect handling of [r32] address (long mode) - -while executing in Long Mode (x86-64) instructions such as - -mov eax,[r15d] - -end up executing as - -mov eax,[r15] - -according to x86 programmer manuals the behavior of using the Address-Size override (in long mode) is supposed to ignore the high 32bits of the register. I use this fact in my operating system to reduce register usage (the high 32 bits of r15 holds other data). consequently a general protection exception occurs since the memory address isn't "canonical". this error doesn't always appear since the high 32 bits might not be zero in those conditions. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1098729 b/results/classifier/zero-shot-user-mode/output/instruction/1098729 deleted file mode 100644 index 7807819ad..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1098729 +++ /dev/null @@ -1,49 +0,0 @@ -instruction: 0.598 -runtime: 0.226 -syscall: 0.176 - - - -qemu-user-static for armhf: segfault in threaded code - - -Currently running QEMU from git (fedf2de31023) and running the armhf version of qemu-user-static which I have renamed qemu-armhf-static to follow the naming convention used in Debian. - -The host systems is a Debian testing x86_64-linux and I have an Debian testing armhf chroot which I invoke using schroot. - -Majority of program in the armhf chroot run fine, but I'm getting qemu segfaults in multi-threaded programs. - -As an example, I've grabbed the threads demo program here: - - https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_mutex.c - -and changed NUMTHRDS from 4 to 10. I compile it as (same compile command on both x86_64 host and armhf guest): - - gcc -Wall -lpthread dotprod_mutex.c -o dotprod_mutex - -When compiled for x86_64 host it runs perfectly and even under Valgrind displays no errors whatsoever. - -However, when I compile the program in my armhs chroot and run it it usually (but not always) segaults or hangs or crashes. Example output: - - - (armhf) $ ./dotprod_mutex - Thread 1 did 100000 to 200000: mysum=100000.000000 global sum=100000.000000 - Thread 0 did 0 to 100000: mysum=100000.000000 global sum=200000.000000 - TCG temporary leak before f6731ca0 - qemu-arm-static: /home/erikd/Git/qemu-posix-timer-hacking/Upstream/tcg/tcg-op.h:2371: - tcg_gen_goto_tb: Assertion `(tcg_ctx.goto_tb_issue_mask & (1 << idx)) == 0' failed. - - - (armhf) $ ./dotprod_mutex - qemu: uncaught target signal 11 (Segmentation fault) - core dumped - Segmentation fault - - (armhf) $ ./dotprod_mutex - qemu-arm-static: /home/erikd/Git/qemu-posix-timer-hacking/Upstream/tcg/tcg.c:519: - tcg_temp_free_internal: Assertion `idx >= s->nb_globals && idx < s->nb_temps' failed. - - - (armhf) $ ./dotprod_mutex - Thread 1 did 100000 to 200000: mysum=100000.000000 global sum=100000.000000 - qemu: uncaught target signal 11 (Segmentation fault) - core dumped - Segmentation fault \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1128 b/results/classifier/zero-shot-user-mode/output/instruction/1128 deleted file mode 100644 index 60212a6ae..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1128 +++ /dev/null @@ -1,30 +0,0 @@ -instruction: 0.608 -runtime: 0.223 -syscall: 0.169 - - - -PPC: `spr_write_xer` doesn't set flag bits in `cpu_xer` -Description of problem: -`spr_write_xer()` does not set the `ca`, `ov`, `so`, `ca32`, `ov32` etc. flag bits in the `cpu_xer` variable. - -In fact it copies all bits from the source `GPR` and _excludes_ each flag bit. - -This is not a problem for execution since `spr_read_xer()` gets the flag bits from `cpu_ca/ov/so...` and not from `cpu_xer`. - -Nonetheless it is problem for tools which trace the execution in QEMU (e.g. https://github.com/BinaryAnalysisPlatform/qemu). - -A fix would be to remove the `~` in https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L481 -Steps to reproduce: -Haven't found out yet how to debug QEMU so the TCGv values can be investigated. But in general one need to: - -- Execute a binary which executes something like: -``` -r4 = 0xffffffffffffffff -mtxer r4 -``` -and check the `cpu_xer` value after the `xer` write. - -Checking the debug logs (`in_asm,cpu`) doesn't work, since the `xer` value in the logs is not taken directly from `cpu_xer`. -Additional information: -Code ref: https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L480-L483 diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1129571 b/results/classifier/zero-shot-user-mode/output/instruction/1129571 deleted file mode 100644 index 34d70dbe1..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1129571 +++ /dev/null @@ -1,20 +0,0 @@ -instruction: 0.715 -runtime: 0.174 -syscall: 0.111 - - - -libreoffice armhf FTBFS - -We have been experiencing FTBFS of LibreOffice 3.5.7, 12.04, armhf in the launchpad buildds. We believe this is likely due to an error in qemu. - -While we do not have a small test case yet, we do have a build log (attaching here). - -The relevant snippet from the build log is: - -3.5.7/solver/unxlngr.pro/bin/jaxp.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/juh.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/parser.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/unoil.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/ridl.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/jurt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xmlsearch.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/LuceneHelpWrapper.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/HelpIndexerTool.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-core-2.3.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-analyzers-2.3.jar" com.sun.star.help.HelpIndexerTool -lang cs -mod swriter -zipdir ../../unxlngr.pro/misc/ziptmpswriter_cs -o ../../unxlngr.pro/bin/swriter_cs.zip.unxlngr.pro -dmake: Error code 132, while making '../../unxlngr.pro/bin/swriter_cs.zip' - -We believe this is from bash error code 128 + 4, where 4 is illegal instruction, thus leading us to suspect qemu. - -Any help in tracking this down would be appreciated. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1147 b/results/classifier/zero-shot-user-mode/output/instruction/1147 deleted file mode 100644 index 07f7e2a86..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1147 +++ /dev/null @@ -1,15 +0,0 @@ -instruction: 0.697 -runtime: 0.214 -syscall: 0.089 - - - -x86_64 emu on aarch64 host: cpu_exec: assertion failed: (cpu == current_cpu) -Description of problem: -Execution of some binaries crashes with `Bail out! ERROR:../qemu-7.0.0/accel/tcg/cpu-exec.c:933:cpu_exec: assertion failed: (cpu == current_cpu)`. Looking at the code, that code is wrapped in a gcc/clang ifdef. Recompiling with clang produces this crash instead: `... include/qemu/rcu.h:102: void rcu_read_unlock(void): Assertion 'p_rcu_reader->depth != 0' failed.` - -No easier steps to reproduce (yet) than `systemd-nspawn`ing into an x86_64 Ubuntu container invoking qemu-x86_64-static through binfmt. Commands such as `ls` work fine, while `apt-get` will immediately crash with the error listed above. - -Note that this happens running Asahi Linux on the bare metal of an M1-based Macbook Pro. This same issue does *not* occur running the *same* binaries with the *same* x86_64 Ubuntu image on an Arch or Ubuntu VM under macOS on the same machine - regardless of if the QEMU binaries were built in a VM or in Asahi. - -These are big.LITTLE chips. Using taskset/affinity to limit the target process to a single specific core does not help. The Asahi kernel has a 16K page-size, which is known to cause trouble for some programs. qemu-arm(-static) however works without any issues (the M1 cannot run 32-bit ARM code natively, only 64-bit). diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1156 b/results/classifier/zero-shot-user-mode/output/instruction/1156 deleted file mode 100644 index cdd76107e..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1156 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.852 -runtime: 0.096 -syscall: 0.052 - - - -Incorrect implementation of vmsumudm instruction diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1156313 b/results/classifier/zero-shot-user-mode/output/instruction/1156313 deleted file mode 100644 index 095f87a9a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1156313 +++ /dev/null @@ -1,132 +0,0 @@ -instruction: 0.397 -runtime: 0.351 -syscall: 0.252 - -semantic: 0.869 -mistranslation: 0.841 -assembly: 0.789 -device: 0.777 -instruction: 0.707 -other: 0.705 -vnc: 0.702 -graphic: 0.657 -socket: 0.605 -boot: 0.576 -network: 0.533 -KVM: 0.518 - -X86-64 flags handling broken - -The current qemu sources cause improper handling of flags on x86-64. -This bug seems to have shown up a few weeks ago. - -A plain install of Debian GNU/Linux makes user processes catch -spurious signals. The kernel seems to run stably, though. - -The ADX feature works very poorly. It might be related; at least it -allows for reproducibly provoking invalid behaviour. - -Here is a test case: - -================================================================ -qemumain.c -#include <stdio.h> -long adx(); -int -main () -{ - printf ("%lx\n", adx (0xffbeef, 17)); - return 0; -} -================================================================ -qemuadx.s: - .globl adx -adx: xor %rax, %rax -1: dec %rdi - jnz 1b - .byte 0xf3, 0x48, 0x0f, 0x38, 0xf6, 0xc0 # adox %rax, %rax - .byte 0x66, 0x48, 0x0f, 0x38, 0xf6, 0xc0 # adcx %rax, %rax - ret -================================================================ - -Compile and execute: -$ gcc -m64 qemumain.c qemuadx.s -$ a.out -ffffff8000378cd8 - -Expected output is simply "0". The garbage value varies between qemu -compiles and guest systems. - -Note that one needs a recent GNU assembler in order to handle adox and -adcx. For convenience I have supplied them as byte sequences. - -Exaplanation and feeble analysis: - -The 0xffbeef argument is a loop count. It is necessary to loop for a -while in order to trigger this bug. If the loop count is decreased, -the bug will seen intermittently; the lower the count, the less -frequent the invalid behaviour. - -It seems like a reasonable assumption that this bug is related to -flags handling at context switch. Presumably, qemu keeps flags state -in some internal format, then recomputes then when needing to form the -eflags register, as needed for example for context switching. - -I haven't tried to reproduce this bug using qemu-x86_64 and SYSROOT, -but I strongly suspect that to be impossible. I use -qemu-system-x86_64 and the guest Debian GNU/Linux x86_64 (version -6.0.6) . - -The bug happens also with the guest FreeBSD x86_64 version 9.1. (The -iteration count for triggering the problem 50% of the runs is not the -same when using the kernel Linux and FreeBSD's kernel, presumably due -to different ticks.) - -The bug happens much more frequently for a loaded system; in fact, the -loop count can be radically decreased if two instances of the trigger -program are run in parallel. - -Richard Henderson <email address hidden> writes: - - Patch at http://patchwork.ozlabs.org/patch/229139/ - -Thanks. I can confirm that this fixes the bug triggered by my test case -(and yours). However, the instability of Debian GNU/Linux x86_64 has -not improved. - -The exact same Debian version (debian "testing") updated at the same -time runs well on hardware. - -My qemu Debian system now got messed up, since I attempted an upgrade in -the buggy qemu, which segfaulted several times during the upgrade. I -need to reinstall, and then rely on -snapshot. - -There is a problem with denorms which is reproducible, but whether that -is a qemu bug, and whether it can actually cause the observed -instability, is questionable. Here is a testcase for that problem: - - - - -It should terminate. The observed buggy behaviour is that it hangs. - -The instability problem can be observed at gmplib.org/devel/tm-date.html. -hwl-deb.gmplib.org is Debian under qemu with -cpu Haswell,+adx. - -Not that the exact same qemu runs FreeBSD flawlessly (hwl.gmplib.org). -It is neither instable nor does it run the denorms testcase poorly. - -I fully realise this is a hopeless bug report, but I am sure you can -reproduce it, since it is far from GMP specific. After all apt-get -update; apt-get upgrade triggered it. Debugging it will be a nightmare. - -Qemu version: main git repo from less than a week ago + Richard ADX -patch. - --- -Torbjörn - - -It looks from this bug that we fixed the initial ADOX bug in commit c53de1a2896cc (2013), and I've just tried the 'qemu-denorm-problem.s' test case from comment #1 and it works OK, so I think we've fixed that denormals bug too. Given that, and that this bug report is 4 years old, I'm going to close it. If you're still having problems with recent versions of QEMU, please open a new bug. - - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1165383 b/results/classifier/zero-shot-user-mode/output/instruction/1165383 deleted file mode 100644 index 6a1a0e1ce..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1165383 +++ /dev/null @@ -1,9 +0,0 @@ -instruction: 0.711 -runtime: 0.174 -syscall: 0.115 - - - -executable qemu-1.4.0/i386-linux-user/./qemu-i386 gives a segmentation fault - -executable qemu-1.4.0/i386-linux-user/./qemu-i386 gives a segmentation fault \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1178 b/results/classifier/zero-shot-user-mode/output/instruction/1178 deleted file mode 100644 index acd97b51b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1178 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.365 -runtime: 0.339 -syscall: 0.297 - - - -is that riscv64 `feq.s` only should consider the lowest 32-bits. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1182490 b/results/classifier/zero-shot-user-mode/output/instruction/1182490 deleted file mode 100644 index 5f02ab548..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1182490 +++ /dev/null @@ -1,82 +0,0 @@ -instruction: 0.389 -runtime: 0.314 -syscall: 0.296 - - - -[qemu-1.5] coroutine-win32.c broken on NULL pointer - -Program received signal SIGSEGV, Segmentation fault. -[Switching to Thread 4340.0x163c] -qemu_coroutine_switch (action=COROUTINE_TERMINATE, to_=0x0, from_=0x3ba1c80) - at /home/cauchy/vcs/git/qemu/coroutine-win32.c:47 -(gdb) bt -#0 qemu_coroutine_switch (action=COROUTINE_TERMINATE, to_=0x0, - from_=0x3ba1c80) at /home/cauchy/vcs/git/qemu/coroutine-win32.c:47 -#1 coroutine_trampoline (co_=0x3ba1c80) - at /home/cauchy/vcs/git/qemu/coroutine-win32.c:58 -#2 0x0000000077098fed in ?? () -#3 0x0000000000000000 in ?? () -(gdb) -(gdb) info registers -rax 0x0 0 -rbx 0x3ba1c80 62528640 -rcx 0x0 0 -rdx 0x0 0 -rsi 0x770b28d0 1997220048 -rdi 0x3ba1b38 62528312 -rbp 0x0 0x0 -rsp 0xc0bff60 0xc0bff60 -r8 0x3184c0 3245248 -r9 0x43e31a 4449050 -r10 0x0 0 -r11 0x206 518 -r12 0x0 0 -r13 0x0 0 -r14 0x0 0 -r15 0x0 0 -rip 0x43e2cd 0x43e2cd <coroutine_trampoline+61> -eflags 0x10206 [ PF IF RF ] -cs 0x33 51 -ss 0x2b 43 -ds 0x0 0 -es 0x0 0 -fs 0x0 0 -gs 0x0 0 -(gdb) disassemble -Dump of assembler code for function coroutine_trampoline: - 0x000000000043e290 <+0>: push %rdi - 0x000000000043e291 <+1>: push %rsi - 0x000000000043e292 <+2>: push %rbx - 0x000000000043e293 <+3>: sub $0x30,%rsp - 0x000000000043e297 <+7>: mov %rcx,%rbx - 0x000000000043e29a <+10>: lea 0x26dc1f(%rip),%rcx # -0x6abec0 <__emutls_v.current> - 0x000000000043e2a1 <+17>: mov 0x6868dd68(%rip),%rax # 0x68acc010 - 0x000000000043e2a8 <+24>: mov %rax,0x28(%rsp) - 0x000000000043e2ad <+29>: xor %eax,%eax - 0x000000000043e2af <+31>: callq 0x695808 <__emutls_get_address> - 0x000000000043e2b4 <+36>: mov 0x9090d9(%rip),%rsi # -0xd47394 <__imp_SwitchToFiber> - 0x000000000043e2bb <+43>: mov %rax,%rdi - 0x000000000043e2be <+46>: xchg %ax,%ax - 0x000000000043e2c0 <+48>: mov 0x8(%rbx),%rcx - 0x000000000043e2c4 <+52>: callq *(%rbx) - 0x000000000043e2c6 <+54>: mov 0x10(%rbx),%rdx - 0x000000000043e2ca <+58>: mov %rdx,(%rdi) -=> 0x000000000043e2cd <+61>: movl $0x2,0x38(%rdx) - 0x000000000043e2d4 <+68>: mov 0x30(%rdx),%rcx - 0x000000000043e2d8 <+72>: callq *%rsi - 0x000000000043e2da <+74>: jmp 0x43e2c0 <coroutine_trampoline+48> -End of assembler dump. -(gdb) - - -From: - -qemu_coroutine_switch (action=COROUTINE_TERMINATE, to_=0x0, from_=0x3ba1c80) - at /home/cauchy/vcs/git/qemu/coroutine-win32.c:47 - -We can see qemu_coroutine_switch was call with to_=NULL, then crashed at line 47: - -to->action = action; \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1207896 b/results/classifier/zero-shot-user-mode/output/instruction/1207896 deleted file mode 100644 index e4f282c81..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1207896 +++ /dev/null @@ -1,9 +0,0 @@ -instruction: 0.517 -runtime: 0.286 -syscall: 0.197 - - - -binfmt wrapper for argv[0] handling - -Please, add patch https://lists.gnu.org/archive/html/qemu-devel/2011-09/msg03841.html to upstream. 2 years have passed and this patch is not jet applied. Why? 99% GNU/Linux distribution uses qemu with this patch. It is 100% needed. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1209 b/results/classifier/zero-shot-user-mode/output/instruction/1209 deleted file mode 100644 index 284bb64a7..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1209 +++ /dev/null @@ -1,11 +0,0 @@ -instruction: 0.434 -runtime: 0.405 -syscall: 0.161 - - - -Optionally do not clear the screen when starting a VM -Additional information: -``` -QEMU emulator version 6.2.0 (qemu-6.2.0-14.fc36) -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/121 b/results/classifier/zero-shot-user-mode/output/instruction/121 deleted file mode 100644 index a839dc1e2..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/121 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.493 -runtime: 0.294 -syscall: 0.213 - - - -multiprocess program gets incorrect results with qemu arm-linux-user diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1211 b/results/classifier/zero-shot-user-mode/output/instruction/1211 deleted file mode 100644 index e61bb67e8..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1211 +++ /dev/null @@ -1,13 +0,0 @@ -instruction: 0.531 -runtime: 0.320 -syscall: 0.150 - - - -Bad fonts in "cirrus" VGA card. -Description of problem: -Similar to #988. Fixed by set "no_bitblt" and "sw_cursor" in XF86Config file. -Steps to reproduce: -Similar to #988. -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/122 b/results/classifier/zero-shot-user-mode/output/instruction/122 deleted file mode 100644 index 9c833ed96..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/122 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.483 -syscall: 0.283 -runtime: 0.234 - - - -linux-user does not check PROT_EXEC diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1221966 b/results/classifier/zero-shot-user-mode/output/instruction/1221966 deleted file mode 100644 index ef56b1f59..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1221966 +++ /dev/null @@ -1,40 +0,0 @@ -instruction: 0.512 -runtime: 0.348 -syscall: 0.140 - - - -SIGSEGV in static_code_gen_buffer - -Trying to run 'ls' (or, anything else as far as I can tell) from a SunOS 5.8 box under RHEL 6.4 linux, I get a segfault. I've tried qemu-1.5.3, qemu-1.6.0, and I fetched git://git.qemu-project.org/qemu.git. I've also tried a statically linked sh from /sbin/ and it also segfaulted. - -wcolburn@anotheruvula</home/anotheruvula/qemu>$ gdb bin/qemu-sparc -GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1) -Copyright (C) 2010 Free Software Foundation, Inc. -License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> -This is free software: you are free to change and redistribute it. -There is NO WARRANTY, to the extent permitted by law. Type "show copying" -and "show warranty" for details. -This GDB was configured as "x86_64-redhat-linux-gnu". -For bug reporting instructions, please see: -<http://www.gnu.org/software/gdb/bugs/>... -Reading symbols from /home/anotheruvula/qemu/bin/qemu-sparc...done. -(gdb) run ../sparc/ls -Starting program: /home/anotheruvula/qemu/bin/qemu-sparc ../sparc/ls -[Thread debugging using libthread_db enabled] - -Program received signal SIGSEGV, Segmentation fault. -0x00007ffff8259116 in static_code_gen_buffer () -Missing separate debuginfos, use: debuginfo-install glib2-2.22.5-7.el6.x86_64 glibc-2.12-1.107.el6_4.4.x86_64 -(gdb) where -#0 0x00007ffff8259116 in static_code_gen_buffer () -#1 0x00007ffff7f570cd in cpu_tb_exec (cpu=0x7ffffa2b1210, tb_ptr= - 0x7ffff82590d0 "A\213n \205í\017\205Í") - at /home/anotheruvula/qemu-devel/cpu-exec.c:56 -#2 0x00007ffff7f57b2d in cpu_sparc_exec (env=0x7ffffa2b1348) - at /home/anotheruvula/qemu-devel/cpu-exec.c:631 -#3 0x00007ffff7f77f36 in cpu_loop (env=0x7ffffa2b1348) - at /home/anotheruvula/qemu-devel/linux-user/main.c:1089 -#4 0x00007ffff7f798ff in main (argc=2, argv=0x7fffffffdfc8, envp= - 0x7fffffffdfe0) at /home/anotheruvula/qemu-devel/linux-user/main.c:4083 -(gdb) \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1228 b/results/classifier/zero-shot-user-mode/output/instruction/1228 deleted file mode 100644 index c105dd0ac..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1228 +++ /dev/null @@ -1,49 +0,0 @@ -instruction: 0.523 -syscall: 0.244 -runtime: 0.233 - - - --display curses only recognizes escape characters if pressed very quickly -Description of problem: -The system start and runs perfectly fine, but when I try to exit the escape commands does not seem to work. - -I have tried all the ones from here: -https://www.qemu.org/docs/master/system/keys.html -https://www.qemu.org/docs/master/system/mux-chardev.html - -When using the graphical display, the escape characters works as expected but when using -display curses, they do not. -Steps to reproduce: -1. Start qemu with the command provided -2. Try to exit using ctrl + x a - Not working -3. Try to exit using alt + 2 - Not working - -The same issues occurs when running qemu on a Linux machine (Ubunt) via Visual Studio Code / ssh. - -I'm guessing this is a macOS specific issue or maybe something to do with my Locale (sv-SE). -Additional information: -Linux 0.01 build: -https://github.com/mariuz/linux-0.01 - -**Tests using showkey** - -Alt + 2 from mobile ssh client (Terminus) -> Ubuntu machine -``` -^[2 27 0033 0x1b - 50 0062 0x32 -``` - -Option + 2 from macOS Terminal + ssh -> Ubuntu machine -``` -@ 64 0100 0x40 -``` - -Esc + 2 from macOS Terminal + ssh -> Ubuntu machine -``` -^[ 27 0033 0x1b -2 50 0062 0x32 -``` - -**Update** - -It seems to work if I press ESC + 2 at exactly the same time. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1233225 b/results/classifier/zero-shot-user-mode/output/instruction/1233225 deleted file mode 100644 index cadb2201a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1233225 +++ /dev/null @@ -1,30 +0,0 @@ -instruction: 0.521 -runtime: 0.297 -syscall: 0.181 - - - -mips/mipsel linux user float division problem - -Hi, - -I tested the following with the qemu git HEAD as of 2013-09-30 on Debian stable and testing. My host runs amd64 but I also tried this out inside a i386 chroot with the same result. The problem occurs for mips and mipsel. Given the following program: - -#include <stdio.h> -int main(int argc, char **argv) -{ - int a = 1; - double d = a/2.0; - printf("%f\n", d); - return 0; -} - -Instead of printing 0.5, it will print 2.0 if executed in qemu user mode. - -$ mipsel-linux-gnu-gcc mipstest.c -$ ~/qemu/mipsel-linux-user/qemu-mipsel ./a.out -2.0 - -Expecting this to be a problem with my cross compiler (gcc-4.4 from emdebian) I ran a fully emulated debian squeeze environment inside qemu. There, I compiled the same program natively with gcc and as expected got 0.5 as the output. I also copied the cross compiled binary inside the emulated environment and also got 0.5 when I ran it. So the same mips/mipsel binary produces different output depending on whether it is run in a fully emulated environment or qemu user mode. - -Can anybody else reproduce this problem? \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1245543 b/results/classifier/zero-shot-user-mode/output/instruction/1245543 deleted file mode 100644 index b705d0b14..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1245543 +++ /dev/null @@ -1,29 +0,0 @@ -instruction: 0.777 -runtime: 0.139 -syscall: 0.084 - - - -Wrong implementation of SSE4.1 pmovzxbw and similar instructions - -QEMU 1.5.0 (and git version, as far as I can tell from the source code) has incorrect implementation of pmovzxbw and similar SSE4.1 instructions. The instruction zero-extends the first 8 8-bit elements of a vector to 16bit vector and puts them to another vector. The current implementation applies this operation only to the first element and zeros out the rest. - -To verify, compile the attached program for SSE4.1 (g++ -msse4.1 cvtint.cc). On real hardware, it produces the following output: - -$ ./a.out -1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 - -On QEMU, the output is as follows: - -$ ./a.out -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - -QEMU is invoked as: - -qemu-system-x86_64 \ - -M pc -cpu Haswell,+sse4.1,+avx,+avx2,+fma,enforce -m 512 \ - -serial stdio -no-reboot \ - -kernel vmlinuz -initrd initrd.img \ - -netdev user,id=user.0 -device rtl8139,netdev=user.0 -redir tcp:2222::22 \ - -hda ubuntu-amd64.ext3 \ - --append "rw console=tty root=/dev/sda" \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1245703 b/results/classifier/zero-shot-user-mode/output/instruction/1245703 deleted file mode 100644 index 09ee6c108..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1245703 +++ /dev/null @@ -1,15 +0,0 @@ -instruction: 0.417 -runtime: 0.359 -syscall: 0.224 - - - -LD_PREFIX option reads directories recursively in an endless loop - -If I run qemu user emulation with -L /path/to/my/sysroot/ in which also the proc and dev filesystem is mounted QEMU eats my memory until it gets killed by the kernel. - -According to the strace output it follows the symbolic links in the proc filesystem running forever in a recursive loop. - -The easiest solution would be to add in the function "add_dir_maybe" in the file util/path.c an additional check for symbolic links that it don't follow them. - -Also I don't really understand the need of doing this. A lot of ressources are wasted everytime QEMU-user is started just by having the directory structure in memory. In my case this are more than 20000 entries which QEMU is loading every time. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1248 b/results/classifier/zero-shot-user-mode/output/instruction/1248 deleted file mode 100644 index e49b527c2..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1248 +++ /dev/null @@ -1,17 +0,0 @@ -instruction: 0.496 -runtime: 0.387 -syscall: 0.117 - - - -s390x: glibc widestring algorithms broken -Description of problem: -Several wide-string functions from glibc are broken und qemu user emulation. -Affected are at least: `wcsbrk()`, `wcsspn()` and `wcscspn()`. All of these are implemented in optimized assembler in glibc. - -Unfortunately I don't have access to the real hardware to check the behavior there. But it would probably been detected by now. -Also I don't know which instructions exactly don't work, as I don't have any knowledge about s390x assembler. -Steps to reproduce: -1. Compile the test program above -2. Run the program -3. Output is `0`, should be `1`. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1248168 b/results/classifier/zero-shot-user-mode/output/instruction/1248168 deleted file mode 100644 index d50947941..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1248168 +++ /dev/null @@ -1,30 +0,0 @@ -instruction: 0.634 -syscall: 0.253 -runtime: 0.113 - - - -MIPS, self-modifying code and uncached memory - -Self-modifying code does not work properly in MIPS in uncached and unmapped kseg1 memory region. - -For example, when running this code I get unexpected behavior: - - 0: e3000010 b 0x390 - 4: 00000000 nop - ... - 380: 00701f40 mfc0 ra,c0_epc - 384: 0400e0bb swr zero,4(ra) - 388: 18000042 eret - 38c: 00000000 nop - 390: 25500000 move t2,zero - 394: 02000b34 li t3,0x2 - 398: 23504b01 subu t2,t2,t3 - 39c: e9003c0b j 0xcf003a4 - 3a0: 0a004a21 addi t2,t2,10 - 3a4: ffff0010 b 0x3a4 - 3a8: 00000000 nop - 3ac: 00000000 nop - - I expect that swr instruction in line 384 would change `addi t2,t2,1`0 to `nop` -This should work because no cache is used for this memory region. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1251 b/results/classifier/zero-shot-user-mode/output/instruction/1251 deleted file mode 100644 index 359f1eb61..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1251 +++ /dev/null @@ -1,21 +0,0 @@ -instruction: 0.858 -runtime: 0.090 -syscall: 0.053 - - - -Octeon Instruction BBIT Bug -Steps to reproduce: -1. Compile 64bit binary for Octeon with Octeon instructions -`mips64-octeon-linux-gnu-gcc -o hello hello.c` -2. Run with `qemu-mips64` -`qemu-mips64 -cpu Octeon68XX hello` -3. Get the output below: -``` -qemu: uncaught target signal 4 (Illegal instruction) - core dumped -Illegal instruction -``` -Additional information: -I have a patch for this that I will be submitting to trivial-patches. This is not enough to emulate Octeon specific binaries alone. For small binaries mapping the `CVMSEG_LM = 0xFFFFFFFFFFFF8000 - 0xFFFFFFFFFFFF9FFF` to empty RAM and using this patch is enough. There are additional support issues for `N32` binaries that will require a separate issue. - -[hello](/uploads/d8b5e631508fd232b4a7b3a40f7e08f6/hello) diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1254672 b/results/classifier/zero-shot-user-mode/output/instruction/1254672 deleted file mode 100644 index e2ad033cd..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1254672 +++ /dev/null @@ -1,47 +0,0 @@ -instruction: 0.424 -syscall: 0.328 -runtime: 0.247 - - - -ps segfaults with qemu-{arm,armel,mips,powerpc}-static - -Host: Ubuntu Precise AMD64 -Guest: Debian Testing armhf - -After running a debootstrap for Debian testing/armhf and entering the chroot, simply running "ps" causes a segmentation fault. - -$ sudo qemu-debootstrap --arch=armhf testing armhf http://ftp.uk.debian.org/debian/ -[...] -$ sudo chroot armhf -# ps -Signal 11 (SEGV) caught by ps (procps-ng version 3.3.4). -/bin/ps:display.c:59: please report this bug - -I couldn't find a bug report for procps, which would be unusual if such a bug existed, so I'm assuming the bug is in qemu. - -Unfortunately trying to run debootstrap for an Ubuntu variant fails to find the release file. - -ps is used a lot, as you can imagine, but specifically it fails when trying to install some packages via "apt-get install" and no attempt is made to recover. - -ProblemType: Bug -DistroRelease: Ubuntu 12.04 -Package: qemu-user-static 1.0.50-2012.03-0ubuntu2.1 -ProcVersionSignature: Ubuntu 3.8.0-33.48~precise1-generic 3.8.13.11 -Uname: Linux 3.8.0-33-generic x86_64 -NonfreeKernelModules: wl -ApportVersion: 2.0.1-0ubuntu17.6 -Architecture: amd64 -Date: Mon Nov 25 10:43:12 2013 -Dependencies: - -InstallationMedia: Ubuntu 12.04.3 LTS "Precise Pangolin" - Release amd64 (20130820.1) -MarkForUpload: True -ProcEnviron: - LANGUAGE=en_GB:en - TERM=xterm - PATH=(custom, no user) - LANG=en_GB.UTF-8 - SHELL=/bin/bash -SourcePackage: qemu-linaro -UpgradeStatus: No upgrade log present (probably fresh install) \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1254786 b/results/classifier/zero-shot-user-mode/output/instruction/1254786 deleted file mode 100644 index e5e672bcd..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1254786 +++ /dev/null @@ -1,48 +0,0 @@ -instruction: 0.790 -runtime: 0.127 -syscall: 0.083 - - - -qemu-m68k-static: illegal instruction ebc0 during debootstrap second stage - -Host: Ubuntu Precise amd64 -Guest: Debian (ports) sid m68k - -$ sudo qemu-debootstrap --no-check-gpg --arch=m68k sid m68k http://ftp.debian-ports.org/debian -I: Running command: debootstrap --arch m68k --foreign --no-check-gpg sid m68k http://ftp.debian-ports.org/debian -[...] -I: Running command: chroot m68k /debootstrap/debootstrap --second-stage -qemu: fatal: Illegal instruction: ebc0 @ f67e5662 -D0 = 6ffffef5 A0 = f67fbf58 F0 = 0000000000000000 ( 0) -D1 = 0000010a A1 = 00000000 F1 = 0000000000000000 ( 0) -D2 = 0000000f A2 = 00000000 F2 = 0000000000000000 ( 0) -D3 = 00000000 A3 = f67e0000 F3 = 0000000000000000 ( 0) -D4 = 00000000 A4 = 00000000 F4 = 0000000000000000 ( 0) -D5 = 00000000 A5 = f67fc000 F5 = 0000000000000000 ( 0) -D6 = 00000000 A6 = f6fff7cc F6 = 0000000000000000 ( 0) -D7 = 00000000 A7 = f6fff580 F7 = 0000000000000000 ( 0) -PC = f67e5662 SR = 0000 ----- FPRESULT = 0 -Aborted (core dumped) - -ProblemType: Bug -DistroRelease: Ubuntu 12.04 -Package: qemu-user-static 1.0.50-2012.03-0ubuntu2.1 -ProcVersionSignature: Ubuntu 3.8.0-33.48~precise1-generic 3.8.13.11 -Uname: Linux 3.8.0-33-generic x86_64 -NonfreeKernelModules: wl -ApportVersion: 2.0.1-0ubuntu17.6 -Architecture: amd64 -Date: Mon Nov 25 16:08:26 2013 -Dependencies: - -InstallationMedia: Ubuntu 12.04.3 LTS "Precise Pangolin" - Release amd64 (20130820.1) -MarkForUpload: True -ProcEnviron: - LANGUAGE=en_GB:en - TERM=xterm - PATH=(custom, no user) - LANG=en_GB.UTF-8 - SHELL=/bin/bash -SourcePackage: qemu-linaro -UpgradeStatus: No upgrade log present (probably fresh install) \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1254828 b/results/classifier/zero-shot-user-mode/output/instruction/1254828 deleted file mode 100644 index 16b3976cd..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1254828 +++ /dev/null @@ -1,43 +0,0 @@ -instruction: 0.428 -runtime: 0.360 -syscall: 0.212 - - - -qemu-sparc64-static: Segmentation Fault during debootstrap second stage - -Host: Ubuntu Precise amd64 -Guest: Debian Sid (ports) sparc64 - -When attempting the second stage of a debootstrap for a sparc64 Debian Sid guest, a segmentation fault occurs. - -$ sudo qemu-debootstrap --no-check-gpg --arch=sparc64 sid sparc64 http://ftp.debian-ports.org/debian -I: Running command: debootstrap --arch sparc64 --foreign --no-check-gpg sid sparc64 http://ftp.debian-ports.org/debian -[...] -I: Running command: chroot sparc64 /debootstrap/debootstrap --second-stage -/debootstrap/debootstrap: 22: .: Can't open /usr/share/debootstrap/functions -Segmentation fault (core dumped) - -Running a simple "sudo chroot sparc64" exits silently on amd64, and reports a segfault on i386. - -ProblemType: Bug -DistroRelease: Ubuntu 12.04 -Package: qemu-user-static 1.0.50-2012.03-0ubuntu2.1 -ProcVersionSignature: Ubuntu 3.8.0-33.48~precise1-generic 3.8.13.11 -Uname: Linux 3.8.0-33-generic x86_64 -NonfreeKernelModules: wl -ApportVersion: 2.0.1-0ubuntu17.6 -Architecture: amd64 -Date: Mon Nov 25 17:49:34 2013 -Dependencies: - -InstallationMedia: Ubuntu 12.04.3 LTS "Precise Pangolin" - Release amd64 (20130820.1) -MarkForUpload: True -ProcEnviron: - LANGUAGE=en_GB:en - TERM=xterm - PATH=(custom, no user) - LANG=en_GB.UTF-8 - SHELL=/bin/bash -SourcePackage: qemu-linaro -UpgradeStatus: No upgrade log present (probably fresh install) \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1255 b/results/classifier/zero-shot-user-mode/output/instruction/1255 deleted file mode 100644 index c4658610e..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1255 +++ /dev/null @@ -1,17 +0,0 @@ -instruction: 0.680 -runtime: 0.179 -syscall: 0.141 - - - -32bit qemu-arm fails to run systemctl "Allocating guest commpage: Cannot allocate memory" -Description of problem: -I am using a bare minimal install of the latest 32 bit version of debian with only ssh installed. I have compiled qemu from the latest git with "./configure --target-list=arm-linux-user --static --disable-pie". When I try to run systemctl from the latest version of raspbian, I experience the error: "Allocating guest commpage: Cannot allocate memory". -Steps to reproduce: -1. Download and extract the included systemctl and required libs. [systemctl+libs.tgz](/uploads/a2834ed651a981fded4bcc19ea9ca31b/systemctl+libs.tgz) -2. run "qemu-arm -L ./ systemctl --version" -Additional information: -- I think this is related to [Issue 690](https://gitlab.com/qemu-project/qemu/-/issues/690). -- When I run "qemu-arm -L ./ -B 0x20000 systemctl --version" there is no error. -- The error still happens when setting vm.mmap_min_addr to 0. -- The error does not occur on v5.0.0, but does occur on v5.1.0 and v6.1.0. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1261743 b/results/classifier/zero-shot-user-mode/output/instruction/1261743 deleted file mode 100644 index 2d0f72e26..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1261743 +++ /dev/null @@ -1,11 +0,0 @@ -instruction: 0.460 -syscall: 0.290 -runtime: 0.250 - - - -trace-backend "simple" doesn't support "disable" property of event - -trace-backend "simple" generates wrong eventid in trace/generated-tracers.c after "disable" property occured in trace-events record. - -Result: missing or mixing logs in trace file. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1263747 b/results/classifier/zero-shot-user-mode/output/instruction/1263747 deleted file mode 100644 index be09616dc..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1263747 +++ /dev/null @@ -1,35 +0,0 @@ -instruction: 0.491 -runtime: 0.354 -syscall: 0.155 - - - -Arm64 fails to run a binary which runs OK on real hardware - -This binary: - -http://oirase.annexia.org/tmp/test.gz - -runs OK on real aarch64 hardware. It is a statically linked Linux binary which (if successful) will print "hello, world" and exit cleanly. - -On qemu-arm64 userspace emulator it doesn't print anything and loops forever using 100% CPU. - ----- -The following section is only if you wish to compile this binary from source, otherwise you can ignore it. - -First compile OCaml from: - -https://github.com/ocaml/ocaml - -(note you have to compile it on aarch64 or in qemu, it's not possible to cross-compile). You will have to apply the one-line patch from: - -https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00179.html - - ./configure - make -j1 world.opt - -Then do: - - echo 'print_endline "hello, world"' > test.ml - ./boot/ocamlrun ./ocamlopt -I stdlib stdlib.cmxa test.ml -o test - ./test \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1283519 b/results/classifier/zero-shot-user-mode/output/instruction/1283519 deleted file mode 100644 index fe57aa4bb..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1283519 +++ /dev/null @@ -1,16 +0,0 @@ -instruction: 0.888 -syscall: 0.074 -runtime: 0.038 - - - -PowerPC altivec rounding instructions vrfi(m|n|z)not correctly mapped - -When using ppc-linux-user/qemu-ppc on a ppc ELF executable, I see that QEMU wrongly recognizes the vrfim, vrfin and vrfiz instructions: - -If the binary contains vrfim QEMU sees vrfiz -If the binary contains vrfin QEMU sees vrfim -If the binary contains vrfiz QEMU sees vrfin -The vrfip instruction is correctly recognized. - -Those instructions normally round a floating-point altivec vector to zero (z), infinity (p), minus infinity (m) or nearest (n). \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1285363 b/results/classifier/zero-shot-user-mode/output/instruction/1285363 deleted file mode 100644 index 69b8f613b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1285363 +++ /dev/null @@ -1,51 +0,0 @@ -instruction: 0.355 -syscall: 0.347 -runtime: 0.298 - - - -qemu-aarch64-static segfaults - -I've found a couple conditions that causes qemu-user-static to core dump fairly reliably - same with upstream git - while a binary built from suse's aarch64-1.6 branch seems to consistently work fine. - -Testing suggests they are resolved by the sigprocmask wrapper patches included in suse's tree. - - 1) dh_fixperms is a script that commonly runs at the end of a package build. - Its basically doing a `find | xargs chmod`. - 2) debootstrap --second-stage - This is used to configure an arm64 chroot that was built using - debootstrap on a non-native host. It is basically invoking a bunch of - shell scripts (postinst, etc). When it blows up, the stack consistently - looks like this: - -Core was generated by `/usr/bin/qemu-aarch64-static /bin/sh -e -/debootstrap/debootstrap --second-stage'. -Program terminated with signal SIGSEGV, Segmentation fault. -#0 0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0, -__dest=0x400082c330) at -/usr/include/x86_64-linux-gnu/bits/string3.h:51 -51 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); -(gdb) bt -#0 0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0, -__dest=0x400082c330) at -/usr/include/x86_64-linux-gnu/bits/string3.h:51 -#1 stq_p (v=274886476624, ptr=0x400082c330) at -/mnt/qemu.upstream/include/qemu/bswap.h:280 -#2 stq_le_p (v=274886476624, ptr=0x400082c330) at -/mnt/qemu.upstream/include/qemu/bswap.h:315 -#3 target_setup_sigframe (set=0x7fff62ae3530, env=0x62d9c678, -sf=0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167 -#4 target_setup_frame (usig=usig@entry=17, ka=ka@entry=0x604ec1e0 -<sigact_table+512>, info=info@entry=0x0, set=set@entry=0x7fff62ae3530, -env=env@entry=0x62d9c678) - at /mnt/qemu.upstream/linux-user/signal.c:1286 -#5 0x0000000060059f46 in setup_frame (env=0x62d9c678, -set=0x7fff62ae3530, ka=0x604ec1e0 <sigact_table+512>, sig=17) at -/mnt/qemu.upstream/linux-user/signal.c:1322 -#6 process_pending_signals (cpu_env=cpu_env@entry=0x62d9c678) at -/mnt/qemu.upstream/linux-user/signal.c:5747 -#7 0x0000000060056e60 in cpu_loop (env=env@entry=0x62d9c678) at -/mnt/qemu.upstream/linux-user/main.c:1082 -#8 0x0000000060005079 in main (argc=<optimized out>, argv=<optimized -out>, envp=<optimized out>) at -/mnt/qemu.upstream/linux-user/main.c:4374 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1287195 b/results/classifier/zero-shot-user-mode/output/instruction/1287195 deleted file mode 100644 index 468667b03..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1287195 +++ /dev/null @@ -1,9 +0,0 @@ -instruction: 0.578 -syscall: 0.298 -runtime: 0.124 - - - -validate_guest_space incorrectly enabled on AArch64 - -When running linux-user targetting AArch64, validate_guest_space() in elfload.c reserves space in the guest address space for the ARM commpage. Since there is no commpage on AArch64, this function should be disable on that target. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1308381 b/results/classifier/zero-shot-user-mode/output/instruction/1308381 deleted file mode 100644 index bb824ab60..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1308381 +++ /dev/null @@ -1,20 +0,0 @@ -instruction: 0.930 -runtime: 0.043 -syscall: 0.026 - - - -illegal instructions for AArch64 ARMv8 - -The test case is in the attachment. To reproduce as following (I tried both GCC and Clang): -$aarch64-linux-gnu-gcc qemu.c -o test -$./test -qemu: uncaught target signal 4 (Illegal instruction) - core dumped -Illegal instruction (core dumped) - -There are 3 intrinsics are tested in the test case: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: -SQXTUN Bd, Hn -SQXTUN Hd, Sn -SQXTUN Sd, Dn. - -It seems that these instructions are not supported in QEMU. Is this a bug? \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1311614 b/results/classifier/zero-shot-user-mode/output/instruction/1311614 deleted file mode 100644 index 4d1134cb9..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1311614 +++ /dev/null @@ -1,53 +0,0 @@ -instruction: 0.545 -runtime: 0.250 -syscall: 0.205 - - - -qemu-arm segfaults with gcc 4.9.0 - -I have an ARM chroot that working with qemu-arm emulation - -[root@filzbach fedya]# cat /proc/sys/fs/binfmt_misc/arm -enabled -interpreter /usr/bin/qemu-arm-binfmt -flags: P -offset 0 -magic 7f454c4601010100000000000000000002002800 -mask ffffffffffffff00fffffffffffffffffeffffff - - -In chroot installed gcc dependencies with 4.9.0 version - -sudo rpm --root /home/fedya/root/ -qa | grep 4.9.0 - -libgcc1-4.9.0_2014.04-1-omv2013.0.armv7hl -libgomp1-4.9.0_2014.04-1-omv2013.0.armv7hl -libstdc++6-4.9.0_2014.04-1-omv2013.0.armv7hl -gcc-4.9.0_2014.04-1-omv2013.0.armv7hl -gcc-cpp-4.9.0_2014.04-1-omv2013.0.armv7hl -libstdc++-devel-4.9.0_2014.04-1-omv2013.0.armv7hl -gcc-c++-4.9.0_2014.04-1-omv2013.0.armv7hl - - -When i try to run "rpm" , "rpmbuild", "rpm2cpio"command i always see qemu segfault message - - -example: - -[root@filzbach /]# uname -a -Linux filzbach.lindev.ch 3.13.6-nrjQL-desktop-70omv #1 SMP PREEMPT Wed Mar 12 21:40:00 UTC 2014 armv7l armv7l armv7l GNU/Linux - -[root@filzbach /]# rpm -qemu: uncaught target signal 11 (Segmentation fault) - core dumped - - -Segfault became apparent only after gcc upgrade from 4.8.3 to 4.9.0. - -When i downgrade it to 4.8.3 all working fine again. -It looks like a qemu bug with gcc. - - -P.S. -I tried to rebuild qemu with gcc 4.9.0 -I tried to build qemu from git sources, from fedora sources, from suse sources etc. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1328996 b/results/classifier/zero-shot-user-mode/output/instruction/1328996 deleted file mode 100644 index 0b9b32cd6..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1328996 +++ /dev/null @@ -1,9 +0,0 @@ -instruction: 0.790 -syscall: 0.115 -runtime: 0.095 - - - -[AArch64] - blr x30 is handled incorrectly - -Whenever x30 is used as the operand for blr, the result will be incorrect. There is no restriction on using x30 (LR) with the blr instruction in the ARMv8 manual. There are two statically linked 64-bit executables in files.tar.gz: good and bad. The executable "good" uses "blr x9", and the output is what is expected: "func". The executable "bad" uses "blr x30" and nothing is printed out. It prints "func" on the actual device. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1339 b/results/classifier/zero-shot-user-mode/output/instruction/1339 deleted file mode 100644 index b755525c8..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1339 +++ /dev/null @@ -1,22 +0,0 @@ -instruction: 0.655 -runtime: 0.206 -syscall: 0.139 - - - -RVV vfncvt.rtz.x.f.w Assertion failed -Description of problem: -when execute -``` -vsetvli t0, x0, e16, m1 -vfncvt.rtz.x.f.w v0, v4 -``` -report error: - -qemu-riscv64: ../target/riscv/translate.c:212: decode_save_opc: Assertion \`ctx->insn_start != NULL' failed. Segmentation fault (core dumped) -Steps to reproduce: -1. write the code -2. compile -3. excute -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1356916 b/results/classifier/zero-shot-user-mode/output/instruction/1356916 deleted file mode 100644 index 39dd8e3bb..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1356916 +++ /dev/null @@ -1,12 +0,0 @@ -instruction: 0.709 -syscall: 0.163 -runtime: 0.127 - - - -Too small argv limit - -Current kernels don't have a fixed argv/environ limit any more, but the user-space emulation of qemu is still using a fixed limit. This can cause execve to fail when it wouldn't on a real system. For example, the follwing command should not fail in the emulated environment: - -$ /bin/true $(yes | head -n 100000) --bash: /bin/true: Argument list too long \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1357206 b/results/classifier/zero-shot-user-mode/output/instruction/1357206 deleted file mode 100644 index 05e0960e4..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1357206 +++ /dev/null @@ -1,65 +0,0 @@ -instruction: 0.411 -runtime: 0.347 -syscall: 0.241 - - - -QEMU user mode still crashes in multi-thread code. - -I compiled the qemu 2.0 release source and find out qemu crashing when emulating multi-thread code in user mode. - -I did a little search and found LP:668799 but it is far from now and it is probably not the problem here. - -I used program below as the test program: - -#include <stdio.h> -#include <stdlib.h> -#include <pthread.h> - -void *print_message_function( void *ptr ); - -main() -{ - pthread_t thread1, thread2; - const char *message1 = "Thread 1"; - const char *message2 = "Thread 2"; - int iret1, iret2; - - /* Create independent threads each of which will execute function */ - - iret1 = pthread_create( &thread1, NULL, print_message_function, (void*) message1); - if(iret1) - { - fprintf(stderr,"Error - pthread_create() return code: %d\n",iret1); - exit(EXIT_FAILURE); - } - - iret2 = pthread_create( &thread2, NULL, print_message_function, (void*) message2); - if(iret2) - { - fprintf(stderr,"Error - pthread_create() return code: %d\n",iret2); - exit(EXIT_FAILURE); - } - - printf("pthread_create() for thread 1 returns: %d\n",iret1); - printf("pthread_create() for thread 2 returns: %d\n",iret2); - - /* Wait till threads are complete before main continues. Unless we */ - /* wait we run the risk of executing an exit which will terminate */ - /* the process and all threads before the threads have completed. */ - - pthread_join( thread1, NULL); - pthread_join( thread2, NULL); - - exit(EXIT_SUCCESS); -} - -void *print_message_function( void *ptr ) -{ - char *message; - message = (char *) ptr; - printf("%s \n", message); -} - -Compiled to i386 and aarch64 object, -and both qemu-i386 and qemu-aarch64 had segmentation faults. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1357226 b/results/classifier/zero-shot-user-mode/output/instruction/1357226 deleted file mode 100644 index fe240ba2f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1357226 +++ /dev/null @@ -1,17 +0,0 @@ -instruction: 0.424 -syscall: 0.392 -runtime: 0.184 - - - -qemu: uncaught target signal 11 (Segmentation fault) - core dumped - -steps to reproduce: -pbuilder-dist utopic armhf create -pbuilder-dist utopic armhf login -apt-get install imagemagick -convert foo.xpm foo.png -qemu: uncaught target signal 11 (Segmentation fault) - core dumped -Segmentation fault - -(doesn't matter if images are actually there or not) \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1361912 b/results/classifier/zero-shot-user-mode/output/instruction/1361912 deleted file mode 100644 index 79834a0a3..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1361912 +++ /dev/null @@ -1,15 +0,0 @@ -instruction: 0.511 -runtime: 0.396 -syscall: 0.093 - - - -qemu-mips64 Segmentation fault - -When I ran qemu-mips64 for any mips 64 executable , I got this error: - -$ ./qemu-mips64 ../lang -qemu: uncaught target signal 11 (Segmentation fault) - core dumped -Segmentation fault (core dumped) - -Is this a known issue? \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1362635 b/results/classifier/zero-shot-user-mode/output/instruction/1362635 deleted file mode 100644 index 2e1104a3b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1362635 +++ /dev/null @@ -1,48 +0,0 @@ -instruction: 0.607 -runtime: 0.229 -syscall: 0.164 - - - -bdrv_read co-routine re-entered recursively - -calling bdrv_read in a loop leads to the follwing situation: - -bs->drv->bdrv_aio_readv is called, and finally calls bdrv_co_io_em_complete in other thread context. -there is a possibility of calling bdrv_co_io_em_complete before calling qemu_coroutine_yield in bdrv_co_io_em. And qemu fails with "co-routine re-entered recursively". - -static void bdrv_co_io_em_complete(void *opaque, int ret) -{ - CoroutineIOCompletion *co = opaque; - - co->ret = ret; - qemu_coroutine_enter(co->coroutine, NULL); -} - -static int coroutine_fn bdrv_co_io_em(BlockDriverState *bs, int64_t sector_num, - int nb_sectors, QEMUIOVector *iov, - bool is_write) -{ - CoroutineIOCompletion co = { - .coroutine = qemu_coroutine_self(), - }; - BlockDriverAIOCB *acb; - - if (is_write) { - acb = bs->drv->bdrv_aio_writev(bs, sector_num, iov, nb_sectors, - bdrv_co_io_em_complete, &co); - } else { - acb = bs->drv->bdrv_aio_readv(bs, sector_num, iov, nb_sectors, - bdrv_co_io_em_complete, &co); - } - - trace_bdrv_co_io_em(bs, sector_num, nb_sectors, is_write, acb); - if (!acb) { - return -EIO; - } - qemu_coroutine_yield(); - - return co.ret; -} - -is it a bug, or may be I don't understand something? \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1368 b/results/classifier/zero-shot-user-mode/output/instruction/1368 deleted file mode 100644 index 200a40326..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1368 +++ /dev/null @@ -1,44 +0,0 @@ -instruction: 0.662 -syscall: 0.180 -runtime: 0.158 - - - -unexpect rax value -Description of problem: -- When I execute "mov -0x8(%rbp), %rax" and "movq 0xb8000, (%rax)", the value of rax should be 0x7fedf but it is 0x7fefe. It is 1 less. -Steps to reproduce: -- 1. Code currently executed -<pre> -(gdb) x/2i $pc -=> 0x2202 <vga_init+12>: mov -0x8(%rbp),%rax - 0x2206 <vga_init+16>: movq $0xb8000,(%rax) -</pre> -- 2. Value of memory address -0x8(%rbp) -<pre> -(gdb) x /xg $rbp-0x8 -0x7fec8: 0x000000000007fedf -</pre> -- 3. Value of rax before execution -<pre> -(gdb) p /x $rax -$1 = 0xfffffffd -</pre> -- 4. Value of rax after execution -<pre> -(gdb) p /x $rax -$1 = 0x7fedf -</pre> -It's all right so far. -- 5. View the current execution code again -<pre> -(gdb) x/i $pc -=> 0x2207 <vga_init+17>: movl $0xb8000,(%rax) -</pre> -the code address changed from 0x2206 to 0x2207 and the code changed from "movq xx, xx" to "movl xx, xx".<br> -Now rax is 0x7fedf. -- 6. After execution<br> -After executing "movl $0xb8000,(%rax)"<br> -The rax change to 0x7fede -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1370 b/results/classifier/zero-shot-user-mode/output/instruction/1370 deleted file mode 100644 index 1a7ba6455..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1370 +++ /dev/null @@ -1,19 +0,0 @@ -instruction: 0.864 -runtime: 0.090 -syscall: 0.046 - - - -x86 BLSI and BLSR semantic bug -Description of problem: -The result of instruction BLSI and BLSR is different from the CPU. The value of CF is different. -Steps to reproduce: -1. Compile this code -``` -void main() { - asm("blsi rax, rbx"); -} -``` -2. Execute and compare the result with the CPU. The value of `CF` is exactly the opposite. This problem happens with BLSR, too. -Additional information: -This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1371 b/results/classifier/zero-shot-user-mode/output/instruction/1371 deleted file mode 100644 index 113113035..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1371 +++ /dev/null @@ -1,25 +0,0 @@ -instruction: 0.859 -runtime: 0.082 -syscall: 0.059 - - - -x86 BLSMSK semantic bug -Description of problem: -The result of instruction BLSMSK is different with from the CPU. The value of CF is different. -Steps to reproduce: -1. Compile this code -``` -void main() { - asm("mov rax, 0x65b2e276ad27c67"); - asm("mov rbx, 0x62f34955226b2b5d"); - asm("blsmsk eax, ebx"); -} -``` -2. Execute and compare the result with the CPU. - - CPU - - CF = 0 - - QEMU - - CF = 1 -Additional information: -This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1372 b/results/classifier/zero-shot-user-mode/output/instruction/1372 deleted file mode 100644 index bb22b6c3e..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1372 +++ /dev/null @@ -1,26 +0,0 @@ -instruction: 0.835 -runtime: 0.112 -syscall: 0.053 - - - -x86 BEXTR semantic bug -Description of problem: -The result of instruction BEXTR is different with from the CPU. The value of destination register is different. I think QEMU does not consider the operand size limit. -Steps to reproduce: -1. Compile this code -``` -void main() { - asm("mov rax, 0x17b3693f77fb6e9"); - asm("mov rbx, 0x8f635a775ad3b9b4"); - asm("mov rcx, 0xb717b75da9983018"); - asm("bextr eax, ebx, ecx"); -} -``` -2. Execute and compare the result with the CPU. - - CPU - - RAX = 0x5a - - QEMU - - RAX = 0x635a775a -Additional information: -This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1373 b/results/classifier/zero-shot-user-mode/output/instruction/1373 deleted file mode 100644 index 0089f6cb5..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1373 +++ /dev/null @@ -1,26 +0,0 @@ -instruction: 0.744 -runtime: 0.148 -syscall: 0.108 - - - -x86 ADOX and ADCX semantic bug -Description of problem: -The result of instruction ADOX and ADCX are different from the CPU. The value of one of EFLAGS is different. -Steps to reproduce: -1. Compile this code -``` -void main() { - asm("push 512; popfq;"); - asm("mov rax, 0xffffffff84fdbf24"); - asm("mov rbx, 0xb197d26043bec15d"); - asm("adox eax, ebx"); -} -``` -2. Execute and compare the result with the CPU. This problem happens with ADCX, too (with CF). - - CPU - - OF = 0 - - QEMU - - OF = 1 -Additional information: -This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1374 b/results/classifier/zero-shot-user-mode/output/instruction/1374 deleted file mode 100644 index 2d173ebf3..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1374 +++ /dev/null @@ -1,28 +0,0 @@ -instruction: 0.859 -runtime: 0.080 -syscall: 0.061 - - - -x86 BZHI semantic bug -Description of problem: -The result of instruction BZHI is different from the CPU. The value of destination register and SF of EFLAGS are different. -Steps to reproduce: -1. Compile this code -``` -void main() { - asm("mov rax, 0xb1aa9da2fe33fe3"); - asm("mov rbx, 0x80000000ffffffff"); - asm("mov rcx, 0xf3fce8829b99a5c6"); - asm("bzhi rax, rbx, rcx"); -} -``` -2. Execute and compare the result with the CPU. - - CPU - - RAX = 0x0x80000000ffffffff - - SF = 1 - - QEMU - - RAX = 0xffffffff - - SF = 0 -Additional information: -This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1375 b/results/classifier/zero-shot-user-mode/output/instruction/1375 deleted file mode 100644 index 46575271e..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1375 +++ /dev/null @@ -1,25 +0,0 @@ -instruction: 0.824 -runtime: 0.129 -syscall: 0.047 - - - -x86 SSE/SSE2/SSE3 instruction semantic bugs with NaN -Description of problem: -The result of SSE/SSE2/SSE3 instructions with NaN is different from the CPU. From Intel manual Volume 1 Appendix D.4.2.2, they defined the behavior of such instructions with NaN. But I think QEMU did not implement this semantic exactly because the byte result is different. -Steps to reproduce: -1. Compile this code -``` -void main() { - asm("mov rax, 0x000000007fffffff; push rax; mov rax, 0x00000000ffffffff; push rax; movdqu XMM1, [rsp];"); - asm("mov rax, 0x2e711de7aa46af1a; push rax; mov rax, 0x7fffffff7fffffff; push rax; movdqu XMM2, [rsp];"); - asm("addsubps xmm1, xmm2"); -} -``` -2. Execute and compare the result with the CPU. This problem happens with other SSE/SSE2/SSE3 instructions specified in the manual, Volume 1 Appendix D.4.2.2. - - CPU - - xmm1[3] = 0xffffffff - - QEMU - - xmm1[3] = 0x7fffffff -Additional information: -This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1376 b/results/classifier/zero-shot-user-mode/output/instruction/1376 deleted file mode 100644 index 0d711c8d7..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1376 +++ /dev/null @@ -1,21 +0,0 @@ -instruction: 0.776 -runtime: 0.160 -syscall: 0.064 - - - -x86 LSL and LAR fault -Description of problem: -From the description of LSL and LAR instructions in manual, `If the segment descriptor cannot be accessed or is an invalid type for the instruction, the ZF flag is cleared and no value is loaded in the destination operand.`. When it happens at the CPU, it seems they do nothing (nop). However, in QEMU, it crashes. -Steps to reproduce: -1. Compile this code -``` -void main() { - asm("mov rax, 0xa02e698e741f5a6a"); - asm("mov rbx, 0x20959ddd7a0aef"); - asm("lsl ax, bx"); -} -``` -2. Execute. QEMU crashes but CPU does not. This problem happens with LAR, too. -Additional information: -This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1377 b/results/classifier/zero-shot-user-mode/output/instruction/1377 deleted file mode 100644 index 049371876..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1377 +++ /dev/null @@ -1,19 +0,0 @@ -instruction: 0.901 -syscall: 0.049 -runtime: 0.049 - - -x86 CVT* series instructions fault -Description of problem: -For example, CVTSD2SS instruction converts SRC[63:0] double precision floating point to DEST[31:0] single precision floating point. Although the CVTSD2SS instruction uses only 8 bytes, if it overlaps page boundary, I think QEMU tries to access over the valid memory and crashes. -Steps to reproduce: -1. Compile this code -``` -void main() { - mmap(0x555555559000, 0x1000, flag, ~~, 0); - asm("cvtsd2ss xmm1, qword ptr [0x555555559ff8]"); -} -``` -2. Execute. QEMU crashes but CPU does not. -Additional information: -This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1388 b/results/classifier/zero-shot-user-mode/output/instruction/1388 deleted file mode 100644 index c91406cd6..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1388 +++ /dev/null @@ -1,20 +0,0 @@ -instruction: 0.403 -runtime: 0.348 -syscall: 0.249 - - - -QEMU 7.2.0 - Update file repository with x86/x64 Windows installer -Description of problem: -In file repository - -https://qemu.weilnetz.de/w32/ -https://qemu.weilnetz.de/w64/ - -are not availble Windows installer for x86 and x64 platform and QEMU final 7.2.0. - -The latest version is 7.2.0.RC4 (08.12.2022). - -Thanks. -Steps to reproduce: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1394 b/results/classifier/zero-shot-user-mode/output/instruction/1394 deleted file mode 100644 index 9ac91871a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1394 +++ /dev/null @@ -1,67 +0,0 @@ -instruction: 0.449 -runtime: 0.318 -syscall: 0.233 - - - -Byte-swapping issue in getresuid on qemu-user-sparc64 -Description of problem: -When calling getresuid() in the big-endian sparc64 guest, the uid_t values are written with their 16-bit halves reversed. - -For example, the UID 0x000003e8 (1000) becomes 0x03e80000. -Steps to reproduce: -A minimal test case looks like this: -```c -#define _GNU_SOURCE -#include <stdio.h> -#include <sys/types.h> -#include <pwd.h> -#include <unistd.h> - -int main(int argc, char **argv) { - struct passwd *pw = getpwuid(geteuid()); - if (pw == NULL) { - perror("getpwuid failure"); - return 1; - } - printf("getpwuid()->pw_uid=0x%08x\n", pw->pw_uid); - - uid_t ruid = 0, euid = 0, suid = 0; - if (getresuid(&ruid, &euid, &suid) != 0) { - perror("getresuid failure"); - return 1; - } - printf("getresuid()->suid=0x%08x\n", suid); - - return 0; -} -``` - -Compile and run with: -``` -$ sparc64-linux-gnu-gcc -Wall -O0 -g -o sid-sparc64/test test.c -$ sudo chroot sid-sparc64 -[chroot] $ qemu-sparc64-static ./test -``` - -Alternatively, static compilation without a chroot is also possible (despite a warning about `getpwuid()`): -``` -$ sparc64-linux-gnu-gcc -static -Wall -O0 -g -o test test.c -$ qemu-sparc64-static ./test -``` - -Expected output: -``` -$ ./test -getpwuid()->pw_uid=0x000003e8 -getresuid()->suid=0x000003e8 -``` - -Actual output: -``` -$ ./test -getpwuid()->pw_uid=0x000003e8 -getresuid()->suid=0x03e80000 -``` -Additional information: -I'm not sure if this is a glibc, qemu or kernel issue, but it doesn't occur outside qemu. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1397 b/results/classifier/zero-shot-user-mode/output/instruction/1397 deleted file mode 100644 index 801ef1bdb..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1397 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.432 -runtime: 0.295 -syscall: 0.273 - - - -riscv: break, hbreak does not set a breakpoint on the correct address when providing symbols diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1404690 b/results/classifier/zero-shot-user-mode/output/instruction/1404690 deleted file mode 100644 index 879dcfb0b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1404690 +++ /dev/null @@ -1,44 +0,0 @@ -instruction: 0.666 -runtime: 0.230 -syscall: 0.103 - - - -Qemu crashes with chrooted m68k - -I'm using qemu-m68k 2.2.0 to chroot into a m68k coldfire linux, which works fine on the coldfire machine. - -I've been able to use binfmt_msc and used the above code to use qemu with strace: - -#include <unistd.h> -#include <string.h> - -int main(int argc, char **argv, char **envp) { - char *newargv[argc + 4]; - - newargv[0] = argv[0]; - newargv[1] = "-cpu"; - newargv[2] = "cfv4e"; - newargv[3] = "-strace"; - - memcpy(&newargv[4], &argv[1], sizeof(*argv) * (argc - 1)); - newargv[argc + 3] = NULL; - return execve("/usr/bin/qemu-m68k", newargv, envp); -} - -Everything works fine. I can run bash, busybox, ash, but when I try to run a ls or just type an invalid command, I got the attached sequence of messages, which end like so: - -11351 waitpid(-1,0xf6fffa00,0x3) = -1 errno=10 (No child processes) -qemu: fatal: Illegal instruction: 0000 @ f6fffa30 -D0 = ffffffff A0 = f67dcf50 F0 = 0000000000000000 ( 0) -D1 = 0000000a A1 = f66e0898 F1 = 0000000000000000 ( 0) -D2 = f6fffaa8 A2 = f67df268 F2 = 0000000000000000 ( 0) -D3 = 00000000 A3 = 00000000 F3 = 0000000000000000 ( 0) -D4 = 00000008 A4 = 800026c4 F4 = 0000000000000000 ( 0) -D5 = 00000000 A5 = f67d98e0 F5 = 0000000000000000 ( 0) -D6 = f6fffaa8 A6 = f6fffa7c F6 = 0000000000000000 ( 0) -D7 = 00000002 A7 = f6fffa24 F7 = 0000000000000000 ( 0) -PC = f6fffa30 SR = 0000 ----- FPRESULT = 0 -Aborted - -How can I debug it further to try to figure out if this is a qemu issue or not? Thanks \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1412 b/results/classifier/zero-shot-user-mode/output/instruction/1412 deleted file mode 100644 index ed296c581..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1412 +++ /dev/null @@ -1,11 +0,0 @@ -instruction: 0.816 -runtime: 0.097 -syscall: 0.087 - - - -QEMU segfault (null pointer dereference) in sve_probe_page from ldff1* instructions -Description of problem: -After upgrading to QEMU v7.2.0 from v7.1.0, when executing any SVE ldff1* instructions with a faulting address, QEMU crashes due to a null pointer dereference at target/arm/sve_helper.c:5364 - -I believe this was introduced in b8967ddf393aaf35fdbc07b4cb538a40f8b6fe37 (@rth7680), since in that commit `full` is dereferenced before the `flags & TLB_INVALID_MASK` check at line 5369, and full is set to null by `probe_access_full` when `TLB_INVALID_MASK` is given. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1416988 b/results/classifier/zero-shot-user-mode/output/instruction/1416988 deleted file mode 100644 index c1d25349b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1416988 +++ /dev/null @@ -1,38 +0,0 @@ -instruction: 0.378 -runtime: 0.327 -syscall: 0.295 - - - -Wrong signal handling in qemu-aarch64. - -Running GCC 5.0 testsuite under qemu-aarch64, I noticed that tests connected with stack unwinding fail with: - -qemu: uncaught target signal 11 (Segmentation fault) - core dumped - -or run into infinite loop. - -Here is one example: - -$ /home/max/build/gcc-aarch64/gcc/xgcc -B/home/max/build/gcc-aarch64/gcc/ /home/max/src/toolchain/gcc/gcc/testsuite/gcc.dg/cleanup-11.c -fexceptions -fnon-call-exceptions -O2 -lm -o ./cleanup-11.exe - -$ qemu-aarch64 -L /home/max/install/aarch64/aarch64-linux/sys-root/ -R 0 -/cleanup-11.exe -qemu: uncaught target signal 11 (Segmentation fault) - core dumped. - -Actually, this caused by ABI incompatibility between Linux Kernel (trunk) and qemu-aarch64. In fact, size of siginfo structure in Linux and target_siginfo structure in qemu-aarch64 differ: - -sizeof (struct target_siginfo) = 136 // QEMU -sizeof (struct siginfo) = 128 // Linux Kernel - - -This caused by wrong TARGET_SI_PAD_SIZE defined in linux-user/syscall_defs.h: - -#define TARGET_SI_PAD_SIZE ((TARGET_SI_MAX_SIZE/sizeof(int)) - 3) - -In Kernel respective value is: - -#define SI_PAD_SIZE ((SI_MAX_SIZE - __ARCH_SI_PREAMBLE_SIZE) / sizeof(int)) -............................................. -#define __ARCH_SI_PREAMBLE_SIZE (4 * sizeof(int)) // for Aarch64 - -Trivial fix, changing TARGET_SI_PAD_SIZE to right value, is attached. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1428352 b/results/classifier/zero-shot-user-mode/output/instruction/1428352 deleted file mode 100644 index 0b125b71f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1428352 +++ /dev/null @@ -1,50 +0,0 @@ -instruction: 0.394 -runtime: 0.320 -syscall: 0.286 - - - -SYSRET instruction incorrectly implemented - -The Intel architecture manual states that when returning to user mode, the SYSRET instruction will re-load the stack selector (%ss) from the IA32_STAR model specific register using the following logic: - -SS.Selector <-- (IA32_STAR[63:48]+8) OR 3; (* RPL forced to 3 *) - -Another description of the instruction behavior which shows the same logic in a slightly different form can also be found here: - -http://tptp.cc/mirrors/siyobik.info/instruction/SYSRET.html - -[...] - SS(SEL) = IA32_STAR[63:48] + 8; - SS(PL) = 0x3; -[...] - -In other words, the value of the %ss register is supposed to be loaded from bits 63:48 of the IA32_STAR model-specific register, incremented by 8, and then ORed with 3. ORing in the 3 sets the privilege level to 3 (user). This is done since SYSRET returns to user mode after a system call. - -However, helper_sysret() in target-i386/seg_helper.c does not do the "OR 3" step. The code looks like this: - - cpu_x86_load_seg_cache(env, R_SS, selector + 8, - 0, 0xffffffff, - DESC_G_MASK | DESC_B_MASK | DESC_P_MASK | - DESC_S_MASK | (3 << DESC_DPL_SHIFT) | - DESC_W_MASK | DESC_A_MASK); - -It should look like this: - - cpu_x86_load_seg_cache(env, R_SS, (selector + 8) | 3, - 0, 0xffffffff, - DESC_G_MASK | DESC_B_MASK | DESC_P_MASK | - DESC_S_MASK | (3 << DESC_DPL_SHIFT) | - DESC_W_MASK | DESC_A_MASK); - -The code does correctly set the privilege level bits for the code selector register (%cs) but not for the stack selector (%ss). - -The effect of this is that when SYSRET returns control to the user-mode caller, %ss will be have the privilege level bits cleared. In my case, it went from 0x2b to 0x28. This caused a crash later: when the user-mode code was preempted by an interrupt, and the interrupt handler would do an IRET, a general protection fault would occur because the %ss value being loaded from the exception frame was not valid for user mode. (At least, I think that's what happened.) - -This behavior seems inconsistent with real hardware, and also appears to be wrong with respect to the Intel documentation, so I'm pretty confident in calling this a bug. :) - -Note that this issue seems to have been around for a long time. I discovered it while using QEMU 2.2.0, but I happened to have the sources for QEMU 0.10.5, and the problem is there too (in os_helper.c). I am using FreeBSD/amd64 9.1-RELEASE as my host system, without KVM. - -The fix is fairly simple. I'm attaching a patch which worked for me. Using this fix, the code that I'm testing now behaves the same on the QEMU virtual machine as on real hardware. - -- Bill (<email address hidden>) \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1429313 b/results/classifier/zero-shot-user-mode/output/instruction/1429313 deleted file mode 100644 index 092aafc78..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1429313 +++ /dev/null @@ -1,15 +0,0 @@ -instruction: 0.525 -runtime: 0.314 -syscall: 0.161 - - - -qemu-user doesn't block target signals on entry to signal hanlder. - -Upon entry to a target signal handler the function process_pending_signals in linux-user/signal.c block the appropriate host signals, but signals already received and queued by Qemu are not blocked. If multiple signals arrive in quick succession this results incorrect recursion in the target signal handler. - -The attached test case my be run as: - -$ (sleep 2 ; echo) | qemu-i386 ./a.out -.................. Recursion in signal handler! -qemu: uncaught target signal 6 (Aborted) - core dumped \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1435 b/results/classifier/zero-shot-user-mode/output/instruction/1435 deleted file mode 100644 index 010c82238..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1435 +++ /dev/null @@ -1,22 +0,0 @@ -instruction: 0.538 -runtime: 0.241 -syscall: 0.221 - - - -Infinite recursion in tcg_gen_mulu2_i32 for certain 32-bit hosts. -Description of problem: -`tcg_gen_mulu2_i32` infinitely recurses on a 32-bit host (TCG target) that has neither `TCG_TARGET_HAS_mulu2_i32` nor `TCG_TARGET_HAS_muluh_i32`. - -I don't actually think there is any host that is 32-bits and has neither mulu2 nor muluh. The only reference I found is [this](https://gitlab.com/qemu-project/qemu/-/commit/df9ebea53ebc1c98217743f56c30ae3a46031bb9) commit, which adds an `#error` if that situation is hit. But the check, which [still exists](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/include/tcg/tcg.h#L174), checks if those flags are *defined*, not for their value. I guess, over the years as the code was refactored, the check wasn't updated because, frankly, there aren't any hosts that match that situation (except mine). - -One easy fix is to change the check mentioned above to check the actual macro value so that compilation fails. I can create a PR for that. -Steps to reproduce: -(Note: I'm linking to the v7.2.0 tag so that these links stay relevant). - -1. `tcg_gen_mulu2_i32` [calls](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L890) `tcg_gen_mul_i64`. -2. `tcg_gen_mul_i64` on 32-bit hosts, due to [this](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1097) check for `TCG_TARGET_REG_BITS == 32`, is defined [here](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1218), and [calls](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1226) `tcg_gen_mulu2_i32`. -3. Rinse and repeat. -4. Eventually, as gen_mulu2/mul functions spill while trying to allocate temps, they will overflow the TB buffer. This will restart code generation with smaller and smaller block sizes, until the block size reaches 1 instruction. TCG will then give up and [assert](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/accel/tcg/translate-all.c#L869). -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1441 b/results/classifier/zero-shot-user-mode/output/instruction/1441 deleted file mode 100644 index 1ccce7520..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1441 +++ /dev/null @@ -1,40 +0,0 @@ -instruction: 0.788 -runtime: 0.124 -syscall: 0.088 - - - -Assertion failure when executing RISC-V vfncvt.rtz.x.f.w instruction -Description of problem: -When emulating the `vfncvt.rtz.x.f.w` instruction, QEMU crashes with an assertion failure at `target/riscv/translate.c:211`, complaining that ```decode_save_opc: Assertion `ctx->insn_start != NULL' failed.``` - -It appears this problem first emerged with https://gitlab.com/qemu-project/qemu/-/commit/a9814e3e08d2aacbd9018c36c77c2fb652537848 -Steps to reproduce: -The following C program triggers the assertion failure when built a sufficiently recent version of the Clang cross compiler (in my case 15.0.6): -``` -/* test.c */ -#include <riscv_vector.h> - -#define LEN 4 - -int main(int argc, char *argv[]) { - double in[LEN]; - int out[LEN]; - - vfloat64m1_t vf = vle64_v_f64m1(in, LEN); - vint32mf2_t vi = vfncvt_rtz_x_f_w_i32mf2(vf, LEN); - vse32_v_i32mf2(out, vi, LEN); - - return 0; -} -``` - -The above `test.c` can be compiled and run as follows: -``` -clang -O3 -march=rv64gcv -static test.c -qemu-riscv64 -cpu "rv64,zba=true,zbb=true,zbc=true,zbs=true,v=true,vlen=512,elen=64,vext_spec=v1.0" a.out -qemu-riscv64: ../target/riscv/translate.c:211: decode_save_opc: Assertion `ctx->insn_start != NULL' failed. -Segmentation fault (core dumped) -``` -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1452 b/results/classifier/zero-shot-user-mode/output/instruction/1452 deleted file mode 100644 index 28a598631..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1452 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.490 -syscall: 0.388 -runtime: 0.122 - - - -Tricore: support for shuffle and syscall instruction diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1457275 b/results/classifier/zero-shot-user-mode/output/instruction/1457275 deleted file mode 100644 index c32fcbf4c..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1457275 +++ /dev/null @@ -1,111 +0,0 @@ -instruction: 0.336 -runtime: 0.333 -syscall: 0.331 - - - -qemu-user hangs in m{,un}map loop - -Gentoo amd64 there, tried both 2.3.0 and eba05e922e8e7f307bc5d4104a78797e55124e97 versions of qemu. Reproduces with qemu-x86_64 as well. - -∞ strace qemu-arm bin/true 2>&1| head -n 100 -execve("/usr/bin/qemu-arm", ["qemu-arm", "bin/true"], [/* 49 vars */]) = 0 -uname({sysname="Linux", nodename="l29ah-home", ...}) = 0 -brk(0) = 0x62a4d070 -brk(0x62a4e2b0) = 0x62a4e2b0 -arch_prctl(ARCH_SET_FS, 0x62a4d980) = 0 -set_tid_address(0x62a4dc50) = 7841 -set_robust_list(0x62a4dc60, 24) = 0 -rt_sigaction(SIGRTMIN, {0x6011bd10, [], SA_RESTORER|SA_SIGINFO, 0x60122710}, NULL, 8) = 0 -rt_sigaction(SIGRT_1, {0x6011bda0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x60122710}, NULL, 8) = 0 -rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 -getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 -readlink("/proc/self/exe", "/usr/bin/qemu-arm", 4096) = 17 -brk(0x62a6f2b0) = 0x62a6f2b0 -brk(0x62a70000) = 0x62a70000 -rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 -mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x2c951ff9000 -mprotect(0x2c951ff9000, 4096, PROT_NONE) = 0 -clone(child_stack=0x2c9527f8df0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x2c9527f99d0, tls=0x2c9527f9700, child_tidptr=0x2c9527f99d0) = 7842 -rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 -gettimeofday({1432174351, 569148}, NULL) = 0 -getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 -time(NULL) = 1432174351 -openat(AT_FDCWD, "/usr/gnemul/qemu-arm", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) -uname({sysname="Linux", nodename="l29ah-home", ...}) = 0 -mprotect(0x60519000, 33558528, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 -madvise(0x605190b0, 33554432, MADV_HUGEPAGE) = -1 EINVAL (Invalid argument) -mmap(NULL, 50331648, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c94eff9000 -brk(0x62a91000) = 0x62a91000 -mmap(NULL, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0x1000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0x2000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0x3000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0x4000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0x5000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0x6000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0x7000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0x8000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0x9000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0xa000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0xb000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0xc000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0xd000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0xe000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0xf000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0x10000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 -mmap(0x11000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 -mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 -munmap(0x2c857ff8000, 4096) = 0 -munmap(0x2c857ff9000, 4143972352) = 0 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1462640 b/results/classifier/zero-shot-user-mode/output/instruction/1462640 deleted file mode 100644 index 8dab5f39a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1462640 +++ /dev/null @@ -1,41 +0,0 @@ -instruction: 0.500 -runtime: 0.303 -syscall: 0.197 - - - -shmat fails on 32-to-64 setup - - -I am trying to run a guest mips32 program (user mode) on a x86_64 host. The program fails on a call to shmat() reproducibly. when digging into this problem, I could make a small guest POC that fails when compiled as i386 (-m32) running on a x86_64 host, but pass when compiled as 64bit. The problem has to do with mmap flags. - -From what I can understand, when running 32bits guests programs, qemu reserve the whole guest virtual space with an mmap call. That mmap call specifys MAP:PRIVATE flag. When shmat is called, it tries to make part of that region MAP_SHARED and that fails. - -As a possible fix, it looks like it is possible to first unmap the shm region before calling shmat. - -steps to reproduce: -1 - create a file shm.c with content below -2 - compile with: gcc -m32 shm.c -o shm32 -3 - run on a x86_64 host: qemu-i386 ./shm32 -4 - observe shmat fails, by returning ptr -1 - -5- compile without -m32: : gcc shm.c -o shm64 -6 - observe it pass: qemu-x84_64 ./shm64 - - - -#include <sys/ipc.h> -#include <sys/shm.h> -#include <sys/mman.h> -#include <stdio.h> - -int main() -{ - struct shmid_ds shm_desc; - int err = 0; - int id = shmget(IPC_PRIVATE, 688128, IPC_CREAT|IPC_EXCL|0666); - err = shmctl(id, IPC_STAT, &shm_desc); - const void *at = 0x7f7df38ea000; - void* ptr = shmat(id, at, 0); - printf( "got err %d, ptr %p\n", err, ptr ); -} \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1469342 b/results/classifier/zero-shot-user-mode/output/instruction/1469342 deleted file mode 100644 index d33abcb59..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1469342 +++ /dev/null @@ -1,9 +0,0 @@ -instruction: 0.907 -runtime: 0.076 -syscall: 0.018 - - - -qemu-i386 pentium3/athlon incorrect instruction set - -Running a binary containing a movsd instruction (SSE2) in 32-bit qemu-i386 -cpu pentium3 from 20150609 results in flawless execution whereas it should crash with SIGILL as P3 only had SSE. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1471 b/results/classifier/zero-shot-user-mode/output/instruction/1471 deleted file mode 100644 index 8afd16b85..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1471 +++ /dev/null @@ -1,22 +0,0 @@ -instruction: 0.675 -syscall: 0.186 -runtime: 0.139 - - - -16fc5726a6 breaks curl SSL connections -Description of problem: -`./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk` should work, just as `./qemu-aarch64 /path/to/curl-aarch64 https://news.bbc.co.uk` does. However, commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4 broke this (determined via `git bisect`). -Steps to reproduce: -1. Checkout and build `qemu` commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4 -2. On an aarch64 host system, download the amd64 build of `curl` from https://github.com/moparisthebest/static-curl/releases/tag/v7.87.0 -3. Run `./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk` -4. Observe the following error message: - -``` -curl: (35) error:1416D07B:SSL routines:tls_process_key_exchange:bad signature -``` - -Note that the `aarch64` equivalent works just fine. As does the previous commit using `amd64`. - -Also note, this bug is also present at current tip (13356edb87506c148b163b8c7eb0695647d00c2a). diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1494 b/results/classifier/zero-shot-user-mode/output/instruction/1494 deleted file mode 100644 index 24749be76..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1494 +++ /dev/null @@ -1,938 +0,0 @@ -instruction: 0.409 -runtime: 0.340 -syscall: 0.251 - - - -[regression] [bisected] [coredump] qemu-x86_64 segfaults on ppc64le (4K page size) when downloading go dependencies: unexpected fault address 0x0 -Description of problem: -qemu-x86_64 segfaults when trying to compile yay inside an Arch Linux x86_64 chroot from a Gentoo Linux ppc64le (4K page size) host. Hardware is a Raptor CS Talos 2 Power 9. - -It works with qemu-7.2 so this is a regression in git master (or less likely with the patch). - -``` -[niko@talos2 yay]$ makepkg -s -==> Making package: yay 11.3.2-1 (Wed 15 Feb 2023 05:03:01 PM CET) -==> Checking runtime dependencies... -==> Checking buildtime dependencies... -==> Retrieving sources... - -> Found yay-11.3.2.tar.gz -==> Validating source files with sha256sums... - yay-11.3.2.tar.gz ... Passed -==> Extracting sources... - -> Extracting yay-11.3.2.tar.gz with bsdtar -==> Removing existing $pkgdir/ directory... -==> Starting build()... -go build -trimpath -mod=readonly -modcacherw -ldflags '-X "main.yayVersion=11.3.2" -X "main.localePath=/usr/share/locale/" -linkmode=external' -buildmode=pie -o yay -go: downloading github.com/Jguer/votar v1.0.0 -go: downloading github.com/Jguer/aur v1.0.1 -go: downloading github.com/Jguer/go-alpm/v2 v2.1.2 -go: downloading github.com/Morganamilo/go-pacmanconf v0.0.0-20210502114700-cff030e927a5 -go: downloading golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab -go: downloading github.com/Morganamilo/go-srcinfo v1.0.0 -go: downloading golang.org/x/term v0.0.0-20220722155259-a9ba230a4035 -go: downloading github.com/leonelquinteros/gotext v1.5.0 -go: downloading github.com/adrg/strutil v0.3.0 -go: downloading golang.org/x/text v0.3.7 -make: *** [Makefile:113: yay] Illegal instruction (core dumped) -``` - -``` -[niko@talos2 yay]$ makepkg -s -==> Making package: yay 11.3.2-1 (Wed 15 Feb 2023 05:10:01 PM CET) -==> Checking runtime dependencies... -==> Checking buildtime dependencies... -==> Retrieving sources... - -> Found yay-11.3.2.tar.gz -==> Validating source files with sha256sums... - yay-11.3.2.tar.gz ... Passed -==> Extracting sources... - -> Extracting yay-11.3.2.tar.gz with bsdtar -==> Starting build()... -go build -trimpath -mod=readonly -modcacherw -ldflags '-X "main.yayVersion=11.3.2" -X "main.localePath=/usr/share/locale/" -linkmode=external' -buildmode=pie -o yay -go: downloading github.com/Jguer/votar v1.0.0 -go: downloading github.com/Jguer/go-alpm/v2 v2.1.2 -go: downloading github.com/Morganamilo/go-srcinfo v1.0.0 -go: downloading github.com/Jguer/aur v1.0.1 -go: downloading github.com/leonelquinteros/gotext v1.5.0 -go: downloading github.com/Morganamilo/go-pacmanconf v0.0.0-20210502114700-cff030e927a5 -go: downloading golang.org/x/term v0.0.0-20220722155259-a9ba230a4035 -go: downloading github.com/adrg/strutil v0.3.0 -go: downloading golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab -go: downloading golang.org/x/text v0.3.7 -# math/bits -unexpected fault address 0x0 -fatal error: fault -[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0xabb70a] - -goroutine 4 [running]: -runtime.throw({0xdbf491?, 0x1?}) - /usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0xc0001d7750 sp=0xc0001d7720 pc=0x4389fd -runtime.sigpanic() - /usr/lib/go/src/runtime/signal_unix.go:851 +0x28a fp=0xc0001d77b0 sp=0xc0001d7750 pc=0x44f4ea -cmd/compile/internal/ssa.ValHeap.Less({{0xc0001ae1c0, 0x4, 0x8}, {0xc0001de700, 0x28, 0x100}}, 0x8?, 0xc0001de700?) - /usr/lib/go/src/cmd/compile/internal/ssa/schedule.go:59 +0xaa fp=0xc0001d77e0 sp=0xc0001d77b0 pc=0xabb70a -cmd/compile/internal/ssa.(*ValHeap).Less(0x4?, 0x8?, 0xc0001de700?) - <autogenerated>:1 +0x77 fp=0xc0001d7860 sp=0xc0001d77e0 pc=0xad7677 -container/heap.up({0xf24240, 0xc00019eb40}, 0xc00081b370?) - /usr/lib/go/src/container/heap/heap.go:92 +0x7e fp=0xc0001d7898 sp=0xc0001d7860 pc=0x7024de -container/heap.Push({0xf24240, 0xc00019eb40}, {0xdb1f80?, 0xc00081b370?}) - /usr/lib/go/src/container/heap/heap.go:53 +0x5a fp=0xc0001d78c0 sp=0xc0001d7898 pc=0x7022da -cmd/compile/internal/ssa.schedule(0xc0004ea000) - /usr/lib/go/src/cmd/compile/internal/ssa/schedule.go:349 +0x151c fp=0xc0001d7eb0 sp=0xc0001d78c0 pc=0xabcd9c -cmd/compile/internal/ssa.Compile(0xc0004ea000) - /usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc0001dbb68 sp=0xc0001d7eb0 pc=0x76bc43 -cmd/compile/internal/ssagen.buildssa(0xc00071b540, 0x2) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc0001dbea8 sp=0xc0001dbb68 pc=0xaf0527 -cmd/compile/internal/ssagen.Compile(0xc00071b540, 0x0?) - /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0001dbf70 sp=0xc0001dbea8 pc=0xae796c -cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0001dbfb0 sp=0xc0001dbf70 pc=0xcc681a -cmd/compile/internal/gc.compileFunctions.func3.1() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0001dbfe0 sp=0xc0001dbfb0 pc=0xcc6c52 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0001dbfe8 sp=0xc0001dbfe0 pc=0x46e201 -created by cmd/compile/internal/gc.compileFunctions.func3 - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 - -goroutine 1 [semacquire]: -runtime.gopark(0xc0000062e8?, 0xc00019a050?, 0x0?, 0xa0?, 0x4027dba128?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0005ad968 sp=0xc0005ad948 pc=0x43b716 -runtime.goparkunlock(...) - /usr/lib/go/src/runtime/proc.go:387 -runtime.semacquire1(0xc0008c4768, 0x20?, 0x1, 0x0, 0x0?) - /usr/lib/go/src/runtime/sema.go:160 +0x20f fp=0xc0005ad9d0 sp=0xc0005ad968 pc=0x44c9af -sync.runtime_Semacquire(0xc0008b8000?) - /usr/lib/go/src/runtime/sema.go:62 +0x27 fp=0xc0005ada08 sp=0xc0005ad9d0 pc=0x46a6e7 -sync.(*WaitGroup).Wait(0xc000659800?) - /usr/lib/go/src/sync/waitgroup.go:116 +0x4b fp=0xc0005ada30 sp=0xc0005ada08 pc=0x487deb -cmd/compile/internal/gc.compileFunctions() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:183 +0x235 fp=0xc0005ada88 sp=0xc0005ada30 pc=0xcc6675 -cmd/compile/internal/gc.Main(0xdf8e28) - /usr/lib/go/src/cmd/compile/internal/gc/main.go:332 +0x13aa fp=0xc0005adf20 sp=0xc0005ada88 pc=0xcc86aa -main.main() - /usr/lib/go/src/cmd/compile/main.go:57 +0xdd fp=0xc0005adf80 sp=0xc0005adf20 pc=0xcf00bd -runtime.main() - /usr/lib/go/src/runtime/proc.go:250 +0x207 fp=0xc0005adfe0 sp=0xc0005adf80 pc=0x43b2e7 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0005adfe8 sp=0xc0005adfe0 pc=0x46e201 - -goroutine 2 [force gc (idle)]: -runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009afb0 sp=0xc00009af90 pc=0x43b716 -runtime.goparkunlock(...) - /usr/lib/go/src/runtime/proc.go:387 -runtime.forcegchelper() - /usr/lib/go/src/runtime/proc.go:305 +0xb0 fp=0xc00009afe0 sp=0xc00009afb0 pc=0x43b550 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009afe8 sp=0xc00009afe0 pc=0x46e201 -created by runtime.init.6 - /usr/lib/go/src/runtime/proc.go:293 +0x25 - -goroutine 17 [GC sweep wait]: -runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc000096780 sp=0xc000096760 pc=0x43b716 -runtime.goparkunlock(...) - /usr/lib/go/src/runtime/proc.go:387 -runtime.bgsweep(0x0?) - /usr/lib/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc0000967c8 sp=0xc000096780 pc=0x425cce -runtime.gcenable.func1() - /usr/lib/go/src/runtime/mgc.go:178 +0x26 fp=0xc0000967e0 sp=0xc0000967c8 pc=0x41aee6 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000967e8 sp=0xc0000967e0 pc=0x46e201 -created by runtime.gcenable - /usr/lib/go/src/runtime/mgc.go:178 +0x6b - -goroutine 18 [GC scavenge wait]: -runtime.gopark(0xc000194000?, 0xf1ad58?, 0x1?, 0x0?, 0x0?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc000096f70 sp=0xc000096f50 pc=0x43b716 -runtime.goparkunlock(...) - /usr/lib/go/src/runtime/proc.go:387 -runtime.(*scavengerState).park(0x1487ce0) - /usr/lib/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc000096fa0 sp=0xc000096f70 pc=0x423c13 -runtime.bgscavenge(0x0?) - /usr/lib/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc000096fc8 sp=0xc000096fa0 pc=0x4241e5 -runtime.gcenable.func2() - /usr/lib/go/src/runtime/mgc.go:179 +0x26 fp=0xc000096fe0 sp=0xc000096fc8 pc=0x41ae86 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000096fe8 sp=0xc000096fe0 pc=0x46e201 -created by runtime.gcenable - /usr/lib/go/src/runtime/mgc.go:179 +0xaa - -goroutine 33 [finalizer wait]: -runtime.gopark(0x43ba92?, 0x4027cf9f48?, 0x0?, 0x0?, 0xc00009a770?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009a628 sp=0xc00009a608 pc=0x43b716 -runtime.runfinq() - /usr/lib/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00009a7e0 sp=0xc00009a628 pc=0x419f27 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009a7e8 sp=0xc00009a7e0 pc=0x46e201 -created by runtime.createfing - /usr/lib/go/src/runtime/mfinal.go:163 +0x45 - -goroutine 49 [select]: -runtime.gopark(0xc0004e6fb0?, 0x2?, 0xf0?, 0x6d?, 0xc0004e6f6c?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0004e6da0 sp=0xc0004e6d80 pc=0x43b716 -runtime.selectgo(0xc0004e6fb0, 0xc0004e6f68, 0xc000504000?, 0x0, 0xd26040?, 0x1) - /usr/lib/go/src/runtime/select.go:327 +0x7be fp=0xc0004e6ee0 sp=0xc0004e6da0 pc=0x44b8be -cmd/compile/internal/gc.compileFunctions.func3() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:141 +0x132 fp=0xc0004e6fe0 sp=0xc0004e6ee0 pc=0xcc6a12 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0004e6fe8 sp=0xc0004e6fe0 pc=0x46e201 -created by cmd/compile/internal/gc.compileFunctions - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:134 +0xf8 - -goroutine 3 [runnable]: -runtime.asyncPreempt2() - /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0004f7858 sp=0xc0004f7838 pc=0x439e1f -runtime.asyncPreempt() - /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0004f79e0 sp=0xc0004f7858 pc=0x46f85b -cmd/compile/internal/ssa.is64BitInt(0xc000141480) - /usr/lib/go/src/cmd/compile/internal/ssa/rewrite.go:218 +0xa fp=0xc0004f79e8 sp=0xc0004f79e0 pc=0x7e2e8a -cmd/compile/internal/ssa.rewriteValueAMD64_OpLoad(0xc00086a458) - /usr/lib/go/src/cmd/compile/internal/ssa/rewriteAMD64.go:29312 +0x51 fp=0xc0004f7a28 sp=0xc0004f79e8 pc=0x884911 -cmd/compile/internal/ssa.rewriteValueAMD64(0xc00089f678?) - /usr/lib/go/src/cmd/compile/internal/ssa/rewriteAMD64.go:838 +0x31be fp=0xc0004f7a48 sp=0xc0004f7a28 pc=0x819bbe -cmd/compile/internal/ssa.applyRewrite(0xc0001b2000, 0xdf92a8, 0xdf9348, 0x1) - /usr/lib/go/src/cmd/compile/internal/ssa/rewrite.go:133 +0x1016 fp=0xc0004f7e80 sp=0xc0004f7a48 pc=0x7e27d6 -cmd/compile/internal/ssa.lower(0xc0001b2000?) - /usr/lib/go/src/cmd/compile/internal/ssa/lower.go:10 +0x2f fp=0xc0004f7eb0 sp=0xc0004f7e80 pc=0x7b4c4f -cmd/compile/internal/ssa.Compile(0xc0001b2000) - /usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc0004fbb68 sp=0xc0004f7eb0 pc=0x76bc43 -cmd/compile/internal/ssagen.buildssa(0xc00071b900, 0x3) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc0004fbea8 sp=0xc0004fbb68 pc=0xaf0527 -cmd/compile/internal/ssagen.Compile(0xc00071b900, 0x0?) - /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0004fbf70 sp=0xc0004fbea8 pc=0xae796c -cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0004fbfb0 sp=0xc0004fbf70 pc=0xcc681a -cmd/compile/internal/gc.compileFunctions.func3.1() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0004fbfe0 sp=0xc0004fbfb0 pc=0xcc6c52 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0004fbfe8 sp=0xc0004fbfe0 pc=0x46e201 -created by cmd/compile/internal/gc.compileFunctions.func3 - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 - -goroutine 50 [runnable]: -cmd/compile/internal/ssa.(*Value).clobbersFlags(0xc0007ce6d8?) - /usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:243 +0xd5 fp=0xc0000dbbf0 sp=0xc0000dbbe8 pc=0x79c375 -cmd/compile/internal/ssa.flagalloc(0xc0000ca000) - /usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:39 +0x172a fp=0xc0000dbeb0 sp=0xc0000dbbf0 pc=0x79c0ca -cmd/compile/internal/ssa.Compile(0xc0000ca000) - /usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc0000dfb68 sp=0xc0000dbeb0 pc=0x76bc43 -cmd/compile/internal/ssagen.buildssa(0xc00071ba40, 0x1) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc0000dfea8 sp=0xc0000dfb68 pc=0xaf0527 -cmd/compile/internal/ssagen.Compile(0xc00071ba40, 0x0?) - /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0000dff70 sp=0xc0000dfea8 pc=0xae796c -cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0000dffb0 sp=0xc0000dff70 pc=0xcc681a -cmd/compile/internal/gc.compileFunctions.func3.1() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0000dffe0 sp=0xc0000dffb0 pc=0xcc6c52 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000dffe8 sp=0xc0000dffe0 pc=0x46e201 -created by cmd/compile/internal/gc.compileFunctions.func3 - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 - -goroutine 51 [runnable]: -cmd/compile/internal/ssa.(*Value).clobbersFlags(0xc000780d90?) - /usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:243 +0xd5 fp=0xc00091bbf0 sp=0xc00091bbe8 pc=0x79c375 -cmd/compile/internal/ssa.flagalloc(0xc000774540) - /usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:39 +0x172a fp=0xc00091beb0 sp=0xc00091bbf0 pc=0x79c0ca -cmd/compile/internal/ssa.Compile(0xc000774540) - /usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc00091fb68 sp=0xc00091beb0 pc=0x76bc43 -cmd/compile/internal/ssagen.buildssa(0xc000703900, 0x0) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc00091fea8 sp=0xc00091fb68 pc=0xaf0527 -cmd/compile/internal/ssagen.Compile(0xc000703900, 0x0?) - /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc00091ff70 sp=0xc00091fea8 pc=0xae796c -cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc00091ffb0 sp=0xc00091ff70 pc=0xcc681a -cmd/compile/internal/gc.compileFunctions.func3.1() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc00091ffe0 sp=0xc00091ffb0 pc=0xcc6c52 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00091ffe8 sp=0xc00091ffe0 pc=0x46e201 -created by cmd/compile/internal/gc.compileFunctions.func3 - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 -# unicode/utf8 -unexpected fault address 0x0 -fatal error: fault -[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x411410] - -goroutine 19 [running]: -runtime.throw({0xdbf491?, 0x4000804d28?}) - /usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0xc0004f1830 sp=0xc0004f1800 pc=0x4389fd -runtime.sigpanic() - /usr/lib/go/src/runtime/signal_unix.go:851 +0x28a fp=0xc0004f1890 sp=0xc0004f1830 pc=0x44f4ea -runtime.mapaccess2_fast32(0xc0009b3c00, 0xc000562000, 0x6be729) - /usr/lib/go/src/runtime/map_fast32.go:53 +0x170 fp=0xc0004f1898 sp=0xc0004f1890 pc=0x411410 -cmd/compile/internal/ssagen.genssa(0xc000562000, 0xc000988ee0) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:6964 +0x965 fp=0xc0004f1ea8 sp=0xc0004f1898 pc=0xb27345 -cmd/compile/internal/ssagen.Compile(0xc0000fcb40, 0x0?) - /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0004f1f70 sp=0xc0004f1ea8 pc=0xae7b8f -cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0004f1fb0 sp=0xc0004f1f70 pc=0xcc681a -cmd/compile/internal/gc.compileFunctions.func3.1() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0004f1fe0 sp=0xc0004f1fb0 pc=0xcc6c52 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0004f1fe8 sp=0xc0004f1fe0 pc=0x46e201 -created by cmd/compile/internal/gc.compileFunctions.func3 - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 - -goroutine 1 [semacquire]: -runtime.gopark(0x20?, 0xd7ca20?, 0x0?, 0x60?, 0xc00003a600?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0005a9968 sp=0xc0005a9948 pc=0x43b716 -runtime.goparkunlock(...) - /usr/lib/go/src/runtime/proc.go:387 -runtime.semacquire1(0xc0006d5a88, 0x20?, 0x1, 0x0, 0x0?) - /usr/lib/go/src/runtime/sema.go:160 +0x20f fp=0xc0005a99d0 sp=0xc0005a9968 pc=0x44c9af -sync.runtime_Semacquire(0xc0000fdb80?) - /usr/lib/go/src/runtime/sema.go:62 +0x27 fp=0xc0005a9a08 sp=0xc0005a99d0 pc=0x46a6e7 -sync.(*WaitGroup).Wait(0xc0008ca400?) - /usr/lib/go/src/sync/waitgroup.go:116 +0x4b fp=0xc0005a9a30 sp=0xc0005a9a08 pc=0x487deb -cmd/compile/internal/gc.compileFunctions() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:183 +0x235 fp=0xc0005a9a88 sp=0xc0005a9a30 pc=0xcc6675 -cmd/compile/internal/gc.Main(0xdf8e28) - /usr/lib/go/src/cmd/compile/internal/gc/main.go:332 +0x13aa fp=0xc0005a9f20 sp=0xc0005a9a88 pc=0xcc86aa -main.main() - /usr/lib/go/src/cmd/compile/main.go:57 +0xdd fp=0xc0005a9f80 sp=0xc0005a9f20 pc=0xcf00bd -runtime.main() - /usr/lib/go/src/runtime/proc.go:250 +0x207 fp=0xc0005a9fe0 sp=0xc0005a9f80 pc=0x43b2e7 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0005a9fe8 sp=0xc0005a9fe0 pc=0x46e201 - -goroutine 2 [force gc (idle)]: -runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009cfb0 sp=0xc00009cf90 pc=0x43b716 -runtime.goparkunlock(...) - /usr/lib/go/src/runtime/proc.go:387 -runtime.forcegchelper() - /usr/lib/go/src/runtime/proc.go:305 +0xb0 fp=0xc00009cfe0 sp=0xc00009cfb0 pc=0x43b550 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009cfe8 sp=0xc00009cfe0 pc=0x46e201 -created by runtime.init.6 - /usr/lib/go/src/runtime/proc.go:293 +0x25 - -goroutine 3 [GC sweep wait]: -runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009d780 sp=0xc00009d760 pc=0x43b716 -runtime.goparkunlock(...) - /usr/lib/go/src/runtime/proc.go:387 -runtime.bgsweep(0x0?) - /usr/lib/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc00009d7c8 sp=0xc00009d780 pc=0x425cce -runtime.gcenable.func1() - /usr/lib/go/src/runtime/mgc.go:178 +0x26 fp=0xc00009d7e0 sp=0xc00009d7c8 pc=0x41aee6 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009d7e8 sp=0xc00009d7e0 pc=0x46e201 -created by runtime.gcenable - /usr/lib/go/src/runtime/mgc.go:178 +0x6b - -goroutine 4 [GC scavenge wait]: -runtime.gopark(0xc0000380e0?, 0xf1ad58?, 0x1?, 0x0?, 0x0?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009df70 sp=0xc00009df50 pc=0x43b716 -runtime.goparkunlock(...) - /usr/lib/go/src/runtime/proc.go:387 -runtime.(*scavengerState).park(0x1487ce0) - /usr/lib/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc00009dfa0 sp=0xc00009df70 pc=0x423c13 -runtime.bgscavenge(0x0?) - /usr/lib/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc00009dfc8 sp=0xc00009dfa0 pc=0x4241e5 -runtime.gcenable.func2() - /usr/lib/go/src/runtime/mgc.go:179 +0x26 fp=0xc00009dfe0 sp=0xc00009dfc8 pc=0x41ae86 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009dfe8 sp=0xc00009dfe0 pc=0x46e201 -created by runtime.gcenable - /usr/lib/go/src/runtime/mgc.go:179 +0xaa - -goroutine 17 [finalizer wait]: -runtime.gopark(0x43ba92?, 0x4027cf9fe8?, 0x0?, 0x0?, 0xc00009c770?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009c628 sp=0xc00009c608 pc=0x43b716 -runtime.runfinq() - /usr/lib/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00009c7e0 sp=0xc00009c628 pc=0x419f27 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009c7e8 sp=0xc00009c7e0 pc=0x46e201 -created by runtime.createfing - /usr/lib/go/src/runtime/mfinal.go:163 +0x45 - -goroutine 49 [runnable]: -runtime.asyncPreempt2() - /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0009c1308 sp=0xc0009c12e8 pc=0x439e1f -runtime.asyncPreempt() - /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0009c1490 sp=0xc0009c1308 pc=0x46f85b -cmd/compile/internal/ssa.PopulateABIInRegArgOps(0xc000754700) - /usr/lib/go/src/cmd/compile/internal/ssa/debug.go:436 +0x57 fp=0xc0009c16f0 sp=0xc0009c1490 pc=0x779bb7 -cmd/compile/internal/ssa.BuildFuncDebug(0xc00041e5a0?, 0xc000754700, 0xc000000049?, 0xa?, 0xc00098c000) - /usr/lib/go/src/cmd/compile/internal/ssa/debug.go:578 +0x1d6 fp=0xc0009c1898 sp=0xc0009c16f0 pc=0x77adb6 -cmd/compile/internal/ssagen.genssa(0xc000754700, 0xc0004bfce0) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7157 +0xf2b fp=0xc0009c1ea8 sp=0xc0009c1898 pc=0xb2790b -cmd/compile/internal/ssagen.Compile(0xc0000fc8c0, 0x0?) - /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0009c1f70 sp=0xc0009c1ea8 pc=0xae7b8f -cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0009c1fb0 sp=0xc0009c1f70 pc=0xcc681a -cmd/compile/internal/gc.compileFunctions.func3.1() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0009c1fe0 sp=0xc0009c1fb0 pc=0xcc6c52 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0009c1fe8 sp=0xc0009c1fe0 pc=0x46e201 -created by cmd/compile/internal/gc.compileFunctions.func3 - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 - -goroutine 5 [select]: -runtime.gopark(0xc00009e7b0?, 0x2?, 0xf0?, 0xe5?, 0xc00009e76c?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009e5a0 sp=0xc00009e580 pc=0x43b716 -runtime.selectgo(0xc00009e7b0, 0xc00009e768, 0x0?, 0x0, 0xd26040?, 0x1) - /usr/lib/go/src/runtime/select.go:327 +0x7be fp=0xc00009e6e0 sp=0xc00009e5a0 pc=0x44b8be -cmd/compile/internal/gc.compileFunctions.func3() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:141 +0x132 fp=0xc00009e7e0 sp=0xc00009e6e0 pc=0xcc6a12 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009e7e8 sp=0xc00009e7e0 pc=0x46e201 -created by cmd/compile/internal/gc.compileFunctions - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:134 +0xf8 - -goroutine 50 [runnable]: -runtime.asyncPreempt2() - /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0001cd308 sp=0xc0001cd2e8 pc=0x439e1f -runtime.asyncPreempt() - /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0001cd490 sp=0xc0001cd308 pc=0x46f85b -cmd/compile/internal/ssa.PopulateABIInRegArgOps(0xc000192000) - /usr/lib/go/src/cmd/compile/internal/ssa/debug.go:436 +0x57 fp=0xc0001cd6f0 sp=0xc0001cd490 pc=0x779bb7 -cmd/compile/internal/ssa.BuildFuncDebug(0xc0001a65a0?, 0xc000192000, 0xc000000049?, 0x12?, 0xc0001a4000) - /usr/lib/go/src/cmd/compile/internal/ssa/debug.go:578 +0x1d6 fp=0xc0001cd898 sp=0xc0001cd6f0 pc=0x77adb6 -cmd/compile/internal/ssagen.genssa(0xc000192000, 0xc00019f260) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7157 +0xf2b fp=0xc0001cdea8 sp=0xc0001cd898 pc=0xb2790b -cmd/compile/internal/ssagen.Compile(0xc0000fca00, 0x0?) - /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0001cdf70 sp=0xc0001cdea8 pc=0xae7b8f -cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0001cdfb0 sp=0xc0001cdf70 pc=0xcc681a -cmd/compile/internal/gc.compileFunctions.func3.1() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0001cdfe0 sp=0xc0001cdfb0 pc=0xcc6c52 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0001cdfe8 sp=0xc0001cdfe0 pc=0x46e201 -created by cmd/compile/internal/gc.compileFunctions.func3 - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 - -goroutine 20 [runnable]: -runtime.asyncPreempt2() - /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0008e10f8 sp=0xc0008e10d8 pc=0x439e1f -runtime.asyncPreempt() - /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0008e1280 sp=0xc0008e10f8 pc=0x46f85b -cmd/compile/internal/ssagen.AddrAuto(0xc000201ed0, 0x81308171a15?) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7649 +0x94 fp=0xc0008e12a8 sp=0xc0008e1280 pc=0xb2d9d4 -cmd/compile/internal/amd64.ssaGenValue(0xc0008bec60, 0xc000781ab0) - /usr/lib/go/src/cmd/compile/internal/amd64/ssa.go:1037 +0x13dc fp=0xc0008e1898 sp=0xc0008e12a8 pc=0xb3d6bc -cmd/compile/internal/ssagen.genssa(0xc0004e4000, 0xc0008e8070) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7024 +0x3ff8 fp=0xc0008e1ea8 sp=0xc0008e1898 pc=0xb2a9d8 -cmd/compile/internal/ssagen.Compile(0xc0000fcc80, 0x0?) - /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0008e1f70 sp=0xc0008e1ea8 pc=0xae7b8f -cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0008e1fb0 sp=0xc0008e1f70 pc=0xcc681a -cmd/compile/internal/gc.compileFunctions.func3.1() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0008e1fe0 sp=0xc0008e1fb0 pc=0xcc6c52 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0008e1fe8 sp=0xc0008e1fe0 pc=0x46e201 -created by cmd/compile/internal/gc.compileFunctions.func3 - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 -# internal/reflectlite -unexpected fault address 0x0 -fatal error: fault -[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x66b360] - -goroutine 6 [running]: -runtime.throw({0xdbf491?, 0x8?}) - /usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0xc0000dc720 sp=0xc0000dc6f0 pc=0x4389fd -runtime.sigpanic() - /usr/lib/go/src/runtime/signal_unix.go:851 +0x28a fp=0xc0000dc780 sp=0xc0000dc720 pc=0x44f4ea -cmd/compile/internal/abi.(*assignState).regAllocate(0xc0000dc7a0, 0x41b2b1, {0x14cdd40, 0xc0000dc808}, 0xa8) - /usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:607 fp=0xc0000dc788 sp=0xc0000dc780 pc=0x66b360 -cmd/compile/internal/abi.(*assignState).assignParamOrReturn(0xc0000dc8a8, 0xc0008977a0, {0xf23198, 0xc000a0b080}, 0x20?) - /usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:777 +0x165 fp=0xc0000dc840 sp=0xc0000dc788 pc=0x66bae5 -cmd/compile/internal/abi.(*ABIConfig).ABIAnalyzeFuncType(0xc0000bca60, 0xc00089b710) - /usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:404 +0x3d7 fp=0xc0000dc9f8 sp=0xc0000dc840 pc=0x669a17 -cmd/compile/internal/abi.(*ABIConfig).ABIAnalyze(0xd41a80?, 0xc0000d0600?, 0x0?) - /usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:432 +0x5d fp=0xc0000dcb68 sp=0xc0000dc9f8 pc=0x669e7d -cmd/compile/internal/ssagen.buildssa(0xc0008cc500, 0x1) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:455 +0x1209 fp=0xc0000dcea8 sp=0xc0000dcb68 pc=0xaef709 -cmd/compile/internal/ssagen.Compile(0xc0008cc500, 0x0?) - /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0000dcf70 sp=0xc0000dcea8 pc=0xae796c -cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0000dcfb0 sp=0xc0000dcf70 pc=0xcc681a -cmd/compile/internal/gc.compileFunctions.func3.1() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0000dcfe0 sp=0xc0000dcfb0 pc=0xcc6c52 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000dcfe8 sp=0xc0000dcfe0 pc=0x46e201 -created by cmd/compile/internal/gc.compileFunctions.func3 - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 - -goroutine 1 [runnable]: -runtime.gopark(0xc0000be000?, 0xc0004edec0?, 0xb0?, 0x99?, 0xc000739978?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc000739910 sp=0xc0007398f0 pc=0x43b716 -runtime.chansend(0xc000d540c0, 0xc0007399e8, 0x1, 0xc0007399d8?) - /usr/lib/go/src/runtime/chan.go:259 +0x42e fp=0xc000739998 sp=0xc000739910 pc=0x40602e -runtime.chansend1(0xd7ca20?, 0x4000803501?) - /usr/lib/go/src/runtime/chan.go:145 +0x1d fp=0xc0007399c8 sp=0xc000739998 pc=0x405bdd -cmd/compile/internal/gc.compileFunctions.func4(0xc00180cc40) - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:160 +0x27 fp=0xc0007399e8 sp=0xc0007399c8 pc=0xcc68a7 -cmd/compile/internal/gc.compileFunctions.func5({0xc001099500, 0x222, 0x350?}) - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:170 +0x53 fp=0xc000739a30 sp=0xc0007399e8 pc=0xcc6713 -cmd/compile/internal/gc.compileFunctions() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:181 +0x1ff fp=0xc000739a88 sp=0xc000739a30 pc=0xcc663f -cmd/compile/internal/gc.Main(0xdf8e28) - /usr/lib/go/src/cmd/compile/internal/gc/main.go:332 +0x13aa fp=0xc000739f20 sp=0xc000739a88 pc=0xcc86aa -main.main() - /usr/lib/go/src/cmd/compile/main.go:57 +0xdd fp=0xc000739f80 sp=0xc000739f20 pc=0xcf00bd -runtime.main() - /usr/lib/go/src/runtime/proc.go:250 +0x207 fp=0xc000739fe0 sp=0xc000739f80 pc=0x43b2e7 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000739fe8 sp=0xc000739fe0 pc=0x46e201 - -goroutine 2 [force gc (idle)]: -runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009cfb0 sp=0xc00009cf90 pc=0x43b716 -runtime.goparkunlock(...) - /usr/lib/go/src/runtime/proc.go:387 -runtime.forcegchelper() - /usr/lib/go/src/runtime/proc.go:305 +0xb0 fp=0xc00009cfe0 sp=0xc00009cfb0 pc=0x43b550 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009cfe8 sp=0xc00009cfe0 pc=0x46e201 -created by runtime.init.6 - /usr/lib/go/src/runtime/proc.go:293 +0x25 - -goroutine 3 [GC sweep wait]: -runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009d780 sp=0xc00009d760 pc=0x43b716 -runtime.goparkunlock(...) - /usr/lib/go/src/runtime/proc.go:387 -runtime.bgsweep(0x0?) - /usr/lib/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc00009d7c8 sp=0xc00009d780 pc=0x425cce -runtime.gcenable.func1() - /usr/lib/go/src/runtime/mgc.go:178 +0x26 fp=0xc00009d7e0 sp=0xc00009d7c8 pc=0x41aee6 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009d7e8 sp=0xc00009d7e0 pc=0x46e201 -created by runtime.gcenable - /usr/lib/go/src/runtime/mgc.go:178 +0x6b - -goroutine 4 [GC scavenge wait]: -runtime.gopark(0xc0000380e0?, 0xf1ad58?, 0x1?, 0x0?, 0x0?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009df70 sp=0xc00009df50 pc=0x43b716 -runtime.goparkunlock(...) - /usr/lib/go/src/runtime/proc.go:387 -runtime.(*scavengerState).park(0x1487ce0) - /usr/lib/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc00009dfa0 sp=0xc00009df70 pc=0x423c13 -runtime.bgscavenge(0x0?) - /usr/lib/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc00009dfc8 sp=0xc00009dfa0 pc=0x4241e5 -runtime.gcenable.func2() - /usr/lib/go/src/runtime/mgc.go:179 +0x26 fp=0xc00009dfe0 sp=0xc00009dfc8 pc=0x41ae86 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009dfe8 sp=0xc00009dfe0 pc=0x46e201 -created by runtime.gcenable - /usr/lib/go/src/runtime/mgc.go:179 +0xaa - -goroutine 17 [finalizer wait]: -runtime.gopark(0x43ba92?, 0x4027d38828?, 0x0?, 0x0?, 0xc00009c770?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009c628 sp=0xc00009c608 pc=0x43b716 -runtime.runfinq() - /usr/lib/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00009c7e0 sp=0xc00009c628 pc=0x419f27 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009c7e8 sp=0xc00009c7e0 pc=0x46e201 -created by runtime.createfing - /usr/lib/go/src/runtime/mfinal.go:163 +0x45 - -goroutine 5 [runnable]: -runtime.asyncPreempt2() - /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc000194658 sp=0xc000194638 pc=0x439e1f -runtime.asyncPreempt() - /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0001947e0 sp=0xc000194658 pc=0x46f85b -cmd/compile/internal/ssagen.(*state).stmt(0xc0001fe500, {0xf2a400, 0xc000a990a0?}) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1432 +0xbb fp=0xc000194b68 sp=0xc0001947e0 pc=0xaf509b -cmd/compile/internal/ssagen.(*state).stmtList(...) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421 -cmd/compile/internal/ssagen.buildssa(0xc0005d9540, 0x2) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:552 +0x1ee6 fp=0xc000194ea8 sp=0xc000194b68 pc=0xaf03e6 -cmd/compile/internal/ssagen.Compile(0xc0005d9540, 0x0?) - /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc000194f70 sp=0xc000194ea8 pc=0xae796c -cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc000194fb0 sp=0xc000194f70 pc=0xcc681a -cmd/compile/internal/gc.compileFunctions.func3.1() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc000194fe0 sp=0xc000194fb0 pc=0xcc6c52 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000194fe8 sp=0xc000194fe0 pc=0x46e201 -created by cmd/compile/internal/gc.compileFunctions.func3 - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 - -goroutine 33 [select]: -runtime.gopark(0xc0000997b0?, 0x2?, 0xf0?, 0x95?, 0xc00009976c?) - /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0000995a0 sp=0xc000099580 pc=0x43b716 -runtime.selectgo(0xc0000997b0, 0xc000099768, 0xc000110000?, 0x0, 0xd26040?, 0x1) - /usr/lib/go/src/runtime/select.go:327 +0x7be fp=0xc0000996e0 sp=0xc0000995a0 pc=0x44b8be -cmd/compile/internal/gc.compileFunctions.func3() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:141 +0x132 fp=0xc0000997e0 sp=0xc0000996e0 pc=0xcc6a12 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000997e8 sp=0xc0000997e0 pc=0x46e201 -created by cmd/compile/internal/gc.compileFunctions - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:134 +0xf8 - -goroutine 22 [runnable]: -runtime.asyncPreempt2() - /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0000ad2d0 sp=0xc0000ad2b0 pc=0x439e1f -runtime.asyncPreempt() - /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0000ad458 sp=0xc0000ad2d0 pc=0x46f85b -cmd/compile/internal/ssagen.(*state).stmt(0xc0016ada00, {0xf295c0, 0xc00134d450?}) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1455 +0x19a fp=0xc0000ad7e0 sp=0xc0000ad458 pc=0xaf517a -cmd/compile/internal/ssagen.(*state).stmtList(...) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421 -cmd/compile/internal/ssagen.(*state).stmt(0xc0016ada00, {0xf29800, 0xc0013eebc0?}) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1441 +0x45e5 fp=0xc0000adb68 sp=0xc0000ad7e0 pc=0xaf95c5 -cmd/compile/internal/ssagen.(*state).stmtList(...) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421 -cmd/compile/internal/ssagen.buildssa(0xc0005d8b40, 0x3) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:552 +0x1ee6 fp=0xc0000adea8 sp=0xc0000adb68 pc=0xaf03e6 -cmd/compile/internal/ssagen.Compile(0xc0005d8b40, 0x0?) - /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0000adf70 sp=0xc0000adea8 pc=0xae796c -cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0000adfb0 sp=0xc0000adf70 pc=0xcc681a -cmd/compile/internal/gc.compileFunctions.func3.1() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0000adfe0 sp=0xc0000adfb0 pc=0xcc6c52 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000adfe8 sp=0xc0000adfe0 pc=0x46e201 -created by cmd/compile/internal/gc.compileFunctions.func3 - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 - -goroutine 49 [runnable]: -runtime.asyncPreempt2() - /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0017932d0 sp=0xc0017932b0 pc=0x439e1f -runtime.asyncPreempt() - /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc001793458 sp=0xc0017932d0 pc=0x46f85b -cmd/compile/internal/ssagen.(*state).stmt(0xc001794000, {0xf295c0, 0xc00140a960?}) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1455 +0x19a fp=0xc0017937e0 sp=0xc001793458 pc=0xaf517a -cmd/compile/internal/ssagen.(*state).stmtList(...) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421 -cmd/compile/internal/ssagen.(*state).stmt(0xc001794000, {0xf2a400, 0xc000a92a10?}) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1436 +0x150 fp=0xc001793b68 sp=0xc0017937e0 pc=0xaf5130 -cmd/compile/internal/ssagen.(*state).stmtList(...) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421 -cmd/compile/internal/ssagen.buildssa(0xc0005d9680, 0x0) - /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:552 +0x1ee6 fp=0xc001793ea8 sp=0xc001793b68 pc=0xaf03e6 -cmd/compile/internal/ssagen.Compile(0xc0005d9680, 0x0?) - /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc001793f70 sp=0xc001793ea8 pc=0xae796c -cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc001793fb0 sp=0xc001793f70 pc=0xcc681a -cmd/compile/internal/gc.compileFunctions.func3.1() - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc001793fe0 sp=0xc001793fb0 pc=0xcc6c52 -runtime.goexit() - /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc001793fe8 sp=0xc001793fe0 pc=0x46e201 -created by cmd/compile/internal/gc.compileFunctions.func3 - /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 -``` -Steps to reproduce: -1. Create an Arch Linux chroot from a bootstrap tarball: https://wiki.archlinux.org/title/Install_Arch_Linux_from_existing_Linux#Method_A:_Using_the_bootstrap_tarball_(recommended) -2. Chroot into it using the following script: -``` -#!/bin/bash - -basedir="/home/niko/chroots/arch-x86_64" -cp /etc/resolv.conf ${basedir}/etc/ -cp /usr/bin/qemu-x86_64 ${basedir}/usr/bin/ -sed -i 's!#Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$arch!Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$a> -mount --make-slave --bind ${basedir} ${basedir} -mount -t proc none ${basedir}/proc -mount -t sysfs none ${basedir}/sys/ -mount --make-rslave --rbind /dev ${basedir}/dev -mount --make-rslave --rbind /run ${basedir}/run -chroot ${basedir} /bin/bash -sleep 3 -umount -R ${basedir}/run -umount -R ${basedir}/dev -umount ${basedir}/sys -umount ${basedir}/proc -umount ${basedir} -mount | grep chroots | grep arch-x86_64 | grep -v snap -``` -3. Initialize pacaman keyring and update system: -``` -# pacman-key --init -# pacman-key --populate -# pacman -Syu -``` -4. Download the yay `PKGBUILD` from the AUR (https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=yay) and run `makepkg -s` -5. Wait for the crash. -Additional information: -``` -Wed 2023-02-15 17:03:22 CET 495600 1000 1000 SIGILL present /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 > -Wed 2023-02-15 17:11:25 CET 509058 1000 1000 SIGSEGV present /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 > -talos2 ~ # coredumpctl gdb 495600 - PID: 495600 (go) - UID: 1000 (niko) - GID: 1000 (niko) - Signal: 4 (ILL) - Timestamp: Wed 2023-02-15 17:03:21 CET (13min ago) - Command Line: /usr/bin/qemu-x86_64 /usr/bin/go build -trimpath -mod=readonly -modcacherw -ldflags $'-X "main.yayVersion=11.3.2" -X "main.localePath=/usr/share/locale/" -linkmode=external' -buildmode=pie -o yay - Executable: /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 - Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope - Unit: user@1000.service - User Unit: vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope - Slice: user-1000.slice - Owner UID: 1000 (niko) - Boot ID: 33cad872d21043ebbe3dd6581bdd28c6 - Machine ID: b3e834569b8ff461391f5ac061feb773 - Hostname: talos2 - Storage: /var/lib/systemd/coredump/core.go.1000.33cad872d21043ebbe3dd6581bdd28c6.495600.1676477001000000.zst (present) - Size on Disk: 7.4M - Message: Process 495600 (go) of user 1000 dumped core. - -GNU gdb (Gentoo 12.1 vanilla) 12.1 -Copyright (C) 2022 Free Software Foundation, Inc. -License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> -This is free software: you are free to change and redistribute it. -There is NO WARRANTY, to the extent permitted by law. -Type "show copying" and "show warranty" for details. -This GDB was configured as "powerpc64le-unknown-linux-gnu". -Type "show configuration" for configuration details. -For bug reporting instructions, please see: -<https://bugs.gentoo.org/>. -Find the GDB manual and other documentation resources online at: - <http://www.gnu.org/software/gdb/documentation/>. - -For help, type "help". -Type "apropos word" to search for commands related to "word"... -Reading symbols from /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64... -BFD: warning: /var/tmp/coredump-8CHpqc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000002 -BFD: warning: /var/tmp/coredump-8CHpqc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001 -BFD: warning: /var/tmp/coredump-8CHpqc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002 - -warning: Can't open file /usr/lib/ld-linux-x86-64.so.2 during file-backed mapping note processing - -warning: Can't open file /usr/lib/libresolv.so.2 during file-backed mapping note processing - -warning: Can't open file /usr/lib/libc.so.6 during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/f2/f2133743f1bb49d82c152c57fea6c71755a865029a19ff845dd27e420f5fa0be-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/89/89e115246dee235465b64002c5ab8a7df3a3f1b776d78dab9cd937c4892860a0-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/79/791d1887c70eed91dc52577c14310590649cb307ef557d46d8cc10df4704a957-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/86/86d5a3a0121a98ed0805aa57bc14d0bd85178c04054816d99495336d86c5bf5f-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/31/31d19f3051c8985f29f85ea43d9445e4b848c58a17a79d4e726280a9bced5743-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/79/79d75d9215f18cbef6b6a66468f78efd92edc13f7093f600b1552032732410aa-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/bc/bcdca8f344789eb190a1124fe919aa975d08f07250bfc6d780b0ae0cc28092fe-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/86/86e73e7b053ab6e1e1d149b5d1bbba621bfc3d0bbc66ec6310c072c82a7221e7-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/b1/b12eb8399331175352cb92b971280ba5c0c501c6ffa5c330921c3c0667c5f199-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/32/3264d3f95a5e2e731c952060b0cd4cb3bc37ff884513397336d40c935d098e5b-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/19/1977592d2d60e1dd1025609428d04f6cc17283759aae0c97bd8f35e8a341679b-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/a9/a9b261a012c19401c1fd78154a20f58bb7778e731e17f903eb3fe8ed3a5ddd59-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/96/9697f94a563c1bd04db2a82ac1770821f97548911f616dd1149bb87d0f48d65b-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/56/56e54c1dc0b6bee517915ce0bdf694a3b94f4de88b2cabb987b645e1255594fb-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/7e/7e9d9d14f25fe76951999c17680e09a181c5f14c9c4f30fe6bff8d0d669590c3-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/f4/f431652315a861a2a85b47ae12cfc99734b3db4754aa35c9158254e4ba3507c0-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/1c/1c51052ad1af6b1a1575f9bbc3f4616ed673578a285ae9a29f5548eed68c05dd-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/be/be3037525f021f1d7e2e8499d3dcc0f44be39adf70eb91979c96db3e5645bcf1-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/55/557fa6c4030abc2d7b6407ce3093ae5772939f1a2595be09dd670ecd1c5ec8f2-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/69/69a73f1b9f395cf4a1666dde8d7971a0bd9313fbfa55a5109eb02e59b301be09-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/ab/abc0750a5bd45b2346aa5bc87092f67207e9436307e3e32cb470952f87d13fb6-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/da/dadc71547f56ab68eccefd0d571599f99739a3d75acc444d97829d6ab62a6922-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/91/915619420aacc3b5964e7537365661258ab52ec44fb7ab29790258822c793de5-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/68/6834d594cb4ffe53979a0c4611bb5200e6e0c580acb42f4383ed2fb6a93d758d-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/c6/c6ccbc76ef432925fc1a5ea22ab750ac591f3e8983d2f33f54b01c799e3a274d-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/89/893c62418d079bf692b5ff17db226ae3d0fefdc87cbd0c64f30c437677a288ec-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/d8/d8666c5d7807c5a08b30f2278a1efd691c188804b3090704bd0b3f8ef06c40d9-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/d4/d401ca16783c19ff776f35305023173b63e2610e313b9a793734af80afda4e83-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/d0/d0593989dbf79e26b8bf6705325c6b44044e560a22c3ab81d320c67dcd97f1eb-d during file-backed mapping note processing - -warning: Can't open file /home/niko/.cache/go-build/57/572953ae015634b922f88b0191804a949206100adb6bd2454db615e2774dbe30-d during file-backed mapping note processing - -warning: Can't open file /usr/lib/libnss_mymachines.so.2 during file-backed mapping note processing - -warning: Can't open file /usr/lib/libcap.so.2.67 during file-backed mapping note processing - -warning: Can't open file /usr/lib/libgcc_s.so.1 during file-backed mapping note processing - -warning: Can't open file /usr/lib/libnss_resolve.so.2 during file-backed mapping note processing - -warning: Can't open file /usr/lib/libm.so.6 during file-backed mapping note processing - -warning: Can't open file /usr/lib/libnss_myhostname.so.2 during file-backed mapping note processing - -warning: core file may not match specified executable file. -[New LWP 495627] -[New LWP 495604] -[New LWP 495603] -[New LWP 495614] -[New LWP 495602] -[New LWP 495610] -[New LWP 495618] -[New LWP 495606] -[New LWP 495621] -[New LWP 495608] -[New LWP 495612] -[New LWP 495629] -[New LWP 495615] -[New LWP 495622] -[New LWP 495600] -[New LWP 495605] -[New LWP 495623] -[New LWP 495630] -[New LWP 495616] -[New LWP 495633] -[New LWP 495634] -[New LWP 495635] -[New LWP 495636] -[New LWP 495637] -[New LWP 495632] -[New LWP 495609] -[New LWP 495620] -[New LWP 495617] -[New LWP 495624] -[New LWP 495628] -[New LWP 495625] -[New LWP 495607] -[New LWP 495613] -[New LWP 495626] -[New LWP 495619] -[New LWP 495611] -[New LWP 495631] -[Thread debugging using libthread_db enabled] -Using host libthread_db library "/usr/lib64/libthread_db.so.1". -Core was generated by `/usr/bin/qemu-x86_64 /usr/bin/go build -trimpath -mod=readonly -modcacherw -ldf'. -Program terminated with signal SIGILL, Illegal instruction. -#0 0x00003fff9d5d7284 in code_gen_buffer () -[Current thread is 1 (Thread 0x3fff4bf3c380 (LWP 495627))] -(gdb) info threads - Id Target Id Frame -* 1 Thread 0x3fff4bf3c380 (LWP 495627) 0x00003fff9d5d7284 in code_gen_buffer () - 2 Thread 0x3fffa85ec380 (LWP 495604) 0x000000001029ba2c in __lll_lock_wait () - 3 Thread 0x3fffa862d380 (LWP 495603) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 4 Thread 0x3fffa8362380 (LWP 495614) 0x00000000100ef210 in tb_jmp_cache_get_tb (hash=3271, jc=0x3fff6c00c5c0) - at ../accel/tcg/tb-jmp-cache.h:38 - 5 Thread 0x3fffa8eaf380 (LWP 495602) 0x00000000102cf6ec in syscall () - 6 Thread 0x3fffa8466380 (LWP 495610) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 7 Thread 0x3fffa815d380 (LWP 495618) 0x00000000101e07c8 in g_hash_table_lookup () - 8 Thread 0x3fffa856a380 (LWP 495606) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 9 Thread 0x3fffa809a380 (LWP 495621) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 10 Thread 0x3fffa84e8380 (LWP 495608) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 11 Thread 0x3fffa83e4380 (LWP 495612) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 12 Thread 0x3fff4beba380 (LWP 495629) 0x00003fff9c1c84b8 in code_gen_buffer () - 13 Thread 0x3fffa8321380 (LWP 495615) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 14 Thread 0x3fffa86ae380 (LWP 495622) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 15 Thread 0x200f4000 (LWP 495600) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 16 Thread 0x3fffa85ab380 (LWP 495605) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 17 Thread 0x3fffa8059380 (LWP 495623) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 18 Thread 0x3fff4be79380 (LWP 495630) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 19 Thread 0x3fffa82e0380 (LWP 495616) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 20 Thread 0x3fff4bdb6380 (LWP 495633) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 21 Thread 0x3fff4bd75380 (LWP 495634) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 22 Thread 0x3fff4bd34380 (LWP 495635) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 23 Thread 0x3fff4bcf3380 (LWP 495636) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 24 Thread 0x3fff4bcb2380 (LWP 495637) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 25 Thread 0x3fff4bdf7380 (LWP 495632) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 26 Thread 0x3fffa84a7380 (LWP 495609) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 27 Thread 0x3fffa80db380 (LWP 495620) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 28 Thread 0x3fffa829f380 (LWP 495617) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 29 Thread 0x3fff4bfff380 (LWP 495624) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 30 Thread 0x3fff4befb380 (LWP 495628) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 31 Thread 0x3fff4bfbe380 (LWP 495625) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 32 Thread 0x3fffa8529380 (LWP 495607) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 33 Thread 0x3fffa83a3380 (LWP 495613) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 34 Thread 0x3fff4bf7d380 (LWP 495626) 0x00003fff9d5d7284 in code_gen_buffer () - 35 Thread 0x3fffa811c380 (LWP 495619) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 36 Thread 0x3fffa8425380 (LWP 495611) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 - 37 Thread 0x3fff4be38380 (LWP 495631) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 -(gdb) quit -talos2 ~ # coredumpctl gdb 509058 - PID: 509058 (make) - UID: 1000 (niko) - GID: 1000 (niko) - Signal: 11 (SEGV) - Timestamp: Wed 2023-02-15 17:11:24 CET (6min ago) - Command Line: /usr/bin/qemu-x86_64 /usr/bin/make VERSION=11.3.2 DESTDIR=/home/niko/devel/yay/pkg/yay PREFIX=/usr build - Executable: /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 - Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope - Unit: user@1000.service - User Unit: vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope - Slice: user-1000.slice - Owner UID: 1000 (niko) - Boot ID: 33cad872d21043ebbe3dd6581bdd28c6 - Machine ID: b3e834569b8ff461391f5ac061feb773 - Hostname: talos2 - Storage: /var/lib/systemd/coredump/core.make.1000.33cad872d21043ebbe3dd6581bdd28c6.509058.1676477484000000.zst (present) - Size on Disk: 1.0M - Message: Process 509058 (make) of user 1000 dumped core. - -GNU gdb (Gentoo 12.1 vanilla) 12.1 -Copyright (C) 2022 Free Software Foundation, Inc. -License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> -This is free software: you are free to change and redistribute it. -There is NO WARRANTY, to the extent permitted by law. -Type "show copying" and "show warranty" for details. -This GDB was configured as "powerpc64le-unknown-linux-gnu". -Type "show configuration" for configuration details. -For bug reporting instructions, please see: -<https://bugs.gentoo.org/>. -Find the GDB manual and other documentation resources online at: - <http://www.gnu.org/software/gdb/documentation/>. - -For help, type "help". -Type "apropos word" to search for commands related to "word"... -Reading symbols from /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64... -BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000002 -BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002 -BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001 -BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002 - -warning: Can't open file /usr/lib/ld-linux-x86-64.so.2 during file-backed mapping note processing - -warning: Can't open file /usr/lib/libguile-3.0.so.1.6.0 during file-backed mapping note processing - -warning: Can't open file /usr/lib/libc.so.6 during file-backed mapping note processing - -warning: Can't open file /usr/lib/libgc.so.1.5.1 during file-backed mapping note processing - -warning: Can't open file /usr/lib/libffi.so.8.1.2 during file-backed mapping note processing - -warning: Can't open file /usr/lib/libunistring.so.5.0.0 during file-backed mapping note processing - -warning: Can't open file /usr/lib/libgmp.so.10.4.1 during file-backed mapping note processing - -warning: Can't open file /usr/lib/libcrypt.so.2.0.0 during file-backed mapping note processing - -warning: Can't open file /usr/lib/libm.so.6 during file-backed mapping note processing - -warning: core file may not match specified executable file. -[New LWP 509058] -[New LWP 509060] -[Thread debugging using libthread_db enabled] -Using host libthread_db library "/usr/lib64/libthread_db.so.1". -Core was generated by `/usr/bin/qemu-x86_64 /usr/bin/make VERSION=11.3.2 DESTDIR=/home/niko/devel/yay/'. -Program terminated with signal SIGSEGV, Segmentation fault. -#0 0x0000000010278798 in sigsuspend () -[Current thread is 1 (Thread 0x1bde9000 (LWP 509058))] -(gdb) info threads - Id Target Id Frame -* 1 Thread 0x1bde9000 (LWP 509058) 0x0000000010278798 in sigsuspend () - 2 Thread 0x3fffae0ef380 (LWP 509060) 0x00000000102cf6ec in syscall () -(gdb) quit -``` - -Download coredumps: - -https://drive.google.com/file/d/1GosaobKvmuRg-olaA1-aZcp7zAZcWmcF/view?usp=share_link - -https://drive.google.com/file/d/1N0BmlBIYY-qT5lHqlrKXvPL_FdYl3GfI/view?usp=share_link diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1495 b/results/classifier/zero-shot-user-mode/output/instruction/1495 deleted file mode 100644 index 2a084bc38..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1495 +++ /dev/null @@ -1,12 +0,0 @@ -instruction: 0.765 -runtime: 0.155 -syscall: 0.080 - - - -MacOS fails check-unit for test-io-channel-command for some reason -Description of problem: -While adding the socat dependency to the CI system it triggers a failure on the ARM MacOS build, eg: https://gitlab.com/stsquad/qemu/-/jobs/3769189709 -Steps to reproduce: -1. install socat -2. make check-unit diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1519037 b/results/classifier/zero-shot-user-mode/output/instruction/1519037 deleted file mode 100644 index 2bdf8298d..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1519037 +++ /dev/null @@ -1,13 +0,0 @@ -instruction: 0.640 -syscall: 0.182 -runtime: 0.178 - - - -qemu-i386 32-bit segfault - -I'm getting segfaults on 32-bit linux trying to run binaries using qemu-i386 from git. These segfaults go away when run in gdb or strace - could it be about the environment somehow? - -In contrast qemu-x86_64 works fine. How can I pinpoint the cause of this? - -Thanks! \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1527765 b/results/classifier/zero-shot-user-mode/output/instruction/1527765 deleted file mode 100644 index c3a7dbcba..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1527765 +++ /dev/null @@ -1,78 +0,0 @@ -instruction: 0.417 -runtime: 0.349 -syscall: 0.235 - - - -sh4: ghc randomly segfaults on qemu-sh4-static - -Hello! - -I am currently in the process of bootstrapping ghc for the Debian sh4 port and ran into a strange problem with qemu-sh4-static which randomly segfaults when running ghc to compile a Haskell source: - -root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ls -Main.hi Main.hs Setup.hs ghc-pwd.cabal ghc.mk -root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs -/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) -qemu: uncaught target signal 11 (Segmentation fault) - core dumped -Segmentation fault -root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs -/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) -qemu: uncaught target signal 11 (Segmentation fault) - core dumped -Segmentation fault -root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs -/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) -qemu: uncaught target signal 11 (Segmentation fault) - core dumped -Segmentation fault -root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs -/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) -qemu: uncaught target signal 11 (Segmentation fault) - core dumped -Segmentation fault -root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs -/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) -[1 of 1] Compiling Main ( Main.hs, Main.o ) -qemu: uncaught target signal 11 (Segmentation fault) - core dumped -Segmentation fault -root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs -/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) -[1 of 1] Compiling Main ( Main.hs, Main.o ) -qemu: uncaught target signal 11 (Segmentation fault) - core dumped -Segmentation fault -root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs -/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) -[1 of 1] Compiling Main ( Main.hs, Main.o ) -Bad interface file: /usr/local/lib/sh4-unknown-linux-gnu-ghc-7.10.3/time/dist-install/build/Data/Time/Format/Parse.hi - ghc: panic! (the 'impossible' happened) - (GHC version 7.10.3 for sh4-unknown-linux): - getSymtabName:unknown known-key unique -<<details unavailable>> - -Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug - -root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs -/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) -[1 of 1] Compiling Main ( Main.hs, Main.o ) -Linking Main ... -root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# - -As seen above, compiling a Haskell source code often results in a segfault but simply by retrying to run ghc over and over again, the compile process will eventually succeed and no segfault occurs. - -I have created a tarball which contains the sh4 chroot from the example above which also includes ghc, gcc and the source code in question (in /root/ghc-7.8.4/utils/ghc-pwd). To test, it's probably a good idea to replace the qemu-sh4-static binary in /usr/bin with a current git snapshot (which I tried but didn't help). - -> http://users.physik.fu-berlin.de/~glaubitz/sid-sh4-sbuild-ghc.tgz - -In case anyone wants to try ghc with their own sh4 chroot, here's my version of ghc: - -> https://people.debian.org/~glaubitz/sh4-unknown-linux-gnu-ghc-7.10.3.tar.gz - -Just extract in the chroot of the sh4 chroot. - -Please note, that it might be advisable on sh4 to apply the patches from these two bug reports as otherwise qemu-sh4-static won't work properly on sh4 and misses syscall 186: - -> https://bugs.launchpad.net/ubuntu/+source/qemu-linaro/+bug/1254824 -> https://bugs.launchpad.net/qemu/+bug/1516408 - -The above issue is reproducible with the two patches applied and without. It's also reproducible with both libc6 2.19 and 2.21 in the chroot. Thus, I am currently out of ideas what else to test. - -Cheers, -Adrian \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1528 b/results/classifier/zero-shot-user-mode/output/instruction/1528 deleted file mode 100644 index 5ebb9679b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1528 +++ /dev/null @@ -1,15 +0,0 @@ -instruction: 0.567 -runtime: 0.293 -syscall: 0.141 - - - -ppc64le: qemu-arm: basic hello world fails with "user-exec.c:492: page_set_flags: Assertion `start < end' failed." -Description of problem: -Trying to utilize a RH8 enterprise POWER9 based server to build OpenBMC which utilizes qemu under the covers to validate cross compiles. After some debug, I found that a basic hello-world cross compiled application does not work on POWER9 hardware. -Steps to reproduce: -1. Create basic hello world .c file, cross compile it for arm (arm-linux-gnueabi-gcc hello.c -o hello) -2. Build latest qemu-arm from master -3. Run qemu-arm against hello world binary -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1528239 b/results/classifier/zero-shot-user-mode/output/instruction/1528239 deleted file mode 100644 index ed0bfdeb0..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1528239 +++ /dev/null @@ -1,51 +0,0 @@ -instruction: 0.422 -runtime: 0.310 -syscall: 0.268 - - - -Unable to debug PIE binaries with QEMU gdb stub. - -The issue occurs on current trunk: - -max@max:~/build/qemu$ cat test.c -#include <stdio.h> - -int main() { - printf("Hello, world!\n"); - return 0; -} - -max@max:~/build/qemu$ gcc test.c -fPIC -pie -o bad.x -max@max:~/build/qemu$ ./x86_64-linux-user/qemu-x86_64 -g 1234 bad.x -............................. - - -max@max:~/build/qemu$ gdb -GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 -........................................................................................ -(gdb) file bad.x -Reading symbols from bad.x...(no debugging symbols found)...done. -(gdb) b main -Breakpoint 1 at 0x779 -(gdb) target remote localhost:1234 -Remote debugging using localhost:1234 -Reading symbols from /lib64/ld-linux-x86-64.so.2...warning: the debug information found in "/lib64/ld-2.19.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch). - -Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.19.so...done. -done. -Loaded symbols for /lib64/ld-linux-x86-64.so.2 -Error in re-setting breakpoint 1: Cannot access memory at address 0x775 -Error in re-setting breakpoint 1: Cannot access memory at address 0x775 -0x0000004000a042d0 in _start () from /lib64/ld-linux-x86-64.so.2 -(gdb) c -Continuing. -[Inferior 1 (Remote target) exited normally] -(gdb) - - -max@max:~/build/qemu$ cat config.log -# Configured with: '/home/max/src/qemu/configure' '--prefix=/home/max/install/qemu' '--target-list=arm-linux-user,aarch64-linux-user,x86_64-linux-user' '--static' - - -W/O QEMU or -pie flag breakpoint on main works fine. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1531 b/results/classifier/zero-shot-user-mode/output/instruction/1531 deleted file mode 100644 index d27854f5b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1531 +++ /dev/null @@ -1,21 +0,0 @@ -instruction: 0.388 -runtime: 0.363 -syscall: 0.249 - - - -MIPSr6+MSA emulation is broken in QEMU 6.2.0 (Ubuntu 22.04 LTS) and 7.0.0 -Description of problem: -Many tests (8,11,12,13,15,19,23,30,31,36) are failing due to QEMU emulation problem. -Steps to reproduce: -1. Download the source code from https://github.com/VectorChief/UniSIMD-assembler (master or v1.1.0c) -2. Change to project's test directory and build the binary for MIPS using cross-compiler (see simd_make_m64.mk) -3. Run the binary with QEMU linux-user mode: qemu-mips64el -cpu I6400 simd_test.m64f32Lr6 -c 1 | tee qemu64 -4. Check the output text file qemu64 (with pluma or any other text editor) to see the error printouts -Additional information: -The pre-built binary and its output file are attached as test.tar.gz -[test.tar.gz](/uploads/7a54ba10919a1b221dd8ea0e8c02c064/test.tar.gz) - -Please note, that standalone cross-compiler for MIPS downloaded from the site -(Codescape.GNU.Tools.Package.2020.06-01.for.MIPS.MTI.Linux.CentOS-6.x86_64.tar.gz) -comes with its own version of QEMU 4.1.0 which masks the system's QEMU when added to the PATH. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1533141 b/results/classifier/zero-shot-user-mode/output/instruction/1533141 deleted file mode 100644 index 990465d47..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1533141 +++ /dev/null @@ -1,21 +0,0 @@ -instruction: 0.494 -runtime: 0.309 -syscall: 0.196 - - - -qemu/disas/libvixl/vixl/invalset.h: 2 * sanity check after use ? - -1. - -[qemu/disas/libvixl/vixl/invalset.h:442]: (style) Array index 'low' is used before limits check. - - while (!IsValid(elements[low]) && (low < high)) ++low; - -2. - -[qemu/disas/libvixl/vixl/invalset.h:450]: (style) Array index 'middle' is used before limits check. - - while (!IsValid(elements[middle]) && (middle < high - 1)) ++middle; - -Also, binary search is a standard C library routine. Suggest use. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1536 b/results/classifier/zero-shot-user-mode/output/instruction/1536 deleted file mode 100644 index c142caf14..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1536 +++ /dev/null @@ -1,22 +0,0 @@ -instruction: 0.449 -syscall: 0.292 -runtime: 0.258 - - - -Test programs that use the vextractbm, vextracthm, vextractwm, or vextractdm instructions fail on qemu-ppc64 (but not qemu-ppc64le) -Description of problem: -Some of the test programs that use the vextractbm, vextracthm, vextractwm, or vextractdm instructions fail on qemu-ppc64 (but not qemu-ppc64le). -Steps to reproduce: -1. Download the vsx_mask_extract_runnable_test_030723.c test program from https://gist.githubusercontent.com/johnplatts/db0e9f6683e85e9288fde5c031b3c0e5/raw/ccfb8170f3e613398750830451eebb362875493d/vsx_mask_extract_runnable_test_030723.c. -2. Install the ppc64 gcc cross-compiler and required libraries, which can be done using the ```sudo apt install build-essential gdb-multiarch g++-12-powerpc64-linux-gnu binutils-powerpc64-linux-gnu binutils-powerpc64-linux-gnu-dbg libc6-ppc64-cross libstdc++6-ppc64-cross``` command on Ubuntu 22.04. -3. Compile the vsx_mask_extract_runnable_test_030723.c test program downloaded in step 1 using the ```powerpc64-linux-gnu-gcc-12``` cross-compiler with the ```-mcpu=power10``` option. -4. Execute the program compiled in step 3 using the ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu qemu-ppc64 -cpu power10 ./vsx_mask_extract_runnable_test_030723``` command. - -The issue can also be reproduced by compiling Google Highway and running its unit tests as follows: -1. Clone the Google Highway git repository by running the ```git clone https://github.com/google/highway.git google_highway``` command. -2. Create a ```hwy_ppcbe10_build``` directory inside of the ```google_highway``` directory created in step #1. -3. In the ```hwy_ppc10be_build``` directory created in the previous step, execute the following commands: - - ```CC=powerpc64-linux-gnu-gcc-12 CXX=powerpc64-linux-gnu-g++-12 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER_TARGET="powerpc64-linux-gnu" -DCMAKE_CXX_COMPILER_TARGET="powerpc64-linux-gnu" -DCMAKE_CROSSCOMPILING=true -DCMAKE_CROSSCOMPILING_EMULATOR='/usr/local/bin/qemu-ppc64;-cpu;power10' -DCMAKE_C_FLAGS='-mcpu=power10 -DHWY_DISABLED_TARGETS=6918373452571213824' -DCMAKE_CXX_FLAGS='-mcpu=power10 -DHWY_DISABLED_TARGETS=6918373452571213824'``` - - ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu make``` - - ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ctest -j``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1541 b/results/classifier/zero-shot-user-mode/output/instruction/1541 deleted file mode 100644 index 25ba6f4e0..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1541 +++ /dev/null @@ -1,38 +0,0 @@ -instruction: 0.460 -runtime: 0.288 -syscall: 0.251 - - - -Invalid position of G_NORETURN in clang v15 -Description of problem: -Order of `G_NORETURN` used in https://gitlab.com/qemu-project/qemu/-/blob/0f3de970febd2c9b29dccecb63ca928c6802a101/include/qemu/osdep.h#L240-242 is not valid in clang++ 15.0.7. - -Switching `extern` with `G_NORETURN` seems to fix the issue. -Steps to reproduce: -1. Build qemu system for MIPSEL or use minimal reproducer: - -`example.cpp`: -``` -#include "/path/to/qemu/include/glib-compat.h" - -extern G_NORETURN -void // QEMU_ERROR("code path is reachable") - qemu_build_not_reached_always(void); -``` - -``` -$ clang++ --version -clang version 15.0.7 -Target: x86_64-pc-linux-gnu -Thread model: posix -InstalledDir: /usr/bin -$ clang++ -m64 -mcx16 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu++11 -O0 -g example.cpp -example.cpp:3:8: error: an attribute list cannot appear here -extern G_NORETURN - ^~~~~~~~~~ -/usr/include/glib-2.0/glib/gmacros.h:1075:21: note: expanded from macro 'G_NORETURN' -# define G_NORETURN [[noreturn]] - ^~~~~~~~~~~~ -1 error generated. -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1547 b/results/classifier/zero-shot-user-mode/output/instruction/1547 deleted file mode 100644 index 656dd3aad..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1547 +++ /dev/null @@ -1,18 +0,0 @@ -instruction: 0.557 -runtime: 0.306 -syscall: 0.137 - - - -POWER9 emulation is broken when compiler optimizations are on (for gcc 11.3 and later) -Description of problem: -Comparing two floating point memory operands produces incorrect result -Steps to reproduce: -1. Unpack attached archive and change to test_p64 directory -2. Build the source file with: powerpc64le-linux-gnu-g++ -O2 -static test.cpp -o test_p64 -3. Run with QEMU: qemu-ppc64le -cpu POWER9 test_p64 > output.txt -4. Check the output text file output.txt (with pluma or any other text editor) to see the printouts -Additional information: -The pre-built binary and its output file are attached as test_p64.tar.gz[test_p64.tar.gz](/uploads/0e9dbc22e6841496efc15775e6aa624a/test_p64.tar.gz) - -The purpose of this report is to motivate the creation of a point release QEMU 6.2.1 for Ubuntu 22.04 LTS (which will be supported for years to come). Also cross-linking similar bug report for MIPS with exact same goal: https://gitlab.com/qemu-project/qemu/-/issues/1531 diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1553 b/results/classifier/zero-shot-user-mode/output/instruction/1553 deleted file mode 100644 index e775511df..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1553 +++ /dev/null @@ -1,18 +0,0 @@ -instruction: 0.681 -runtime: 0.165 -syscall: 0.154 - - - -Build error: implicit declaration of function 'qemu_close_to_socket' -Description of problem: -When build the latest master code with MSYS2 on Windows 10, GCC reports: -../ui/spice-core.c: In function 'watch_remove': -../ui/spice-core.c:152:5: error: implicit declaration of function 'qemu_close_to_socket' [-Werror=implicit-function-declaration] - 152 | qemu_close_to_socket(watch->fd); - | ^~~~~~~~~~~~~~~~~~~~ -../ui/spice-core.c:152:5: error: nested extern declaration of 'qemu_close_to_socket' [-Werror=nested-externs] -Steps to reproduce: -1. ./configure --enable-sdl --enable-gtk --target-list=arm-softmmu,aarch64-softmmu -2. cd build -3. make diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1563612 b/results/classifier/zero-shot-user-mode/output/instruction/1563612 deleted file mode 100644 index 0c5fd5910..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1563612 +++ /dev/null @@ -1,56 +0,0 @@ -instruction: 0.493 -runtime: 0.271 -syscall: 0.236 - - - -pulseaudio applications crash under linux-user-x86_64 - -Running a simple application that uses pulseaudio under qemu-i386 or qemu-x86_64 makes it crash (tested on Debian 8.0): - -# apt-get install build-essential qemu-user libpulse-dev pulseaudio -$ cat > test.c << __EOF -#include <pulse/simple.h> - -int main(void) { - pa_simple *s; - pa_sample_spec ss; - ss.format = PA_SAMPLE_S16NE; - ss.channels = 2; - ss.rate = 44100; - s = pa_simple_new(NULL, // Use the default server. - "Fooapp", // Our application's name. - PA_STREAM_PLAYBACK, - NULL, // Use the default device. - "Music", // Description of our stream. - &ss, // Our sample format. - NULL, // Use default channel map - NULL, // Use default buffering - // attributes. - NULL // Ignore error code. - ); - - int16_t buf[2 * 1000]; - int i; - memset(buf, 0, sizeof buf); - for (i = 0; i < 44; i++) { - pa_simple_write(s, buf, sizeof buf, NULL); - } - - pa_simple_free(s); - - return 0; -} -__EOF -$ gcc test.c -o test -lpulse -lpulse-simple -$ ./test -<no output, no error> -$ qemu-x86_64 ./test -qemu: uncaught target signal 11 (Segmentation fault) - core dumped -Segmentation fault -$ - - -I think this is related to the futex system call. In an attempt to debug the problem, I compiled pulseaudio in debug mode and it hit an assertion failure in pa_mutex_unlock. - -Thank you for developing QEMU. :-) \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1568107 b/results/classifier/zero-shot-user-mode/output/instruction/1568107 deleted file mode 100644 index 0a8f34f78..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1568107 +++ /dev/null @@ -1,15 +0,0 @@ -instruction: 0.626 -runtime: 0.250 -syscall: 0.124 - - - -x86_64 linux-user: setup_rt_frame: not implemented - -Trying to run this binary (https://github.com/ethcore/parity/releases/download/v1.0.1/parity_linux_1.0.1-0_amd64.deb) under qemu-x86_64 on ARM, ends like this: - -$ qemu-x86_64 parity --pruning fast - -setup_rt_frame: not implemented -qemu: uncaught target signal 11 (Segmentation fault) - core dumped -Segmentation fault \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1574346 b/results/classifier/zero-shot-user-mode/output/instruction/1574346 deleted file mode 100644 index 86ada75ab..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1574346 +++ /dev/null @@ -1,18 +0,0 @@ -instruction: 0.805 -runtime: 0.102 -syscall: 0.093 - - - -TCG: mov to segment register is incorrectly emulated for AMD CPUs - -In TCG mode, the effect of: - -xorl %eax, %eax -movl %eax, %gs - -is to mark the GS segment unusable and set its base to zero. After doing this, reading MSR_GS_BASE will return zero and using a GS prefix in long mode will treat the GS base as zero. - -This is correct for Intel CPUs but is incorrect for AMD CPUs. On an AMD CPU, writing 0 to %gs using mov, pop, or (I think) lgs will leave the base unchanged. - -To make it easier to use TCG to validate behavior on different CPUs, please consider changing the TCG behavior to match actual CPU behavior when emulating an AMD CPU. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1585840 b/results/classifier/zero-shot-user-mode/output/instruction/1585840 deleted file mode 100644 index ac3638ca5..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1585840 +++ /dev/null @@ -1,15 +0,0 @@ -instruction: 0.464 -runtime: 0.396 -syscall: 0.141 - - - -multiprocess program gets incorrect results with qemu arm-linux-user - -The attached program can run either in a threaded mode or a multiprocess mode. It defaults to threaded mode, and switches to multiprocess mode if the first positional argument is "process". "success" of the test is defined as the final count being seen as 2000000 by both tasks. - -In standard linux x86_64 userspace (i7, 4 cores) and in standard armhf userspace (4 cores), the test program consistently completes successfully in both modes. But with qemu arm-linux-user, the test consistently succeeds in threaded mode and generally fails in multiprocess mode. - -The test reflects an essential aspect of how the Free and Open Source project linuxcnc's IPC system works: shared memory regions (created by shmat, but mmap would probably behave the same) contain data and mutexes. I observed that our testsuite encounters numerous deadlocks and failures when running in an schroot with qemu-user (x86_64 host), and I believe the underlying cause is improper support for atomic operations in a multiprocess model. (the testsuite consistently passes on real hardware) - -I observed the same failure at v1.6.0 and master (v2.6.0-424-g287db79), as well as in the outdated Debian version 1:2.1+dfsg-12+deb8u5a. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1590336 b/results/classifier/zero-shot-user-mode/output/instruction/1590336 deleted file mode 100644 index 4bdc195af..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1590336 +++ /dev/null @@ -1,21 +0,0 @@ -instruction: 0.856 -syscall: 0.075 -runtime: 0.068 - - - -qemu-arm does not reject vrintz on non-v8 cpu - -Hello, - -It seems that qemu-arm does not reject some v8-only instructions as it should, but executes them "correctly". - -For instance, while compiling/running some of the GCC ARM instrinsics tests, we noticed that -vrintz should be rejected on cortex-a9 for instance, while it is executed as if the instruction was supported. - -objdump says: - 1074c: f3fa05a0 vrintz.f32 d16, d16 -and qemu -d in_asm says: -0x0001074c: f3fa05a0 vabal.u<illegal width 64> q8, d26, d16 - -The problem is still present in qemu-2.6.0 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1591611 b/results/classifier/zero-shot-user-mode/output/instruction/1591611 deleted file mode 100644 index d1b061ea1..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1591611 +++ /dev/null @@ -1,29 +0,0 @@ -instruction: 0.525 -runtime: 0.277 -syscall: 0.198 - - - -chroot using qemu-x86_64-static fails on ppc64el - -When attempting to use qemu-x86_64-static from qemu 2.5.0 on a ppc64el host to chroot into an amd64 environment, all commands fail with an assertion error. /usr/bin/qemu-x86_64-static from the host was copied into the chroot /usr/bin, and the host has multiformat support in the kernel. - -Sample output illustrating the problem, as well as bash builtins working: - -# chroot /virtualbox/scratchdisks_local_001/amd64_chroot qemu-x86_64-static /bin/bash -# ls -bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed. -setup_frame: not implemented -setup_frame: not implemented -qemu: uncaught target signal 11 (Segmentation fault) - core dumped -Segmentation fault -setup_frame: not implemented -setup_frame: not implemented -# echo TEST -TEST -# cat test -bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed. -qemu: uncaught target signal 11 (Segmentation fault) - core dumped -Segmentation fault - -It is currently unknown if other host architectures (e.g. aarch64) are also affected. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1593 b/results/classifier/zero-shot-user-mode/output/instruction/1593 deleted file mode 100644 index 5b22b3651..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1593 +++ /dev/null @@ -1,13 +0,0 @@ -instruction: 0.547 -runtime: 0.253 -syscall: 0.200 - - - -SLIRP hostfwd ignores bind address and uses `INADDR_ANY` -Description of problem: -When using `-netdev hostfwd=`..., qemu SLIRP uses `INADDR_ANY` instead of any bind address provided by the user. As a result, even if the user specifies to listen only on localhost (e.g. `-netdev user,hostfwd=tcp:127.0.0.1:22-:22`), qemu will listen on `*.*`. This is a potential security issue (as it may unexpectedly expose the guest to internet or local network traffic). -Additional information: -The bug is here: https://gitlab.com/qemu-project/qemu/-/blob/master/net/slirp.c#L777 - -Rather than hardcoding `INADDR_ANY`, qemu should respect the user-defined bind address. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1594069 b/results/classifier/zero-shot-user-mode/output/instruction/1594069 deleted file mode 100644 index 2189df998..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1594069 +++ /dev/null @@ -1,14 +0,0 @@ -instruction: 0.888 -syscall: 0.057 -runtime: 0.055 - - - -SIMD instructions translated to scalar host instructions - -SIMD instructions inside the guest (NEON, MMX, SSE, SSE2, AVX) are translated to scalar instructions on the host instead of SIMD instructions. It appears that there have been a few efforts to rectify this [1], and even a submitted patch series, but all discussion has effectively died out [2]. - -I would like to see better SIMD performance on qemu, especially as non-x86 architectures are becoming widely used (e.g. ARM). - -[1] http://dl.acm.org/citation.cfm?id=2757098&dl=ACM&coll=DL&CFID=633095244&CFTOKEN=12352103 -[2] https://lists.nongnu.org/archive/html/qemu-devel/2014-10/msg01720.html \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1603734 b/results/classifier/zero-shot-user-mode/output/instruction/1603734 deleted file mode 100644 index 1791c4e33..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1603734 +++ /dev/null @@ -1,13 +0,0 @@ -instruction: 0.613 -runtime: 0.276 -syscall: 0.111 - - - -Hang in fsqrt - -At least qemu-i368 and qemu-x86_64 hang in floatx80_sqrt in versions 2.6.0 and git (2.6.50) for some input values, likely due to an infinite loop at fpu/softfloat.c:6569. - -Steps to reproduce: -1) Compile attached code: gcc -o test test.c -lm -2) `qemu-i368 test` and `qemu-x86_64 test` will hang at 100% cpu \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1605123 b/results/classifier/zero-shot-user-mode/output/instruction/1605123 deleted file mode 100644 index 65efd45f5..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1605123 +++ /dev/null @@ -1,34 +0,0 @@ -instruction: 0.750 -runtime: 0.167 -syscall: 0.082 - - - -PEXT returns wrong values, seemingly switches arguments - -Hi, - -I fiddled with BMI2 instructions and discovered that pext instructions -emulated with "qemu-x86_64 -cpu Haswell" return the wrong value. It -seemingly switches up its arguments. I suspect that the error is around the -gen_helper_pext(...) call in target-i386/translate.c. I checked helper_pext -in target-i386/int_helper.c and it works fine. - -I ran my program on a CPU with BMI2 instruction set too, and it indeed -returns different values. - -I didn't check pdep, it could have the same problem. - -$ qemu-x86_64 --version -qemu-x86_64 version 2.6.50 (v2.6.0-2095-ge66b05e-dirty), Copyright (c) 2003-2008 Fabrice Bellard - -$ uname -a -Linux lenard-hp 4.3.0-1-amd64 #1 SMP Debian 4.3.5-1 (2016-02-06) x86_64 GNU/Linux - -I compiled the attached file with the command line "gcc -o main -g -mbmi2 main.c". - -$ gcc --version -gcc (Debian 5.4.0-6) 5.4.0 20160609 - -Best regards, -Lénárd Szolnoki \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1611394 b/results/classifier/zero-shot-user-mode/output/instruction/1611394 deleted file mode 100644 index 0b3751883..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1611394 +++ /dev/null @@ -1,35 +0,0 @@ -instruction: 0.570 -runtime: 0.229 -syscall: 0.201 - - - -qemu-ppc: Scalar Single-Precision Floating-Point instructions should not test MSR[SPV] - -According to "Signal Processing Engine (SPE) Programming Environments Manual" at -http://cache.nxp.com/files/32bit/doc/ref_manual/SPEPEM.pdf?fsrch=1&sr=1&pageNum=1 - -c.f section 4.2.3 and also Figure 2-2. - -When MSR[SPV] is _NOT_ set, then the embedded scalar single-precision floating-point instructions -should _NOT_ generate an Embedded Floating-Point Unavailable Interrupt. - - -Hence, some tests for MSR[SPV] in file target-ppc/translate.c need to be removed. -Namely, in the definitions of -1. GEN_SPEFPUOP_ARITH2_32_32 -2. gen_efsabs -3. gen_efsnabs -4. gen_efsneg -5. GEN_SPEFPUOP_COMP_32 - -Note, the macro GEN_SPEFPUOP_CONV_32_32 is already correct. - -One more thing, afaict the macro GEN_SPEFPUOP_CONV_32_64 is used by both -efs- and efd- instructions, and will need to be split in two versions. -The efs-use (i.e for efscfd) should be as it is today, but the use by efd-instructions -(e.g efdctui) will need to add a test for MSR[SPV]. - - - -(I've looked at today's HEAD-revision of target-ppc/translate.c). \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1612 b/results/classifier/zero-shot-user-mode/output/instruction/1612 deleted file mode 100644 index ee226115a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1612 +++ /dev/null @@ -1,57 +0,0 @@ -instruction: 0.409 -syscall: 0.356 -runtime: 0.235 - - - -SVE first-faulting gather loads return incorrect data -Description of problem: -The results of `ldff1(b|h|w|d)` seem to be incorrect when `<Zt> == <Zm>`. The first element is duplicated throughout the vector while the FFR indicates that all elements were successfully loaded. This happens since https://gitlab.com/qemu-project/qemu/-/commit/50de9b78cec06e6d16e92a114a505779359ca532, and still happens on the latest master. -Steps to reproduce: -1. This assembly sequence loads data with an `ldff1d` instruction (and also loads the ffr). Note that with `ldff1d`, `<Zt> == <Zm>`. - -asmtest.s -``` - .type asmtest, @function - .balign 16 - .global asmtest -asmtest: - setffr - ptrue p0.d - index z1.d, #0, #1 - ldff1d z1.d, p0/z, [x0, z1.d, LSL #3] - rdffr p1.b - st1d {z1.d}, p0, [x1] - str p1, [x2] - ret -``` - -This harness for convenience intialises some data and checks the element at index 1, which should be 1. - -test.c -``` -#include <arm_sve.h> -#include <stdio.h> - -void asmtest(int64_t const * data, svint64_t * loaded, svbool_t * ffr); - -int main() { - const int64_t data[] = {42, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, - 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, - 22, 23, 24, 25, 26, 27, 28, 29, 30, 31}; - svint64_t loaded; - svbool_t ffr; - - asmtest(data, &loaded, &ffr); - - // Check value of element at index 1 - svuint64_t lanes = svindex_u64(0, 1); - svbool_t lane = svcmpeq_n_u64(svptrue_b64(), lanes, 1); - printf("%ld\n", svaddv_s64(lane, loaded)); -} -``` - -2. ```clang-15 -fuse-ld=lld -march=armv8-a+sve2 -target aarch64-unknown-linux-gnu -static *.c *.s -o svldffgathertest``` -3. ```qemu-aarch64 svldffgathertest``` - the value printed should be 1, but it can be seen that all values in the loaded vector are 42. -Additional information: -The above code was successfully tested on real SVE hardware. Normal gathers work fine in QEMU, as does a non-gather first-fault load. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1613817 b/results/classifier/zero-shot-user-mode/output/instruction/1613817 deleted file mode 100644 index ebe48a357..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1613817 +++ /dev/null @@ -1,62 +0,0 @@ -instruction: 0.468 -syscall: 0.308 -runtime: 0.224 - - - -x86: ret, lret and iret with noncanonical IP saves wrong IP on the exception stack - -This test program: - -# compile with: gcc -nostartfiles -nostdlib -_start: .globl _start - mov %ss,%eax - push %rax - push %rsp - pushf - mov %cs,%eax - push %rax - mov $0x1234567812345678,%rax - push %rax -//qemu bug: ip=1234567812345678, should be ip=0000000000400abc: - iretq -1: - jmp 1b - -should segfault on IRET instruction because return address on stack is invalid -(it is not canonical). And it does, both on native CPU and in qemu. -But there is a difference: on native CPU, it fails before instruction is executed, -IOW: saved IP points to the failed IRET: - -# strace -i ./bad_ip_in_iret -[00007fa609805d57] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 54 vars */]) = 0 -[00000000004000e7] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- - ^^^^^^^^^^^^^^^^-NOTE THIS -[????????????????] +++ killed by SIGSEGV (core dumped) +++ - - -In qemu, evidently instruction succeeds, and then emulated CPU throws an exception because fetching instructions from non-canonical addresses is not allowed: - -/ # strace -i ./bad_ip_in_iret -[000000000041a790] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 5 vars */]) = 0 -[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- - ^^^^^^^^^^^^^^^^-NOTE THIS -[????????????????] +++ killed by SIGSEGV +++ -Segmentation fault - -Thus, the emulation is not the same as real CPU. - -This is not specific to IRET, the same happens with "far return" LRET, -and with ordinary RET instructions as well. -In qemu: - -/ # strace -i ./bad_ip_in_lret -[000000000041a790] execve("./bad_ip_in_lret", ["./bad_ip_in_lret"], [/* 5 vars */]) = 0 -[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- -[????????????????] +++ killed by SIGSEGV +++ -Segmentation fault -/ # strace -i ./bad_ip_in_ret -[000000000041a790] execve("./bad_ip_in_ret", ["./bad_ip_in_ret"], [/* 5 vars */]) = 0 -[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- -[????????????????] +++ killed by SIGSEGV +++ -Segmentation fault \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1614348 b/results/classifier/zero-shot-user-mode/output/instruction/1614348 deleted file mode 100644 index cb2c5fc2c..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1614348 +++ /dev/null @@ -1,45 +0,0 @@ -instruction: 0.604 -runtime: 0.254 -syscall: 0.143 - - - -qemu-arm core dumped for no entry symbol programe - -Hi qemu developers, - -Environment: -* Fedora 24 x86_64 -* qemu-arm version 2.6.92, Copyright (c) 2003-2008 Fabrice Bellard -* arm-linux-gnu-gcc 6.1.1 20160621 (Red Hat Cross 6.1.1-2) (GCC) target: arm-linux-gnueabi -* glibc-arm-linux-gnu-devel-2.23 - -very simple hello.c: - -#include <stdio.h> - -int main(int argc, char *argv[]) -{ - printf("Hello World\n"); - - return 0; -} - -arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib -lc - -/usr/bin/arm-linux-gnu-ld: Warning: Cannot find entry symbol _start; defaulting to 00000000000101fc - -qemu-arm -L /usr/arm-linux-gnu ./a.out - -Hello World -qemu: uncaught target signal 4 (Illegal instruction) - core dumped -Illegal instruction - -But provided entry symbol: - -arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib /usr/arm-linux-gnu/lib/crt1.o /usr/arm-linux-gnu/lib/crti.o /usr/arm-linux-gnu/lib/crtn.o -lc - -qemu-arm -L /usr/arm-linux-gnu ./a.out is able to work happily! - -Regards, -Leslie Zhai \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1619896 b/results/classifier/zero-shot-user-mode/output/instruction/1619896 deleted file mode 100644 index 0cc01a8a8..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1619896 +++ /dev/null @@ -1,56 +0,0 @@ -instruction: 0.417 -syscall: 0.343 -runtime: 0.240 - - - -linux-user missing cmsg IP_PKTINFO support ("Unsupported ancillary data: 0/8") - -Hello, - -I have the following issue when launching the Teamspeak Server x86 binary on an arm host. - -Host: - Linux 4.6.2 (vanilla) - Ubuntu 14.04.5 LTS - HW: Cubietruck board, armv7l - - -Used SW: Release archive qemu-2.7.0.tar.bz2 and git commit 1dc33ed90bf1fe1c2014dffa0d9e863c520d953a -Configure options: - ../configure --target-list=i386-linux-user -I attached the output of the configure script as configure.log - -Testcase: - -1. Download and extract TeamSpeak 3 Server 3.0.13.3 (x86) - Souce: http://dl.4players.de/ts/releases/3.0.13.3/teamspeak3-server_linux_x86-3.0.13.3.tar.bz2 - -2. Modifiy ts3server_minimal_runscript.sh for ease of use - - ./ts3server $@ - + /usr/local/bin/qemu-i386 ./ts3server $@ - -3. Execute ./ts3server_minimal_runscript.sh - -Wait for 6 Minutes until teamspeak server started. QEMU saturates the cpu while Teamspeak is precomputing a puzzle. (Whatever that means) - -After that Teamspeak settles with the following output: - 2016-09-03 10:50:59.555582|INFO |Query | |listening on 0.0.0.0:10011, :::10011 - -The Qemu process is now idling with ~2% cpu load. This is actually the first time for me that QEMU is able to successfully launch the Teamspeak server. Kudos! - -4. Connect client 1 - -TS Clients can connect, but the following line is printed pretty often: - Unsupported ancillary data: 0/8 - -The line seems to come from qemu (linux-user/syscall.c) - - -5. Connect client 2 -When a second client is connected the audio transmission is successful for a few seconds, but the server drops the connection after that and refuses to take new connections. - -Please let me know, if you need more information. I'll gladly provide strace or valgrind logs. - -Best regards, -Tobias \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1620 b/results/classifier/zero-shot-user-mode/output/instruction/1620 deleted file mode 100644 index 19dc1cdc8..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1620 +++ /dev/null @@ -1,100 +0,0 @@ -instruction: 0.405 -runtime: 0.336 -syscall: 0.259 - - - -SME FMOPA outer product instruction gives incorrect result -Description of problem: -The SME outer product instructions operate on tiles of elements. In the -below example we are performing an outer product of a vector of 1.0 -by itself. This naturally should produce a matrix filled with 1.0 -values, however if we read the values of the tile and printf them we -instead observe 0.0 values. - -Without digging into the underlying QEMU code this appears to be a bug -in how elements are set based on the tile number, since the same code -using za0.s rather than za1.s correctly reports all 1.0 values as output -as expected. - -main.c -``` -#include <stdio.h> - -void foo(float *dst); - -int main() { - float dst[16]; - foo(dst); - - // This should print: - // >>> 1.000000 1.000000 1.000000 1.000000 - // >>> 1.000000 1.000000 1.000000 1.000000 - // >>> 1.000000 1.000000 1.000000 1.000000 - // >>> 1.000000 1.000000 1.000000 1.000000 - for (int i=0; i<4; ++i) { - printf(">>> "); - for (int j=0; j<4; ++j) { - printf("%lf ", (double)dst[i * 4 + j]); - } - printf("\n"); - } -} -``` - -foo.S -``` -.global foo -foo: - stp x29, x30, [sp, -80]! - mov x29, sp - stp d8, d9, [sp, 16] - stp d10, d11, [sp, 32] - stp d12, d13, [sp, 48] - stp d14, d15, [sp, 64] - - smstart - - ptrue p0.s, vl4 - fmov z0.s, #1.0 - - // An outer product of a vector of 1.0 by itself should be a matrix of 1.0. - // Note that we are using tile 1 here (za1.s) rather than tile 0. - zero {za} - fmopa za1.s, p0/m, p0/m, z0.s, z0.s - - // Read the first 4x4 sub-matrix of elements from tile 1: - // Note that za1h should be interchangable here. - mov w12, #0 - mova z0.s, p0/m, za1v.s[w12, #0] - mova z1.s, p0/m, za1v.s[w12, #1] - mova z2.s, p0/m, za1v.s[w12, #2] - mova z3.s, p0/m, za1v.s[w12, #3] - - // And store them to the input pointer (dst in the C code): - st1w {z0.s}, p0, [x0] - add x0, x0, #16 - st1w {z1.s}, p0, [x0] - add x0, x0, #16 - st1w {z2.s}, p0, [x0] - add x0, x0, #16 - st1w {z3.s}, p0, [x0] - - smstop - - ldp d8, d9, [sp, 16] - ldp d10, d11, [sp, 32] - ldp d12, d13, [sp, 48] - ldp d14, d15, [sp, 64] - ldp x29, x30, [sp], 80 - ret -``` -Steps to reproduce: -``` -$ clang -target aarch64-linux-gnu -march=armv9-a+sme test.c -O1 -static -$ ~/qemu/build/qemu-aarch64 ./a.out ->>> 0.000000 0.000000 0.000000 0.000000 ->>> 0.000000 0.000000 0.000000 0.000000 ->>> 0.000000 0.000000 0.000000 0.000000 ->>> 0.000000 0.000000 0.000000 0.000000 -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1637 b/results/classifier/zero-shot-user-mode/output/instruction/1637 deleted file mode 100644 index 6bf9bfcf4..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1637 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.803 -runtime: 0.101 -syscall: 0.096 - - - -Crash when executing `ucomiss` instructions emulating an x86-64 CPU on an AArch64 host diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1641637 b/results/classifier/zero-shot-user-mode/output/instruction/1641637 deleted file mode 100644 index 650ce0719..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1641637 +++ /dev/null @@ -1,719 +0,0 @@ -instruction: 0.510 -runtime: 0.287 -syscall: 0.203 - - - -incorrect illegal SSE3 instructions reporting on x86_64 - -Hi all, we found 28 differently encoded illegal SSE3 instructions reporting on the most recent x86_64 user mode linux qemu (version 2.7.0). We believe these reporting should be incorrect because the same code can be executed on a real machine. The instructions are the following: - -pabsb %mm0, %mm1 -pabsb %xmm0, %xmm1 -pabsd %mm0, %mm1 -pabsd %xmm0, %xmm1 -pabsw %mm0, %mm1 -pabsw %xmm0, %xmm1 -phaddd %mm0, %mm1 -phaddd %xmm0, %xmm1 -phaddsw %mm0, %mm1 -phaddsw %xmm0, %xmm1 -phaddw %mm0, %mm1 -phaddw %xmm0, %xmm1 -phsubd %mm0, %mm1 -phsubd %xmm0, %xmm1 -phsubsw %mm0, %mm1 -phsubsw %xmm0, %xmm1 -phsubw %mm0, %mm1 -phsubw %xmm0, %xmm1 -pmaddubsw %mm0, %mm1 -pmaddubsw %xmm0, %xmm1 -pmulhrsw %mm0, %mm1 -pmulhrsw %xmm0, %xmm1 -psignb %mm0, %mm1 -psignb %xmm0, %xmm1 -psignd %mm0, %mm1 -psignd %xmm0, %xmm1 -psignw %mm0, %mm1 -psignw %xmm0, %xmm1 - -The following is the proof of code - -/********** Beginning of bug 1.c: pabsb %mm0, %mm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; - asm("pabsb %mm0, %mm1"); - asm("mov %0, %%rdx\n" - "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 1.c **********/ - - -/********** Beginning of bug 2.c: pabsb %xmm0, %xmm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; - asm("pabsb %xmm0, %xmm1"); - asm("mov %0, %%rdx\n" - "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 2.c **********/ - - -/********** Beginning of bug 3.c: pabsd %mm0, %mm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; - asm("pabsd %mm0, %mm1"); - asm("mov %0, %%rdx\n" - "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 3.c **********/ - - -/********** Beginning of bug 4.c: pabsd %xmm0, %xmm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; - asm("pabsd %xmm0, %xmm1"); - asm("mov %0, %%rdx\n" - "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 4.c **********/ - - -/********** Beginning of bug 5.c: pabsw %mm0, %mm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; - asm("pabsw %mm0, %mm1"); - asm("mov %0, %%rdx\n" - "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 5.c **********/ - - -/********** Beginning of bug 6.c: pabsw %xmm0, %xmm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; - asm("pabsw %xmm0, %xmm1"); - asm("mov %0, %%rdx\n" - "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 6.c **********/ - - -/********** Beginning of bug 7.c: phaddd %mm0, %mm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; - asm("phaddd %mm0, %mm1"); - asm("mov %0, %%rdx\n" - "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 7.c **********/ - - -/********** Beginning of bug 8.c: phaddd %xmm0, %xmm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; - asm("phaddd %xmm0, %xmm1"); - asm("mov %0, %%rdx\n" - "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 8.c **********/ - - -/********** Beginning of bug 9.c: phaddsw %mm0, %mm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; - asm("phaddsw %mm0, %mm1"); - asm("mov %0, %%rdx\n" - "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 9.c **********/ - - -/********** Beginning of bug 10.c: phaddsw %xmm0, %xmm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; - asm("phaddsw %xmm0, %xmm1"); - asm("mov %0, %%rdx\n" - "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 10.c **********/ - - -/********** Beginning of bug 11.c: phaddw %mm0, %mm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; - asm("phaddw %mm0, %mm1"); - asm("mov %0, %%rdx\n" - "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 11.c **********/ - - -/********** Beginning of bug 12.c: phaddw %xmm0, %xmm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; - asm("phaddw %xmm0, %xmm1"); - asm("mov %0, %%rdx\n" - "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 12.c **********/ - - -/********** Beginning of bug 13.c: phsubd %mm0, %mm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; - asm("phsubd %mm0, %mm1"); - asm("mov %0, %%rdx\n" - "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 13.c **********/ - - -/********** Beginning of bug 14.c: phsubd %xmm0, %xmm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; - asm("phsubd %xmm0, %xmm1"); - asm("mov %0, %%rdx\n" - "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 14.c **********/ - - -/********** Beginning of bug 15.c: phsubsw %mm0, %mm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; - asm("phsubsw %mm0, %mm1"); - asm("mov %0, %%rdx\n" - "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 15.c **********/ - - -/********** Beginning of bug 16.c: phsubsw %xmm0, %xmm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; - asm("phsubsw %xmm0, %xmm1"); - asm("mov %0, %%rdx\n" - "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 16.c **********/ - - -/********** Beginning of bug 17.c: phsubw %mm0, %mm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; - asm("phsubw %mm0, %mm1"); - asm("mov %0, %%rdx\n" - "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 17.c **********/ - - -/********** Beginning of bug 18.c: phsubw %xmm0, %xmm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; - asm("phsubw %xmm0, %xmm1"); - asm("mov %0, %%rdx\n" - "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 18.c **********/ - - -/********** Beginning of bug 19.c: pmaddubsw %mm0, %mm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char i2[0x10]; -unsigned char i3[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm0\n"::"r"((char *)(i2)));; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i3)));; - asm("pmaddubsw %mm0, %mm1"); - asm("mov %0, %%rdx\n" - "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 19.c **********/ - - -/********** Beginning of bug 20.c: pmaddubsw %xmm0, %xmm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char i2[0x10]; -unsigned char i3[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i2)));; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i3)));; - asm("pmaddubsw %xmm0, %xmm1"); - asm("mov %0, %%rdx\n" - "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 20.c **********/ - - -/********** Beginning of bug 21.c: pmulhrsw %mm0, %mm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; - asm("pmulhrsw %mm0, %mm1"); - asm("mov %0, %%rdx\n" - "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 21.c **********/ - - -/********** Beginning of bug 22.c: pmulhrsw %xmm0, %xmm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; - asm("pmulhrsw %xmm0, %xmm1"); - asm("mov %0, %%rdx\n" - "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 22.c **********/ - - -/********** Beginning of bug 23.c: psignb %mm0, %mm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; - asm("psignb %mm0, %mm1"); - asm("mov %0, %%rdx\n" - "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 23.c **********/ - - -/********** Beginning of bug 24.c: psignb %xmm0, %xmm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; - asm("psignb %xmm0, %xmm1"); - asm("mov %0, %%rdx\n" - "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 24.c **********/ - - -/********** Beginning of bug 25.c: psignd %mm0, %mm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; - asm("psignd %mm0, %mm1"); - asm("mov %0, %%rdx\n" - "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 25.c **********/ - - -/********** Beginning of bug 26.c: psignd %xmm0, %xmm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; - asm("psignd %xmm0, %xmm1"); - asm("mov %0, %%rdx\n" - "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 26.c **********/ - - -/********** Beginning of bug 27.c: psignw %mm0, %mm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; - asm("psignw %mm0, %mm1"); - asm("mov %0, %%rdx\n" - "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 27.c **********/ - - -/********** Beginning of bug 28.c: psignw %xmm0, %xmm1 **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char i1[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; - asm("mov %0, %%rdx\n" - "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; - asm("psignw %xmm0, %xmm1"); - asm("mov %0, %%rdx\n" - "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} - -/********** End of bug 28.c **********/ - -For any of the above code, when compiled into x86-64 binary code with gcc, qemu reports the illegal instructions bug. However, these can be correctly executed on a real machine. For example, - -$ gcc 28.c -o 28 -$ qemu-x86_64 ./28 -qemu: uncaught target signal 4 (Illegal instruction) - core dumped -Illegal instruction -$ ./28 -00000000000000000000000000000000 - -Some information about the system: - -$ qemu-x86_64 --version -qemu-x86_64 version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers -$ uname -a -Linux cgos-System-Product-Name 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux -$ gcc --version -gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 -Copyright (C) 2013 Free Software Foundation, Inc. -This is free software; see the source for copying conditions. There is NO -warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - - -Thanks! \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1641861 b/results/classifier/zero-shot-user-mode/output/instruction/1641861 deleted file mode 100644 index 4c21dcc92..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1641861 +++ /dev/null @@ -1,42 +0,0 @@ -instruction: 0.569 -runtime: 0.230 -syscall: 0.201 - - - -ARM QEMU doesn't enforce that RES0 bits in FPSCR are non-writeable - -Hi all, we systematically tested the QEMU implementation for emulating arm user mode programs. We found that QEMU incorrectly emulate the FPSCR register. The following the proof of code: - -/*********** Beginning of the bug: arm.c **********/ - -int printf(const char *format, ...); -unsigned char i0[0x10]; -unsigned char o[0x10]; -int main() { - int k = 0; - asm("mov r2, %0\n" - "ldr r0, [r2]\n"::"r"((char *)(i0)));; - asm("vmsr fpscr, r0"); - asm("mov r2, %0\n" - "vmrs r4, fpscr\n" - "str r4, [r2]\n"::"r"((char *)(o)));; - for (k = 0; k < 0x10; k++) - printf("%02x", o[0x10 - 1 - k]); - printf("\n"); -} -unsigned char i0[0x10] = {0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x28, 0x1c, 0xc7, 0x01, 0x00, 0x00, 0x00, 0x00}; - -/*********** End fo the bug **********/ - -When the program is compiled into arm binary code and running on a real arm machine, and running in qemu, we have the following result - -$ arm-linux-gnueabihf-gcc arm.c -o arm -static -$ ./arm -000000000000000000000000fff7009f -$ qemu-arm arm -000000000000000000000000ffffffff - -According to the ARM manual, bits[19, 14:13, 6:5] of FPSCR should be reserved as zero. However, arm qemu fails to keep these bits to be zero: these bits can be actually modified in QEMU. - -Thanks! \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1642 b/results/classifier/zero-shot-user-mode/output/instruction/1642 deleted file mode 100644 index 1e881b5ff..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1642 +++ /dev/null @@ -1,28 +0,0 @@ -instruction: 0.735 -runtime: 0.142 -syscall: 0.124 - - - -Qemu aarch64 tcg crashes when emulating an STXP instruction but only on a Windows host -Description of problem: -Qemu segfaults when trying to emulate an STXP instruction, but only when running natively on a windows host (msys2 build). This is not the same as https://gitlab.com/qemu-project/qemu/-/issues/1581. - -I've managed to git-bisect it to this change: https://github.com/qemu/qemu/commit/546789c7df8866c55cae8d3195e8e58328a35d51 -Sadly i cannot investigate it further and contribute a fix, but it seems like a problem with one of the I128 arguments to `helper_atomic_cmpxchgo_le ` - -UPD: Issue is also in master (as of `caa9cbd566877b34e9abcc04d936116fc5e0ab28`) -Steps to reproduce: -N/A -Additional information: -``` -Thread 9 received signal SIGSEGV, Segmentation fault. -0x00007ff67efc32dc in helper_atomic_cmpxchgo_le (env=0x24796b08c10, addr=18446684150325987376, oldv=46236672343829145701101521005152, newv=2595395441251766838621186119693696, oi=3650) at ../accel/tcg/atomic_common.c.inc:60 -60 CMPXCHG_HELPER(cmpxchgo_le, Int128) -(gdb) bt -#0 0x00007ff67efc32dc in helper_atomic_cmpxchgo_le (env=0x24796b08c10, - addr=18446684150325987376, oldv=46236672343829145701101521005152, - newv=2595395441251766838621186119693696, oi=3650) at ../accel/tcg/atomic_common.c.inc:60 -#1 0x00000247a124f73d in ?? () - -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1648 b/results/classifier/zero-shot-user-mode/output/instruction/1648 deleted file mode 100644 index 77e8a220c..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1648 +++ /dev/null @@ -1,64 +0,0 @@ -instruction: 0.607 -runtime: 0.209 -syscall: 0.185 - - - -linux-user: incorrect alignment of sigframe::pretcode & rt_sigframe::pretcode cause crash -Description of problem: -Corrent Print Result: - -sp: cdd3b4e8 - -SUCCEEDED! - -qemu-x86_64 Print Result: - -sp: 2804170 - -qemu: uncaught target signal 11 (Segmentation fault) - core dumped - -Segmentation fault - -Reason of Bug: - -sigframe::pretcode & rt_sigframe::pretcode must align of 16n-sizeof(void*) instead of 16n, Because rsp align of 16n before instruction "call" in caller, After "call", push address of "call" in caller. sp of begin in callee is 16n-sizeof(void*) - -For example on x86_64: - -reference to "qemu/linux-user/i386/signal.c" - -``` -# define TARGET_FPSTATE_FXSAVE_OFFSET 0 - -struct rt_sigframe { - abi_ulong pretcode; - struct target_ucontext uc; - struct target_siginfo info; - struct target_fpstate fpstate QEMU_ALIGNED(16); -}; -#define TARGET_RT_SIGFRAME_FXSAVE_OFFSET ( \ - offsetof(struct rt_sigframe, fpstate) + TARGET_FPSTATE_FXSAVE_OFFSET) -``` - -offsetof(struct rt_sigframe, fpstate) align of 16 - -TARGET_FPSTATE_FXSAVE_OFFSET is 0 - -TARGET_RT_SIGFRAME_FXSAVE_OFFSET is 16n, also alignment of fxsave is 64 - -so address of rt_sigframe::pretcode is 16n instead of 16n - sizeof(void*), It is incorect! - -Fix the bug: - -``` -struct rt_sigframe { - abi_ulong pretcode; - struct target_ucontext uc; - struct target_siginfo info; - abi_ulong unused QEMU_ALIGNED(16); - struct target_fpstate fpstate; -}; -``` - -offsetof(struct rt_sigframe, fpstate) is 16n+8, so address of rt_sigframe::pretcode is 16n-8 on x86_64. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1654137 b/results/classifier/zero-shot-user-mode/output/instruction/1654137 deleted file mode 100644 index 17bdb8269..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1654137 +++ /dev/null @@ -1,13 +0,0 @@ -instruction: 0.537 -runtime: 0.352 -syscall: 0.111 - - - -Ctrl-A b not working in 2.8.0 - -With a recent update from 2.7.0 to 2.8.0 I have discovered that I can no longer send a "break" to the VM. Ctrl-A b is simply ignored. Other Ctrl-A sequences seem to work correctly. - -This is on a NetBSD amd64 system, version 7.99.53, and qemu was installed on this system from source. - -Reverting to the previous install restores "break" capability. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1661815 b/results/classifier/zero-shot-user-mode/output/instruction/1661815 deleted file mode 100644 index 29e0b7158..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1661815 +++ /dev/null @@ -1,32 +0,0 @@ -instruction: 0.463 -runtime: 0.318 -syscall: 0.219 - - - -Stack address is returned from function translate_one - -The vulnerable version is qemu-2.8.0, and the vulnerable function is in "target-s390x/translate.c". - -The code snippet is as following. - -static ExitStatus translate_one(CPUS390XState *env, DisasContext *s) -{ - const DisasInsn *insn; - ExitStatus ret = NO_EXIT; - DisasFields f; - ... - s->fields = &f; - ... - s->pc = s->next_pc; - return ret; -} - -A stack address, i.e. the address of local variable "f" is returned from current function through the output parameter "s->fields" as a side effect. - -This issue is one kind of undefined behaviors, according the C Standard, 6.2.4 [ISO/IEC 9899:2011] (https://www.securecoding.cert.org/confluence/display/c/DCL30-C.+Declare+objects+with+appropriate+storage+durations) - -This dangerous defect may lead to an exploitable vulnerability. -We suggest sanitizing "s->fields" as null before return. - -Note that this issue is reported by shqking and Zhenwei Zou together. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1673976 b/results/classifier/zero-shot-user-mode/output/instruction/1673976 deleted file mode 100644 index de3f9b7ee..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1673976 +++ /dev/null @@ -1,17 +0,0 @@ -instruction: 0.523 -runtime: 0.325 -syscall: 0.152 - - - -linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert) - -I'm running a command command (locale-gen) inside of an armv7h chroot mounted on my x86_64 desktop by putting qemu-arm-static into /usr/bin/ of the chroot file system and I get a core dump. - -locale-gen -Generating locales... - en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed. -qemu: uncaught target signal 6 (Aborted) - core dumped -/usr/bin/locale-gen: line 41: 34 Aborted (core dumped) localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale - -I've done this same thing successfully for years, but this breakage has appeared some time in the last 3 or so months. Possibly with the update to qemu version 2.8. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1696353 b/results/classifier/zero-shot-user-mode/output/instruction/1696353 deleted file mode 100644 index 1495a5143..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1696353 +++ /dev/null @@ -1,41 +0,0 @@ -instruction: 0.541 -runtime: 0.297 -syscall: 0.162 - - - -golang binaries fail to start under linux-user - -With current master golang binaries fail when run under linux-user, for example: - -[will@localhost qemu]$ ./arm-linux-user/qemu-arm glide -runtime: failed to create new OS thread (have 2 already; errno=22) -fatal error: newosproc - -runtime stack: -runtime.throw(0x45f879, 0x9) - /usr/lib/golang/src/runtime/panic.go:566 +0x78 -runtime.newosproc(0x1092c000, 0x1093bfe0) - /usr/lib/golang/src/runtime/os_linux.go:160 +0x1b0 -runtime.newm(0x4ae1e8, 0x0) - /usr/lib/golang/src/runtime/proc.go:1572 +0x12c -runtime.main.func1() - /usr/lib/golang/src/runtime/proc.go:126 +0x24 -runtime.systemstack(0x5ef900) - /usr/lib/golang/src/runtime/asm_arm.s:247 +0x80 -runtime.mstart() - /usr/lib/golang/src/runtime/proc.go:1079 - -goroutine 1 [running]: -runtime.systemstack_switch() - /usr/lib/golang/src/runtime/asm_arm.s:192 +0x4 fp=0x109287ac sp=0x109287a8 -runtime.main() - /usr/lib/golang/src/runtime/proc.go:127 +0x5c fp=0x109287d4 sp=0x109287ac -runtime.goexit() - /usr/lib/golang/src/runtime/asm_arm.s:998 +0x4 fp=0x109287d4 sp=0x109287d4 - -The reason for this is that the golang runtime does not pass the CLONE_SYSVMEM flag to clone so the clone flags checks fail: - -https://github.com/golang/go/blob/master/src/runtime/os_linux.go#L155 - -The attached patch allows golang binaries to start under linux-user. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1696773 b/results/classifier/zero-shot-user-mode/output/instruction/1696773 deleted file mode 100644 index c64cba86b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1696773 +++ /dev/null @@ -1,13 +0,0 @@ -instruction: 0.559 -syscall: 0.379 -runtime: 0.061 - - - -golang calls to exec crash user emulation - -An example program can be found here: - -https://github.com/willnewton/qemucrash - -This code starts a goroutine (thread) and calls exec repeatedly. This works ok natively but when run under ARM user emulation it segfaults (usually, there are occasionally other failures). \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1697 b/results/classifier/zero-shot-user-mode/output/instruction/1697 deleted file mode 100644 index fc39589a1..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1697 +++ /dev/null @@ -1,25 +0,0 @@ -instruction: 0.434 -runtime: 0.392 -syscall: 0.175 - - - -qemu-arm -cpu cortex-m55 dummy_test qemu-arm: ../accel/tcg/user-exec.c:492: page_set_flags: Assertion `last <= GUEST_ADDR_MAX' failed. -Description of problem: -Basic testing failed for cortex m55 -Steps to reproduce: -1.Pulled the newest qemu 8.0.50 - -2.Create a Dummy test with only return 0 in main function - -3.run ` arm-none-eabi-gcc -o dummy_test -O2 -g -mcpu=cortex-m55 dummy_test.cc --specs=rdimon.specs` and then `qemu-arm -cpu cortex-m55 dummy_test` - -`arm-none-eabi-gcc (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 12.2.1 20230214 -Copyright (C) 2022 Free Software Foundation, Inc. -This is free software; see the source for copying conditions. There is NO -warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.` - -`qemu-arm version 8.0.50 (v8.0.0-1739-g5f9dd6a8ce) -Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers` -Additional information: -It is a known problem in another issues: https://gitlab.com/qemu-project/qemu/-/issues/1528#note_1389268261. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1701808 b/results/classifier/zero-shot-user-mode/output/instruction/1701808 deleted file mode 100644 index 7ab4775ab..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1701808 +++ /dev/null @@ -1,22 +0,0 @@ -instruction: 0.632 -runtime: 0.245 -syscall: 0.124 - - - -stack smashing in or after recvmsg system call in aarch64 user mode - -A program that invokes recvmsg aborts with "*** stack smashing detected ***" when run in qemu-aarch64 (user mode), but works fine when running on native aarch64 hardware. - -How to reproduce: -$ aarch64-linux-gnu-gcc-5 -O -Wall /media/develdata/devel/qemu-bug/testpassfd.c -static -DEXTRA_SPACE=0 -$ QEMU_LD_PREFIX=/usr/aarch64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-aarch64 ./a.out -*** stack smashing detected ***: ./a.out terminated -qemu: uncaught target signal 6 (Aborted) - core dumped - -On native aarch64 hardware: -$ ./a.out -$ echo $? -0 - -The parameter EXTRA_SPACE can be used to add additional space to the array that receives the recvmsg data. With -DEXTRA_SPACE=9 (or larger), the program runs fine. Which suggests that recvmsg is storing up to 9 bytes more than allowed in memory. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1701973 b/results/classifier/zero-shot-user-mode/output/instruction/1701973 deleted file mode 100644 index afea95994..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1701973 +++ /dev/null @@ -1,23 +0,0 @@ -instruction: 0.472 -syscall: 0.366 -runtime: 0.162 - - - -pread does not work right under qemu-sh4 - -The pread system call returns a wrong value in some case, in a program running under qemu-sh4 (version 2.9.0). - -How to reproduce: -- Compile the program: - sh4-linux-gnu-gcc-5 -O -Wall -static -o test-pread test-pread.c -- Set environment variable for using qemu-sh4 (actually not needed, since the program is statically linked here). -- ~/inst-qemu/2.9.0/bin/qemu-sh4 test-pread - -Expected output: -ret=1 errno=0 - -Actual output: -ret=0 errno=2 -test-pread.c:44: assertion 'ret == 1' failed -qemu: uncaught target signal 6 (Aborted) - core dumped \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1701974 b/results/classifier/zero-shot-user-mode/output/instruction/1701974 deleted file mode 100644 index bd9ed0e66..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1701974 +++ /dev/null @@ -1,23 +0,0 @@ -instruction: 0.599 -syscall: 0.206 -runtime: 0.194 - - - -pwrite does not work right under qemu-sh4 - -The pwrite system call has no effect when writing to a non-zero file position, in a program running under qemu-sh4 (version 2.9.0). - -How to reproduce: -- Compile the program: - sh4-linux-gnu-gcc-5 -O -Wall -static -o test-pwrite test-pwrite.c -- Set environment variable for using qemu-sh4 (actually not needed, since the program is statically linked here). -- ~/inst-qemu/2.9.0/bin/qemu-sh4 test-pwrite - -Expected output: -buf = 01W3456789 - -Actual output: -buf = 0123456789 -test-pwrite.c:56: assertion 'strcmp ("01W3456789",buf) == 0' failed -qemu: uncaught target signal 6 (Aborted) - core dumped \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1707 b/results/classifier/zero-shot-user-mode/output/instruction/1707 deleted file mode 100644 index ff27eb8d6..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1707 +++ /dev/null @@ -1,29 +0,0 @@ -instruction: 0.524 -runtime: 0.304 -syscall: 0.172 - - - -linux-user qemu-x86_64 can't exec a binary on aarch64 or Loongarch. -Description of problem: -on master branch, we build an simply hello.c with x86_cross gcc. -then. run './build/qemu-x86_64 hello', no output. -Steps to reproduce: -1. build an hello.c with x86_64 cross. use --static. -2. build qemu-x86_64 on aarch64 or LoongArch host. -3. run './build/qemu-x86_64 hello' -Additional information: -[strace.txt](/uploads/5362e0e9b04ad9a582470faf4a9fcedb/strace.txt) - - - - [hello](/uploads/12d9277fa4e853286414f575010a37ac/hello) - - -The following commit causes this problem． - -commit 86f04735ac2088d5c069c3d1712212ec7428c562 -Author: Helge Deller <deller@gmx.de> -Date: Sun Dec 25 09:23:19 2022 +0100 - - linux-user: Fix brk() to release pages diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1713066 b/results/classifier/zero-shot-user-mode/output/instruction/1713066 deleted file mode 100644 index 5576b4817..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1713066 +++ /dev/null @@ -1,25 +0,0 @@ -instruction: 0.765 -runtime: 0.152 -syscall: 0.084 - - - -Incorrect handling of aarch64 ldp in some cases - -In some cases the ldp instruction (and presumably other multi-register loads and stores) can behave incorrectly. - -Given the following instruction: -ldp x0, x1, [x0] - -This will load two 64 bit values from memory, however if each location to load is on a different page and the second page is unmapped this will raise an exception. When this happens x0 has already been updated so after the exception handler has run the operating system will try to rerun the instruction. QEMU will now try to perform an invalid load and raise a new exception. - -I believe this is incorrect as section D.1.14.5 of the ARMv8 reference manual B.a states that, on taking an exception, registers used in the generation of addresses are restored to their initial value, so x0 shouldn't be changed, where x1 can be un an unknown state. - -I found the issue running FreeBSD with the cortex-strings implementation of memcpy. This uses a similar instruction when copying between 64 and 96 bytes. - -I've observed this on: -QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.14), Copyright (c) 2003-2008 Fabrice Bellard - -And checked I still get the same behaviour on: -QEMU emulator version 2.9.94 (v2.10.0-rc4-dirty) -Git revision: 248b23735645f7cbb503d9be6f5bf825f2a603ab \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1716767 b/results/classifier/zero-shot-user-mode/output/instruction/1716767 deleted file mode 100644 index de9e24831..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1716767 +++ /dev/null @@ -1,40 +0,0 @@ -instruction: 0.461 -runtime: 0.336 -syscall: 0.203 - - - -file(1) fails with "Invalid argument" on qemu-sh4-user - -We recently discovered that file(1) fails on qemu-sh4-user when running on an ELF file: - -(sid_sh4)root@vs94:/# file /bin/bash -/bin/bash: ERROR: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV) error reading (Invalid argument) -(sid_sh4)root@vs94:/# - -Running with "-d" yields more output: - -(sid_sh4)root@vs94:/# file -d /bin/bash 2>&1 | tail -322: >> 7 byte&,=97,"(ARM)"] -0 == 97 = 0 -mget(type=1, flag=0, offset=7, o=0, nbytes=863324, il=0, nc=1) -mget/96 @7: \000\000\000\000\000\000\000\000\000\002\000*\000\001\000\000\000\250\317A\0004\000\000\000L(\r\000\027\000\000\0004\000 \000\n\000(\000\032\000\031\000\006\000\000\0004\000\000\0004\000@\0004\000@\000@\001\000\000@\001\000\000\005\000\000\000\004\000\000\000\003\000\000\000t\001\000\000t\001@\000t\001@\000\023\000\000 - -323: >> 7 byte&,=-1,"(embedded)"] -0 == 18446744073709551615 = 0 -[try softmagic 1] -[try elf -1] -/bin/bash: ERROR: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV) error reading (Invalid argument) -(sid_sh4)root@vs94:/# - -It seems that the comparison above has a bogus (overflown?) value. - -On actual hardware, it works: - -root@tirpitz:~> file /bin/bash -/bin/bash: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=4dd0e4281755827d8bb6686fd481f8c80ea73e9a, for GNU/Linux 3.2.0, stripped -root@tirpitz:~> - -I have uploaded a chroot with Debian unstable which allows to reproduce the issue: - -> https://people.debian.org/~glaubitz/sid-sh4-sbuild.tar.gz \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1722 b/results/classifier/zero-shot-user-mode/output/instruction/1722 deleted file mode 100644 index 09c7afa14..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1722 +++ /dev/null @@ -1,93 +0,0 @@ -instruction: 0.361 -runtime: 0.359 -syscall: 0.281 - - - -qemu-mipsn32: Illegal Instruction at `exts` instruction -Description of problem: -Run with the command above, I got this error: - -``` -qemu-mipsn32 run -qemu: uncaught target signal 4 (Illegal instruction) - core dumped -Illegal instruction (core dumped) -``` - -I then tried to debug the program with qemu option `-g 1234` and know that - -``` -$ gdb-multiarch run -... - -pwndbg> target remote 0:1234 -... - -pwndbg> c -Continuing. - -Program received signal SIGILL, Illegal instruction. -0x3f7d2434 in ?? () from /lib32/ld.so.1 -warning: GDB can't find the start of the function at 0x3f7d2434. -x/10i - -pwndbg> x/10i $pc -=> 0x3f7d2434: 0x7047f03a - 0x3f7d2438: lui a3,0x7000 - 0x3f7d243c: ori a3,a3,0x5e - 0x3f7d2440: b 0x3f7d241c - 0x3f7d2444: subu v0,a3,v0 - 0x3f7d2448: sltiu a7,a3,-3 - 0x3f7d244c: bnezl a7,0x3f7d246c - 0x3f7d2450: subu a3,a4,v0 - 0x3f7d2454: addiu a3,a3,1 - 0x3f7d2458: li v0,-4 -``` - -So I know the problem is in libc32/ld.so.1. When I dissasemble that file and look at offset 0x4434, it's an `exts` instruction as below: - -``` -$ file /lib32/ld.so.1 -/lib32/ld-2.15.so: ELF 32-bit MSB shared object, MIPS, N32 MIPS64 rel2 version 1 (SYSV), dynamically linked, stripped - -$ ./mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-objdump -d /lib32/ld.so.1 | less - ... - 4434: 7047f03a exts a3,v0,0x0,0x1e - 4438: 3c077000 lui a3,0x7000 - 443c: 34e7005e ori a3,a3,0x5e - 4440: 1000fff6 b 441c <GLIBC_2.0@@GLIBC_2.0+0x441c> - 4444: 00e21023 subu v0,a3,v0 - 4448: 2cebfffd sltiu a7,a3,-3 - 444c: 55600007 bnezl a7,446c <GLIBC_2.0@@GLIBC_2.0+0x446c> - 4450: 01023823 subu a3,a4,v0 - 4454: 24e70001 addiu a3,a3,1 - 4458: 2402fffc li v0,-4 -``` -Steps to reproduce: -1. Download toolchain of mips64-n32 on toolchains.bootlin.com [here](https://toolchains.bootlin.com/releases_mips64-n32.html) -2. Write this c code to file `run.c`: - -```c -#include <stdio.h> - -int main(){ - puts("hello world"); - while (1); -} -``` - -3. Compile file run.c with downloaded toolchain: - -``` -mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-gcc run.c -o run -``` - -> Step 1, 2 and 3 can be skip if you download the attached `run` file. - -4. Download the attached ld -5. Make new dir at `/lib32` and move the file ld to `/lib32` -6. Run command `qemu-mipsn32 run` -Additional information: -[ld-2.15.so](/uploads/95f4da26e42d43d39aa2350670134bb5/ld-2.15.so) - -[run](/uploads/01be57442009a75cf2f59cbcf53474f4/run) diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1724485 b/results/classifier/zero-shot-user-mode/output/instruction/1724485 deleted file mode 100644 index b0f06b5d2..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1724485 +++ /dev/null @@ -1,24 +0,0 @@ -instruction: 0.529 -runtime: 0.258 -syscall: 0.213 - - - -Invalid assertion in arm_read_memory_func - -Hi, - -I think there is an invalid assertion in arm_read_memory_func: -assert(info->endian == BFD_ENDIAN_LITTLE) - -I face it in the following use case: target armeb-linux (I use qemu user mode), -d in_asm -cpu any. - -At some point during program startup, glibc's _dl_new_object calls strlen, which is written in thumb2 mode (armv6t2). So print_insn_arm() calls arm_read_memory_func() with length==2, and info->flags == INSN_ARM_BE32, and the assert is false. - -If I remove the assert, execution continues OK. - -With the assert, I get the error message from the assert, and qemu then stalls. - -Can you confirm the assert can be removed? Or if not, explain me how to avoid/fix the subsequent qemu stall? - -Thanks \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1725267 b/results/classifier/zero-shot-user-mode/output/instruction/1725267 deleted file mode 100644 index 0bfe72ed2..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1725267 +++ /dev/null @@ -1,37 +0,0 @@ -instruction: 0.414 -runtime: 0.298 -syscall: 0.288 - - - -armeb regression since qemu version 2.8 - -Hi, - -I have noticed a regression when I upgraded from qemu-armeb 2.7 to 2.8, and the problem is still present with version 2.10.1. - -I am using qemu for GCC validation, noticed problems with testcases involving atomics, I'm attaching here atomic-exchange-4.exe. - -# with 2.7: -$ qemu-armeb -cpu any -R 0 -L $PWD -E LD_LIBRARY_PATH=$PWD/lib $PWD/atomic-exchange-4.exe -$ echo $? -0 -# with 2.8, 2.10.1: -$ qemu-armeb -cpu any -R 0 -L $PWD -E LD_LIBRARY_PATH=$PWD/lib $PWD/atomic-exchange-4.exe -qemu: uncaught target signal 6 (Aborted) - core dumped -Aborted (core dumped) -$ echo $? -134 - -The source code is gcc/testsuite/gcc.dg/atomic-exchange-4.c - -Running with -d in_asm shows a difference early in the startup code: -IN: _dl_sysdep_start -[...] -0x40a17790: 908ff103 addls pc, pc, r3, lsl #2 - -and then the next address is not the same with qemu 2.7 and 2.10.1 - -I hope you have enough data/information to reproduce and confirm/fix the problem. - -Thanks \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1726394 b/results/classifier/zero-shot-user-mode/output/instruction/1726394 deleted file mode 100644 index f6e19da63..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1726394 +++ /dev/null @@ -1,11 +0,0 @@ -instruction: 0.503 -syscall: 0.388 -runtime: 0.109 - - - -Passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address) - -qemu-user passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address) unmodified, but the third argument is an address to a BPF filter, causing an EFAULT. Now, the filter is architecture-specifc, so you can't just rewrite the addresses, so the safest bet is to just return an error here. - -I guess you should just return EINVAL, but not sure. I'd really like something that can be identified, so seccomp errors can be ignored when it's not supported. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1729 b/results/classifier/zero-shot-user-mode/output/instruction/1729 deleted file mode 100644 index bed8862c9..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1729 +++ /dev/null @@ -1,53 +0,0 @@ -instruction: 0.526 -runtime: 0.308 -syscall: 0.166 - - - -mremap fails with EFAULT if address range overlaps with stack guard -Description of problem: -When running 32-bit user-static on 64-bit host, `mremap` behave differently from the kernel. This difference let programs that call `pthread_getattr_np` on musl-libc to run into a loop on repeated calling `mremap`. - -https://git.musl-libc.org/cgit/musl/plain/src/thread/pthread_getattr_np.c - -``` c - while (mremap(p-l-PAGE_SIZE, PAGE_SIZE, 2*PAGE_SIZE, 0)==MAP_FAILED && errno==ENOMEM) - l += PAGE_SIZE; -``` -Steps to reproduce: -Compile the following program against musl-libc arm 32-bit, and run it in qemu-user-static on x86_64 host. - -``` c -#define _GNU_SOURCE -#include <pthread.h> - -int main(int argc, char *argv[]) { - pthread_attr_t attr; - return pthread_getattr_np(pthread_self(), &attr); -} -``` - -For example, on x86_64 fedora 38 with podman and qemu-user-static installed, we can reproduce this with alpine container: - -``` -$ podman run --rm -it --arch arm/v7 docker.io/library/alpine:latest - -/ # apk add alpine-sdk - -...... - -/ # cat test.c -#define _GNU_SOURCE -#include <pthread.h> - -int main(int argc, char *argv[]) { - pthread_attr_t attr; - return pthread_getattr_np(pthread_self(), &attr); -} - -/ # gcc test.c - -/ # ./a.out -``` -Additional information: -Original thread on musl mail list where this was initially reported: https://www.openwall.com/lists/musl/2017/06/15/9 diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1734 b/results/classifier/zero-shot-user-mode/output/instruction/1734 deleted file mode 100644 index b63d23c45..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1734 +++ /dev/null @@ -1,22 +0,0 @@ -instruction: 0.550 -runtime: 0.285 -syscall: 0.164 - - - -mmap-ing more than 1GB of files fails on v8.0 of QEMU, but works on older version -Description of problem: -Trying to run an application using QEMU user mode for an ARM binary. My host system is Ubuntu 22.04 based. The v6.2 from Ubuntu repos is able to mmap files that contain more than 1GB of address space, but version 8.0 that I compiled will not. - -I created a repo with a readme, and a simple application that you can use to demonstrate the problem: -https://github.com/mwales/qemu_mmap_test - -Example application simply takes a list of files, mmaps the entire file into memory, and then computes a checksum of the file data. Once the file(s) sizes exceed around 1GB, the mmap calls will fail because the memory from 0x00000000 - 0x40000000 has been exhausted. -Steps to reproduce: -1. Compile test application that mmaps entire files -2. Create 5 256MB test files -3. Run the program tell it to mmap all the files. The first 3 files succeed, but the 4th when run gets a -1 returned from mmap. -Additional information: -Lots of details on my github writeup and a demo of the bug in question. - -It seems that this 1GB limit is an artifact of where QEMU loaded the original ELF binary at (0x40000000). I've also been playing around with moving that address using the -B 0x80000000 option, but I've encountered other problems doing that. As I diagnose that, I figured I would write up this report on what I've seen so far incase I'm doing something dumb / creating a bad build or something. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1737 b/results/classifier/zero-shot-user-mode/output/instruction/1737 deleted file mode 100644 index 307c29e67..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1737 +++ /dev/null @@ -1,55 +0,0 @@ -instruction: 0.516 -runtime: 0.261 -syscall: 0.223 - - - -qemu-aarch64: Incorrect result for ssra instruction when using vector lengths of 1024-bit or higher. -Description of problem: -``` -#include <arm_sve.h> -#include <stdio.h> - -#define SZ 32 - -int main(int argc, char* argv[]) { - svbool_t pg = svptrue_b64(); - uint64_t VL = svcntd(); - - fprintf(stderr, "One SVE vector can hold %li uint64_ts\n", VL); - - int64_t sr[SZ], sx[SZ], sy[SZ]; - uint64_t ur[SZ], ux[SZ], uy[SZ]; - - for (uint64_t i = 0; i < SZ; ++i) { - sx[i] = ux[i] = 0; - sy[i] = uy[i] = 1024; - } - - for (uint64_t i = 0; i < SZ; i+=VL) { - fprintf(stderr, "Processing elements %li - %li\n", i, i + VL - 1); - - svint64_t SX = svld1(pg, sx + i); - svint64_t SY = svld1(pg, sy + i); - svint64_t SR = svsra(SX, SY, 4); - svst1(pg, sr + i, SR); - - svuint64_t UX = svld1(pg, ux + i); - svuint64_t UY = svld1(pg, uy + i); - svuint64_t UR = svsra(UX, UY, 4); - svst1(pg, ur + i, UR); - } - - for (uint64_t i = 0; i < SZ; ++i) { - fprintf(stderr, "sr[%li]=%li, ur[%li]\n", i, sr[i], ur[i]); - } - - return 0; -} -``` -Steps to reproduce: -1. Build the above C source using "gcc -march=armv9-a -O1 ssra.c", can also use clang. -2. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=64 ./a.out" and you'll see the expected result of 64 (signed and unsigned) -3. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=128 ./a.out" and you'll see the expected result of 64 for unsigned but the signed result is 0. This suggests the emulation of SVE2 ssra instruction is incorrect for this and bigger vector lengths. -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1738434 b/results/classifier/zero-shot-user-mode/output/instruction/1738434 deleted file mode 100644 index 63f53b8e2..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1738434 +++ /dev/null @@ -1,34 +0,0 @@ -instruction: 0.485 -syscall: 0.279 -runtime: 0.235 - - - -CALL FWORD PTR [ESP] handled incorrectly - -To keep the story short, this 32-bit code crashes on 64-bit Windows whereas it works fine on real system and VMware: - - push 33h - push offset _far_call - call fword ptr[esp] - jmp _ret -_far_call: - retf -_ret: - -32-bit code running under WoW64 on 64-bit Windows has the ability to switch to the 64-bit mode via so called "Heaven's gate". In order to do that you have to make a far call/jmp by 0x33 selector how the code snippet above shows. QEMU throws an access violation exception whereas the code snippet runs with no problems on real CPU and VMware. By the way, this code works fine under QEMU, I hope it gives you a hint where to look: - - push 23h - push offset _far_call - call fword ptr[esp] - jmp _ret -_far_call: - retf -_ret: - -0x23 is a default 32-bit selector for 32-bit processes running under WoW64. - -Environment: -QEMU: 2.10.93, command line: qemu-system-x86_64.exe -m 2G -snapshot -cdrom full_path_to_iso fullP_path_to_img -Guest OS: Windows 7 x64 SP1 build 7601 or Windows 10 version 1709 build 16299.19 -Host OS: Windows 10 x64 version 1703 build 15063.786 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1740219 b/results/classifier/zero-shot-user-mode/output/instruction/1740219 deleted file mode 100644 index f8f0681f3..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1740219 +++ /dev/null @@ -1,65 +0,0 @@ -instruction: 0.377 -runtime: 0.321 -syscall: 0.302 - - - -static linux-user ARM emulation has several-second startup time - -static linux-user emulation has several-second startup time - -My problem: I'm a Parabola packager, and I'm updating our -qemu-user-static package from 2.8 to 2.11. With my new -statically-linked 2.11, running `qemu-arm /my/arm-chroot/bin/true` -went from taking 0.006s to 3s! This does not happen with the normal -dynamically linked 2.11, or the old static 2.8. - -What happens is it gets stuck in -`linux-user/elfload.c:init_guest_space()`. What `init_guest_space` -does is map 2 parts of the address space: `[base, base+guest_size]` -and `[base+0xffff0000, base+0xffff0000+page_size]`; where it must find -an acceptable `base`. Its strategy is to `mmap(NULL, guest_size, -...)` decide where the first range is, and then check if that -+0xffff0000 is also available. If it isn't, then it starts trying -`mmap(base, ...)` for the entire address space from low-address to -high-address. - -"Normally," it finds an accaptable `base` within the first 2 tries. -With a static 2.11, it's taking thousands of tries. - ----- - -Now, from my understanding, there are 2 factors working together to -cause that in static 2.11 but not the other builds: - - - 2.11 increased the default `guest_size` from 0xf7000000 to 0xffff0000 - - PIE (and thus ASLR) is disabled for static builds - -For some reason that I don't understand, with the smaller -`guest_size` the initial `mmap(NULL, guest_size, ...)` usually -returns an acceptable address range; but larger `guest_size` makes it -consistently return a block of memory that butts right up against -another already mapped chunk of memory. This isn't just true on the -older builds, it's true with the 2.11 builds if I use the `-R` flag to -shrink the `guest_size` back down to 0xf7000000. That is with -linux-hardened 4.13.13 on x86-64. - -So then, it it falls back to crawling the entire address space; so it -tries base=0x00001000. With ASLR, that probably succeeds. But with -ASLR being disabled on static builds, the text segment is at -0x60000000; which is does not leave room for the needed -0xffff1000-size block before it. So then it tries base=0x00002000. -And so on, more than 6000 times until it finally gets to and passes -the text segment; calling mmap more than 12000 times. - ----- - -I'm not sure what the fix is. Perhaps try to mmap a continuous chunk -of size 0xffff1000, then munmap it and then mmap the 2 chunks that we -actually need. The disadvantage to that is that it does not support -the sparse address space that the current algorithm supports for -`guest_size < 0xffff0000`. If `guest_size < 0xffff0000` *and* the big -mmap fails, then it could fall back to a sparse search; though I'm not -sure the current algorithm is a good choice for it, as we see in this -bug. Perhaps it should inspect /proc/self/maps to try to find a -suitable range before ever calling mmap? \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1741 b/results/classifier/zero-shot-user-mode/output/instruction/1741 deleted file mode 100644 index 34b8096fd..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1741 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.653 -runtime: 0.181 -syscall: 0.166 - - - -95059f9c313a7fbd7f22e4cdc1977c0393addc7b breaks some 32bit architectures in linux-user on amd64 diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1748296 b/results/classifier/zero-shot-user-mode/output/instruction/1748296 deleted file mode 100644 index 6c26d4608..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1748296 +++ /dev/null @@ -1,31 +0,0 @@ -instruction: 0.733 -runtime: 0.168 -syscall: 0.099 - - - -TCG throws Invalid Opcode when executing x86 BMI shlx instruction - -I am unable to use BMI in my project when running under TCG. I narrowed the problem down to incorrect instruction decoding for BMI instructions (which have a 2 byte VEX prefix). The gen_sse function in translate.c reaches the goto label do_0f_38_fx, but b does not equal 0x1f7, 0x2f7, or 0x3f7, so the switch takes the default path and raises an invalid opcode exception. - -The code executes correctly and passes the test under KVM. - -I have created a complete repro here: https://github.com/doug65536/qemu-bmibug - -The makefile has the following utility targets: - -debug-kvm: Build and run the VM using KVM and wait for gdbstub attach - -run: Run the test case with TCG, make fails if the test fails. (It will fail) - -run-kvm: Run the test case with KVM, make fails if the test fails. (It will succeed) - -debug: Build and run the VM with TCG and wait for GDB attach - -attach-gdb: Run GDB and attach to KVM gdbstub - -The VM runs with -cpu max. CPUID reports support for BMI, BMI2, and ABM. - -You can quickly verify the issue by executing `make run-kvm` to confirm that KVM passes, then `make run` to confirm that TCG fails. - -I believe the bug affects other BMI, BMI2, and ABM instructions, but I have only completely verified incorrect execution of SHLX. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1748612 b/results/classifier/zero-shot-user-mode/output/instruction/1748612 deleted file mode 100644 index c3b69847a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1748612 +++ /dev/null @@ -1,21 +0,0 @@ -instruction: 0.542 -runtime: 0.277 -syscall: 0.181 - - - -qemu-user option -strace -D <file> doesn't work - -I have been trying to access qemu -strace output from a script -The main problem was it was on stderr, the strace output was merged with my program's stderr output. -Then I tried to use the -D option, to log the output to a file. -This didn't work even if the log file was created, but it was empty. - -I have looked at the source code and found the print function was not qemu_log with -strace but gemu_log (to be clear it was GEMU NOT QEMU) - - -I have then replaced all gemu_log by qemu_log removed declaration of gemu_log and recompiled, it seems to works just fine right now. - -removed declaration here and here: -https://github.com/qemu/qemu/blob/master/linux-user/main.c#L108 -https://github.com/qemu/qemu/blob/master/linux-user/qemu.h#L203 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1749393 b/results/classifier/zero-shot-user-mode/output/instruction/1749393 deleted file mode 100644 index 666458855..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1749393 +++ /dev/null @@ -1,32 +0,0 @@ -instruction: 0.613 -runtime: 0.288 -syscall: 0.099 - - - -sbrk() not working under qemu-user with a PIE-compiled binary? - -In Debian unstable, we recently switched bash to be a PIE-compiled binary (for hardening). Unfortunately this resulted in bash being broken when run under qemu-user (for all target architectures, host being amd64 for me). - -$ sudo chroot /srv/chroots/sid-i386/ qemu-i386-static /bin/bash -bash: xmalloc: .././shell.c:1709: cannot allocate 10 bytes (0 bytes allocated) - -bash has its own malloc implementation based on sbrk(): -https://git.savannah.gnu.org/cgit/bash.git/tree/lib/malloc/malloc.c - -When we disable this internal implementation and rely on glibc's malloc, then everything is fine. But it might be that glibc has a fallback when sbrk() is not working properly and it might hide the underlying problem in qemu-user. - -This issue has also been reported to the bash upstream author and he suggested that the issue might be in qemu-user so I'm opening a ticket here. Here's the discussion with the bash upstream author: -https://lists.gnu.org/archive/html/bug-bash/2018-02/threads.html#00080 - -You can find the problematic bash binary in that .deb file: -http://snapshot.debian.org/archive/debian/20180206T154716Z/pool/main/b/bash/bash_4.4.18-1_i386.deb - -The version of qemu I have been using is 2.11 (Debian package qemu-user-static version 1:2.11+dfsg-1) but I have had reports that the problem is reproducible with older versions (back to 2.8 at least). - -Here are the related Debian bug reports: -https://bugs.debian.org/889869 -https://bugs.debian.org/865599 - -It's worth noting that bash used to have this problem (when compiled as a PIE binary) even when run directly but then something got fixed in the kernel and now the problem only appears when run under qemu-user: -https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1751422 b/results/classifier/zero-shot-user-mode/output/instruction/1751422 deleted file mode 100644 index 55fb2b16d..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1751422 +++ /dev/null @@ -1,10 +0,0 @@ -instruction: 0.931 -runtime: 0.047 -syscall: 0.022 - - - -some instructions translate error in x86 - -There is some instructions translation error on target i386 in many versions, such as 2.11.1, 2.10.2, 2.7.1 and so on. -The error translation instructions include les, lds. I has got a patch, but I have no idea how to apply it. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1751494 b/results/classifier/zero-shot-user-mode/output/instruction/1751494 deleted file mode 100644 index b4acf134b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1751494 +++ /dev/null @@ -1,42 +0,0 @@ -instruction: 0.849 -runtime: 0.086 -syscall: 0.064 - -instruction: 0.878 -graphic: 0.676 -assembly: 0.586 -device: 0.585 -semantic: 0.580 -mistranslation: 0.510 -other: 0.502 -socket: 0.335 -network: 0.320 -vnc: 0.279 -boot: 0.154 -KVM: 0.051 - -tcg-target.inc.c:3495:no such instruction: `xgetbv' - -While building QEMU on Mac OS 10.6.8 I saw this error message: -tag-target.inc.c:3495:no such instruction: `xgetbv' -In the file tcg/i386/tcg-target.inc.c at line 3495 is where the issue is located. This is the problem code: -asm ("xgetbv" : "=a" (xcrl), "=d" (xcrh) : "c" (0)); - -https://github.com/asmjit/asmjit/issues/78 -According to the above link, another project also experienced this problem on Mac OS X. The fix was to replace the name of the instruction with the encoded form '.byte 0x0F, 0x01, 0xd0'. - -Host info: -Mac OS 10.6.8 -GCC 5.2.0 - -Additional information: -This may be a gcc issue. I have compiled QEMU on Mac OS 10.12 and didn't experience any issues. The compiler used was Apple's clang. - -The exact commit that causes this problem is this: - -commit 770c2fc7bb70804ae9869995fd02dadd6d7656ac -tcg/i386: Add vector operations - -This has been fixed here: -https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1019242af11400252 - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1755 b/results/classifier/zero-shot-user-mode/output/instruction/1755 deleted file mode 100644 index af2d0153a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1755 +++ /dev/null @@ -1,26 +0,0 @@ -instruction: 0.630 -runtime: 0.203 -syscall: 0.167 - - - -qemu-arm fails to execute a cortex-M binary (page_set_flags: Assertion 'last <= GUEST_ADDR_MAX' failed.) -Description of problem: -I've noticed that qemu-arm (so linux-user mode) fails to execute a binary targeting cortex-M. This used to work until commit -"Make the commpage executable". -Steps to reproduce: -1. Compile a simple hello.c for arm-eabi. If you don't have such a toolchain, you can download one from https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads For instance https://developer.arm.com/-/media/Files/downloads/gnu/12.2.rel1/binrel/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi.tar.xz (for an x86_64 linux host) - -2.# compile for cortex-m3: - -3. arm-none-eabi-gcc hello.c -o hello.exe.m3 -mcpu=cortex-m3 -specs=rdimon.specs - -4.qemu-arm -cpu cortex-m3 hello.exe.m3 -.....user-exec.c:492: page_set_flags: Assertion 'last <= GUEST_ADDR_MAX' failed. - -5. # compile for cortex-a9: - -6. arm-none-eabi-gcc hello.c -o hello.exe.a9 -mcpu=cortex-a9 -specs=rdimon.specs - -7. qemu-arm -cpu cortex-a9 hello.exe.a9 -Hello diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1756 b/results/classifier/zero-shot-user-mode/output/instruction/1756 deleted file mode 100644 index 106fc0f59..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1756 +++ /dev/null @@ -1,49 +0,0 @@ -instruction: 0.406 -runtime: 0.322 -syscall: 0.272 - - - -qemu8-user on Linux: SIGSEGV because brk(NULL) does not exist -Description of problem: -On Linux, the return value of the system call brk(NULL) need not point to a page that exists. -If so, then qemu8-user will generate SIGSEGV at the next call to brk() with a higher value, -because qemu8 believes that it should maintain contiguous .bss with bytes of value 0. -Thus qemu8-user so calls `memset(g2h_untagged(target_brk), 0, brk_page - target_brk); -in do_brk() at ../linux-user/syscall.c:867, and this generates SIGSEGV at -the non-existent page that covers brk(NULL). - -Instead, the safest thing to do is nothing at all. -Linux deliberately returns a random value for brk(NULL), subject to the conditions -that the value be at least as large as the maximum over all PT_LOAD of (.p_vaddr + .p_memsz), -and "somewhat near" that maximum. The purpose of randomness is to use variability -to interfere with effectiveness of malware, and to expose application coding errors -regarding brk() and sbrk(). If qemu-user wants to preserve contiguous .bss, -then qemu-user should call memset() only if the first page of the range exists. -(As explained in the next paragraph, "contiguous .bss" is a murky concept.) - -Linux itself is partly to blame, because it computes the maximum (.p_vaddr + .p_memsz) -over all the PT_LOAD of the most recent execve(). The most recent execve() seen by -Linux might have no relationship to the state of the address space at the time of -_either_ call to brk(). The app can do arbitrary mmap, munmap, mprotect at any time. -In particular, the run-time de-compressor of UPX does exactly that for a compressed -main program. The maximum computed by Linux is for the compressed program, -which has a different layout than the de-compressed program. - -There is a Linux system call prctl(PR_SET_MM_BRK, new_value) which sets a value -for "the brk", but that syscall tries to validate the new_value based on -the most recent execve(). Once again, that has no relationship to the current -layout of the address space produced by the UPX de-compressor. -Steps to reproduce: -1. build qemu8-x86_64 from -``` -commit fcb237e64f9d026c03d635579c7b288d0008a6e5 (HEAD -> master, origin/master, origin/HEAD) -Merge: 2ff49e96ac c00aac6f14 -Date: Mon Jul 10 09:17:06 2023 +0100 -``` -2. run `build/qemu-x86_64 -strace upx-4.0.2-amd64_linux/upx --version` where the upx -is from https://github.com/upx/upx/releases/download/v4.0.2/upx-4.0.2-amd64_linux.tar.xz -3. output ends with -``` -372621 close(3) = 0 -372621 munmap(0x0000004000803000,3055) = 0 diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1756519 b/results/classifier/zero-shot-user-mode/output/instruction/1756519 deleted file mode 100644 index 4b7715c5b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1756519 +++ /dev/null @@ -1,52 +0,0 @@ -instruction: 0.362 -runtime: 0.355 -syscall: 0.283 - - - -qemu linux-user crash in QOM path canonicalization during do_fork() call to cpu_create - -qemu-riscv64 version 2.11.50 (v2.11.0-2491-g2bb39a657a) crashes running gcc libgomp.c/sort-1.c testsuite test case with the following message: - -(process:11683): GLib-CRITICAL **: g_hash_table_iter_next: assertion 'ri->version == ri->hash_table->version' failed -** -ERROR:qom/object.c:1665:object_get_canonical_path_component: code should not be reached -qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x60139c16 - - -Backtrace obtained via gdb: - -#0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 -#1 0x0000000060139b21 in abort () at abort.c:79 -#2 0x0000000060100505 in g_assertion_message (domain=domain@entry=0x0, file=file@entry=0x60213ca1 "qom/object.c", line=line@entry=1665, - func=func@entry=0x60214420 <__func__.18106> "object_get_canonical_path_component", message=message@entry=0x7fffe8000cd0 "code should not be reached") - at gtestutils.c:2430 -#3 0x0000000060100586 in g_assertion_message_expr (domain=0x0, file=0x60213ca1 "qom/object.c", line=1665, - func=0x60214420 <__func__.18106> "object_get_canonical_path_component", expr=<optimized out>) at gtestutils.c:2453 -#4 0x0000000060098334 in object_get_canonical_path_component (obj=0x7fffe81340b0) at qom/object.c:1665 -#5 0x0000000060098366 in object_get_canonical_path (obj=0x7fffe81340b0) at qom/object.c:1675 -#6 0x000000006008e152 in device_set_realized (obj=0x7fffe81340b0, value=true, errp=0x7ffff762fe68) at hw/core/qdev.c:874 -#7 0x0000000060098bf4 in property_set_bool (obj=0x7fffe81340b0, v=0x7fffe80fd3c0, name=0x60213694 "realized", opaque=0x7fffe80fd140, errp=0x7ffff762fe68) - at qom/object.c:1926 -#8 0x0000000060096fee in object_property_set (obj=0x7fffe81340b0, v=0x7fffe80fd3c0, name=0x60213694 "realized", errp=0x7ffff762fe68) at qom/object.c:1122 -#9 0x0000000060099ebd in object_property_set_qobject (obj=0x7fffe81340b0, value=0x7fffe80fd310, name=0x60213694 "realized", errp=0x7ffff762fe68) - at qom/qom-qobject.c:27 -#10 0x0000000060097274 in object_property_set_bool (obj=0x7fffe81340b0, value=true, name=0x60213694 "realized", errp=0x7ffff762fe68) at qom/object.c:1191 -#11 0x0000000060092ec5 in cpu_create (typename=0x6250e1a0 "any-riscv-cpu") at qom/cpu.c:61 -#12 0x000000006009301a in cpu_generic_init (typename=0x601dd58f "riscv-cpu", cpu_model=0x601dd527 "any") at qom/cpu.c:98 -#13 0x000000006004cb61 in cpu_copy (env=0x7ffff008cd60) at /opt/qemu/linux-user/main.c:3881 -#14 0x000000006005b79a in do_fork (env=0x7ffff008cd60, flags=4001536, newsp=275531880704, parent_tidptr=275531882704, newtls=275531884288, - child_tidptr=275531882704) at /opt/qemu/linux-user/syscall.c:6348 -#15 0x0000000060063e56 in do_syscall (cpu_env=0x7ffff008cd60, num=220, arg1=4001536, arg2=275531880704, arg3=275531882704, arg4=275531884288, - arg5=275531882704, arg6=275531884288, arg7=0, arg8=0) at /opt/qemu/linux-user/syscall.c:10001 -#16 0x000000006004c89f in cpu_loop (env=0x7ffff008cd60) at /opt/qemu/linux-user/main.c:3600 -#17 0x000000006005b68f in clone_func (arg=0x7ffff7775050) at /opt/qemu/linux-user/syscall.c:6311 -#18 0x0000000060121797 in start_thread (arg=0x7ffff7632700) at pthread_create.c:463 -#19 0x000000006019b4fb in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 - - -Attached is a test case source code extracted from libgomp test suite. - -Note that it is a multi-threaded and requires 5 or more threads to fail. Number of launched threads is controlled by OMP_NUM_THREADS evironment variable, defaulting to number of hardware threads. Changing constants in the test case makes it fail with different numbers of threads. - -I will attach statically linked riscv64 binary executable if size limits permit. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1756807 b/results/classifier/zero-shot-user-mode/output/instruction/1756807 deleted file mode 100644 index 9c75e0c1c..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1756807 +++ /dev/null @@ -1,73 +0,0 @@ -instruction: 0.389 -runtime: 0.351 -syscall: 0.260 - - - -performance regression in qemu-user + proot - -To reproduce: - -1. Install qemu-user-static and proot -2. Enter some arm chroot using them: - - proot -0 -q qemu-arm-static -w / -r chroot/ /bin/bash - -3. Run a command which normally takes a short but measurable amount of time: - - cd /usr/share/doc && time grep -R hello - -Result: - -This is over 100 times slower on 18.04 than it was on 16.04. I am not sure if proot or qemu is causing the problem, but proot version has not changed. Also note that on 16.04 I am using the cloud repo version of qemu, which is newer than 16.04 stock, but still older than 18.04. - -Although system 2 is lower spec than system 1, it should not be this much slower. No other software seems to be affected. - -If required I can supply a chroot tarball. It is essentially just a Debian bootstrap though. - -Logs: - - - -System 1: i7-6700 3.4GHz, 32GB RAM, 512GB Crucial MX100 SSD, Ubuntu 16.04 -qemu-arm version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.4~cloud0) -proot 5.1.0 - -al@al-desktop:~/rpi-ramdisk/raspbian$ proot -0 -q qemu-arm-static -w / -r root/ /bin/bash -root@al-desktop:/# cd /usr/share/doc -root@al-desktop:/usr/share/doc# time grep -R hello -dash/copyright:Debian GNU/Linux hello source package as the file COPYING. If not, - -real 0m0.066s -user 0m0.040s -sys 0m0.008s - - - - - -System 2: i5-5300U 2.30GHz, 8GB RAM, 256GB Crucial MX300 SSD, Ubuntu 18.04 -qemu-arm version 2.11.1(Debian 1:2.11+dfsg-1ubuntu4) -proot 5.1.0 - -al@al-thinkpad:~/rpi-ramdisk/raspbian$ proot -0 -q qemu-arm-static -w / -r root/ /bin/bash -root@al-thinkpad:/# cd /usr/share/doc -root@al-thinkpad:/usr/share/doc# time grep -R hello -dash/copyright:Debian GNU/Linux hello source package as the file COPYING. If not, - -real 0m24.176s -user 0m0.366s -sys 0m11.352s - -ProblemType: Bug -DistroRelease: Ubuntu 18.04 -Package: qemu (not installed) -ProcVersionSignature: Ubuntu 4.15.0-12.13-generic 4.15.7 -Uname: Linux 4.15.0-12-generic x86_64 -ApportVersion: 2.20.8-0ubuntu10 -Architecture: amd64 -Date: Mon Mar 19 07:13:25 2018 -InstallationDate: Installed on 2018-03-18 (0 days ago) -InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180318) -SourcePackage: qemu -UpgradeStatus: No upgrade log present (probably fresh install) \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1761153 b/results/classifier/zero-shot-user-mode/output/instruction/1761153 deleted file mode 100644 index 2cfbd1643..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1761153 +++ /dev/null @@ -1,29 +0,0 @@ -instruction: 0.571 -runtime: 0.295 -syscall: 0.134 - - - -qemu-user incorrect mmap for large files on 64bits host and 32bits executable. - -qemu-user seems to incorrectly mmap a file if the offset is > 4GiB and guest binary is 32 bits elf. - -See attached test program `test_mmap.c`. - -``` -$ gcc -g -m32 -march=i386 test_mmap.c -o test_mmap -$ file test_mmap -test_mmap: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e36db05f4dfd8a9cfde8a969214a242c1f5a4b49, with debug_info, not stripped -$ uname -a -Linux localhost.localdomain 4.15.10-300.fc27.x86_64 #1 SMP Thu Mar 15 17:13:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux -$ qemu-i386 --version -qemu-i386 version 2.10.1(qemu-2.10.1-2.fc27) -Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers -$ ./test_mmap -$ qemu-i386 test_mmap -Incorrect data 1 -``` - -Tested with qemu-i386 packaged in Fedora 27 and qemu-i386 compiled from git master (094b62cd9c) - -The issue was firstly detected on (more complex program) using qemu-arm (with 32bits binary) so it is probably a 32/64bits problem independently of the cpu family. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1761401 b/results/classifier/zero-shot-user-mode/output/instruction/1761401 deleted file mode 100644 index 27bd12965..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1761401 +++ /dev/null @@ -1,16 +0,0 @@ -instruction: 0.601 -runtime: 0.202 -syscall: 0.198 - - - -ARM/Neon: vcvt rounding error - -Hello, - -While using QEMU commit 47d3b60858d90ac8a0cc3a72af7f95c96781125a (March 28, 2018), I've noticed failures in one of the GCC ARM/Neon tests. The test passes on hardware, and with QEMU-2.11.0, so it looks like a recent regression. - -The test builds a vector of 4 float32 with "125.9" as value, then converts them to 4 uint32_t. -The expected result is 125, but we get 126 instead. - -Maybe it's just a matter of default rounding mode? \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1763 b/results/classifier/zero-shot-user-mode/output/instruction/1763 deleted file mode 100644 index a2f449bd2..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1763 +++ /dev/null @@ -1,18 +0,0 @@ -instruction: 0.468 -syscall: 0.315 -runtime: 0.217 - - - -ldd fails with qemu-aarch64 -Description of problem: -see the original issue for full details https://github.com/multiarch/qemu-user-static/issues/172 -Steps to reproduce: -1. docker run --rm -it arm64v8/ubuntu:16.04 ldd /bin/ls - -Also possible on other newer OSs (eg: Ubuntu:18.04) with different compiled binaries. -Additional information: -``` -WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested -ldd: exited with unknown exit code (139) -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1768 b/results/classifier/zero-shot-user-mode/output/instruction/1768 deleted file mode 100644 index 5f2f92cfe..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1768 +++ /dev/null @@ -1,38 +0,0 @@ -instruction: 0.697 -runtime: 0.162 -syscall: 0.141 - - - -Could not allocate more than ~2GB with qemu-user -Description of problem: -On qemu-user, failed to allocate more than about 2GB on 32bit platform supporting up to 4GB (arm, ppc, etc.) -Steps to reproduce: -1. Try to allocate more than 2GB [e.g. for(i=0;i<64;i++) if(malloc(64*1024*1024)==NULL) perror("Failed to allocate 64MB");] -2. Only 1 64MB chunck is allocated in the upper 2GB memory space -3. Failed to allocate after about 2GB. -Additional information: -The problem is in **pageflags_find** and **pageflags_next** functions (found in _accel/tcg/user-exec.c_) 3rd parameters, that should be **target_ulong** instead of incorrect _target_long_ (the parameter will be converted signed extended to uint64_t). -The testing program is the following: -``` -#include <stdio.h> -#include <stdlib.h> - -int main(int argc,char *argv[]) { - unsigned int a; - unsigned int i; - char *al; - unsigned int sss=1U*1024*1024*64; - for(a=0;a<128;a++) { - al=malloc(sss); - if(al!=NULL) { - printf("ALLOC OK %u (%08lX)!\n",sss*(a+1),al); - } - else { - printf("Cannot alloc %d\n",(a+1)*sss); - perror("Cannot alloc"); - exit(1); - } - } -} -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1768246 b/results/classifier/zero-shot-user-mode/output/instruction/1768246 deleted file mode 100644 index af5c82ba4..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1768246 +++ /dev/null @@ -1,19 +0,0 @@ -instruction: 0.490 -runtime: 0.327 -syscall: 0.183 - - - -cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. - -OpenJDK no longer works on qemu-sh4, it previously did after #1735384 was fixed. - -Crash indicates an assertion failure: - -(sid-sh4-sbuild)root@nofan:/# java --version -qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. -qemu: uncaught target signal 6 (Aborted) - core dumped -Aborted -(sid-sh4-sbuild)root@nofan:/# - -Haven't bi-sected the issue yet, but will do so later. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1770 b/results/classifier/zero-shot-user-mode/output/instruction/1770 deleted file mode 100644 index 474992070..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1770 +++ /dev/null @@ -1,28 +0,0 @@ -instruction: 0.568 -syscall: 0.224 -runtime: 0.208 - - - -Wrong unpacked structure for epoll_event on qemu-or1k (openrisc) -Description of problem: -When using cmake automoc, the process will infinite loop waiting for epoll_events. -Steps to reproduce: -1. Try to compile cmake with qt5 support -2. The build process will freeze when "Automatic MOC" is invoked -Additional information: -The problem is that or1k has a "packed" epoll_event structure, so it should be also packed in target_epoll_event structure. -Following the (very trivial) patch: -``` ---- qemu-20230327/linux-user/syscall_defs.h.orig 2023-03-27 15:41:42.000000000 +0200 -+++ qemu-20230327/linux-user/syscall_defs.h 2023-06-30 17:29:39.034322213 +0200 -@@ -2714,7 +2709,7 @@ - #define FUTEX_CMD_MASK ~(FUTEX_PRIVATE_FLAG | FUTEX_CLOCK_REALTIME) - - #ifdef CONFIG_EPOLL --#if defined(TARGET_X86_64) -+#if defined(TARGET_X86_64) || defined(TARGET_OPENRISC) - #define TARGET_EPOLL_PACKED QEMU_PACKED - #else - #define TARGET_EPOLL_PACKED -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1771 b/results/classifier/zero-shot-user-mode/output/instruction/1771 deleted file mode 100644 index 24181e1f0..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1771 +++ /dev/null @@ -1,39 +0,0 @@ -instruction: 0.733 -runtime: 0.138 -syscall: 0.129 - - - -Missing CASA instruction handling for SPARC qemu-user -Description of problem: -Qemu-sparc does not handle the CASA instruction, even if the selected CPU (in this case, LEON3) support it. -Steps to reproduce: -1. Launch a program that use CASA instruction (any program, also "ls" on a recent glibc [>=2.31]) -2. qemu-sparc will raise "Illegal instruction" -Additional information: -The following patch remove the missing handling, but it needs asi load/store that is not implemented for sparc32 user-space. - -``` -diff -urp qemu-20230327.orig/target/sparc/translate.c qemu-20230327/target/sparc/translate.c ---- qemu-20230327.orig/target/sparc/translate.c 2023-03-27 15:41:42.000000000 +0200 -+++ qemu-20230327/target/sparc/translate.c 2023-04-01 15:24:18.293176711 +0200 -@@ -5521,7 +5522,7 @@ static void disas_sparc_insn(DisasContex - case 0x37: /* stdc */ - goto ncp_insn; - #endif --#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) -+//#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) - case 0x3c: /* V9 or LEON3 casa */ - #ifndef TARGET_SPARC64 - CHECK_IU_FEATURE(dc, CASA); -@@ -5529,8 +5530,8 @@ static void disas_sparc_insn(DisasContex - rs2 = GET_FIELD(insn, 27, 31); - cpu_src2 = gen_load_gpr(dc, rs2); - gen_cas_asi(dc, cpu_addr, cpu_src2, insn, rd); -+//#endif - break; --#endif - default: - goto illegal_insn; - } -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1773743 b/results/classifier/zero-shot-user-mode/output/instruction/1773743 deleted file mode 100644 index 5055b19e7..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1773743 +++ /dev/null @@ -1,27 +0,0 @@ -instruction: 0.521 -runtime: 0.250 -syscall: 0.229 - - - -qemu-user -g xxx -E LD_PROFILE=xxx segfault - -Here is two simple steps to reproduce the bug: - -$ qemu-x86_64 -E LD_PROFILE=libc.so.6 -E LD_PROFILE_OUTPUT=. -g 12345 -L / /bin/ls - -(libc.so and /bin/ls might change on your system, in this case we just need a binary with a profilable needed library) - -In a other window launch: - -$ gdb -(gdb) target remote :12345 -(gdb) c - -At this point qemu will segfault. - -It seems this problem is appends when sigprof passed to gdb. -One way I have found to bypass this: -patch gdbstub.c gdb_handlesig and ignore sig if -sig == TARGET_SIGPROF -(which means now I can't catch sigprof on gdb anymore) \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1776478 b/results/classifier/zero-shot-user-mode/output/instruction/1776478 deleted file mode 100644 index c284359ca..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1776478 +++ /dev/null @@ -1,52 +0,0 @@ -instruction: 0.504 -runtime: 0.276 -syscall: 0.220 - - - -Getting qemu: uncaught target signal 6 when running lv2 plugin cross-compilation - -Hey, -I am part of the Zynthian team and we use qemu-arm-static to cross compile lv2 audio plugins. - -When running a compilation of DISTRHO-Ports we get: - -lv2_ttl_generator: pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. -qemu: uncaught target signal 6 (Aborted) - core dumped -./scripts/generate-ttl.sh: line 27: 16524 Aborted $GEN ./$FILE -Makefile:62: recipe for target 'gen_lv2' failed -make[1]: *** [gen_lv2] Error 134 -make[1]: Leaving directory '/home/pi/zynthian-sw/plugins/DISTRHO-Ports' -Makefile:104: recipe for target 'lv2' failed -make: *** [lv2] Error 2 - - -lv2_ttl_generator source is here: -https://github.com/DISTRHO/DISTRHO-Ports/tree/master/libs/lv2-ttl-generator - -The command that is ruining is -lv2_ttl_generator ./TAL-Filter-2.so - -And ./TAL-Filter-2.so source is here: -https://github.com/DISTRHO/DISTRHO-Ports/tree/master/ports/tal-filter-2/source - - - -Is there a way to debug what is going on? -This runs fine on a Raspberrypi which is armv7 - -A workaround would also help. - - -Bug in Zynthian: -https://github.com/zynthian/zynthian-sys/issues/59 -Bug in DISTRHO-Ports: -https://github.com/DISTRHO/DISTRHO-Ports/issues/29 - -Using qemu-arm-static version from master from two days ago: -qemu-arm version 2.12.50 (v2.12.0-1182-ga7a7309ca5-dirty), commit: a7a7309ca52c327c6603d60db90ae4feeae719f7 - -Also saw this in qemu-arm version 2.12.0 (Debian 1:2.12+dfsg-3) - -Thanks, -Guy \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1777226 b/results/classifier/zero-shot-user-mode/output/instruction/1777226 deleted file mode 100644 index 42b33b0f9..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1777226 +++ /dev/null @@ -1,21 +0,0 @@ -instruction: 0.608 -syscall: 0.213 -runtime: 0.179 - - - -qemu-user warnings confuse userland applications - -I recently observed that warning messages emitted by qemu-user can confuse applications when reading from stdout/stderr. This was observed with the configure script of OpenJDK-11 on qemu-sh4: - -configure: Found potential Boot JDK using configure arguments -configure: Potential Boot JDK found at /usr/lib/jvm/java-10-openjdk-sh4 is incorrect JDK version (qemu: Unsupported syscall: 318); ignoring -configure: (Your Boot JDK version must be one of: 10 11) -configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK -configure exiting with result code 1 - -See: https://buildd.debian.org/status/fetch.php?pkg=openjdk-11&arch=sh4&ver=11%7E18-1&stamp=1529119043&raw=0 - -Commenting out the line of code which emits the warning fixes the problem for me and the configure script finishes without problems. - -Thus, qemu should be modified to avoid cluttering stdout or stderr with its own messages and rather send those warnings to a log file or similar. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1779 b/results/classifier/zero-shot-user-mode/output/instruction/1779 deleted file mode 100644 index 9162a7df6..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1779 +++ /dev/null @@ -1,36 +0,0 @@ -instruction: 0.581 -runtime: 0.255 -syscall: 0.164 - - - -PowerPC AltiVec source vector subnormal values are not flushed to zero -Description of problem: -AltiVec specifies that source and result vectors are flushed to zero (in NJ mode). Only result vectors are flushed to zero. -Steps to reproduce: -1. Compile the attached Rust program (e.g. `cargo +nightly build --target powerpc-unknown-linux-gnu`) -2. Run the program and expect assertions to pass. -3. See assertions fail. -Additional information: -See the offending Rust program: - -``` -#![feature(stdsimd, powerpc_target_feature)] - -use std::arch::powerpc::*; - -#[target_feature(enable = "altivec")] -unsafe fn add(x: f32, y: f32) -> f32 { - let array: [f32; 4] = unsafe { std::mem::transmute(vec_add(vec_splats(x), vec_splats(y))) }; - array[0] -} - -pub fn main() { - let result = unsafe { add(-1.0857398e-38, 0.) }; - assert_eq!(result, 0.); - - // if the input is flushed, the result will be +0 - // if only the output is flushed, the result is -0 - assert!(result.is_sign_positive()); -} -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1780 b/results/classifier/zero-shot-user-mode/output/instruction/1780 deleted file mode 100644 index 873d0e863..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1780 +++ /dev/null @@ -1,23 +0,0 @@ -instruction: 0.875 -runtime: 0.072 -syscall: 0.053 - - - -PowerPC mishandles xscmpudp instruction -Description of problem: -xscmpudp instruction is mishandled -Steps to reproduce: -1. Compile the attached program with VSX (e.g. `RUSTFLAGS=-Ctarget-feature=+vsx cargo build --target=powerpc64-unknown-linux-gnu`) -2. Run the program and expect assertions to pass. -3. See assertions fail. -Additional information: -When VSX is disabled, the `fcmpu` instruction is emitted instead (and handled properly). See the offending program: -``` -pub fn main() { - use std::hint::black_box; - assert!(black_box(f64::NAN) - .clamp(black_box(0f64), black_box(0f64)) - .is_nan()); -} -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1781281 b/results/classifier/zero-shot-user-mode/output/instruction/1781281 deleted file mode 100644 index 9c716f633..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1781281 +++ /dev/null @@ -1,34 +0,0 @@ -instruction: 0.663 -runtime: 0.264 -syscall: 0.074 - - - -qemu-ppc64le uncaught target signal 4 (Illegal instruction) - -qemu-ppc64le version 2.12.0 -host machine: x86_64 Arch Linux - -I'm currently working on VSX support in libVPX, I'm using qemu to test, on line 723 of vpx_dsp/ppc/loopfilter_vsx.c, when I change the vec_sub to vec_subs I get: - -qemu: uncaught target signal 4 (Illegal instruction) - core dumped - -Thread 1 "qemu-ppc64le" received signal SIGILL, Illegal instruction. -0x00007ffff66d1bf6 in sigsuspend () from /usr/lib/libc.so.6 -(gdb) bt -#0 0x00007ffff66d1bf6 in sigsuspend () from /usr/lib/libc.so.6 -#1 0x000055555567ee68 in ?? () -#2 0x000055555567fd18 in ?? () -#3 0x00005555556805ef in process_pending_signals () -#4 0x0000555555661e69 in cpu_loop () -#5 0x000055555561fd72 in main () - -This can be reproduced by downloading this patch (patchset 1): - -https://chromium-review.googlesource.com/c/webm/libvpx/+/1134034 - -and running - -qemu-ppc64le -L /home/ltrudeau/x-tools/powerpc64le-unknown-linux-gnu/powerpc64le-unknown-linux-gnu/sysroot/ ./test_libvpx --gtest_also_run_disabled_tests "--gtest_filter=VSX/*Loop*/*" - -I don't observe any issues when running the code on a POWER9 machine. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1783362 b/results/classifier/zero-shot-user-mode/output/instruction/1783362 deleted file mode 100644 index fe3bb007f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1783362 +++ /dev/null @@ -1,53 +0,0 @@ -instruction: 0.494 -runtime: 0.283 -syscall: 0.223 - - - -qemu-user: mmap should return failure (MAP_FAILED, -1) instead of success (NULL, 0) when len==0 - -As shown in https://github.com/beehive-lab/mambo/issues/19#issuecomment-407420602, with len==0 mmap returns success (NULL, 0) instead of failure (MAP_FAILED, -1) in a x86_64 host executing a ELF 64-bit LSB executable, ARM aarch64 binary. - -Steps to reproduce the bug: - -- (cross-)compile the attached source file: - -$ aarch64-linux-gnu-gcc -static -std=gnu99 -lpthread test/mmap_qemu.c -o mmap_qemu - -- Execute in a x86_64 host with qemu-user and qemu-user-binfmt: - -$ ./mmap_qemu -alloc: 0 -MAP_FAILED: -1 -errno: 0 -mmap_qemu: test/mmap_qemu.c:15: main: Assertion `alloc == MAP_FAILED' failed. -qemu: uncaught target signal 6 (Aborted) - core dumped -Aborted (core dumped) - -- Execute in a ARM host without any additional dependecy: - -$ ./mmap_qemu -alloc: -1 -MAP_FAILED: -1 -errno: 22 - -The bug is present in Fedora: - -$ qemu-aarch64 --version -qemu-aarch64 version 2.11.2(qemu-2.11.2-1.fc28) -Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers -$ uname -r -4.17.7-200.fc28.x86_64 - -And also in Ubuntu: - -$ qemu-aarch64 --version -qemu-aarch64 version 2.12.0 (Debian 1:2.12+dfsg-3ubuntu3) -Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers -$ uname -r -4.15.0-23-generic - -Possibly related to: - -- https://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029109.html -- https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203852 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1790 b/results/classifier/zero-shot-user-mode/output/instruction/1790 deleted file mode 100644 index 146f17037..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1790 +++ /dev/null @@ -1,35 +0,0 @@ -instruction: 0.837 -runtime: 0.093 -syscall: 0.070 - - - -[AARCH64] STGP instruction is not writing the value of the second register to memory -Description of problem: -My application is built with Clang 16 and the option -fsanitize=memtag-stack. -It means the the MTE protection is activated for the stack. -The local variables are tagged and the compiler is often using the STGP instruction "Store Allocation Tag and Pair of registers" in order to transfer the value of two 64-bit registers to memory. -The following instruction was not working as expected: - 18004: 69000895 stgp x21, x2, [x4] -The value of the second register x2 is not transferred to the memory. -Only x21 is written. - -I think that the issue is in trans_STGP(). -We don't call finalize_memop_pair() like we do for in the general trans_STP(). - -``` -diff --git a/target/arm/tcg/translate-a64.c b/target/arm/tcg/translate-a64.c -index 7d0c8f79a7..f599f3e136 100644 ---- a/target/arm/tcg/translate-a64.c -+++ b/target/arm/tcg/translate-a64.c -@@ -3034,6 +3034,8 @@ static bool trans_STGP(DisasContext *s, arg_ldstpair *a) - - tcg_rt = cpu_reg(s, a->rt); - tcg_rt2 = cpu_reg(s, a->rt2); -+ mop = a->sz + 1; -+ mop = finalize_memop_pair(s, mop); - - assert(a->sz == 3); -``` - -With this fix, my OS (Kinibi) is now able to boot. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1791763 b/results/classifier/zero-shot-user-mode/output/instruction/1791763 deleted file mode 100644 index 7afe07140..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1791763 +++ /dev/null @@ -1,19 +0,0 @@ -instruction: 0.474 -syscall: 0.282 -runtime: 0.244 - - - -broken signal handling in nios2 user-mode emulation - -This bug is against the 3.0 release. - -It appears that the signal handling parts of the nios2 user-mode emulation have never really been completed or tested. Some examples of failing tests from the GCC testsuite are gcc.dg/pr78185.c and gcc.dg/cleanup-10.c. - -Some problems I've identified and tried to fix with the attached patch are: - -- Code copied from the Linux kernel wasn't adjusted to differentiate between host and target data types and address spaces. - -- The sigaltstack() system call returns EINVAL because fields are listed in the wrong order in struct target_sigaltstack. - -With this patch, the system calls to set up the signal handler are returning successfully, but the handler isn't being invoked, so something is still wrong. I think I need another pair of eyes to look over this code. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1793119 b/results/classifier/zero-shot-user-mode/output/instruction/1793119 deleted file mode 100644 index 21c945193..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1793119 +++ /dev/null @@ -1,35 +0,0 @@ -instruction: 0.666 -runtime: 0.168 -syscall: 0.167 - - - -Wrong floating-point emulation on AArch64 with FPCR set to zero - -On AArch64, with FPCR set to Zero (i.e., FPU set to IEEE-754 compliant mode), floating-point emulation does not produce the same results as real hardware (e.g., Raspberry Pi 3 with AArch64 Linux). - -I attached a sample that reproduces the issue. It divides `x` by `y` and puts the result in `r`. The expected result of the operation is `q`. - -Output on real hardware: -========================================================= -fpcr = 0x07000000. -x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023. -fpcr = 0x00000000. -x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf023. q = 0x43300fde9cbcf023. -========================================================= - -Notice that after setting FPCR to zero, `r` equals `q`. - -Output on qemu 3.0.0 (Linux user-mode emulation): -========================================================= -fpcr = 0x07000000. -x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023. -fpcr = 0x00000000. -x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf024. q = 0x43300fde9cbcf023. -========================================================= - -Notice that after setting FPCR to zero, `r` is not equal to `q`. - -Also notice that, using another proprietary operating system, the same issue arises between a real board and QEMU. This might be an issue in emulation of the AArch64 instruction "fdiv". - -Build command line: aarch64-linux-gnu-gcc -static -O0 -o sample1 sample1.c \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1793539 b/results/classifier/zero-shot-user-mode/output/instruction/1793539 deleted file mode 100644 index 977b07eac..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1793539 +++ /dev/null @@ -1,15 +0,0 @@ -instruction: 0.619 -syscall: 0.222 -runtime: 0.160 - - - -qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6003ddc5 - -During the build of gedit for RISC-V this error occurs: - -$ qemu-riscv64 -E LD_LIBRARY_PATH=gedit/.libs ./gedit/.libs/gedit -qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6003ddc5 -qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x600009e4 - -https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/gedit/standard/riscv64 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1793608 b/results/classifier/zero-shot-user-mode/output/instruction/1793608 deleted file mode 100644 index 0198b9ee6..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1793608 +++ /dev/null @@ -1,22 +0,0 @@ -instruction: 0.730 -runtime: 0.183 -syscall: 0.087 - - - -qemu doesn't seem to support lxvwsx for POWER9 target - -When running a simple program built for POWER9 on QEMU 3.0.0 in linux-user mode, it crashes with a message: "illegal instruction". It turns out that lxvwsx instruction "Load Word and Splat Indexed" is not supported. If workaround is implemented by issuing two separate instructions (first load then splat) then all tests pass correctly. - -Operating system: Ubuntu Mate 16.04.2 64-bit (or Linux Mint 18 64-bit). -Cross-compiler for gcc-powerpc64le-linux-gnu is installed (gcc-5 series). -QEMU 3.0.0 is built from source and installed with: sudo make install - -The program in question: https://github.com/VectorChief/UniSIMD-assembler -Turn off the workaround: RT_ELEM_COMPAT_PW9 should be set to 1 in the following file: -https://github.com/VectorChief/UniSIMD-assembler/blob/master/core/config/rtarch_p32_128x1v2.h - -Change to the "test" directory and type "make -f simd_make_p64.mk". -powerpc64le-linux-gnu-objdump -d simd_test.p64_32Lp9 > simd_test_p64_32Lp9.txt -Open newly created text file simd_test_p64_32Lp9.txt and search for lxvwsx (in s_test01, ...) -The instruction shows up in objdump correctly. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1796520 b/results/classifier/zero-shot-user-mode/output/instruction/1796520 deleted file mode 100644 index d1312187f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1796520 +++ /dev/null @@ -1,42 +0,0 @@ -instruction: 0.526 -runtime: 0.242 -syscall: 0.231 - - - -autogen crashes on qemu-sh4-user after 61dedf2af7 - -Running "autogen --help" crashes on qemu-sh4-user with: - -(sid-sh4-sbuild)root@nofan:/# autogen --help -Unhandled trap: 0x180 -pc=0xf64dd2de sr=0x00000000 pr=0xf63b9c74 fpscr=0x00080000 -spc=0x00000000 ssr=0x00000000 gbr=0xf61102a8 vbr=0x00000000 -sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf64dd2a0 fpul=0x00000003 -r0=0xf6fc1320 r1=0x00000000 r2=0xffff5dc4 r3=0xf67bfb50 -r4=0xf6fc1230 r5=0xf6fc141c r6=0x000003ff r7=0x00000000 -r8=0x00000004 r9=0xf63e20bc r10=0xf6fc141c r11=0xf63e28f0 -r12=0xf63e2258 r13=0xf63eae1c r14=0x00000804 r15=0xf6fc1220 -r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 -r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 -(sid-sh4-sbuild)root@nofan:/# - -Bi-secting found this commit to be the culprit: - -61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit -commit 61dedf2af79fb5866dc7a0f972093682f2185e17 -Author: Richard Henderson <email address hidden> -Date: Tue Jul 18 10:02:50 2017 -1000 - - target/sh4: Add missing FPSCR.PR == 0 checks - - Both frchg and fschg require PR == 0, otherwise undefined_operation. - - Reviewed-by: Aurelien Jarno <email address hidden> - Signed-off-by: Richard Henderson <email address hidden> - Message-Id: <email address hidden> - Signed-off-by: Aurelien Jarno <email address hidden> - -:040000 040000 980d79b69ae712f23a1e4c56983e97a843153b4a 1024c109f506c7ad57367c63bc8bbbc8a7a36cd7 M target - -Reverting 61dedf2af79fb5866dc7a0f972093682f2185e17 fixes the problem for me. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1798 b/results/classifier/zero-shot-user-mode/output/instruction/1798 deleted file mode 100644 index 27cab4936..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1798 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.369 -runtime: 0.354 -syscall: 0.277 - - - -conversions of malloc/calloc/free to g_malloc/g_new/g_free etc diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1805 b/results/classifier/zero-shot-user-mode/output/instruction/1805 deleted file mode 100644 index 5598411dd..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1805 +++ /dev/null @@ -1,72 +0,0 @@ -instruction: 0.513 -runtime: 0.307 -syscall: 0.180 - - - -build-user-hexagon CI job is not actually testing hexagon -Description of problem: -Look at the output from the `build-user-hexagon` CI job and see what compiler meson reports it is using: - - https://gitlab.com/qemu-project/qemu/-/jobs/4790457871 - -``` -Project name: qemu -Project version: 8.0.91 -C compiler for the host machine: cc -m64 -mcx16 (gcc 10.2.1 "cc (Debian 10.2.1-6) 10.2.1 20210110") -C linker for the host machine: cc -m64 -mcx16 ld.bfd 2.35.2 -Host machine cpu family: x86_64 -Host machine cpu: x86_64 -``` - -What is 'cc' resolving to ? - -``` -$ podman run -it registry.gitlab.com/qemu-project/qemu/qemu/debian-hexagon-cross cc -v | grep Target -Target: x86_64-linux-gnu -``` - -That is a x86_64 target native compiler, not a hexagon target cross compiler. - -The ``tests/docker/dockerfiles/debian-hexagon-cross.docker`` file installs the hexagon toolchain under ``/opt`` and adds the dir to ``$PATH`` with: - -``` -ENV PATH $PATH:${TOOLCHAIN_INSTALL}/${TOOLCHAIN_BASENAME}/x86_64-linux-gnu/bin -``` - -This toolchain just installs a `clang` binary, not ``cc`` - -So when ``configure`` runs it looks for ``cc`` first and finds the naitve x86_64 GCC install from the container, not the clang cross compiler - -It is also not possible to merely set ``CC=clang`` because meson will assume it is a native compiler and crash and burn when unable to run binaries - -``` -# CC=clang ./configure --target-list=x86_64-softmmu -Using './build' as the directory for build output -...snip... -Sphinx not found/usable, disabling docs. -Disabling PIE due to missing toolchain support -The Meson build system -Version: 1.2.0 -Source dir: /qemu -Build dir: /qemu/build -Build type: native build -Project name: qemu -Project version: 8.0.92 - -../meson.build:1:0: ERROR: Executables created by c compiler clang -m64 -mcx16 are not runnable. -``` - -AFAICT, the root problem here is that the hexagon container is not setup in the same way as the other cross compiler containers. - -We need the toolchain binaries to be named after the target triplet - ie not ``clang`` but ``hexagon-unknown-linux-musl-clang`` - -This used to be done but was thrown away when switching to a pre-built toolchain in b9052d36342c947b36447558ed0a0dd3fb3fb8f4 - -Then the container also needs to set the configure args for the cross target - -``` -ENV QEMU_CONFIGURE_OPTS --cross-prefix=hexagon-unknown-linux-musl- -``` - -AFAICT, this was never done, so even before switching to the pre-built toolchain, I think the `build-user-hexagon` CI job was running a native built not hexagon build. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1805913 b/results/classifier/zero-shot-user-mode/output/instruction/1805913 deleted file mode 100644 index 8284507c5..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1805913 +++ /dev/null @@ -1,27 +0,0 @@ -instruction: 0.579 -runtime: 0.257 -syscall: 0.163 - - - -readdir() returns NULL (errno=EOVERFLOW) for 32-bit user-static qemu on 64-bit host - -This can be simply reproduced by compiling and running the attached C code (readdir-bug.c) under 32-bit user-static qemu, such as qemu-arm-static: - -# Setup docker for user-static binfmt -docker run --rm --privileged multiarch/qemu-user-static:register --reset -# Compile the code and run (readdir for / is fine, so create a new directory /test). -docker run -v /path/to/qemu-arm-static:/usr/bin/qemu-arm-static -v /path/to/readdir-bug.c:/tmp/readdir-bug.c -it --rm arm32v7/ubuntu:18.10 bash -c '{ apt update && apt install -y gcc; } >&/dev/null && mkdir -p /test && cd /test && gcc /tmp/readdir-bug.c && ./a.out' -dir=0xff5b4150 -readdir(dir)=(nil) -errno=75: Value too large for defined data type - -Do remember to replace the /path/to/qemu-arm-static and /path/to/readdir-bug.c to the actual paths of the files. - -The root cause is in glibc: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getdents.c;h=6d09a5be7057e2792be9150d3a2c7b293cf6fc34;hb=a5275ba5378c9256d18e582572b4315e8edfcbfb#l87 - -By C standard, the return type of readdir() is DIR*, in which the inode number and offset are 32-bit integers, therefore, glibc calls getdents64() and check if the inode number and offset fits the 32-bit range, and reports EOVERFLOW if not. - -The problem here is for 32-bit user-static qemu running on 64-bit host, getdents64 simply passing through the inode number and offset from underlying getdents64 syscall (from 64-bit kernel), which is very likely to not fit into 32-bit range. On real hardware, the 32-bit kernel creates 32-bit inode numbers, therefore works properly. - -The glibc code makes sense to do the check to be conformant with C standard, therefore ideally it should be a fix on qemu side. I admit this is difficult because qemu has to maintain a mapping between underlying 64-bit inode numbers and 32-bit inode numbers, which would severely hurt the performance. I don't expect this could be fix anytime soon (or even there would be a fix), but it would be worthwhile to surface this issue. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1806243 b/results/classifier/zero-shot-user-mode/output/instruction/1806243 deleted file mode 100644 index 12f383045..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1806243 +++ /dev/null @@ -1,90 +0,0 @@ -instruction: 0.466 -runtime: 0.409 -syscall: 0.125 - - - -ARM conditional branch after if-then instruction not working - -Hello - -There seems to be an issue with QEMU when debugging if-then condition blocks from the thumb2 instruction set. The following snippet runs fine during normal execution, but keeps hanging at the conditional branch when debugging. The jump at the branch should only be executed as long as $r0 is lower than $r1. Problem is that once both are equal, the execution is not continued past the branch and the program counter never gets popped. - -2000407a: push {lr} -2000407c: movs r0, r6 -2000407e: ldmia r7!, {r1, r6} -20004080: push {r0, r1} -20004082: str.w r6, [r7, #-4]! -20004086: ldr r6, [sp, #0] -20004088: pop {r0, r1} -2000408a: adds r0, #1 -2000408c: cmp r0, r1 -2000408e: itt lt -20004090: pushlt {r0, r1} -20004092: blt.w 0x20004082 ; unpredictable <IT:lt> // <-- GDB hangs here -20004096: pop {pc} - -I have tried to reproduce the problem with inline assembly but for some reason the following example just worked: - -void f() { - static uint8_t stack[256]{}; - stack[255] = 4; - - asm volatile("\n\t" - "push {lr}" - "\n\t" - - // pre-conditions - "movs r7, %[stack]" - "\n\t" - "movs r6, #1" - "\n\t" - - "movs r0, r6" - "\n\t" - "ldmia r7!, {r1, r6}" - "\n\t" - "push {r0, r1}" - "\n\t" - "1:" - "\n\t" - "str.w r6, [r7, #-4]!" - "\n\t" - "ldr r6, [sp, #0]" - "\n\t" - "pop {r0, r1}" - "\n\t" - "adds r0, #1" - "\n\t" - "cmp r0, r1" - "\n\t" - "itt lt" - "\n\t" - "pushlt {r0, r1}" - "\n\t" - - // Original instruction - //"blt.w 0x20004082" // ; unpredictable <IT:lt> - - // Trying to fake it - "blt.w 1b" - "\n\t" - - "pop {pc}" - "\n\t" - : - : [stack] "r"(&stack[255])); -} - -The only real major difference I see to the other code snipped is that the inline assembly is running from flash memory where as the original code runs in ram? Maybe that's a clue somehow? - -Quickly reading through already reported ARM bugs I think this might be related: -https://bugs.launchpad.net/qemu/+bug/1364501 -At least the symptoms sound identical. - - -The versions I'm running are: -QEMU 3.0.0 -arm-none-eabi-gdb 8.2 - -I've also captured some trace output for single stepping from the pushlt to the blt.w instruction with the trace arguments unimp, guest_errors, op, int, exec. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1807 b/results/classifier/zero-shot-user-mode/output/instruction/1807 deleted file mode 100644 index 311d69b5e..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1807 +++ /dev/null @@ -1,30 +0,0 @@ -instruction: 0.588 -runtime: 0.209 -syscall: 0.203 - - - -sparc64 always segfaults doesn't work on Ubuntu 23.04 -Description of problem: -It segfaults when it tries to use 'printf' or 'puts' to print to the screen. -Steps to reproduce: -Do the following at the command line - -``` -$ sparc64-linux-gnu-g++ --version -sparc64-linux-gnu-g++ (Ubuntu 12.2.0-14ubuntu2) 12.2.0 -Copyright (C) 2022 Free Software Foundation, Inc. -This is free software; see the source for copying conditions. There is NO -warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -$ echo -e "#include <stdio.h> \n int main(void) { puts(\"Hello World\"); }" > test.cpp -$ sparc64-linux-gnu-g++ -o test test.cpp -static -$ qemu-sparc64-static --version -qemu-sparc64 version 7.2.0 (Debian 1:7.2+dfsg-5ubuntu2) -Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers -$ qemu-sparc64-static ./test -Segmentation fault (core dumped) -$ qemu-sparc-static ./test -qemu-sparc-static: ./test: Invalid ELF image for this architecture -$ qemu-sparc32plus-static ./test -qemu-sparc32plus-static: ./test: Invalid ELF image for this architecture -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1808565 b/results/classifier/zero-shot-user-mode/output/instruction/1808565 deleted file mode 100644 index 053327017..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1808565 +++ /dev/null @@ -1,13 +0,0 @@ -instruction: 0.556 -runtime: 0.276 -syscall: 0.168 - - - -Reading /proc/self/task/<pid>/maps is not remapped to the target - -Seeing this in qemu-user 3.1.0 - -The code in is_proc_myself which supports remapping of /proc/self/maps and /proc/<pid>/maps does not support remapping of /proc/self/task/<pid>/maps or /proc/<pid>/task/<pid>/maps. Extending is_proc_myself to cover these cases causes the maps to be rewritten correctly. - -These are useful in multithreaded programs to avoid freezing the entire program to capture the maps for a single tid. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1809546 b/results/classifier/zero-shot-user-mode/output/instruction/1809546 deleted file mode 100644 index e0bd98234..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1809546 +++ /dev/null @@ -1,49 +0,0 @@ -instruction: 0.621 -runtime: 0.264 -syscall: 0.115 - - -Writing a byte to a pl011 SFR overwrites the whole SFR - -The bug is present in QEMU 2.8.1 and, if my analysis is correct, also on master. - -I first noticed that a PL011 UART driver, which is fine on real hardware, fails to enable the RX interrupt in the IMSC register when running in QEMU. However, the problem only comes up if the code is compiled without optimizations. I think I've narrowed it down to a minimal example that will exhibit the problem if run as a bare-metal application. - -Given: - -pl011_addr: .word 0x10009000 - -The following snippet will be problematic: - - ldr r3, pl011_addr - ldrb r2, [r3, #0x38] // IMSC - mov r2, #0 - orr r2, r2, #0x10 // R2 == 0x10 - strb r2, [r3, #0x38] // Whole word reads correctly after this - ldrb r2, [r3, #0x39] - mov r2, #0 - strb r2, [r3, #0x39] // Problem here! Overwrites offset 0x38 as well - -After the first strb instruction, which writes to 0x10009038, everything is fine. It can be seen in the QEMU monitor: - -(qemu) xp 0x10009038 -0000000010009038: 0x00000010 - -After the second strb instruction, the write to 0x10009039 clears the entire word: - -(qemu) xp 0x10009038 -0000000010009038: 0x00000000 - -QEMU command-line, using the vexpress-a9 which has the PL011 at 0x10009000: - -qemu-system-arm -S -M vexpress-a9 -m 32M -no-reboot -nographic -monitor telnet:127.0.0.1:1234,server,nowait -kernel pl011-sfr.bin -gdb tcp::2159 -serial mon:stdio - -Compiling the original C code with optimizations makes the driver work. It compiles down to assembly that only does a single write: - - ldr r3, pl011_addr - mov r2, #0x10 - str r2, [r3, #0x38] - -Attached is the an assembly file, and linkscript, that shows the problem, and also includes the working code. - -I haven't debugged inside of QEMU itself but it seems to me that the problem is in pl011_write in pl011.c - the functions looks at which offset is being written, and then writes the entire SFR that offset falls under, which means that changing a single byte will change the whole SFR. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1810433 b/results/classifier/zero-shot-user-mode/output/instruction/1810433 deleted file mode 100644 index 286888daa..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1810433 +++ /dev/null @@ -1,53 +0,0 @@ -instruction: 0.597 -syscall: 0.242 -runtime: 0.161 - - - -aarch64-linux-user master: inconsistent pwrite behaviour - -Hello, - -I am running aarch64-linux-user from master, commit 20d6c7312f1b812bb9c750f4087f69ac8485cc90 - -And I've found the following inconsistent emulation of pwrite() call when buf==NULL and len=0. -Minimal reproducible sample is the following: - -#define _GNU_SOURCE -#include <stdlib.h> -#include <stdio.h> -#include <unistd.h> -#include <sys/types.h> -#include <sys/stat.h> -#include <fcntl.h> -#include <string.h> - -/* - System | Result --------------------------+---------------- - Native x86_64 4.12.14 | pwrite ret = 0 - Native aarch64 4.4.159 | pwrite ret = 0 - qemu-aarch64 at x86_64 | pwrite ret = -1 - ( 20d6c7312f1b8 ) | -*/ - -int main(int argc, char** argv) { - int fd = open("test.dat", O_CREAT | O_RDWR, 0644); - if (fd < 0) { - perror("open"); - return 1; - } - - int ret = fallocate(fd, 0, 0, 1000); - if (ret < 0) { - perror("fallocate"); - return 1; - } - - ssize_t ret_pwrite = pwrite(fd, NULL, 0, 0); - printf("pwrite ret = %ld\n", ret_pwrite); - - close(fd); - - return 0; -} \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1812 b/results/classifier/zero-shot-user-mode/output/instruction/1812 deleted file mode 100644 index c8fde1316..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1812 +++ /dev/null @@ -1,31 +0,0 @@ -instruction: 0.571 -runtime: 0.220 -syscall: 0.209 - - - -older programs running under qemu-aarch64 segfaults -Description of problem: -Numerous aarch64 programs segfaults when run under qemu-aarch64. -Steps to reproduce: -1. Install an arm64 chroot (with working qemu-aarch64 binfmt_misc setup): -``` -debootstrap --variant=minbase --arch=arm64 jessie /tmp/jessie-arm64/ http://archive.debian.org/debian -or -debootstrap --variant=minbase --arch=arm64 xenial /tmp/xenial-arm64/ http://ports.ubuntu.com/ -``` -2. build qemu-aarch64; cp qemu-aarch64 /tmp/jessie-arm64/ -3. chroot /tmp/jessie-arm64/ -4. ./qemu-aarch64 /bin/ls -``` -qemu: uncaught target signal 11 (Segmentation fault) - core dumped -Segmentation fault -``` -Additional information: -Old userspace (eg Debian jessie, Ubuntu xenial) does not work within qemu 8.1-rc2 aarch64 linux-user emulation, since commit 59b6b42cd3446862567637f3a7ab31d69c9bef51 . My guess is that old userspace isn't prepared for recent CPU features, but it still smells strange. - -Not all programs segfaults. dash works, ls or bash does not. - -A chroot is easier in this case, since many old programs don't run inside current environment, like asserting while reading locale-specific information. To run debootstrap and to enter the resulting chroot, a working qemu-aarch64 binfmt_misc setup is needed. - -Reverting the mentioned commit makes everything work again. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1812451 b/results/classifier/zero-shot-user-mode/output/instruction/1812451 deleted file mode 100644 index 13ec90c3b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1812451 +++ /dev/null @@ -1,20 +0,0 @@ -instruction: 0.634 -syscall: 0.225 -runtime: 0.141 - - - -In windows host, tftp arbitrary file read vulnerability - -https://github.com/qemu/qemu/blob/master/slirp/tftp.c#L343 - - if (!strncmp(req_fname, "../", 3) || - req_fname[strlen(req_fname) - 1] == '/' || - strstr(req_fname, "/../")) { - tftp_send_error(spt, 2, "Access violation", tp); - return; - } - -There are file path check for not allowing escape tftp directory. -But, in windows, file path is separated by "\" backslash. -So, guest can read arbitrary file in Windows host. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1812861 b/results/classifier/zero-shot-user-mode/output/instruction/1812861 deleted file mode 100644 index 5a7a8d667..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1812861 +++ /dev/null @@ -1,28 +0,0 @@ -instruction: 0.587 -runtime: 0.239 -syscall: 0.174 - - - -QEMU in user-mode emulation mode crashes when the user program jumps to an invalid address - -Running this code: - -void (*func)() = 0x12345678; - -int main() -{ - func(); - return 0; -} - -Produces the following output: - -qemu-arm-static: /build/qemu-DqynNa/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. -qemu-arm-static: /build/qemu-DqynNa/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. -Segmentation fault - -The expected result is as follows: - -qemu: uncaught target signal 11 (Segmentation fault) - core dumped -Segmentation fault \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1813307 b/results/classifier/zero-shot-user-mode/output/instruction/1813307 deleted file mode 100644 index 0c84edfc4..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1813307 +++ /dev/null @@ -1,27 +0,0 @@ -instruction: 0.498 -syscall: 0.294 -runtime: 0.208 - - - -util/path.c/follow_path() does not handle "/" well - -Hello, - -I noticed that qemu does not handle "/" very well in follow_path(). - -Specifically, I was trying to run gdbserver under qemu, and it failed inside its implementation of __getcwd. - -Indeed it does something like - if (__lstat ("/", &st) < 0) -..... -and then loops from current dir toward the top using lstat("..") - -On qemu side, lstat forwards the request to follow_path() in util/path.c, and when passed "/", it returns the path in QEMU_LD_PREFIX (which was the top of my sysroot). -OTHT, the series of lstat("..") finally reaches the real device root because it's not recognized as "/" in follow_path(), so this is inconsistent and __getcwd fails. - -I suppose there's a good reason for returning QEMU_LD_PREFIX when asking for "/", but why is it so? - -If there's no good reason, maybe the behaviour could be changed to map "/" to "/" ? - -Thanks \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1815024 b/results/classifier/zero-shot-user-mode/output/instruction/1815024 deleted file mode 100644 index 3c95bc42b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1815024 +++ /dev/null @@ -1,21 +0,0 @@ -instruction: 0.883 -runtime: 0.068 -syscall: 0.049 - - - -SIGILL on instruction "stck" under qemu-s390x in user mode - -qemu-s390x in user mode crashes with SIGILL (under host architecture x86_64, running Debian unstable) when executing target instruction "stck" ("STORE CLOCK", see https://www-01.ibm.com/support/docview.wss?uid=isg26480faec85f44e2385256d5200627dee&aid=1), which is basically a kind of equivalent of Intel "rdtsc". The same instruction works fine under qemu-s390x in system mode. The bug is reproducible with both the qemu version distributed in Debian unstable and with the latest upstream master (commit 47994e16b1d66411953623e7c0bf0cdcd50bd507). - -This bug manifested itself as a crash of ssh-keygen program, which uses "stck" to obtain some bits of randomness during key creation. Bisection of the code led to the attached minimal example. Compile with (inside an s390x system): - - $ gcc -c -o test.o test.c - $ gcc -c -o rdtsc.o rdtsc.S - $ gcc -o test test.o rdtsc.o - -Then run test. It will crash with SIGILL in user mode and run fine in system mode. Also, compare with the original file at https://github.com/openssl/openssl/blob/master/crypto/s390xcpuid.pl#L139 (there the instruction "stckf" is also used; it is probable that it has the same problem if it is supported altogether, but it did not test for this). - -Running qemu-s390x with options -d in_asm,out_asm,op,op_opt,exec,nochain,cpu gives the trace attached in log.txt. - -Thanks, Giovanni. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1818075 b/results/classifier/zero-shot-user-mode/output/instruction/1818075 deleted file mode 100644 index da97086a9..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1818075 +++ /dev/null @@ -1,59 +0,0 @@ -instruction: 0.544 -runtime: 0.278 -syscall: 0.179 - - - -qemu x86 TCG doesn't support AVX insns - -I'm trying to execute code that has been built with -march=skylake -mtune=generic -mavx2 under qemu-user x86-64 with -cpu Skylake-Client. However this code just hangs at 100% CPU. - -Adding input tracing shows that it is likely hanging when dealing with an AVX instruction: - -warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] -warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] -warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] -warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] -warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] -warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] -warning: TCG doesn't support requested feature: CPUID.01H:ECX.rdrand [bit 30] -warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] -warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] -warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] -warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] -warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18] -warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.3dnowprefetch [bit 8] -warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] - -IN: -0x4000b4ef3b: c5 fb 5c ca vsubsd %xmm2, %xmm0, %xmm1 -0x4000b4ef3f: c4 e1 fb 2c d1 vcvttsd2si %xmm1, %rdx -0x4000b4ef44: 4c 31 e2 xorq %r12, %rdx -0x4000b4ef47: 48 85 d2 testq %rdx, %rdx -0x4000b4ef4a: 79 9e jns 0x4000b4eeea - -[ hangs ] - -Attaching a gdb produces this stacktrace: - -(gdb) bt -#0 canonicalize (status=0x55a20ff67a88, parm=0x55a20bb807e0 <float64_params>, part=...) - at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:350 -#1 float64_unpack_canonical (s=0x55a20ff67a88, f=0) - at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:547 -#2 float64_sub (a=0, b=4890909195324358656, status=0x55a20ff67a88) - at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:776 -#3 0x000055a20baa1949 in helper_subsd (env=<optimized out>, d=0x55a20ff67ad8, s=<optimized out>) - at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/target/i386/ops_sse.h:623 -#4 0x000055a20cfcfea8 in static_code_gen_buffer () -#5 0x000055a20ba3f764 in cpu_tb_exec (itb=<optimized out>, cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>) - at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:171 -#6 cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, - cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>) - at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:615 -#7 cpu_exec (cpu=cpu@entry=0x55a20ff5f4d0) - at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:725 -#8 0x000055a20ba6d728 in cpu_loop (env=0x55a20ff67780) - at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/x86_64/../i386/cpu_loop.c:93 -#9 0x000055a20ba049ff in main (argc=<optimized out>, argv=0x7ffc58572868, envp=<optimized out>) - at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/main.c:819 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1818483 b/results/classifier/zero-shot-user-mode/output/instruction/1818483 deleted file mode 100644 index 016a66372..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1818483 +++ /dev/null @@ -1,48 +0,0 @@ -instruction: 0.539 -syscall: 0.231 -runtime: 0.229 - - - -qemu user mode does not support binfmt_misc config with flags include "P" - -Hi Sir: -During our test in chroot environment with qemu-user-static, we got some test cases failed because of program output warning with unexpected full path name. -For example in test module "Devscripts" -the test item for broken tarball expected the warning info: -<tar: This does not look like a tar archive -tar: ******* > -but the output was: -</bin/tar: This does not look like a tar archive -/bin/tar: ******> -the cause is the config file of binfmt_misc was set not to send argv0, for example: -type command "tar" after chroot: -========================== -lpeng@lpeng-VirtualBox:~/projects_lpeng/qemu/mips_2/sid$ sudo chroot . -[sudo] password for lpeng: -root@lpeng-VirtualBox:/# tar -/bin/tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options -Try '/bin/tar --help' or '/bin/tar --usage' for more information. -root@lpeng-VirtualBox:/# -=========================== - -by adding output log in main()@qemu/Linux-user/main.c -we found the original input command was changed, and qemu do not know that, we got the input args: -argv_0----/usr/bin/qemu-mips64el-static--- -argv_1----/bin/tar--- -argv_2----NULL--- - -Next step we modified the flags=P in the corresponding config under folder /proc/sys/fs/binfmt_misc, then binfmt_misc sent argv[0] to qemu. -But chroot could not start bash because in current qemu dose not consider about this unexpected one more"argv[0]" - - -After modified qemu code temporary to handle the new argv list we got the input args, and from argv[2] is the original input command -argv_0----/usr/bin/qemu-mips64el-static--- -argv_1----/bin/tar--- -argv_2----tar--- - -We need the original input from command line, so is it possible that let binfmt_misc to pass one more additional args or env to qemu as a token of the binfmt_misc flag, then qemu can judge how to parse the input args by it? -looking forward your suggestions. - -Thanks -luyou \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1820686 b/results/classifier/zero-shot-user-mode/output/instruction/1820686 deleted file mode 100644 index ad5531d2a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1820686 +++ /dev/null @@ -1,11 +0,0 @@ -instruction: 0.875 -runtime: 0.095 -syscall: 0.030 - - - -risc-v: 'c.unimp' instruction decoded as 'c.addi4spn fp, 0' - -QEMU 3.1 incorrectly decodes the "c.unimp" instruction (opcode 0x0000) as an "addi4spn fp, 0" when either of the two following bytes are non-zero. This is because the ctx->opcode value used when decoding the instruction is actually filled with a 32-bit load (to handle normal uncompressed instructions) but when a compressed instruction is found only the low 16 bits are valid. Other reserved/illegal bit patterns with the addi4spn opcode are also incorrectly decoded. - -I believe that the switch to decodetree on master happened to fix this issue, but hopefully it is helpful to have this recorded somewhere. I've included a simple one line patch if anyone wants to backport this. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1821430 b/results/classifier/zero-shot-user-mode/output/instruction/1821430 deleted file mode 100644 index acee1db04..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1821430 +++ /dev/null @@ -1,38 +0,0 @@ -instruction: 0.724 -runtime: 0.186 -syscall: 0.090 - - - -qemu-user-arm (4.0.0-rc0) crashes - -I'm using qemu-user-arm for crosscompilation needs, usually via a wrapper. -qemu-user-arm (4.0.0-rc0) crashes with SIGILL on at least 2 instructions: - -first case (sadly I don't have more data handy, can reproduce at a later time if needed): -(gdb) x/i $pc -=> 0xfffce314: vseleq.f64 d0, d17, d0 - -second case (llvm-config): -qemu cmdline: -qemu-arm -strace -cpu max -r 5.0.0 -L /home/asavah/kross/build/rpi3/rootfs -E LD_LIBRARY_PATH=/home/asavah/kross/build/rpi3/rootfs/usr/bin:/home/asavah/kross/build/rpi3/rootfs/usr/lib /home/asavah/kross/build/rpi3/rootfs/usr/bin/llvm-config --shared-mode - ---- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0xf9f89f80} --- -qemu: uncaught target signal 4 (Illegal instruction) - core dumped - -output from gdb(arm) attached to qemu-user-arm -Program received signal SIGILL, Illegal instruction. -0xf9f77f80 in ?? () -(gdb) bt -#0 0xf9f77f80 in ?? () -#1 0xfffd796c in ?? () -Backtrace stopped: previous frame identical to this frame (corrupt stack?) -(gdb) x/i $pc -=> 0xf9f77f80: vrintm.f64 d18, d18 - - -The very same binaries when run with qemu-user-arm 3.1.0 (both from ubuntu 19.04 package and self built) -work flawlessly. - -This is clearly a regression. -Please fix before releasing 4.0.0. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1821444 b/results/classifier/zero-shot-user-mode/output/instruction/1821444 deleted file mode 100644 index 0f8cb900a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1821444 +++ /dev/null @@ -1,35 +0,0 @@ -instruction: 0.711 -runtime: 0.199 -syscall: 0.090 - - - -qemu-ppc (user) incorrectly translates float32 arithmetics - -I'm using qemu-3.1.0 (Gentoo). - -When I was running regression test suite via qemu-ppc for GHC I noticed a few uint32_t<->float32 failures I did not expect to encounter. - -Here is an example - -$ cat a.c -#include <stdio.h> -#include <stdint.h> - -int main() { - volatile uint32_t i = 1; - printf("0x1 = %e\n", *(volatile float*)&i); -} - -$ powerpc-unknown-linux-gnu-gcc -O2 a.c -Wall -o a -fno-strict-aliasing -fno-stack-protector -static && ./a -0x1 = 2.802597e-45 - -$ scp a timberdoodle.ppc64.dev.gentoo.org:~/ -a 100% 826KB 102.0KB/s 00:08 - -$ ssh timberdoodle.ppc64.dev.gentoo.org ./a -0x1 = 1.401298e-45 -$ qemu-ppc ./a -0x1 = 2.802597e-45 - -Looks like off-by-one bit somewhere. I'm not sure if it's FPU instruction or some internals of printf() that are emulated incorrectly. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1821515 b/results/classifier/zero-shot-user-mode/output/instruction/1821515 deleted file mode 100644 index 1edfedbfa..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1821515 +++ /dev/null @@ -1,44 +0,0 @@ -instruction: 0.496 -runtime: 0.302 -syscall: 0.202 - - - -qemu-ppc (user) incorrectly converts float(nan)->double(non-nan) - -Noticed on qemu-3.1.0 on GHC test suite where float32 comparisons didn't work on NaNs. -Here is the minimal reproducer: - -```c -// cat a.c -#include <stdio.h> -#include <math.h> -#include <stdint.h> - -int main() { - volatile float f1 = NAN; - volatile float f2 = NAN; - printf ("f1 (%e, %#x) >= f2 (%e, %#x): %s\n", - f1, *(volatile uint32_t*)&f1, - f2, *(volatile uint32_t*)&f2, - (f1 >= f2) ? "True" - : "False"); - volatile double d = f1; - printf ("d (%e, %#llx)\n", - d, *(volatile uint64_t*)&d); -} -``` - -``` -# incorrect execution: -$ powerpc-unknown-linux-gnu-gcc -O2 a.c -o a -static && qemu-ppc ./a -f1 (5.104236e+38, 0x7fc00000) >= f2 (5.104236e+38, 0x7fc00000): True -d (5.104236e+38, 0x47f8000000000000) - -# correct execution -$ scp a timberdoodle.ppc64.dev.gentoo.org:~/; ssh timberdoodle.ppc64.dev.gentoo.org ./a -f1 (nan, 0x7fc00000) >= f2 (nan, 0x7fc00000): False -d (nan, 0x7ff8000000000000) -``` - -Note: qemu-ppc handled float32 extension as it was not a NaN (exp=111..1111) but a normalized number. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1824344 b/results/classifier/zero-shot-user-mode/output/instruction/1824344 deleted file mode 100644 index f56b3780f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1824344 +++ /dev/null @@ -1,51 +0,0 @@ -instruction: 0.713 -runtime: 0.195 -syscall: 0.092 - - - -x86: retf or iret pagefault sets wrong error code - -With a x86_64 or i386 guest, non-KVM, when trying to execute a -"iret/iretq/retf" instruction in userspace with invalid stack pointer -(under a protected mode OS, like Linux), wrong bits are set in the -pushed error code; bit 2 is not set, indicating the error comes from -kernel space. - -If the guest OS is using this flag to decide whether this was a kernel -or user page fault, it will mistakenly decide a kernel has irrecoverably -faulted, possibly causing guest OS panic. - - -How to reproduce the problem a guest (non-KVM) Linux: -Note, on recent Linux kernel version, this needs a CPU with SMAP support -(eg. -cpu max) - -$ cat tst.c -int main() -{ -__asm__ volatile ( -"mov $0,%esp\n" -"retf" -); -return 0; -} - -$ gcc tst.c -$ ./a.out -Killed - - -"dmesg" shows the kernel has in fact triggered a "BUG: unable to handle -kernel NULL pointer dereference...", but it has "recovered" by killing -the faulting process (see attached screenshot). - - -Using self-compiled qemu from git: -commit 532cc6da74ec25b5ba6893b5757c977d54582949 (HEAD -> master, tag: v4.0.0-rc3, origin/master, origin/HEAD) -Author: Peter Maydell <email address hidden> -Date: Wed Apr 10 15:38:59 2019 +0100 - - Update version for v4.0.0-rc3 release - - Signed-off-by: Peter Maydell <email address hidden> \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1824778 b/results/classifier/zero-shot-user-mode/output/instruction/1824778 deleted file mode 100644 index 6c6489e5b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1824778 +++ /dev/null @@ -1,13 +0,0 @@ -instruction: 0.868 -runtime: 0.081 -syscall: 0.051 - - -PowerPC64: tlbivax does not work for addresses above 4G - -The tlbivax instruction in QEMU does not work for address above 4G. The reason behind this is a simple 32bit trunction of an address. -Changing the argument ea from uint32_t to target_ulong for the function booke206_invalidate_ea_tlb() in target/ppc/mmu_helper.c solves the issue. - -I did not reproduce this using Linux so I have no public example for reproducing it. However it's a pretty straight forward change. - -Issue can be seen in all version of QEMU. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1826568 b/results/classifier/zero-shot-user-mode/output/instruction/1826568 deleted file mode 100644 index 6ec702457..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1826568 +++ /dev/null @@ -1,19 +0,0 @@ -instruction: 0.771 -runtime: 0.136 -syscall: 0.093 - - - -RISC-V Disassembler/translator instruction decoding disagreement - - -When running QEMU V3.1.0 for platform RISC-V, 64bit, Spike V1.10 with "-d in_asm -singlestep -D qemu_log.txt", my (faulty) test code brought up this message in the logs: - - 0x000000008002cade: 051300009517e2bf illegal - Disassembler disagrees with translator over instruction decoding - Please report this to <email address hidden> - - -You may want to resolve the disagreement. - -Axel \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1828867 b/results/classifier/zero-shot-user-mode/output/instruction/1828867 deleted file mode 100644 index 4d25c0d79..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1828867 +++ /dev/null @@ -1,14 +0,0 @@ -instruction: 0.915 -runtime: 0.048 -syscall: 0.037 - - - -QEmu translation is incorrect when using REX in combination with LAHF/SAHF - -When translating code that is using LAHF and SAHF in combination with the REX prefix then qemu translates incorrectly. -These two instructions only ever use the AH register. Contrary to other instructions where if you use REX + high bit offsets then it'll pull in rsp and a few other registers. -On hardware the REX prefix doesn't effect behaviour of these instructions at all. -QEMU incorrectly selects RSP as the register of choice here due to this combination of REX + AH register usage. - -I've attached a patch that is super terrible just so I can work around the issue locally and to sort of show off how it is to be "fixed" \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1829459 b/results/classifier/zero-shot-user-mode/output/instruction/1829459 deleted file mode 100644 index 001dfa31a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1829459 +++ /dev/null @@ -1,41 +0,0 @@ -instruction: 0.463 -syscall: 0.313 -runtime: 0.224 - - - -qemu seems to lack support for pid namespace. - -# Version - -qemu-4.0.0 - -# commands used to launch qemu-aarch64 in user mode. - -printf '%s\n' ':qemu-aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-aarch64:'"${QEMU_BINFMT_FLAGS}" >/proc/sys/fs/binfmt_misc/register - -> sudo cp /usr/bin/qemu-aarch64 $RPI/usr/bin -> sudo chroot $RPI /bin/ksh -l - -# host - -Gentoo Linux amd64 - -# Guest - -Gentoo Linux aarch64 - -# The problem that I have - -"emerge" program fails due to the error, "qemu: qemu_thread_create: Invalid argument". -"emerge" is Gentoo's package manager that compiles and installs packages. - -# How to reproduce the issue - -Execute - -unshare --pid -- echo hello world - -or - -python -c "import portage.process; portage.process.spawn(['echo', 'hello', 'world'], unshare_pid=True)" \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1830 b/results/classifier/zero-shot-user-mode/output/instruction/1830 deleted file mode 100644 index 6f8d2813f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1830 +++ /dev/null @@ -1,32 +0,0 @@ -instruction: 0.486 -runtime: 0.306 -syscall: 0.208 - - - -command hangs in CentOS 7 arm64 container with Ubuntu 22 amd64 host -Description of problem: -The command hangs in the container, taking over the CPU: - -``` -$ docker run -it centos:7 -[root@42e655bf3d60 /]# LD_DEBUG=all /lib64/ld-2.17.so --list /usr/bin/true & -[1] 74 -[root@42e655bf3d60 /]# 74: file=/usr/bin/true [0]; generating link map - -[root@42e655bf3d60 /]# ps -e -o pid,ppid,etime,time,state,args - PID PPID ELAPSED TIME S COMMAND - 1 0 34:59 00:00:00 S /usr/libexec/qemu-binfmt/aarch64-binfmt-P /bin/bash /bin/bash - 74 1 03:16 00:03:13 R /usr/libexec/qemu-binfmt/aarch64-binfmt-P /lib64/ld-2.17.so /lib64/ld-2.17.so - 80 1 4-19:34:01 00:00:00 R ps -e -o pid,ppid,etime,time,state,args -[root@42e655bf3d60 /]# -``` -Steps to reproduce: -1. Start container -2. Run `/lib64/ld-2.17.so --list /usr/bin/true` -Additional information: -1. The problem is not observed in an Ubuntu 20.04 host system performing the same scenario. -2. My team build environment has amd64 native architecture hardware. I ran a similar scenario on an AWS arm64 native machine (QEMU is not needed) and the command works fine in the container. -3. My team builds several Linux images daily - about a dozen amd64 and eight arm64. This is the only image that's causing us this problem. -4. I built trace-cmd but when I tried to start a trace it told me `No events enabled with kvm`. -5. I built qemu-8.1.0-rc3 and saw the same behavior but I don't think `/usr/libexec/qemu-binfmt/aarch64-binfmt-P` was replaced with a new version so I don't think the old version was used for my container. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1832422 b/results/classifier/zero-shot-user-mode/output/instruction/1832422 deleted file mode 100644 index 16de9858f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1832422 +++ /dev/null @@ -1,15 +0,0 @@ -instruction: 0.766 -syscall: 0.150 -runtime: 0.084 - - - -SSE CMP ops with 8bit immediate throw sigill with oversized byte - -The SSE comparison ops that use an 8bit immediate as a comparison type selector throws a sigill when the immediate is oversized. - -Test op that I found this on is here `66 0f c2 c0 d1 cmppd xmm0,xmm0,0xd1` -According to the x86-64 documentation only bits [2:0] are used for these ops (and [4:0] for the AVX variant) -Currently qemu just checks if the value is >=8 and will throw a sigill in that case. It instead needs to mask. - -I have a small patch that fixes the issue for the SSE variant. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1832916 b/results/classifier/zero-shot-user-mode/output/instruction/1832916 deleted file mode 100644 index 0b1b7cddd..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1832916 +++ /dev/null @@ -1,11 +0,0 @@ -instruction: 0.535 -syscall: 0.243 -runtime: 0.221 - - - -linux-user does not check PROT_EXEC - -At no point do we actually verify that a page is PROT_EXEC before translating. All we end up verifying is that the page is readable. Not the same thing, obviously. - -The following test case should work for any architecture, though I've only validated it for x86_64 and aarch64. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1833 b/results/classifier/zero-shot-user-mode/output/instruction/1833 deleted file mode 100644 index 4bffab8c2..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1833 +++ /dev/null @@ -1,90 +0,0 @@ -instruction: 0.416 -runtime: 0.363 -syscall: 0.221 - - - -ARM64 SME ST1Q incorrectly stores 9 bytes (rather than 16) per 128-bit element -Description of problem: -QEMU incorrectly stores 9 bytes instead of 16 per 128-bit element in the ST1Q SME instruction (https://developer.arm.com/documentation/ddi0602/2022-06/SME-Instructions/ST1Q--Contiguous-store-of-quadwords-from-128-bit-element-ZA-tile-slice-). It copies the first byte of the upper 64-bits, then lower the 64-bits. - -This seems to be a simple issue; I tracked it down to: -https://gitlab.com/qemu-project/qemu/-/blob/master/target/arm/tcg/sme_helper.c?ref_type=heads#L382 - -Updating that `+ 1` to a `+ 8` fixes the problem. -Steps to reproduce: -```c -#include <stdio.h> -#include <stdint.h> -#include <string.h> - -void st1q_sme_copy_test(uint8_t* src, uint8_t* dest) { - asm volatile( - "smstart sm\n" - "smstart za\n" - "ptrue p0.b\n" - "mov x12, xzr\n" - "ld1q {za0h.q[w12, 0]}, p0/z, %0\n" - "st1q {za0h.q[w12, 0]}, p0, %1\n" - "smstop za\n" - "smstop sm\n" : : "m"(*src), "m"(*dest) : "w12", "p0"); -} - -void print_first_128(uint8_t* data) { - putchar('['); - for (int i = 0; i < 16; i++) { - printf("%02d", data[i]); - if (i != 15) - printf(", "); - } - printf("]\n"); -} - -int main() { - _Alignas(16) uint8_t dest[512] = { }; - _Alignas(16) uint8_t src[512] = { }; - for (int i = 0; i < sizeof(src); i++) - src[i] = i; - puts("Before"); - printf(" src: "); - print_first_128(src); - printf("dest: "); - print_first_128(dest); - st1q_sme_copy_test(src, dest); - puts("\nAfter "); - printf(" src: "); - print_first_128(src); - printf("dest: "); - print_first_128(dest); -} -``` - -Compile with (requires at least clang ~14, tested with clang 16):<br/> -`clang ./qemu_repro.c -march=armv9-a+sme+sve -o ./qemu_repro` - -Run with:<br/> -`qemu-aarch64 -cpu max,sme=on ./qemu_repro` - -It's expected just to copy from `src` to `dest` and output: -``` -Before - src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] -dest: [00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] - -After - src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] -dest: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] -``` - -But currently outputs: -``` -Before - src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] -dest: [00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] - -After - src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] -dest: [00, 08, 09, 10, 11, 12, 13, 14, 15, 00, 00, 00, 00, 00, 00, 00] -``` -Additional information: -N/A diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1833668 b/results/classifier/zero-shot-user-mode/output/instruction/1833668 deleted file mode 100644 index 24ef5f007..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1833668 +++ /dev/null @@ -1,33 +0,0 @@ -instruction: 0.456 -runtime: 0.343 -syscall: 0.201 - - - -linux-user: Unable to run ARM binaries on Aarch64 - -Download a ARM package from https://packages.debian.org/sid/busybox-static - -Here tested with: busybox-static_1.30.1-4_armel.deb - -$ file busybox.armel -busybox.armel: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=12cf572e016bafa240e113b57b3641e94b837f37, stripped - -$ qemu-aarch64 --version -qemu-aarch64 version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.14) - -$ qemu-aarch64 busybox.armel -busybox.armel: Invalid ELF image for this architecture - -$ qemu-aarch64 -cpu cortex-a7 busybox.armel -unable to find CPU model 'cortex-a7' - -Also reproduced with commit 33d609990621dea6c7d056c86f707b8811320ac1, -while the aarch64_cpus[] array contains Aarch64 CPUs, the arm_cpus[] array is empty: - -$ gdb -q aarch64-linux-user/qemu-aarch64 -(gdb) p aarch64_cpus -$1 = {{name = 0x1fe4e8 "cortex-a57", initfn = 0x109bc0 <aarch64_a57_initfn>, class_init = 0x0}, {name = 0x1fe508 "cortex-a53", initfn = 0x109a10 <aarch64_a53_initfn>, class_init = 0x0}, {name = 0x1fe518 "cortex-a72", - initfn = 0x109868 <aarch64_a72_initfn>, class_init = 0x0}, {name = 0x218020 "max", initfn = 0x109d70 <aarch64_max_initfn>, class_init = 0x0}, {name = 0x0, initfn = 0x0, class_init = 0x0}} -(gdb) p arm_cpus -$2 = {{name = 0x0, initfn = 0x0, class_init = 0x0}} \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1834496 b/results/classifier/zero-shot-user-mode/output/instruction/1834496 deleted file mode 100644 index d9586668d..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1834496 +++ /dev/null @@ -1,33 +0,0 @@ -instruction: 0.574 -runtime: 0.294 -syscall: 0.132 - - - -Regressions on arm target with some GCC tests - -Hi, - -After trying qemu master: -commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde -Merge: 68d7ff0 14f5d87 -Author: Peter Maydell <email address hidden> -Date: Fri Jun 21 15:40:50 2019 +0100 - -I found several regressions compared to qemu-3.1 when running the GCC testsuite. -I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests. - -All tests used to pass w/o error (one of them is verbose), but with a recent qemu, all of them make qemu crash: - -qemu: uncaught target signal 6 (Aborted) - core dumped - -This was noticed with GCC master configured with ---target arm-none-linux-gnueabi ---with-mode arm ---with-cpu cortex-a9 - -and calling qemu with --cpu cortex-a9 (the script uses "any", this makes no difference). - -I have noticed other failures with arm-v8 code, but this is probably the same root cause. Since it's a bit tedious to manually rebuild & extract the testcases, I'd prefer to start with this subset, and I can extract more if needed later. - -Thanks \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1835693 b/results/classifier/zero-shot-user-mode/output/instruction/1835693 deleted file mode 100644 index 61b799340..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1835693 +++ /dev/null @@ -1,23 +0,0 @@ -instruction: 0.478 -runtime: 0.317 -syscall: 0.206 - - - -s390x binaries segfault - -Hello World appears to segfault with qemu s390x, on a Debian 10.0.0 Buster amd64 host. - -$ cat hello.cpp -#include <iostream> -using std::cout; - -int main() { - cout << "Hello World!\n"; - return 0; -} - -$ s390x-linux-gnu-g++ -o hello hello.cpp - -$ qemu-s390x-static hello -Segmentation fault \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1835839 b/results/classifier/zero-shot-user-mode/output/instruction/1835839 deleted file mode 100644 index 6d3026e4b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1835839 +++ /dev/null @@ -1,27 +0,0 @@ -instruction: 0.629 -runtime: 0.285 -syscall: 0.087 - - - -qemu-user: $0 incorrectly always reports absolute path - -We just ran into an issue with the Perl package on Debian/m68k when being built with qemu-user [1]. - -The problem can be boiled down to qemu-user always reporting absolute paths for the shell variable $0 no matter on how the command was invoked. - -A simple reproducer is this: - -On normal system (no emulation): - -root@nofan:~> sh -c 'echo $0' -sh -root@nofan:~> - -On qemu-user: - -(sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0' -/bin/sh -(sid-m68k-sbuild)root@nofan:/# - -> [1] https://lists.debian.org/debian-68k/2019/07/msg00007.html \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1836078 b/results/classifier/zero-shot-user-mode/output/instruction/1836078 deleted file mode 100644 index 122112fef..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1836078 +++ /dev/null @@ -1,28 +0,0 @@ -instruction: 0.503 -runtime: 0.251 -syscall: 0.246 - - - -Regressions on arm-linux-gnueabihf target with some GCC tests - -Hi, - -After trying qemu master: -commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde -Merge: 68d7ff0 14f5d87 -Author: Peter Maydell <email address hidden> -Date: Fri Jun 21 15:40:50 2019 +0100 - -even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496, -I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite. -I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests. - -All tests used to pass w/o error, but with a recent qemu, all of them make qemu crash. - -This was noticed with GCC master configured with ---target arm-none-linux-gnueabihf ---with-cpu cortex-a57 ---with-fpu crypto-neon-fp-armv8 - -Thanks \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1836192 b/results/classifier/zero-shot-user-mode/output/instruction/1836192 deleted file mode 100644 index 2d7722ffe..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1836192 +++ /dev/null @@ -1,27 +0,0 @@ -instruction: 0.529 -runtime: 0.275 -syscall: 0.196 - - - -Regressions on arm926 target with some GCC tests - -Hi, - -After trying qemu master: -commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde -Merge: 68d7ff0 14f5d87 -Author: Peter Maydell <email address hidden> -Date: Fri Jun 21 15:40:50 2019 +0100 - -even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496, -I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite, with GCC configured to generate arm10tdmi code by default, and using qemu's --cpu arm926. - -I'm attaching a tarball containing one of the GCC tests (binaries), needed shared libs, and a short script to run the test. - -This was noticed with GCC master configured with ---target arm-none-linux-gnueabi ---with-cpu arm10tdmi ---with-fpu vfp - -Thanks \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1837 b/results/classifier/zero-shot-user-mode/output/instruction/1837 deleted file mode 100644 index 950e16d83..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1837 +++ /dev/null @@ -1,41 +0,0 @@ -instruction: 0.576 -syscall: 0.243 -runtime: 0.181 - - - -Support IP_MULTICAST_IF socket option in linux-user -Additional information: -I've run into this limitation in qemu-aarch64-static version Debian 1:6.2+dfsg-2ubuntu6.12, but from the link above, it doesn't seem to be implemented on master yet. - -Here's some source code that demonstrates the failure: -``` -#include <sys/socket.h> -#include <arpa/inet.h> -#include <netinet/ip.h> -#include <unistd.h> -#include <assert.h> -#include <stdio.h> - -int main() -{ - int fd, ret; - struct in_addr addr = {htonl(INADDR_LOOPBACK)}; - - fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); - assert(fd >= 0); - ret = setsockopt(fd, IPPROTO_IP, IP_MULTICAST_IF, &addr, sizeof(addr)); - if (ret < 0) - { - perror("setsockopt failed"); - return 1; - } - close(fd); - printf("Success!\n"); - return 0; -} -``` - -When run under qemu, it gives the error `setsockopt failed: Protocol not available`. - -It doesn't look like it should be too hard to support (certainly no worse than IP_ADD_MEMBERSHIP). Let me know if I can help with a patch. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1841990 b/results/classifier/zero-shot-user-mode/output/instruction/1841990 deleted file mode 100644 index d309686e1..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1841990 +++ /dev/null @@ -1,44 +0,0 @@ -instruction: 0.753 -syscall: 0.136 -runtime: 0.111 - - - -instruction 'denbcdq' misbehaving - -Instruction 'denbcdq' appears to have no effect. Test case attached. - -On ppc64le native: --- -gcc -g -O -mcpu=power9 bcdcfsq.c test-denbcdq.c -o test-denbcdq -$ ./test-denbcdq -0x00000000000000000000000000000000 -0x0000000000000000000000000000000c -0x22080000000000000000000000000000 -$ ./test-denbcdq 1 -0x00000000000000000000000000000001 -0x0000000000000000000000000000001c -0x22080000000000000000000000000001 -$ ./test-denbcdq $(seq 0 99) -0x00000000000000000000000000000064 -0x0000000000000000000000000000100c -0x22080000000000000000000000000080 --- - -With "qemu-ppc64le -cpu power9" --- -$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq -0x00000000000000000000000000000000 -0x0000000000000000000000000000000c -0x0000000000000000000000000000000c -$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1 -0x00000000000000000000000000000001 -0x0000000000000000000000000000001c -0x0000000000000000000000000000001c -$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100) -0x00000000000000000000000000000064 -0x0000000000000000000000000000100c -0x0000000000000000000000000000100c --- - -I started looking at the code, but I got confused rather quickly. Could be related to endianness? I think denbcdq arrived on the scene before little-endian was a big deal. Maybe something to do with utilizing implicit floating-point register pairs... I don't think the right data is getting to helper_denbcdq, which would point back to the gen_fprp_ptr uses in dfp-impl.inc.c (GEN_DFP_T_FPR_I32_Rc). (Maybe?) \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1847467 b/results/classifier/zero-shot-user-mode/output/instruction/1847467 deleted file mode 100644 index c253d4ba4..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1847467 +++ /dev/null @@ -1,22 +0,0 @@ -instruction: 0.717 -runtime: 0.193 -syscall: 0.090 - - - -qemu-x86_64 segment prefixes error - -qemu-x86_64 version 4.1.0 (qemu-x86_64 version 4.0.0 also have the issue) - -In 64-bit mode (x86_64) the DS, ES, SS or CS segment prefixes should be ignored; qemu-x86_64 does not ignore them. - -example: an x86_64 instructions preceded by FS DS (0x64 0x26) segment prefixes have the linear address of its memory reference flat-mapped (as if DS was in action) whereas it should be FS-mapped (offset by FS_base, because the DS, ES, SS or CS are just ignored). - - -I attach a small C++ program that shows this discrepancy. - -$ ./sample -I'm not in QEMU - -$ qemu-x86_64 ./sample -I'm in QEMU \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1854 b/results/classifier/zero-shot-user-mode/output/instruction/1854 deleted file mode 100644 index 072ecf3c6..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1854 +++ /dev/null @@ -1,24 +0,0 @@ -instruction: 0.610 -runtime: 0.218 -syscall: 0.173 - - - -s390x: qemu-user: ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached -Description of problem: -The nolibc-test program from the Linux kernel crashes since 5f4e5b34092556ab1577e25d1262bd5975b26980 . -Reverting that commit fixes the issue. -Steps to reproduce: -1. Build `nolibc-test` for s390x from Linux kernel tree. (from `tools/testing/selftests/nolibc/`). EDIT: compiled binary is uploaded below. -2. Run it under qemu-s390x. - -``` - ./qemu-s390x nolibc-test -** -ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached -Bail out! ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached -Aborted (core dumped) - -``` -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1854738 b/results/classifier/zero-shot-user-mode/output/instruction/1854738 deleted file mode 100644 index ae273215c..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1854738 +++ /dev/null @@ -1,34 +0,0 @@ -instruction: 0.416 -syscall: 0.412 -runtime: 0.172 - - - -ppc doesn't support for mttcg but ppc64 supported - -Currently ppc and ppc64abi32 doesn't suppport for mttcg, I am looking for support -``` - ppc) - gdb_xml_files="power-core.xml power-fpu.xml power-altivec.xml power-spe.xml" - ;; - ppc64) - TARGET_BASE_ARCH=ppc - TARGET_ABI_DIR=ppc - mttcg=yes - gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml" - ;; - ppc64le) - TARGET_ARCH=ppc64 - TARGET_BASE_ARCH=ppc - TARGET_ABI_DIR=ppc - mttcg=yes - gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml" - ;; - ppc64abi32) - TARGET_ARCH=ppc64 - TARGET_BASE_ARCH=ppc - TARGET_ABI_DIR=ppc - echo "TARGET_ABI32=y" >> $config_target_mak - gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml" - ;; -``` \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1857811 b/results/classifier/zero-shot-user-mode/output/instruction/1857811 deleted file mode 100644 index a03be16d9..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1857811 +++ /dev/null @@ -1,13 +0,0 @@ -instruction: 0.656 -syscall: 0.182 -runtime: 0.163 - - - -qemu user static binary seems to lack support for network namespace. - -Whenever I execute emerge in gentoo linux in qemu-aarch64 chroot, I see the following error message. - -Unable to configure loopback interface: Operation not supported - -If I disable emerge's network-sandbox which utilizes network namespace, the error disappears. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1858415 b/results/classifier/zero-shot-user-mode/output/instruction/1858415 deleted file mode 100644 index a0c41f61f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1858415 +++ /dev/null @@ -1,30 +0,0 @@ -instruction: 0.523 -syscall: 0.244 -runtime: 0.233 - - - -in tcp_emu function has OOB bug - -qemu version: 4.1.0 - -```c -int tcp_emu(struct socket *so, struct mbuf *m){ -............ -case EMU_REALAUDIO: -............ - while (bptr < m->m_data + m->m_len) { - case 6: -............ - lport = (((uint8_t *)bptr)[0] << 8) + ((uint8_t *)bptr)[1]; -............ - *(uint8_t *)bptr++ = (p >> 8) & 0xff; - *(uint8_t *)bptr = p & 0xff; -............ - } -............ -............ -} -``` - -bptr)[1] and bptr++ ,may make bptr == m->m_data + m->m_len,and cause OOB（out of bounds.） \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1859713 b/results/classifier/zero-shot-user-mode/output/instruction/1859713 deleted file mode 100644 index b526b0042..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1859713 +++ /dev/null @@ -1,31 +0,0 @@ -instruction: 0.797 -syscall: 0.121 -runtime: 0.082 - - - -ARM v8.3a pauth not working - -Host: Ubuntu 19.10 - x86_64 machine -QEMU version: 3a63b24a1bbf166e6f455fe43a6bbd8dea413d92 (master) - -ARMV8.3 pauth is not working well. - -With a test code containing two pauth instructions: - - paciasp that sign LR with A key and sp as context; - - autiasp that verify the signature. - -Test: - - Run the program and corrupt LR just before autiasp (ex 0x3e00000400660 instead of 0x3e000000400664) - -Expected: - - autiasp places an invalid pointer in LR - -Result: - - autiasp successfully auth the pointer and places 0x0400660 in LR. - -Further explanations: - Adding traces in qemu code shows that "pauth_computepac" is not robust enough against truncating. - With 0x31000000400664 as input of pauth_auth, we obtain "0x55b1d65b2c138e14" for PAC, "0x30" for bot_bit and "0x38" for top_bit. - With 0x310040008743ec as input of pauth (with same key), we obtain "0x55b1d65b2c138ef4" for PAC, "0x30" for bot_bit and "0x38" for top_bit. - Values of top_bit and bottom_bit are strictly the same and it should not. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1860053 b/results/classifier/zero-shot-user-mode/output/instruction/1860053 deleted file mode 100644 index 487769150..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1860053 +++ /dev/null @@ -1,26 +0,0 @@ -instruction: 0.521 -runtime: 0.363 -syscall: 0.116 - - - -Possible lack of precision when calling clock_gettime via vDSO on user mode ppc64le - -Occurs on QEMU v4.2.0 run on docker (via the qemu-user-static:v4.2.0-2 image) on an AMD64 Ubuntu 18.04.3 LTS machine provided by travis-ci.org. - -From golang's https://github.com/golang/go/issues/36592: - -It was discovered that golang's time.NewTicker() and time.Sleep() malfunction when a compiled application was run via QEMU's ppc64le emulator in user mode. - -The methods did not malfunction on actual PowerPC hardware or when the same golang application was compiled for golang's arm, arm64 or 386 targets and was run via user mode QEMU on the same system. - -Curiously, the methods also worked when the program was compiled under go 1.11, but do malfunction in go 1.12 and 1.13. - -It was identified the change in behaviour was most likely attributable to golang switching to using vSDO for calling clock_gettime() on PowerPC 64 architectures in 1.12. I.E: -https://github.com/golang/go/commit/dbd8af74723d2c98cbdcc70f7e2801f69b57ac5b - -We therefore suspect there may be a bug in QEMU's user-mode emulation of ppc64le as relates to vDSO calls to clock_gettime(). - -The nature of the malfunction of time.NewTicker() and time.Sleep() is such that sleeps or ticks with a granularity of less than one second do not appear to be possible (they all revert to 1 second sleeps/ticks). Could it be that the nanoseconds field of clock_gettime() is getting lost in the vDSO version but not in the syscall? Or some other issue calling these methods via vDSO? - -Thanks in advance. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1860056 b/results/classifier/zero-shot-user-mode/output/instruction/1860056 deleted file mode 100644 index 37aa8c1ba..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1860056 +++ /dev/null @@ -1,26 +0,0 @@ -instruction: 0.674 -syscall: 0.167 -runtime: 0.159 - - - -mips binaries segfault - -Hello World appears to segfault with qemu mips, on a Debian 10.0.0 Buster amd64 host. - -Example: - - -$ cat mips/test/hello.cpp -#include <iostream> -using std::cout; - -int main() { - cout << "Hello World!\n"; - return 0; -} - -$ mips-linux-gnu-g++ -o hello hello.cpp && ./hello -qemu: uncaught target signal 11 (Segmentation fault) - core dumped - -Note that 64-bit MIPS and little endian 32-bit MIPS qemu work fine. The problem is limited to big endian 32-bit MIPS. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1861404 b/results/classifier/zero-shot-user-mode/output/instruction/1861404 deleted file mode 100644 index 939fbc017..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1861404 +++ /dev/null @@ -1,56 +0,0 @@ -instruction: 0.389 -runtime: 0.335 -syscall: 0.275 - - - -AVX instruction VMOVDQU implementation error for YMM registers - -Hi, - -Tested with Qemu 4.2.0, and with git version bddff6f6787c916b0e9d63ef9e4d442114257739. - -The x86 AVX instruction VMOVDQU doesn't work properly with YMM registers (32 bytes). -It works with XMM registers (16 bytes) though. - -See the attached test case `ymm.c`: when copying from memory-to-ymm0 and then back from ymm0-to-memory using VMOVDQU, Qemu only copies the first 16 of the total 32 bytes. - -``` -user@ubuntu ~/Qemu % gcc -o ymm ymm.c -Wall -Wextra -Werror - -user@ubuntu ~/Qemu % ./ymm -00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F - -user@ubuntu ~/Qemu % ./x86_64-linux-user/qemu-x86_64 -cpu max ymm -00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -``` - -This seems to be because in `translate.c > gen_sse()`, the case handling the VMOVDQU instruction calls `gen_ldo_env_A0` which always performs a 16 bytes copy using two 8 bytes load and store operations (with `tcg_gen_qemu_ld_i64` and `tcg_gen_st_i64`). - -Instead, the `gen_ldo_env_A0` function should generate a copy with a size corresponding to the used register. - - -``` -static void gen_sse(CPUX86State *env, DisasContext *s, int b, - target_ulong pc_start, int rex_r) -{ - [...] - case 0x26f: /* movdqu xmm, ea */ - if (mod != 3) { - gen_lea_modrm(env, s, modrm); - gen_ldo_env_A0(s, offsetof(CPUX86State, xmm_regs[reg])); - } else { - [...] -``` - -``` -static inline void gen_ldo_env_A0(DisasContext *s, int offset) -{ - int mem_index = s->mem_index; - tcg_gen_qemu_ld_i64(s->tmp1_i64, s->A0, mem_index, MO_LEQ); - tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, ZMM_Q(0))); - tcg_gen_addi_tl(s->tmp0, s->A0, 8); - tcg_gen_qemu_ld_i64(s->tmp1_i64, s->tmp0, mem_index, MO_LEQ); - tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, ZMM_Q(1))); -} -``` \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1862167 b/results/classifier/zero-shot-user-mode/output/instruction/1862167 deleted file mode 100644 index a713f0713..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1862167 +++ /dev/null @@ -1,9 +0,0 @@ -instruction: 0.742 -runtime: 0.150 -syscall: 0.107 - - - -Variation of SVE register size (qemu-user-aarch64) - -Specification of ARMv8-A SVE extention allows various values for the size of the SVE register. On the other hand, it seems that the current qemu-aarch64 supports only the maximum length of 2048 bits as the SVE register size. I am writing an assembler program for a CPU that is compliant with ARMv8-A + SVE and has a 512-bit SVE register, but when this is run with qemu-user-aarch64, a 2048-bit load / store instruction is executed This causes a segmentation fault. Shouldn't qeum-user-aarch64 have an option to specify the SVE register size? \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1862986 b/results/classifier/zero-shot-user-mode/output/instruction/1862986 deleted file mode 100644 index 0f3345858..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1862986 +++ /dev/null @@ -1,70 +0,0 @@ -instruction: 0.350 -runtime: 0.341 -syscall: 0.309 - - - -qemu-s390x segfaults - -All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault when run on an aarch64 odroid Ubuntu. - -Steps to reproduce: - -root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x "/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig" -Segmentation fault (core dumped) -root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x --version -qemu-s390x version 4.2.0 -Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers -root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x "/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig" -Segmentation fault (core dumped) -root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x --version -qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22) -Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers - - -qemu-arm does work on the same machine: - -root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-arm bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests -Running 4 test cases... - -*** No errors detected -root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-arm bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests -Running 4 test cases... - -*** No errors detected - - -What kind of debug information would be helpful for this issue report? - - -GDB for the self-compiled latest release is not particularly helpful: - -(gdb) run -Starting program: /usr/local/bin/qemu-s390x /root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig -[Thread debugging using libthread_db enabled] -Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". -[New Thread 0x7fb7a2a140 (LWP 28264)] - -Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault. -0x000000555596b218 in __bss_start__ () -(gdb) bt -#0 0x000000555596b218 in __bss_start__ () -#1 0x00000055556120a8 in ?? () -#2 0x00000055579904b0 in ?? () -Backtrace stopped: previous frame inner to this frame (corrupt stack?) - -A bit more information is available in the version shipped by Ubuntu: - -(gdb) run -Starting program: /usr/bin/qemu-s390x /root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig -[Thread debugging using libthread_db enabled] -Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". -[New Thread 0x7fb7a01180 (LWP 28271)] - -Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault. -0x0000005555738f98 in code_gen_buffer () -(gdb) bt -#0 0x0000005555738f98 in code_gen_buffer () -#1 0x00000055555e96c8 in cpu_exec () -#2 0x00000055555ee430 in cpu_loop () -#3 0x00000055555c3328 in main () \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1863247 b/results/classifier/zero-shot-user-mode/output/instruction/1863247 deleted file mode 100644 index 383a023c2..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1863247 +++ /dev/null @@ -1,14 +0,0 @@ -instruction: 0.878 -runtime: 0.078 -syscall: 0.044 - - - -AArch64 EXT instruction for V register does not clear MSB side bits - -On AArch64 CPU with SVE register, there seems to be a bug in the operation when executing EXT instruction to V registers. Bits above the 128 bits of the SVE register must be cleared to 0, but qemu-aarch64 seems to hold the value. - -Example -ext v0.16b, v1.16b v2.16b, 8 - -After executing above instruction, (N-1) to 128 bits of z0 register must be 0, where N is SVE register width. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1863445 b/results/classifier/zero-shot-user-mode/output/instruction/1863445 deleted file mode 100644 index cbb3033f3..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1863445 +++ /dev/null @@ -1,22 +0,0 @@ -instruction: 0.523 -runtime: 0.257 -syscall: 0.220 - - - -assertion failed at translate-all.c:2523 with version 3.1.1 - -I was trying to debug a userspace binary with radare2 and met the following assertion in qemu: - -``` -qemu-mipsel: /builddir/build/BUILD/qemu-3.1.1/accel/tcg/translate-all.c:2523: page_check_range: Assertion `start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)' failed. -qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7fd1c11c5987 -``` - -``` -# qemu-mipsel --version -qemu-mipsel version 3.1.1 (qemu-3.1.1-2.fc30) -Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers -``` - -not much to add. seems like qemu is not properly checking for valid addresses \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1869073 b/results/classifier/zero-shot-user-mode/output/instruction/1869073 deleted file mode 100644 index 35b6e16e6..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1869073 +++ /dev/null @@ -1,13 +0,0 @@ -instruction: 0.565 -runtime: 0.265 -syscall: 0.170 - - - -qemu-arm-static crashes "segmentation fault" when running "git clone -s" - -I want to use qemu-arm-static to cross-compile software. The compiler itself is a native cross-compiler connected via "distcc". - -The problem is that a script tries to do some stuff with "git" and with a "git clone -s" command the whole story reproducibly stops with a "segmentation fault". - -I don't know how to properly debug the issue but it happens 100% of the time that I get the "crash" or git just hangs forever with 100% CPU usage. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1869241 b/results/classifier/zero-shot-user-mode/output/instruction/1869241 deleted file mode 100644 index f111dd0df..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1869241 +++ /dev/null @@ -1,25 +0,0 @@ -instruction: 0.398 -runtime: 0.320 -syscall: 0.282 - - - -svn checkout fails with E000075 "Value too large for defined data type" - -I try to autobuild for ARM7 with qemu-arm-static. Part of this is downloading source via SVN. - -Whenever I try to download a SVN repository I get the following output: - - svn: E000075: Can't read directory '...': Value too large for defined data type - -qemu-arm-static version is 4.2.0 - -I've also tried older versions without change. - -Platform I try to emulate is armv7h (Arch Linux ARM for Raspberry Pi 2) - -Host system is AMD64 - -This can be reproduced 100% of the time. Here I have the issue happening on Travis CI: - -https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/304839747#L7228 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1869782 b/results/classifier/zero-shot-user-mode/output/instruction/1869782 deleted file mode 100644 index fe866d0c7..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1869782 +++ /dev/null @@ -1,19 +0,0 @@ -instruction: 0.401 -syscall: 0.349 -runtime: 0.250 - - - -qemu-arm-static crashes "segmentation fault" when running "svn checkout" - -I'm not actually sure how far I can help as I so far failed to reproduce the issue on my local VM but I get it on Travis CI every time. I even went through the hassle of hacking a Debian repository into their Ubuntu Bionic VM to get qemu 4.2 as I hoped a new version could fix this. - -Here is where the error occured: https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/309106220#L5420 - -I don't get this error with an armv7h chroot. - -Maybe now I'll just try to remove all uses of svn in my build scripts... - -Is it actually a viable solution to cross-build with qemu? I'm starting to doubt it... - -Would it help if I manage to get this core dump out of Travis somehow (maybe make Travis push it to some GIT or upload it to my webserver)? \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1870477 b/results/classifier/zero-shot-user-mode/output/instruction/1870477 deleted file mode 100644 index 47c408fad..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1870477 +++ /dev/null @@ -1,39 +0,0 @@ -instruction: 0.440 -runtime: 0.293 -syscall: 0.267 - - - -qemu-arm hangs when golang running test - - -1. Environment: -Ubuntu 16.04.5 X86_64 -qemu-arm version 4.2.0 -go version go 1.14.1 linux/arm - -2. Summary: -Sometimes "go run test.go" command hang - - -3. Reproduction Method (Attempts: 500 Occurred: 1 ): Frequency: 1/500 - - -test.go -====================================== -package main -import "fmt" -func main(){ - for i:=0; i<1000; i++ { - fmt.Printf("[%d] Hello world\n", i) - } -} -====================================== - -i tested "go run test.go" command called 500 times at qemu arm env. -qemu hangs about 200~300. - -attached strace log. - -please check. -thanks \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1874888 b/results/classifier/zero-shot-user-mode/output/instruction/1874888 deleted file mode 100644 index 3a70e924a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1874888 +++ /dev/null @@ -1,49 +0,0 @@ -instruction: 0.438 -runtime: 0.380 -syscall: 0.183 - - - -certain programs make QEMU crash with "tcg fatal error" - -The following code snippet crashes qemu with - -.../tcg/tcg.c:3279: tcg fatal error -qemu-x86_64: /usr/local/google/home/kostik/qemu-5.0.0-rc4/accel/tcg/cpu-exec.c:701: int cpu_exec(CPUState *): Assertion `!have_mmap_lock()' failed. - -================ -int main() { - /* -00000000 <.data>: - 0: 2e 45 71 ff cs rex.RB jno 0x3 - 4: e9 00 00 f0 00 jmp 0xf00009 - 9: c4 42 7d 31 3e vpmovzxbd ymm15,QWORD PTR [r14] - e: c4 a3 7d 08 64 82 44 vroundps ymm4,YMMWORD PTR [rdx+r8*4+0x44],0x0 - 15: 00 - 16: 0f 1e 0a nop DWORD PTR [rdx] - 19: 43 0f ec 20 rex.XB paddsb mm4,QWORD PTR [r8] - 1d: 66 47 0f 3a 0c 3d 00 rex.RXB blendps xmm15,XMMWORD PTR [rip+0x8000],0x0 # 0x8028 - 24: 80 00 00 00 - 28: c4 e3 f9 df 5f 86 0d vaeskeygenassist xmm3,XMMWORD PTR [rdi-0x7a],0xd - 2f: c4 e2 55 92 74 fc 0a vgatherdps ymm6,DWORD PTR [rsp+ymm7*8+0xa],ymm5 - 36: c4 e2 f9 17 9a 01 00 vptest xmm3,XMMWORD PTR [rdx+0x1] - 3d: 00 00 -*/ - char buf[] = { - 0x2E, 0x45, 0x71, 0xFF, 0xE9, 0x00, 0x00, 0xF0, 0x00, 0xC4, 0x42, 0x7D, 0x31, 0x3E, 0xC4, 0xA3, 0x7D, 0x08, 0x64, 0x82, 0x44, 0x00, 0x0F, 0x1E, 0x0A, 0x43, 0x0F, 0xEC, 0x20, 0x66, 0x47, 0x0F, 0x3A, 0x0C, 0x3D, 0x00, 0x80, 0x00, 0x00, 0x00, 0xC4, 0xE3, 0xF9, 0xDF, 0x5F, 0x86, 0x0D, 0xC4, 0xE2, 0x55, 0x92, 0x74, 0xFC, 0x0A, 0xC4, 0xE2, 0xF9, 0x17, 0x9A, 0x01, 0x00, 0x00, 0x00 - }; - void (*f)(void) = (void (*) (void))buf; - f(); - return 0; -} -================ -Steps to reproduce: -1) clang -static repro.c -o repro -2) qemu-x86_64-static repro - -Tested with 4.2.0 and 5.0.0-rc4. Both -user and -system variants are affected. - -A few more snippets that cause the same sort of behavior: -1) 0x64, 0x46, 0x7D, 0xFF, 0xDF, 0x27, 0x46, 0x0F, 0xD4, 0x83, 0x5E, 0x00, 0x00, 0x00, 0x3E, 0x0F, 0x6A, 0xEF, 0x0F, 0x05, 0xC4, 0x42, 0xFD, 0x1E, 0xCF, 0x46, 0x18, 0xE3, 0x47, 0xCD, 0x4E, 0x6E, 0x0F, 0x0F, 0x16, 0x8A - -2) 0x67, 0x45, 0xDB, 0xD0, 0xAA, 0xC4, 0xE2, 0xB1, 0x01, 0x57, 0x00, 0xF3, 0x6F, 0xF3, 0x42, 0x0F, 0x1E, 0xFD, 0x64, 0x2E, 0xF2, 0x45, 0xD9, 0xC4, 0x3E, 0xF3, 0x0F, 0xAE, 0xF4, 0x3E, 0x47, 0x0F, 0x1C, 0x22, 0x42, 0x73, 0xFF, 0xD9, 0xFD \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1877794 b/results/classifier/zero-shot-user-mode/output/instruction/1877794 deleted file mode 100644 index 1d3db8fe8..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1877794 +++ /dev/null @@ -1,9 +0,0 @@ -instruction: 0.579 -runtime: 0.243 -syscall: 0.179 - - - -Constant Folding on 64-bit Subtraction causes SIGILL on linux-user glxgears ppc64le to x86_64 by way of generating bad shift instruction with c=-1 - -Hello, I've been recently working on my own little branch of QEMU implementing the drm IOCTLs, when I discovered that glxgears seems to crash in GLXSwapBuffers(); with a SIGILL. I investigated this for about 2 weeks, manually trying to trace the call stack, only to find that we seemingly crash in a bad shift instruction. Originally intended to be an shr_i64 generated to an RLDICL, we end up with an all ones(-1) c value, which gets thrown to the macro for generating the MB, and replaces the instruction with mostly ones. This new instruction, FFFFFFE0 is invalid on ppc64le, and crashes in a host SIGILL in codegen_buffer. I tried to see if the output of translate.c had this bad instruction, but all I got were two (shr eax, cl) instructions, and upon creating a test program with shr (eax, cl) in it, nothing happened. Then figuring that there was nothing actually wrong with the instruction in the first place, I turned my eye to the optimizer, and completely disabled constant folding for arithmetic instructions. This seemed to actually resolve the issue, and then I slowly enabled constant folding again on various instructions only to find that enabling not on the shifts, but on subtraction seemed to cause the bug to reappear. I am bewildered and frankly at this point I'm not sure I have a chance in hell of figuring out what causes it, so I'm throwing it here. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1878501 b/results/classifier/zero-shot-user-mode/output/instruction/1878501 deleted file mode 100644 index 3675688f5..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1878501 +++ /dev/null @@ -1,37 +0,0 @@ -instruction: 0.405 -runtime: 0.320 -syscall: 0.275 - - - -qemu-i386 does not define AT_SYSINFO - -qemu-i386 does not define the AT_SYSINFO auxval when running i386 Linux binaries. - -On most libcs, this is properly handled, but this is mandatory for the i686 Bionic (Android) libc or it will segfault. - -This is due to a blind assumption that getauxval(AT_SYSINFO) will return a valid function pointer: - -The code varies from version to version, but it looks like this: - -void *__libc_sysinfo; -// mangled as _Z19__libc_init_sysinfov -void __libc_init_sysinfo() { - bool dummy; - // __bionic_getauxval = getauxval - __libc_sysinfo = reinterpret_cast<void *>(__bionic_getauxval(AT_SYSINFO, dummy)); -} - -A simple way to reproduce is to compile a basic C program against the NDK: - -int main(void) { return 0; } - -$ i686-linux-android-clang -static empty.c -o empty -$ qemu-i386 -cpu max ./empty -qemu: uncaught target signal 11 (Segmentation fault) - core dumped -Segmentation fault - -The place where it segfaults is misleading: It will, at least on the current NDK, crash on __set_thread_area, this is due to it calling a function pointer to __libc_sysinfo returned by __kernel_syscall. - -QEMU 4.1.1 (aarch64) -Pixel 2 XL via Termux \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1880332 b/results/classifier/zero-shot-user-mode/output/instruction/1880332 deleted file mode 100644 index 3bfbd35d9..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1880332 +++ /dev/null @@ -1,13 +0,0 @@ -instruction: 0.531 -syscall: 0.246 -runtime: 0.223 - - - -Possible regression in QEMU 5.0.0 after CVE-2020-10702 (segmentation fault) - -I've come across a very specific situation, but I'm sure it could be replicated in other cases. - -In QEMU 5.0.0 when I use user emulation with a cURL binary for aarch64 and connect to a server using TLS 1.2 and ECDHE-ECDSA-CHACHA20-POLY1305 cypher a segmentation fault occurs. - -I attach a Dockerfile that reproduces this crash and the strace output with and without the de0b1bae6461f67243282555475f88b2384a1eb9 commit reverted. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1880722 b/results/classifier/zero-shot-user-mode/output/instruction/1880722 deleted file mode 100644 index 8395b26e3..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1880722 +++ /dev/null @@ -1,20 +0,0 @@ -instruction: 0.564 -runtime: 0.251 -syscall: 0.185 - - - -Problems related to checking page crossing in use_goto_tb() - -The discussion that led to this bug discovery can be found in this -mailing list thread: -https://lists.nongnu.org/archive/html/qemu-devel/2020-05/msg05426.html - -A workaround for this problem would be to check for page crossings for -both the user and system modes in the use_goto_tb() function across -targets. Some targets like "hppa" already implement this fix but others -don't. - -To solve the root cause of this problem, the linux-user/mmap.c should -be fixed to do all the invalidations required. By doing so, up to 6.93% -performance improvements will be achieved. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1881450 b/results/classifier/zero-shot-user-mode/output/instruction/1881450 deleted file mode 100644 index 02ea0c99b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1881450 +++ /dev/null @@ -1,29 +0,0 @@ -instruction: 0.658 -runtime: 0.254 -syscall: 0.087 - - - -Emulation of a math function fails for m68k Linux user mode - -Please check the attached math-example.c file. -When running the m68k executable under QEMU, it results in an "Illegal instruction" error. -Other targets don't produce this error. - -Steps to reproduce the bug: - -1. Download the math-example.c attached file. -2. Compile it by running: - m68k-linux-gnu-gcc -O2 -static math-example.c -o math-example-m68k -lm -3. Run the executable with QEMU: - /build/qemu-5.0.0/build-gcc/m68k-linux-user/qemu-m68k math-example-m68k - -The output of execution is: - Profiling function expm1f(): - qemu: uncaught target signal 4 (Illegal instruction) - core dumped - Illegal instruction (core dumped) - -Expected output: - Profiling function expm1f(): - Elapsed time: 47 ms - Control result: 71804.953125 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1883268 b/results/classifier/zero-shot-user-mode/output/instruction/1883268 deleted file mode 100644 index 3cc38e8f2..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1883268 +++ /dev/null @@ -1,43 +0,0 @@ -instruction: 0.650 -syscall: 0.180 -runtime: 0.169 - - - -random errors on aarch64 when executing __aarch64_cas8_acq_rel - -Hello, - -Since I upgraded to qemu-5.0 when executing the GCC testsuite, -I've noticed random failures of g++.dg/ext/sync-4.C. - -I'm attaching the source of the testcase, the binary executable and the qemu traces (huge, 111MB!) starting at main (with qemu-aarch64 -cpu cortex-a57 -R 0 -d in_asm,int,exec,cpu,unimp,guest_errors,nochain) - -The traces where generated by a CI build, I built the executable manually but I expect it to be the same as the one executed by CI. - -In seems the problem occurs in f13, which leads to a call to abort() - -The preprocessed version of f13/t13 are as follows: -static bool f13 (void *p) __attribute__ ((noinline)); -static bool f13 (void *p) -{ - return (__sync_bool_compare_and_swap((ditype*)p, 1, 2)); -} -static void t13 () -{ - try { - f13(0); - } - catch (...) { - return; - } - abort(); -} - - -When looking at the execution traces at address 0x00400c9c, main calls f13, which in turn calls __aarch64_cas8_acq_rel (at 0x00401084) -__aarch64_cas8_acq_rel returns to f13 (address 0x0040113c), then f13 returns to main (0x0040108c) which then calls abort (0x00400ca0) - -I'm not quite sure what's wrong :-( - -I've not noticed such random problems with native aarch64 hardware. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1883784 b/results/classifier/zero-shot-user-mode/output/instruction/1883784 deleted file mode 100644 index 67b0a2afc..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1883784 +++ /dev/null @@ -1,15 +0,0 @@ -instruction: 0.635 -runtime: 0.212 -syscall: 0.153 - - - -[ppc64le] qemu behavior differs from ppc64le hardware - -I have some code which passes my test suite on PPC64LE hardware when compiled with GCC 10, but the saem binary fails with both qemu-ppc64le 4.2 (on Fedora 32) and qemu-ppc64le-static 5.0.0 (Debian testing). - -I'm not getting any errors about illegal instructions or anything, like that; the results are just silently different on qemu. - -I've generated a reduced test case, which is attached along with the binaries (both are the same code, one is just statically linked). They should execute successufully on PPC64LE hardware, but on qemu they hit a __builtin_abort (because the computed value doesn't match the expected value). - -Without being familiar with PPC assembly I'm not sure what else I can do, but if there is anything please let me know. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1885350 b/results/classifier/zero-shot-user-mode/output/instruction/1885350 deleted file mode 100644 index 4e5dc9cd8..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1885350 +++ /dev/null @@ -1,29 +0,0 @@ -instruction: 0.691 -syscall: 0.179 -runtime: 0.130 - - - -RISCV dynamic rounding mode is not behaving correctly - -Hello, - -I’ve gone through the RISC-V code in latest QEMU release (qemu-5.0.0-rc2) and when checking the Floating point encodings I found the rounding mode is only updated if the opcode field “rm” is changed “ctx->frm == rm”. But according to RISC-V Volume I: Unprivileged ISA, there’s a dynamic mode when rm=7 where the rounding mode is set with frm value. - -So for the same rm value (=7) and when changing frm value seeking different rounding modes, and according to the below code, the rounding mode won’t be updated. Please correct me if I got this implementation wrong. - -static void gen_set_rm(DisasContext *ctx, int rm) -{ - TCGv_i32 t0; - if (ctx->frm == rm) { - return; - } - ctx->frm = rm; - t0 = tcg_const_i32(rm); - gen_helper_set_rounding_mode(cpu_env, t0); - tcg_temp_free_i32(t0); -} - - -My testcase: -I set statically the rm field in the instruction to 7 and before this execution I changed the value of frm field in fcsr register. For the 1st time it worked (according to the code above, the rm is updated so the round mode will also be updated). But when changing fcsr register an re-execute the instruction, there's no difference and the rounding mode is the same like the previous frm value. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1887306 b/results/classifier/zero-shot-user-mode/output/instruction/1887306 deleted file mode 100644 index a40a3015b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1887306 +++ /dev/null @@ -1,61 +0,0 @@ -instruction: 0.498 -runtime: 0.308 -syscall: 0.194 - - - -qemu-user deadlocks when forked in a multithreaded process - -The following program (also attached) deadlocks when run under QEMU user on Linux. - -#include <pthread.h> -#include <stdio.h> -#include <stdlib.h> -#include <sys/types.h> -#include <sys/wait.h> -#include <unistd.h> - -#define NUM_THREADS 100 -#define NUM_FORKS 10 - -pthread_barrier_t barrier; - -void *t(void *arg) { - for (int i = 0; i < NUM_FORKS; i++) { - pid_t pid = fork(); - if (pid < 0) - abort(); - if (!pid) - _exit(0); - if (waitpid(pid, NULL, 0) < 0) - abort(); - } - //pthread_barrier_wait(&barrier); - return NULL; -} - -int main(void) { - pthread_barrier_init(&barrier, NULL, NUM_THREADS); - pthread_t ts[NUM_THREADS]; - for (size_t i = 0; i < NUM_THREADS; i++) { - if (pthread_create(&ts[i], NULL, t, NULL)) - abort(); - } - for (size_t i = 0; i < NUM_THREADS; i++) { - pthread_join(ts[i], NULL); - } - printf("Done: %d\n", getpid()); - return 0; -} - -To reproduce: -$ gcc test.c -pthread -$ while qemu-x86_64 ./a.out; do :; done - -(Be careful, Ctrl-C/SIGINT doesn't kill the deadlocked child). - -Larger values of NUM_THREADS/NUM_FORKS lead to more often deadlocks. With the values above it often deadlocks on the first try on my machine. When it deadlocks, there is a child qemu process with two threads which is waited upon by one of the worker threads of the parent. - -I tried to avoid the deadlock by serializing fork() with a mutex, but it didn't help. However, ensuring that no thread exits until all forks are done (by adding a barrier to t()) does seem to help, at least, the program above could run for a half an hour until I terminated it. - -Tested on QEMU 5.0.0, 4.2.0 and 2.11.1, with x86_64 and AArch64 linux-user targets. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1888303 b/results/classifier/zero-shot-user-mode/output/instruction/1888303 deleted file mode 100644 index f35a99e6f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1888303 +++ /dev/null @@ -1,26 +0,0 @@ -instruction: 0.726 -runtime: 0.159 -syscall: 0.115 - - - -Intermittent buggines with user mode emulation of x86-64 on aarch64 - -QEMU Version: 5.0.0 -./configure --target-list=x86_64-linux-user --enable-user --prefix=/opt/qemu --static - -Testing using node_exporter from pmm-client-1.17.4-1.el8.x86_64.rpm - -aarch64 system is running CentOS 8 with a mainline 5.4.52 kernel built for 4KB memory pages. - -On aarch64 machine, invoke: - -./qemu-x86_64-static /usr/local/percona/pmm-client/node_exporter.x86_64 -web.listen-address=192.168.0.10:42000 -web.auth-file=/usr/local/percona/pmm-client/pmm.yml -web.ssl-key-file=/usr/local/percona/pmm-client/server.key -web.ssl-cert-file=/usr/local/percona/pmm-client/server.crt -collectors.enabled=diskstats,filefd,filesystem,loadavg,meminfo,netdev,netstat,stat,time,uname,vmstat,meminfo_numa,textfile - -Most of the time it will outright segfault within a few seconds, seemingly when the prometheus server polls for data. - -But, about once every 10 times, it will not sefault and will continue working just fine forever. - -The dynamically linked version of qemu (built without --static) always works without segfaulting, but it just doesn't work, the prometheus server gets no data from it. Again, once in a while it will work, but even when it doesn't work it won't segfault. - -This vaguely feels like a memory alignment issue somewhere, but my debug-fu is not quite strong enough to attack the problem. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1888728 b/results/classifier/zero-shot-user-mode/output/instruction/1888728 deleted file mode 100644 index e5ec58d19..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1888728 +++ /dev/null @@ -1,25 +0,0 @@ -instruction: 0.503 -runtime: 0.298 -syscall: 0.200 - - - -Bare chroot in linux-user fails with pgb_reserved_va: Assertion `guest_base != 0' failed. - -Trying to run a bare chroot with no additional bind mounts fails on git master (8ffa52c20d5693d454f65f2024a1494edfea65d4) with: - -root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ -qemu-m68k-static: /root/qemu/linux-user/elfload.c:2315: pgb_reserved_va: Assertion `guest_base != 0' failed. -Aborted -root@nofan:~/qemu> - -The problem can be worked around by bind-mounting /proc from the host system into the target chroot: - -root@nofan:~/qemu> mount -o bind /proc/ /local_scratch/sid-m68k-sbuild/proc/ -root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ -bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) -(sid-m68k-sbuild)root@nofan:/# - -Host system is an up-to-date Debian unstable (2020-07-23). - -I have not been able to bisect the issue yet since there is another annoying linux-user bug (virtual memory exhaustion) that was somewhere introduced and fixed between v5.0.0 and HEAD and overshadows the original Assertion failure bug. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1889288 b/results/classifier/zero-shot-user-mode/output/instruction/1889288 deleted file mode 100644 index 0bafe90f6..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1889288 +++ /dev/null @@ -1,13 +0,0 @@ -instruction: 0.889 -runtime: 0.081 -syscall: 0.030 - - - -aarch64 BICS instruciton doesn't set flags - -When reading the source for translate-a64.c here: - -https://github.com/qemu/qemu/blob/a466dd084f51cdc9da2e99361f674f98d7218559/target/arm/translate-a64.c#L4783 - -I noticed that it does not appear to call gen_logic_CC for the BICS instruction so is not setting the flags as required. I haven't tried to produce a test case for it but it seems like it might be a bug. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1889411 b/results/classifier/zero-shot-user-mode/output/instruction/1889411 deleted file mode 100644 index d61518a45..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1889411 +++ /dev/null @@ -1,69 +0,0 @@ -instruction: 0.603 -runtime: 0.289 -syscall: 0.108 - - - -RISC-V: Unable to unwind the stack upon signals - -Consider the following program: - -=============================================================== -#include <stdio.h> -#include <stdlib.h> - -#define NOINLINE __attribute__ ((noinline)) - -void NOINLINE abort_me(void) { abort(); /* trigger SIGABRT */ } - -void NOINLINE level1(void) { abort_me(); } - -void NOINLINE level2(void) { level1(); } - -void NOINLINE level3(void) { level2(); } - -void NOINLINE level4(void) { level3();} - -int main(void) { - level4(); - return 0; -} -=============================================================== - -$ riscv64-linux-gnu-gcc -march=rv64imafdc -O0 -g c.c -$ qemu-riscv64 -g 31337 ./c & -$ riscv64-unknown-linux-gnu-gdb -q -ex 'target remote localhost:31337' -ex 'b abort_me' -ex c -ex bt ./c -Reading symbols from c... -Remote debugging using localhost:31337 -Reading symbols from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1... -0x0000004000804f30 in _start () from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1 -Breakpoint 1 at 0x4000000632: file c.c, line 7. -Continuing. - -Breakpoint 1, abort_me () at c.c:7 -7 abort(); /* trigger SIGABRT */ -#0 abort_me () at c.c:7 -#1 0x0000004000000642 in level1 () at c.c:11 -#2 0x0000004000000658 in level2 () at c.c:15 -#3 0x000000400000066e in level3 () at c.c:19 -#4 0x0000004000000684 in level4 () at c.c:23 -#5 0x000000400000069a in main () at c.c:27 -=============================================================== - -So far so good, I get a proper backtrace as expected. If I let the signal trigger however, gdb is not able to unwind the stack: - -(gdb) c -Continuing. - -Program received signal SIGABRT, Aborted. -0x0000004000858074 in ?? () -(gdb) bt -#0 0x0000004000858074 in ?? () - - - -I get the same behaviour for SIGSEGV and SIGILL, I didn't try other signals. Apparently this scenario works on real hardware (see linked gdb issue below), and presumably it would work with system qemu (I haven't tested that yet though). So my guess is that qemu does something differently around signal handling than the linux kernel. - - -Full reproducer: https://gist.github.com/lewurm/befb9ddf5894bad9628b1df77258598b -RISC-V GDB issue: https://github.com/riscv/riscv-binutils-gdb/issues/223 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1890 b/results/classifier/zero-shot-user-mode/output/instruction/1890 deleted file mode 100644 index 9bf988173..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1890 +++ /dev/null @@ -1,31 +0,0 @@ -instruction: 0.522 -runtime: 0.248 -syscall: 0.230 - - - -qemu-arm 8.1.0 Error mapping file: Operation not permitted -Description of problem: -failed to execute the cortex-m binary hello_world, and says: -qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted -Steps to reproduce: -1. -``` -cat > hello_new.c <<EOF -#include <stdio.h> -int main() -{printf("hello world"); return 0;} -EOF -``` -2. -``` -arm-none-eabi-gcc -mcpu=cortex-m55 -g hello_world.c -o hello_world -specs=rdimon.specs -``` -3. -``` -qemu-arm -cpu cortex-m55 hello_world -qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted -``` -Additional information: -1, version 8.0.4 version is okay\ -2, arm-none-eabi-gcc version is 10.3.1 20210824 (release) diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1892081 b/results/classifier/zero-shot-user-mode/output/instruction/1892081 deleted file mode 100644 index 610d95177..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1892081 +++ /dev/null @@ -1,20 +0,0 @@ -instruction: 0.683 -runtime: 0.164 -syscall: 0.153 - - - -Performance improvement when using "QEMU_FLATTEN" with softfloat type conversions - -Attached below is a matrix multiplication program for double data -types. The program performs the casting operation "(double)rand()" -when generating random numbers. - -This operation calls the integer to float softfloat conversion -function "int32_to_float_64". - -Adding the "QEMU_FLATTEN" attribute to the function definition -decreases the instructions per call of the function by about 63%. - -Attached are before and after performance screenshots from -KCachegrind. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1894029 b/results/classifier/zero-shot-user-mode/output/instruction/1894029 deleted file mode 100644 index c96bd6fe3..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1894029 +++ /dev/null @@ -1,45 +0,0 @@ -instruction: 0.633 -runtime: 0.263 -syscall: 0.105 - - - -qemu-i386 malloc error - -Hi!I use qemu-i386-static on 64 bit machines.And memory request succeeded, but the pointer is wrong. -This is my test program: - -#include <stdint.h> -#include <stdio.h> -#include <stdlib.h> -#include <unistd.h> - -int main(int argc, char **argv) -{ - void *pa=0,*pb=0,*pc=0,*pd=0; - pa = malloc(sizeof(uint32_t)); - pb = malloc(sizeof(uint32_t)); - pc = malloc(4); - pd = malloc(4); - printf("pa: 0x%x\n",pa); - printf("pb: 0x%x\n",pb); - printf("pc: 0x%x\n",pc); - printf("pd: 0x%x\n",pd); - printf("uint32_t:%d\n",sizeof(uint32_t)); - free(pa); - free(pb); - free(pc); - free(pd); - return 0; -} - -And it is wrong: - -pa: 0x400051a0 -pb: 0x400051b0 -pc: 0x400051c0 -pd: 0x400051d0 -uint32_t:4 - -Why did I apply for 4 bytes of space, but the pointer only increased by 2 bytes?? -Is it a BUG?? \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1895080 b/results/classifier/zero-shot-user-mode/output/instruction/1895080 deleted file mode 100644 index 807c0df88..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1895080 +++ /dev/null @@ -1,42 +0,0 @@ -instruction: 0.379 -runtime: 0.330 -syscall: 0.291 - - - -pgb_reserved_va: Assertion `addr == test' failed - -This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux-user. - -Firstly, compile fails: -Compiling C object libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o -../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ undeclared here (not in a function) - FLAG_GENERIC(FALLOC_FL_KEEP_SIZE), - -I have to add below include to linux-user/strace.c -diff --git a/linux-user/strace.c b/linux-user/strace.c -index 11fea14fba..22e51d4a8a 100644 ---- a/linux-user/strace.c -+++ b/linux-user/strace.c -@@ -7,6 +7,7 @@ - #include <sys/mount.h> - #include <arpa/inet.h> - #include <netinet/tcp.h> -+#include <linux/falloc.h> - #include <linux/if_packet.h> - #include <linux/netlink.h> - #include <sched.h> - -Then trying qemu-riscv32 with a simple ELF, I get: -linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed. - -strace shows that: -mmap(0x1000, 4294963200, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 -write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed. -) = 103 - -The source code is in the function pgb_reserved_va (linux-user/elfload.c). I think mmap cannot guarantee that the returned pointer (test) equals to the parameter of addr. So is this a bug to assert (addr == test)? - -Attached configure script and test ELF file. - -Thanks. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1895471 b/results/classifier/zero-shot-user-mode/output/instruction/1895471 deleted file mode 100644 index dca5f0d64..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1895471 +++ /dev/null @@ -1,29 +0,0 @@ -instruction: 0.455 -runtime: 0.347 -syscall: 0.198 - - - -compilation error with clang in util/async.c - -configured with ` CC=clang CXX=clang++ ../configure --target-list=x86_64-softmmu --enable-kvm --enable-curl --enable-debug --enable-jemalloc --enable-fuzzing --enable-sdl` and after make I get the following error related to c11 atomics. I'm using clang because I'm experimenting with fuzzer - -[glitz@archlinux /code/qemu/build]$ ninja -j5 -[479/2290] Compiling C object libqemuutil.a.p/util_async.c.o -FAILED: libqemuutil.a.p/util_async.c.o -clang -Ilibqemuutil.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/p11-kit-1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -Ilinux-headers -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Werror -std=gnu99 -g -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -fstack-protector-strong -fsanitize=fuzzer-no-link -iquote /code/qemu/tcg/i386 -isystem /code/qemu/linux-headers -iquote . -iquote /code/qemu -iquote /code/qemu/accel/tcg -iquote /code/qemu/include -iquote /code/qemu/disas/libvixl -pthread -fPIC -MD -MQ libqemuutil.a.p/util_async.c.o -MF libqemuutil.a.p/util_async.c.o.d -o libqemuutil.a.p/util_async.c.o -c ../util/async.c -../util/async.c:79:17: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid) - old_flags = atomic_fetch_or(&bh->flags, BH_PENDING | new_flags); - ^ ~~~~~~~~~~ -/usr/lib/clang/10.0.1/include/stdatomic.h:138:42: note: expanded from macro 'atomic_fetch_or' -#define atomic_fetch_or(object, operand) __c11_atomic_fetch_or(object, operand, __ATOMIC_SEQ_CST) - ^ ~~~~~~ -../util/async.c:105:14: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid) - *flags = atomic_fetch_and(&bh->flags, - ^ ~~~~~~~~~~ -/usr/lib/clang/10.0.1/include/stdatomic.h:144:43: note: expanded from macro 'atomic_fetch_and' -#define atomic_fetch_and(object, operand) __c11_atomic_fetch_and(object, operand, __ATOMIC_SEQ_CST) - ^ ~~~~~~ -2 errors generated. -[483/2290] Compiling C object libqemuutil.a.p/util_qemu-error.c.o -ninja: build stopped: subcommand failed. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1895703 b/results/classifier/zero-shot-user-mode/output/instruction/1895703 deleted file mode 100644 index d46af6a5d..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1895703 +++ /dev/null @@ -1,24 +0,0 @@ -instruction: 0.842 -runtime: 0.085 -syscall: 0.073 - - - -performance degradation in tcg since Meson switch - -The buildsys conversion to Meson (1d806cef0e3..7fd51e68c34) -introduced a degradation in performance in some TCG targets: - --------------------------------------------------------- -Test Program: matmult_double --------------------------------------------------------- -Target Instructions Previous Latest - 1d806cef 7fd51e68 ----------- -------------------- ---------- ---------- -alpha 3 233 957 639 ----- +7.472% -m68k 3 919 110 506 ----- +18.433% --------------------------------------------------------- - -Original report from Ahmed Karaman with further testing done -by Aleksandar Markovic: -https://<email address hidden>/msg740279.html \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1898954 b/results/classifier/zero-shot-user-mode/output/instruction/1898954 deleted file mode 100644 index 09c697ffa..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1898954 +++ /dev/null @@ -1,32 +0,0 @@ -instruction: 0.590 -runtime: 0.278 -syscall: 0.132 - - -x86 f1 opcode hangs qemu - -I have qemu installed and running in linux and windows -in linux i execute the following simple code in real mode of cpu in my vm -90 nop -90 nop -90 nop -f1 ;this should conjure up my interrupt handler from ivt int 1 ---------- end of code ---- -it works properly in vbox,qemu linux,and even in my boot loder -on a real platform - it doeas not work fine in windows 10 (32 bit efi) based qemu ---- -all of the below was retyped there may be typo -so onwards to the flawed software -********** for qemu-system-x86_64.exe ********** -info version -4.2.0v4.2.0.11797-g2890edc853-dirty -********** for qemu-system-i386.exe ********** -info version -4.2.0v4.2.0.11797-g2890edc853-dirty -*********************************************** -my startup code is -"d:\programs\qemu\qemu-system-x86_64.exe" -m 16M -boot a -fda "d:\floppy.img" -cpu Nehalem -machine pc ---- -also same flaw if i change above section to -"d:\programs\qemu\qemu-system-i386.exe" \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1901 b/results/classifier/zero-shot-user-mode/output/instruction/1901 deleted file mode 100644 index 13a696bd8..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1901 +++ /dev/null @@ -1,25 +0,0 @@ -instruction: 0.890 -runtime: 0.081 -syscall: 0.030 - - - -qemu-sparc64 / sparc32plus apparent wrong results from VIS fmul8x16 instruction -Description of problem: -Experimenting with SPARC emulation, I noticed that the results of the UltraSparc fmul8x16 instruction don't appear to match the behaviour of real silicon (aka it doesn't appear to work at all -- in the test program, the result seems to be always 0). Other VIS instructions I tried seem to be OK (I have not tried all of them). - -The same problem is observed both in 64-bit (qemu-sparc64) and 32-bit (qemu-sparc32plus) applications. -Steps to reproduce: -1. Compile the attached test program (which exhaustively tests all possible combinations of 16-bit and 8-bit inputs) with gcc: - ``` - sparc64-unknown-linux-gnu-gcc -static -Os -mcpu=ultrasparc -mvis -o test_fmul8x16 test_fmul8x16.c - ``` -2. Run it in qemu-sparc64: - ``` - qemu-sparc64 -cpu 'TI UltraSparc II' ./test_fmul8x16 - ``` -3. Observe almost all tests fail. - - Running the exact same compiled binary on a real UltraSparc II CPU gives all pass results. -Additional information: -[test_fmul8x16.c](/uploads/2bf68e53652fba2ed69ac3ebb3f4b5e9/test_fmul8x16.c) diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1904210 b/results/classifier/zero-shot-user-mode/output/instruction/1904210 deleted file mode 100644 index 9013efe63..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1904210 +++ /dev/null @@ -1,57 +0,0 @@ -instruction: 0.444 -syscall: 0.334 -runtime: 0.222 - - - -Crashed with 'uncaught target signal SIGILL' while program has registered by signal(SIGILL, handler) - -This binary is an CTF reverse challenge binary, it registers signal handler via 'signal(SIGILL, 0x1193D);' while 0x1193D is the SIGILL handler. - -Please see the attachment, the file 'repair' is the binary i mentioned above, the file 'qemu-arm' is an old version qemu at 2.5.0, and it seems an official release (not modified). - -Which means, it could be a bug in recent release. - -You need to input 'flag{' to the stdin to let the binary execute the illegal instruction at 0x10A68. - -In 2.5.0 version the -strace logs: -116 uname(0xf6ffed40) = 0 -116 brk(NULL) = 0x0009f000 -116 brk(0x0009fd00) = 0x0009fd00 -116 readlink("/proc/self/exe",0xf6ffde78,4096) = 21 -116 brk(0x000c0d00) = 0x000c0d00 -116 brk(0x000c1000) = 0x000c1000 -116 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) -116 rt_sigaction(SIGILL,0xf6ffec48,0xf6ffecd4) = 0 -116 fstat64(1,0xf6ffe8e8) = 0 -116 ioctl(1,21505,-151000980,-151000924,652480,640808) = 0 -116 fstat64(0,0xf6ffe7d0) = 0 -116 ioctl(0,21505,-151001260,-151001204,652480,641152) = 0 -116 write(1,0xa5548,6)input: = 6 -116 read(0,0xa6550,4096)flag{ - = 6 -116 write(1,0xa5548,7)wrong! - = 7 -116 _llseek(0,4294967295,4294967295,0xf6ffee18,SEEK_CUR) = -1 errno=29 (Illegal seek) -116 exit_group(0) - -In 2.11.1, it shows: -113 uname(0xfffeed30) = 0 -113 brk(NULL) = 0x0009f000 -113 brk(0x0009fd00) = 0x0009fd00 -113 readlink("/proc/self/exe",0xfffede68,4096) = 21 -113 brk(0x000c0d00) = 0x000c0d00 -113 brk(0x000c1000) = 0x000c1000 -113 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) -113 rt_sigaction(SIGILL,0xfffeec38,0xfffeecc4) = 0 -113 fstat64(1,0xfffee8d8) = 0 -113 ioctl(1,21505,-71588,-71532,652480,640808) = 0 -113 fstat64(0,0xfffee7c0) = 0 -113 ioctl(0,21505,-71868,-71812,652480,641152) = 0 -113 write(1,0xa5548,6)input: = 6 -113 read(0,0xa6550,4096)flag{ - = 6 ---- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0x00010a68} --- ---- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0x0001182c} --- -qemu: uncaught target signal 4 (Illegal instruction) - core dumped -Illegal instruction (core dumped) \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1904259 b/results/classifier/zero-shot-user-mode/output/instruction/1904259 deleted file mode 100644 index 4b6035126..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1904259 +++ /dev/null @@ -1,35 +0,0 @@ -instruction: 0.457 -runtime: 0.315 -syscall: 0.228 - - - -include/qemu/atomic.h:495:5: error: misaligned atomic operation may incur significant performance penalty (Clang 11; Ubuntu 16 i686) - -Hello. -I haven't found any "official" executables, for emulating RISC-V (32bit; 64bit) so I had to compile those myself. - -I found that auto-generated build scripts, for Ninja, contained some warnings interpreted as errors: - - -oceanfish81@gollvm:~/Desktop/qemu/build$ ninja -j 1 -[2/1977] Compiling C object libqemuutil.a.p/util_qsp.c.o -FAILED: libqemuutil.a.p/util_qsp.c.o -clang-11 -Ilibqemuutil.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0/ -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Werror -std=gnu99 -O2 -g -m32 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -fstack-protector-strong -isystem /home/oceanfish81/Desktop/qemu/linux-headers -isystem linux-headers -iquote /home/oceanfish81/Desktop/qemu/tcg/i386 -iquote . -iquote /home/oceanfish81/Desktop/qemu -iquote /home/oceanfish81/Desktop/qemu/accel/tcg -iquote /home/oceanfish81/Desktop/qemu/include -iquote /home/oceanfish81/Desktop/qemu/disas/libvixl -pthread -Wno-unused-function -fPIC -MD -MQ libqemuutil.a.p/util_qsp.c.o -MF libqemuutil.a.p/util_qsp.c.o.d -o libqemuutil.a.p/util_qsp.c.o -c ../util/qsp.c -In file included from ../util/qsp.c:62: -In file included from /home/oceanfish81/Desktop/qemu/include/qemu/thread.h:4: -In file included from /home/oceanfish81/Desktop/qemu/include/qemu/processor.h:10: -/home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:495:5: error: misaligned atomic operation may incur significant performance penalty [-Werror,-Watomic-alignment] - qatomic_set__nocheck(ptr, val); - ^ -/home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:138:5: note: expanded from macro 'qatomic_set__nocheck' - __atomic_store_n(ptr, i, __ATOMIC_RELAXED) - ^ -/home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:485:12: error: misaligned atomic operation may incur significant performance penalty [-Werror,-Watomic-alignment] - return qatomic_read__nocheck(ptr); - ^ -/home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:129:5: note: expanded from macro 'qatomic_read__nocheck' - __atomic_load_n(ptr, __ATOMIC_RELAXED) - ^ -2 errors generated. -ninja: build stopped: subcommand failed. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1905356 b/results/classifier/zero-shot-user-mode/output/instruction/1905356 deleted file mode 100644 index ad337232e..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1905356 +++ /dev/null @@ -1,18 +0,0 @@ -instruction: 0.823 -runtime: 0.096 -syscall: 0.082 - - - -No check for unaligned data access in ARM32 instructions - -hi - -According to the ARM documentation, there are alignment requirements of load/store instructions. Alignment fault should be raised if the alignment check is failed. However, it seems that QEMU doesn't implement this, which is against the documentation of ARM. For example, the instruction LDRD/STRD/LDREX/STREX must check the address is word alignment no matter what value the SCTLR.A is. - -I attached a testcase, which contains a instruction at VA 0x10240: ldrd r0,[pc.#1] in the main function. QEMU can successfully load the data in the unaligned address. The test is done in QEMU 5.1.0. I can provide more testcases for the other instructions if you need. Many thanks. - -To patch this, we need a check while we translate the instruction to tcg. If the address is unaligned, a signal number (i.e., SIGBUS) should be raised. - -Regards -Muhui \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1906193 b/results/classifier/zero-shot-user-mode/output/instruction/1906193 deleted file mode 100644 index 994641c6a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1906193 +++ /dev/null @@ -1,63 +0,0 @@ -instruction: 0.439 -runtime: 0.384 -syscall: 0.177 - - - -riscv32 user mode emulation: fork return values broken - -When running in a chroot with riscv32 (on x86_64; qemu git master as of today): - -The following short program forks; the child immediately returns with exit(42). The parent checks for the return value - and obtains 40! - -gcc-10.2 - -=============================================== -#include <stdlib.h> -#include <unistd.h> -#include <stdio.h> -#include <sys/wait.h> - -main(c, v) - int c; - char **v; -{ - pid_t pid, p; - int s, i, n; - - s = 0; - pid = fork(); - if (pid == 0) - exit(42); - - /* wait for the process */ - p = wait(&s); - if (p != pid) - exit (255); - - if (WIFEXITED(s)) - { - int r=WEXITSTATUS(s); - if (r!=42) { - printf("child wants to return %i (0x%X), parent received %i (0x%X), difference %i\n",42,42,r,r,r-42); - } - } -} -=============================================== - -(riscv-ilp32 chroot) farino /tmp # ./wait-test-short -child wants to return 42 (0x2A), parent received 40 (0x28), difference -2 - -=============================================== -(riscv-ilp32 chroot) farino /tmp # gcc --version -gcc (Gentoo 10.2.0-r1 p2) 10.2.0 -Copyright (C) 2020 Free Software Foundation, Inc. -Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es -gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE. - -(riscv-ilp32 chroot) farino /tmp # ld --version -GNU ld (Gentoo 2.34 p6) 2.34.0 -Copyright (C) 2020 Free Software Foundation, Inc. -This program is free software; you may redistribute it under the terms of -the GNU General Public License version 3 or (at your option) a later version. -This program has absolutely no warranty. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1906536 b/results/classifier/zero-shot-user-mode/output/instruction/1906536 deleted file mode 100644 index ed08396db..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1906536 +++ /dev/null @@ -1,36 +0,0 @@ -instruction: 0.496 -syscall: 0.274 -runtime: 0.229 - - - -Unable to set SVE VL to 1024 bits or above since 7b6a2198 - -Prior to 7b6a2198e71794c851f39ac7a92d39692c786820, the QEMU option sve-max-vq could be used to set the vector length of the implementation. This is useful (among other reasons) for testing software compiled with a fixed SVE vector length. Since this commit, the vector length is capped at 512 bits. - -To reproduce the issue: - -$ cat rdvl.s -.global _start -_start: - rdvl x0, #1 - asr x0, x0, #4 - mov x8, #93 // exit - svc #0 -$ aarch64-linux-gnu-as -march=armv8.2-a+sve rdvl.s -o rdvl.o -$ aarch64-linux-gnu-ld rdvl.o -$ for vl in 1 2 4 8 16; do ../build-qemu/aarch64-linux-user/qemu-aarch64 -cpu max,sve-max-vq=$vl a.out; echo $?; done -1 -2 -4 -4 -4 - -For a QEMU built prior to the above revision, we get the output: -1 -2 -4 -8 -16 - -as expected. It seems that either the old behavior should be restored, or there should be an option to force a higher vector length? \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1907969 b/results/classifier/zero-shot-user-mode/output/instruction/1907969 deleted file mode 100644 index efa846c8a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1907969 +++ /dev/null @@ -1,64 +0,0 @@ -instruction: 0.352 -syscall: 0.330 -runtime: 0.317 - - - -linux-user/i386: Segfault when mixing threads and signals - -Given the following C program, qemu-i386 will surely and certainly segfault when executing it. -The problem is only noticeable if the program is statically linked to musl's libc and, as written -in the title, it only manifests when targeting i386. - -Removing the pthread calls or the second raise() makes it not segfault. - -The crash is in some part of the TCG-generated code, right when it tries to perform a -%gs-relative access. - -If you want a quick way of cross-compiling this binary: - -* Download a copy of the Zig compiler from https://ziglang.org/download/ -* Compile it with - `zig cc -target i386-linux-musl <C-FILE> -o <OUT>` - -``` -#include <pthread.h> -#include <signal.h> -#include <stdio.h> -#include <string.h> -#include <sys/types.h> -#include <unistd.h> -#include <asm/prctl.h> -#include <sys/syscall.h> - -void sig_func(int sig) -{ - write(1, "hi!\n", strlen("hi!\n")); -} - -void func(void *p) { } - -typedef void *(*F)(void *); - -int main() -{ - pthread_t tid; - - struct sigaction action; - action.sa_flags = 0; - action.sa_handler = sig_func; - - if (sigaction(SIGUSR1, &action, NULL) == -1) { - return 1; - } - - // This works. - raise(SIGUSR1); - - pthread_create(&tid, NULL, (F)func, NULL); - pthread_join(tid, NULL); - - // This makes qemu segfault. - raise(SIGUSR1); -} -``` \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1908 b/results/classifier/zero-shot-user-mode/output/instruction/1908 deleted file mode 100644 index 03517fbdc..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1908 +++ /dev/null @@ -1,55 +0,0 @@ -instruction: 0.359 -runtime: 0.345 -syscall: 0.295 - - - -8.1.0 regression: abnormal segfault in qemu-riscv64-static -Description of problem: -loading_from_clipboard_test of Cockatrice segfaults in qemu-riscv64-static. -Steps to reproduce: -1. Setup an Arch Linux riscv64 qemu-user container: https://github.com/felixonmars/archriscv-packages/wiki/Setup-Arch-Linux-RISC-V-Development-Environment -2. Start the container: `sudo systemd-nspawn -D ./archriscv -a -U` -3. Build cockatrice 2.9.0 with tests in the container: https://github.com/Cockatrice/Cockatrice/releases/tag/2023-09-14-Release-2.9.0 -4. Run tests/loading_from_clipboard/loading_from_clipboard_test in the container -Additional information: -I have done bisection and find out that this commit caused the regression: 2d708164e0475064e0e2167bd73e8570e22df1e0 - -qemu built from HEAD(494a6a2) is still affected by this bug. - -Backtrace: - -``` -#0 0x00007fffe849f133 in code_gen_buffer () -#1 0x00007ffff7b3a433 in cpu_tb_exec (cpu=0x7ffff7f71010, itb=0x7fffe849f040 <code_gen_buffer+4845587>, -tb_exit=0x7fffffffde20) at ../qemu/accel/tcg/cpu-exec.c:457 -#2 0x00007ffff7b3aeac in cpu_loop_exec_tb (cpu=0x7ffff7f71010, tb=0x7fffe849f040 <code_gen_buffer+4845587>, -pc=46912625654024, last_tb=0x7fffffffde30, tb_exit=0x7fffffffde20) at ../qemu/accel/tcg/cpu-exec.c:919 -#3 0x00007ffff7b3b0e0 in cpu_exec_loop (cpu=0x7ffff7f71010, sc=0x7fffffffdeb0) at ../qemu/accel/tcg/cpu-exec.c:1040 -#4 0x00007ffff7b3b19e in cpu_exec_setjmp (cpu=0x7ffff7f71010, sc=0x7fffffffdeb0) -at ../qemu/accel/tcg/cpu-exec.c:1057 -#5 0x00007ffff7b3b225 in cpu_exec (cpu=0x7ffff7f71010) at ../qemu/accel/tcg/cpu-exec.c:1083 -#6 0x00007ffff7a53707 in cpu_loop (env=0x7ffff7f71330) at ../qemu/linux-user/riscv/cpu_loop.c:37 -#7 0x00007ffff7b5d0e0 in main (argc=4, argv=0x7fffffffe768, envp=0x7fffffffe790) at ../qemu/linux-user/main.c:999 -``` - -``` -0x7fffe849f105 <code_gen_buffer+4845784> jl 0x7fffe849f265 <code_gen_buffer+4846136> │ -│ 0x7fffe849f10b <code_gen_buffer+4845790> mov 0x50(%rbp),%rbx │ -│ 0x7fffe849f10f <code_gen_buffer+4845794> mov %rbx,%r12 │ -│ 0x7fffe849f112 <code_gen_buffer+4845797> mov %r12,0x70(%rbp) │ -│ 0x7fffe849f116 <code_gen_buffer+4845801> movabs $0x2aaaaf9bb000,%r13 │ -│ 0x7fffe849f120 <code_gen_buffer+4845811> mov %r13,0x38(%rbp) │ -│ 0x7fffe849f124 <code_gen_buffer+4845815> movq $0xffffffffaf9bb000,0x60(%rbp) │ -│ 0x7fffe849f12c <code_gen_buffer+4845823> mov $0xffffffffaf9bb4e0,%r13 │ -│ > 0x7fffe849f133 <code_gen_buffer+4845830> movzwl 0x0(%r13),%r13d │ -│ 0x7fffe849f138 <code_gen_buffer+4845835> and $0x7f,%ebx │ -│ 0x7fffe849f13b <code_gen_buffer+4845838> shl $0x7,%r13 │ -│ 0x7fffe849f13f <code_gen_buffer+4845842> add %r13,%rbx │ -│ 0x7fffe849f142 <code_gen_buffer+4845845> mov %rbx,0x50(%rbp) │ -│ 0x7fffe849f146 <code_gen_buffer+4845849> shl %rbx │ -│ 0x7fffe849f149 <code_gen_buffer+4845852> mov %rbx,0x38(%rbp) │ -│ 0x7fffe849f14d <code_gen_buffer+4845856> movabs $0x2aaaaf9a88e0,%r13 │ -│ 0x7fffe849f157 <code_gen_buffer+4845866> add %r13,%rbx │ -│ 0x7fffe849f15a <code_gen_buffer+4845869> mov %rbx,0x60(%rbp) -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1908626 b/results/classifier/zero-shot-user-mode/output/instruction/1908626 deleted file mode 100644 index ea27cafb5..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1908626 +++ /dev/null @@ -1,71 +0,0 @@ -instruction: 0.445 -runtime: 0.318 -syscall: 0.237 - - - -Atomic test-and-set instruction does not work on qemu-user - -I try to compile and run PostgreSQL/Greenplum database inside docker container/qemu-aarch64-static: -``` - host: CentOS7 x86_64 - container: centos:centos7.9.2009 --platform linux/arm64/v8 - qemu-user-static: https://github.com/multiarch/qemu-user-static/releases/ -``` - -However, GP/PG's spinlock always gets stuck and reports PANIC errors. It seems its spinlock -has something wrong. -``` -https://github.com/greenplum-db/gpdb/blob/master/src/include/storage/s_lock.h -https://github.com/greenplum-db/gpdb/blob/master/src/backend/storage/lmgr/s_lock.c -``` - -So I extract its spinlock implementation into one test C source file (see attachment file), -and get reprodcued: - -``` -$ gcc spinlock_qemu.c -$ ./a.out -C -- slock inited, lock value is: 0 -parent 139642, child 139645 -P -- slock lock before, lock value is: 0 -P -- slock locked, lock value is: 1 -P -- slock unlock after, lock value is: 0 -C -- slock lock before, lock value is: 1 -P -- slock lock before, lock value is: 1 -C -- slock locked, lock value is: 1 -C -- slock unlock after, lock value is: 0 -C -- slock lock before, lock value is: 1 -P -- slock locked, lock value is: 1 -P -- slock unlock after, lock value is: 0 -P -- slock lock before, lock value is: 1 -C -- slock locked, lock value is: 1 -C -- slock unlock after, lock value is: 0 -P -- slock locked, lock value is: 1 -C -- slock lock before, lock value is: 1 -P -- slock unlock after, lock value is: 0 -C -- slock locked, lock value is: 1 -P -- slock lock before, lock value is: 1 -C -- slock unlock after, lock value is: 0 -P -- slock locked, lock value is: 1 -C -- slock lock before, lock value is: 1 -P -- slock unlock after, lock value is: 0 -C -- slock locked, lock value is: 1 -P -- slock lock before, lock value is: 1 -C -- slock unlock after, lock value is: 0 -P -- slock locked, lock value is: 1 -C -- slock lock before, lock value is: 1 -P -- slock unlock after, lock value is: 0 -P -- slock lock before, lock value is: 1 -spin timeout, lock value is 1 (pid 139642) -spin timeout, lock value is 1 (pid 139645) -spin timeout, lock value is 1 (pid 139645) -spin timeout, lock value is 1 (pid 139642) -spin timeout, lock value is 1 (pid 139645) -spin timeout, lock value is 1 (pid 139642) -... -... -... -``` - -NOTE: this code always works on PHYSICAL ARM64 server. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1909921 b/results/classifier/zero-shot-user-mode/output/instruction/1909921 deleted file mode 100644 index fbdd73ac3..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1909921 +++ /dev/null @@ -1,28 +0,0 @@ -instruction: 0.564 -syscall: 0.264 -runtime: 0.172 - - - - Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff87709b0e - -Hello, - -I have a Raspberry Pi 4 with an ESXi hypervisor installed on it (ESXi ARM Edition). -I created a CentOS 7 VM on it and I'm using a Docker container which is running qemu inside it. - -This container is a Debian Bullseye OS and I'm using qemu-i386 to start my application inside it. -The error given by qemu is the following : - -qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff9d5f9b0e -qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff82f29b0e - -(The pc= value is always different, I guess it is randomly generated). - -My qemu version is : qemu-i386 version 5.1.0 (Debian 1:5.1+dfsg-4+b1) - -Could you please help me? Why am I facing this error? - -Feel free to ask any questions regarding this matter in order to find a solution to it! - -Regards \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1910605 b/results/classifier/zero-shot-user-mode/output/instruction/1910605 deleted file mode 100644 index b61ef251a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1910605 +++ /dev/null @@ -1,22 +0,0 @@ -instruction: 0.639 -syscall: 0.228 -runtime: 0.134 - - - -qemu-arm-static ioctl USBDEVFS_BULK return -1 (EFAULT) Bad address - - - -Snippet of code sample: - -struct usbdevfs_bulktransfer Bulk; -Bulk.ep = hUsb->UsbOut; -Bulk.len = Len; -Bulk.data = (void *)pData; -Bulk.timeout = Timeout; -Bytes = ioctl(hUsb->fd, USBDEVFS_BULK, &Bulk) - -The above code sample return -1 (EFAULT) Bad address when using qemu-arm-static but is running ok when on qemu-aarch64-static. - -I use a 64-bit intel laptop \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1912934 b/results/classifier/zero-shot-user-mode/output/instruction/1912934 deleted file mode 100644 index 3a8703b7f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1912934 +++ /dev/null @@ -1,23 +0,0 @@ -instruction: 0.731 -runtime: 0.190 -syscall: 0.079 - - - -QEMU emulation of fmadds instruction on powerpc64le is buggy - -The attached program test-fmadds.c tests the fmadds instruction on powerpc64le. - -Result on real hardware (POWER8E processor): -$ ./a.out ; echo $? -0 - -Result in Alpine Linux 3.13/powerpcle, emulated by QEMU 5.0.0 on Ubuntu 16.04: -$ ./a.out ; echo $? -32 - -Result in Debian 8.6.0/ppc64el, emulated by QEMU 2.9.0 on Ubuntu 16.04: -$ ./a.out ; echo $? -32 - -Through 'nm --dynamic qemu-system-ppc64 | grep fma' I can see that QEMU is NOT using the fmaf() or fma() function from the host system's libc; this function is working fine in glibc of the host system (see https://www.gnu.org/software/gnulib/manual/html_node/fmaf.html ). \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1913 b/results/classifier/zero-shot-user-mode/output/instruction/1913 deleted file mode 100644 index 9b3c04cba..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1913 +++ /dev/null @@ -1,25 +0,0 @@ -instruction: 0.630 -runtime: 0.241 -syscall: 0.129 - - - -Regression in 8.1.1: qemu-aarch64-static running ldconfig -Description of problem: -Since updating to 8.1.1, qemu crashes when running ldconfig in my sysroot (It's a more or less default Ubuntu 22.04 arm64 rootfs) -Steps to reproduce: -1. Download the arm64 ubuntu base from https://cdimage.ubuntu.com/ubuntu-base/releases/jammy/release/ -2. Extract it -3. Run `qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs` where `rootfs` is where you extracted it with qemu 8.1.1 - -```bash -$ qemu-aarch64-static --version -qemu-aarch64 version 8.1.0 -$ qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs -<works> -$ sudo pacman -U /var/cache/pacman/pkg/qemu-user-static*-8.1.1*.zst -$ qemu-aarch64-static --version -qemu-aarch64 version 8.1.1 -$ qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs -<segfault> -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1913913 b/results/classifier/zero-shot-user-mode/output/instruction/1913913 deleted file mode 100644 index a659a1777..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1913913 +++ /dev/null @@ -1,24 +0,0 @@ -instruction: 0.706 -runtime: 0.182 -syscall: 0.112 - - - -i386-linux-user returns -1 in sigcontext->trapno - -QEMU development version, git commit 74208cd252c5da9d867270a178799abd802b9338. Behaviour has been noted in 5.2.0 generally. - -Certain 16-bit windows programs crash WINE under QEMU linux-user with: - -0084:err:seh:segv_handler Got unexpected trap -1 -wine: Unhandled illegal instruction at address 00006D65 (thread 0084), starting debugger... - -They run correctly on native i386. - -Upon further inspection,it becomes clear these programs are failing at addresses where they are making DOS calls (int 21h ie CD 21 for instance). - -It is also clear that WINE is expecting an exception/signal at this point, to patch in the actual int21h handling code inside WINE. - -However, wine uses sigcontext output extensively to do its structured exception handling. sigcontext->trapno being set to -1 seems to confuse it, causing it to treat the exception as an actual unhandled error. - -I do not know if exception_index is being left at -1 due to the case of privileged instructions being executed in 16-bit ldts not being handled specifically, or if there is some other illegal instruction case causing this. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1914021 b/results/classifier/zero-shot-user-mode/output/instruction/1914021 deleted file mode 100644 index e7634a0e2..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1914021 +++ /dev/null @@ -1,33 +0,0 @@ -instruction: 0.589 -runtime: 0.225 -syscall: 0.186 - - - -qemu: uncaught target signal 4 (Illegal instruction) but gdb remote-debug exited normally - -I'm getting Illegal instruction (core dumped) when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. - -readelf -h a.out_err -ELF Header: - Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 - Class: ELF32 - Data: 2's complement, little endian - Version: 1 (current) - OS/ABI: UNIX - System V - ABI Version: 0 - Type: EXEC (Executable file) - Machine: ARM - Version: 0x1 - Entry point address: 0x8220 - Start of program headers: 52 (bytes into file) - Start of section headers: 54228 (bytes into file) - Flags: 0x5000200, Version5 EABI, soft-float ABI - Size of this header: 52 (bytes) - Size of program headers: 32 (bytes) - Number of program headers: 3 - Size of section headers: 40 (bytes) - Number of section headers: 16 - Section header string table index: 15 - -qemu-arm version 4.0.0 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1914870 b/results/classifier/zero-shot-user-mode/output/instruction/1914870 deleted file mode 100644 index 8c1894c1d..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1914870 +++ /dev/null @@ -1,63 +0,0 @@ -instruction: 0.437 -runtime: 0.360 -syscall: 0.203 - - - -libvixl compilation failure on Debian unstable - -As of commit 0e324626306: - -$ lsb_release -d -Description: Debian GNU/Linux bullseye/sid - -Project version: 5.2.50 -C compiler for the host machine: cc (gcc 10.2.1 "cc (Debian 10.2.1-6) 10.2.1 20210110") -C linker for the host machine: cc ld.bfd 2.35.1 -C++ compiler for the host machine: c++ (gcc 10.2.1 "c++ (Debian 10.2.1-6) 10.2.1 20210110") -C++ linker for the host machine: c++ ld.bfd 2.35.1 - -[6/79] Compiling C++ object libcommon.fa.p/disas_libvixl_vixl_utils.cc.o -FAILED: libcommon.fa.p/disas_libvixl_vixl_utils.cc.o -c++ -Ilibcommon.fa.p -I. -I.. -Iqapi -Itrace -Iui/shader -I/usr/include/capstone -I/usr/include/glib-2.0 -I/usr/lib/hppa-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -pipe -Wall -Winvalid-pch -Wnon-virtual-dtor -Werror -std=gnu++11 -O2 -g -isystem /home/philmd/qemu/linux-headers -isystem linux-headers -iquote . -iquote /home/philmd/qemu -iquote /home/philmd/qemu/include -iquote /home/philmd/qemu/disas/libvixl -iquote /home/philmd/qemu/tcg/hppa -iquote /home/philmd/qemu/accel/tcg -pthread -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wundef -Wwrite-strings -fno-strict-aliasing -fno-common -fwrapv -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fPIE -MD -MQ libcommon.fa.p/disas_libvixl_vixl_utils.cc.o -MF libcommon.fa.p/disas_libvixl_vixl_utils.cc.o.d -o libcommon.fa.p/disas_libvixl_vixl_utils.cc.o -c ../disas/libvixl/vixl/utils.cc -In file included from /home/philmd/qemu/disas/libvixl/vixl/utils.h:30, - from ../disas/libvixl/vixl/utils.cc:27: -/usr/include/string.h:36:43: error: missing binary operator before token "(" - 36 | #if defined __cplusplus && (__GNUC_PREREQ (4, 4) \ - | ^ -/usr/include/string.h:53:62: error: missing binary operator before token "(" - 53 | #if defined __USE_MISC || defined __USE_XOPEN || __GLIBC_USE (ISOC2X) - | ^ -/usr/include/string.h:165:21: error: missing binary operator before token "(" - 165 | || __GLIBC_USE (LIB_EXT2) || __GLIBC_USE (ISOC2X)) - | ^ -/usr/include/string.h:174:43: error: missing binary operator before token "(" - 174 | #if defined __USE_XOPEN2K8 || __GLIBC_USE (LIB_EXT2) || __GLIBC_USE (ISOC2X) - | ^ -/usr/include/string.h:492:19: error: missing binary operator before token "(" - 492 | #if __GNUC_PREREQ (3,4) - | ^ -In file included from /home/philmd/qemu/disas/libvixl/vixl/utils.h:30, - from ../disas/libvixl/vixl/utils.cc:27: -/usr/include/string.h:28:1: error: ‘__BEGIN_DECLS’ does not name a type - 28 | __BEGIN_DECLS - | ^~~~~~~~~~~~~ -In file included from /home/philmd/qemu/disas/libvixl/vixl/utils.h:30, - from ../disas/libvixl/vixl/utils.cc:27: -/usr/include/string.h:44:8: error: ‘size_t’ has not been declared - 44 | size_t __n) __THROW __nonnull ((1, 2)); - | ^~~~~~ -/usr/include/string.h:44:20: error: expected initializer before ‘__THROW’ - 44 | size_t __n) __THROW __nonnull ((1, 2)); - | ^~~~~~~ -/usr/include/string.h:47:56: error: ‘size_t’ has not been declared - 47 | extern void *memmove (void *__dest, const void *__src, size_t __n) - | ^~~~~~ -/usr/include/string.h:48:6: error: expected initializer before ‘__THROW’ - 48 | __THROW __nonnull ((1, 2)); - | ^~~~~~~ -/usr/include/string.h:61:42: error: ‘size_t’ has not been declared - 61 | extern void *memset (void *__s, int __c, size_t __n) __THROW __nonnull ((1)); - | ^~~~~~ - -Is there a package dependency missing? \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1915327 b/results/classifier/zero-shot-user-mode/output/instruction/1915327 deleted file mode 100644 index 5d19395ca..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1915327 +++ /dev/null @@ -1,40 +0,0 @@ -instruction: 0.532 -runtime: 0.277 -syscall: 0.191 - - - -x86_64 cmpxchg behavior in qemu tcg does not match the real CPU - -QEMU version: -1214d55d1c (HEAD, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/nvme/tags/nvme-next-pull-request' into staging - -Consider the following little program: - -$ cat 1.c -#include <stdio.h> -int main() { - int mem = 0x12345678; - register long rax asm("rax") = 0x1234567812345678; - register int edi asm("edi") = 0x77777777; - asm("cmpxchg %[edi],%[mem]" - : [ mem ] "+m"(mem), [ rax ] "+r"(rax) - : [ edi ] "r"(edi)); - long rax2 = rax; - printf("rax2 = %lx\n", rax2); -} - -According to the Intel Manual, cmpxchg should not touch the accumulator in case the values are equal, which is indeed the case on the real CPU: - -$ gcc 1.c -$ ./a.out -rax2 = 1234567812345678 - -However, QEMU appears to zero extend EAX to RAX: - -$ qemu-x86_64 ./a.out -rax2 = 12345678 - -This is also the case for lock cmpxchg. - -Found in BPF development context: https://lore<email address hidden> \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1915925 b/results/classifier/zero-shot-user-mode/output/instruction/1915925 deleted file mode 100644 index abc7e28c7..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1915925 +++ /dev/null @@ -1,23 +0,0 @@ -instruction: 0.510 -runtime: 0.259 -syscall: 0.232 - - - -ARM semihosting HEAPINFO results wrote to wrong address - -This affects latest development branch of QEMU. - -According to the ARM spec of the HEAPINFO semihosting call: - -https://developer.arm.com/documentation/100863/0300/Semihosting-operations/SYS-HEAPINFO--0x16-?lang=en - -> the PARAMETER REGISTER contains the address of a pointer to a four-field data block. - -However, QEMU treated the PARAMETER REGISTER as pointing to a four-field data block directly. - -Here is a simple program that can demonstrate this problem: https://github.com/iNvEr7/qemu-learn/tree/newlib-bug/semihosting-newlib - -This code links with newlib with semihosting mode, which will call the HEAPINFO SVC during crt0 routine. When running in QEMU (make run), it may crash the program either because of invalid write or memory curruption, depending on the compiled program structure. - -Also refer to my discussion with newlib folks: https://sourceware.org/pipermail/newlib/2021/018260.html \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1916269 b/results/classifier/zero-shot-user-mode/output/instruction/1916269 deleted file mode 100644 index 80cf41f4b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1916269 +++ /dev/null @@ -1,25 +0,0 @@ -instruction: 0.879 -syscall: 0.069 -runtime: 0.053 - - - -TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction - -If I run FreeBSD on QEMU 5.2 with TCG acceleration -cpu Nehalem, I get a FPU exception when executing crc32 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253617). This is not a problem with the default CPU (or KVM) since that does not support SSE 4.2. - -Attaching GDB shows this is triggered in target/i386/tcg/translate.c:3067 - - /* simple MMX/SSE operation */ - if (s->flags & HF_TS_MASK) { - gen_exception(s, EXCP07_PREX, pc_start - s->cs_base); - return; - } - -However, according to https://software.intel.com/sites/default/files/m/8/b/8/D9156103.pdf, page 61 the CRC32 instruction works no matter what the value of the TS bit. - -The code sequence in question is: -0xffffffff8105a4de <+126>: f2 48 0f 38 f1 de crc32q %rsi,%rbx -0xffffffff8105a4e4 <+132>: f2 48 0f 38 f1 ca crc32q %rdx,%rcx. - -This should work even with the FPU disabled. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1916344 b/results/classifier/zero-shot-user-mode/output/instruction/1916344 deleted file mode 100644 index e95d79222..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1916344 +++ /dev/null @@ -1,30 +0,0 @@ -instruction: 0.685 -runtime: 0.195 -syscall: 0.120 - - - -User mode networking not working properly on QEMU on Mac OS X host - -Steps to reproduce: - -1. Install QEMU using homebrew on Mac OS X (I used Big Sur) -2. Spin up a guest VM (say) Cent OS8 using user mode networking. -3. Install podman inside the guest -4. Run podman pull alpine - -The result is: - -[root@localhost ~]# podman pull alpine -Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf) -Trying to pull docker.io/library/alpine:latest... -Getting image source signatures -Copying blob ba3557a56b15 [======================================] 2.7MiB / 2.7MiB - unexpected EOF -Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF - -This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest. - -This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X. - -This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1917184 b/results/classifier/zero-shot-user-mode/output/instruction/1917184 deleted file mode 100644 index 87ea13077..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1917184 +++ /dev/null @@ -1,11 +0,0 @@ -instruction: 0.591 -runtime: 0.219 -syscall: 0.190 - - - -qemu-user vm86() segfaults handling interrupt with ss:sp in same page as cs:ip - -When using qemu-i386 to run a program that uses vm86(), if the vm86 code calls an interrupt while cs:ip and ss:sp both point within the same page, do_int tries to write to the page while it is not writable, causing a segfault. - -qemu version 5.2.0, x86-64 host. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1918026 b/results/classifier/zero-shot-user-mode/output/instruction/1918026 deleted file mode 100644 index 42dd6fa45..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1918026 +++ /dev/null @@ -1,35 +0,0 @@ -instruction: 0.523 -syscall: 0.306 -runtime: 0.171 - - - -RISCV64 32-bit AMOs incorrectly simulated - -Version: qemu-riscv64 version 4.2.1 (Debian 1:4.2-3ubuntu6.14) - -test: - amomaxu.w a0, a1, (a0) - ret - -int32_t* value = -7; -EXPECT_EQ(-7, test(&value, -11)); -EXPECT_EQ(-7, value); // FAIL, saw -11 -EXPECT_EQ(-7, test(&value, -7)); -EXPECT_EQ(-7, value); // FAIL, raw -11 -EXPECT_EQ(-7, test(&value, -4)); -EXPECT_EQ(-4, value); - -test: - amomax.w a0, a1, (a0) - ret - -int32_t* value = -7; -EXPECT_EQ(-7, test(&value, -11)); -EXPECT_EQ(-7, value); -EXPECT_EQ(-7, test(&value, -7)); -EXPECT_EQ(-7, value); -EXPECT_EQ(-7, test(&value, -4)); -EXPECT_EQ(-4, value); // FAIL, saw -7 - -I suspect that trans_amo<op>_w should be using tcg_gen_atomic_fetch_<op>_i32 instead of tcg_gen_atomic_fetch_<op>_tl. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1922887 b/results/classifier/zero-shot-user-mode/output/instruction/1922887 deleted file mode 100644 index 521493de0..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1922887 +++ /dev/null @@ -1,36 +0,0 @@ -instruction: 0.699 -runtime: 0.206 -syscall: 0.095 - - - -STR in Thumb 32 decode problem - -Hi - -It seems that QEMU does not have a proper check on the STR instruction in Thumb32 mode. - -Specifically, the machine code is 0xf84f0ddd, which is 0b1111 1000 0100 1111 0000 1101 1101 1101. -This is an STR (immediate, Thumb) instruction with a T4 encoding scheme. - -The symbols is - -Rn = 1111 -Rt = 0000 -P = 1 -U = 0 -W = 1 - -The decode ASL is below: - -if P == ‘1’ && U == ‘1’ && W == ‘0’ then SEE STRT; -if Rn == ‘1101’ && P == ‘1’ && U == ‘0’ && W == ‘1’ && imm8 == ‘00000100’ then SEE PUSH; -if Rn == ‘1111’ || (P == ‘0’ && W == ‘0’) then UNDEFINED; -t = UInt(Rt); n = UInt(Rn); imm32 = ZeroExtend(imm8, 32); -index = (P == ‘1’); add = (U == ‘1’); wback = (W == ‘1’); -if t == 15 || (wback && n == t) then UNPREDICTABLE; - -When Rn == 1111, it should be an undefined instruction, which should raise SEGILL signal. However, it seems that QEMU does not check this constraint, which should be a bug. Many thanks - -Regards -Muhui \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1925512 b/results/classifier/zero-shot-user-mode/output/instruction/1925512 deleted file mode 100644 index 9311ca20c..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1925512 +++ /dev/null @@ -1,24 +0,0 @@ -instruction: 0.919 -runtime: 0.057 -syscall: 0.024 - - - -UNDEFINED case for instruction BLX - -Hi - -I refer to the instruction BLX imm (T2 encoding) in ARMv7 (Thumb mode). - -11110 S imm10H 11 J1 0 J2 imm10L H - - -if H == '1' then UNDEFINED; -I1 = NOT(J1 EOR S); I2 = NOT(J2 EOR S); imm32 = SignExtend(S:I1:I2:imm10H:imm10L:'00', 32); -targetInstrSet = InstrSet_A32; -if InITBlock() && !LastInITBlock() then UNPREDICTABLE; - -According to the manual, if H equals to 1, this instruction should be an UNDEFINED instruction. However, it seems QEMU does not check this constraint in function trans_BLX_i. Thanks - -Regards -Muhui \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1926044 b/results/classifier/zero-shot-user-mode/output/instruction/1926044 deleted file mode 100644 index 37c4b2e7d..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1926044 +++ /dev/null @@ -1,36 +0,0 @@ -instruction: 0.445 -syscall: 0.358 -runtime: 0.197 - - - -QEMU-user doesn't report HWCAP2_MTE - -Reproducible on ffa090bc56e73e287a63261e70ac02c0970be61a - -Host Debian 5.10.24 x86_64 GNU - -Configured with "configure --disable-system --enable-linux-user --static" - -This one works and prints "OK" as expected: -clang tests/tcg/aarch64/mte-3.c -target aarch64-linux-gnu -fsanitize=memtag -march=armv8+memtag -qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out && echo OK - - -This one fails and print "0": -cat mytest.c -#include <stdio.h> -#include <sys/auxv.h> - -#ifndef HWCAP2_MTE -#define HWCAP2_MTE (1 << 18) -#endif - -int main(int ac, char **av) -{ - printf("%d\n", (int)(getauxval(AT_HWCAP2) & HWCAP2_MTE)); -} - - -clang mytest.c -target aarch64-linux-gnu -fsanitize=memtag -march=armv8+memtag -qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1926202 b/results/classifier/zero-shot-user-mode/output/instruction/1926202 deleted file mode 100644 index 4719d7f55..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1926202 +++ /dev/null @@ -1,24 +0,0 @@ -instruction: 0.765 -runtime: 0.175 -syscall: 0.060 - - - -qemu-user can't run some ppc binaries - -qemu-user v6.0.0-rc5, built in static mode, will crash for certain ppc binaries. It seems to have something to do with glibc for some Centos versions. The problem is easiest to see with statically-linked binaries. - -The attached Dockerfile shows how to produce a ppc binary that will crash qemu-user. Here is how to reproduce the problem: - -$ uname -m -x86_64 -$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes -$ docker build -t qemu-bug:centos -f Dockerfile.centos . -$ docker run --rm -it -v$PWD:$PWD -w$PWD qemu-bug:centos cp /helloworld-centos.static.ppc . -$ qemu-ppc version 5.2.95 (v6.0.0-rc5) -Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers -$ qemu-ppc-static ./helloworld-centos.static.ppc -emu: uncaught target signal 4 (Illegal instruction) - core dumped -[1] 16678 illegal hardware instruction (core dumped) qemu-ppc-static ./helloworld-centos.static.ppc - -I can also provide the binary if necessary. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1926246 b/results/classifier/zero-shot-user-mode/output/instruction/1926246 deleted file mode 100644 index a592ad304..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1926246 +++ /dev/null @@ -1,56 +0,0 @@ -instruction: 0.460 -syscall: 0.393 -runtime: 0.147 - - - -chrome based apps can not be run under qemu user mode - -chrome uses /proc/self/exe to fork render process. -Here a simple code to reproduce the issue. It's output parent then child but failed with qemu: unknown option 'type=renderer'. - -Maybe we can modify exec syscall to replace /proc/self/exe to the real path. - -//gcc -o self self.c -#include <stdio.h> -#include <sys/types.h> -#include <unistd.h> -int main(int argc, char** argv) { - if(argc==1){ - printf ("parent\n"); - if ( fork() == 0 ) - { - return execl("/proc/self/exe","/proc/self/exe", "--type=renderer",NULL); - } - } else { - printf ("child\n"); - } - return 0; -} - -similar reports: -https://github.com/AppImage/AppImageKit/issues/965 -https://github.com/golang/go/issues/42080 - -Workardound: -compile chrome or your chrome based app with a patch to content/common/child_process_host_impl.cc:GetChildPath, get the realpath of /proc/self/exe: - -diff --git a/content/common/child_process_host_impl.cc b/content/common/child_process_host_impl.cc -index bc78aba80ac8..9fab74d3bae8 100644 ---- a/content/common/child_process_host_impl.cc -+++ b/content/common/child_process_host_impl.cc -@@ -60,8 +60,12 @@ base::FilePath ChildProcessHost::GetChildPath(int flags) { - #if defined(OS_LINUX) - // Use /proc/self/exe rather than our known binary path so updates - // can't swap out the binary from underneath us. -- if (child_path.empty() && flags & CHILD_ALLOW_SELF) -- child_path = base::FilePath(base::kProcSelfExe); -+ if (child_path.empty() && flags & CHILD_ALLOW_SELF) { -+ if (!ReadSymbolicLink(base::FilePath(base::kProcSelfExe), &child_path)) { -+ NOTREACHED() << "Unable to resolve " << base::kProcSelfExe << "."; -+ child_path = base::FilePath(base::kProcSelfExe); -+ } -+ } - #endif - - // On most platforms, the child executable is the same as the current \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1926759 b/results/classifier/zero-shot-user-mode/output/instruction/1926759 deleted file mode 100644 index 84d0c09b8..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1926759 +++ /dev/null @@ -1,24 +0,0 @@ -instruction: 0.917 -runtime: 0.044 -syscall: 0.039 - - - -WFI instruction results in unhandled CPU exception - -Hi - -I refer to the WFI instruction. The bytecode is 0xe320f003. After the execution, qemu exit with the following crash log. - -qemu: unhandled CPU exception 0x10001 - aborting -R00=00000001 R01=40800b34 R02=40800b3c R03=000102ec -R04=00010a28 R05=00010158 R06=00087460 R07=00010158 -R08=00000000 R09=00000000 R10=00085b7c R11=408009f4 -R12=40800a08 R13=408009f0 R14=0001057c R15=000102f8 -PSR=60000010 -ZC- A usr32 -qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7f5c21d0fa12 - -WFI aims to enter a low-power state and wait for interrupt. The raised exception seems not a right behavior. I can provide a testcase if you needed. Many thanks. - -Regards -Muhui \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1941 b/results/classifier/zero-shot-user-mode/output/instruction/1941 deleted file mode 100644 index 09305576f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1941 +++ /dev/null @@ -1,108 +0,0 @@ -instruction: 0.372 -runtime: 0.320 -syscall: 0.308 - - - -ppc64: VSX vector float to integer conversion instructions do not always return expected results on QEMU 8.0.4 if source vector has NaN values -Description of problem: -The problem is that the VSX xvcvspsxws/xvcvdpsxws/xvcvspsxds/xvcvdpsxds/xvcvspuxws/xvcvdpuxds/xvcvspuxds/xvcvdpuxws instructions incorrectly convert the preceding non-NaN source values to the NaN to integer result instead of the expected non-NaN to integer conversion result with qemu-ppc64le 8.0.4. - -Here are the results of the VSX operations whose results differ from the expected results with QEMU 8.0.4 (generated by running the vsx_f2i_nan_test_program_101423 test program with qemu-ppc64le 8.0.4): -``` -xvcvspsxds ({1, 2, 3, nan}) = {-9223372036854775808, -9223372036854775808} -xvcvspsxds ({nan, 2, 3, nan}) = {-9223372036854775808, -9223372036854775808} -xvcvspsxds ({1, 2, nan, nan}) = {-9223372036854775808, -9223372036854775808} -xvcvspsxds ({nan, 2, nan, nan}) = {-9223372036854775808, -9223372036854775808} - -xvcvspsxws ({1, nan, 3, 4}) = {-2147483648, -2147483648, 3, 4} -xvcvspsxws ({1, 2, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} -xvcvspsxws ({nan, 2, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} -xvcvspsxws ({1, nan, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} -xvcvspsxws ({1, 2, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} -xvcvspsxws ({nan, 2, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} -xvcvspsxws ({1, nan, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} -xvcvspsxws ({nan, nan, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} -xvcvspsxws ({1, 2, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} -xvcvspsxws ({nan, 2, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} -xvcvspsxws ({1, nan, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} - -xvcvspuxds ({1, 2, 3, nan}) = {0, 0} -xvcvspuxds ({nan, 2, 3, nan}) = {0, 0} -xvcvspuxds ({1, 2, nan, nan}) = {0, 0} -xvcvspuxds ({nan, 2, nan, nan}) = {0, 0} - -xvcvspuxws ({1, nan, 3, 4}) = {0, 0, 3, 4} -xvcvspuxws ({1, 2, nan, 4}) = {0, 0, 0, 4} -xvcvspuxws ({nan, 2, nan, 4}) = {0, 0, 0, 4} -xvcvspuxws ({1, nan, nan, 4}) = {0, 0, 0, 4} -xvcvspuxws ({1, 2, 3, nan}) = {0, 0, 0, 0} -xvcvspuxws ({nan, 2, 3, nan}) = {0, 0, 0, 0} -xvcvspuxws ({1, nan, 3, nan}) = {0, 0, 0, 0} -xvcvspuxws ({nan, nan, 3, nan}) = {0, 0, 0, 0} -xvcvspuxws ({1, 2, nan, nan}) = {0, 0, 0, 0} -xvcvspuxws ({nan, 2, nan, nan}) = {0, 0, 0, 0} -xvcvspuxws ({1, nan, nan, nan}) = {0, 0, 0, 0} - -xvcvdpsxws ({1, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} - -xvcvdpuxws ({1, nan}) = {0, 0, 0, 0} - -xvcvdpsxds ({1, nan}) = {-9223372036854775808, -9223372036854775808} - -xvcvdpuxds ({1, nan}) = {0, 0} -``` - -Here are the results of the same VSX conversion operations with QEMU 6.2.0 (generated by running the vsx_f2i_nan_test_program_101423 test program with qemu-ppc64le 6.2.0): -``` -xvcvspsxds ({1, 2, 3, nan}) = {2, -9223372036854775808} -xvcvspsxds ({nan, 2, 3, nan}) = {2, -9223372036854775808} -xvcvspsxds ({1, 2, nan, nan}) = {2, -9223372036854775808} -xvcvspsxds ({nan, 2, nan, nan}) = {2, -9223372036854775808} - -xvcvspsxws ({1, nan, 3, 4}) = {1, -2147483648, 3, 4} -xvcvspsxws ({1, 2, nan, 4}) = {1, 2, -2147483648, 4} -xvcvspsxws ({nan, 2, nan, 4}) = {-2147483648, 2, -2147483648, 4} -xvcvspsxws ({1, nan, nan, 4}) = {1, -2147483648, -2147483648, 4} -xvcvspsxws ({1, 2, 3, nan}) = {1, 2, 3, -2147483648} -xvcvspsxws ({nan, 2, 3, nan}) = {-2147483648, 2, 3, -2147483648} -xvcvspsxws ({1, nan, 3, nan}) = {1, -2147483648, 3, -2147483648} -xvcvspsxws ({nan, nan, 3, nan}) = {-2147483648, -2147483648, 3, -2147483648} -xvcvspsxws ({1, 2, nan, nan}) = {1, 2, -2147483648, -2147483648} -xvcvspsxws ({nan, 2, nan, nan}) = {-2147483648, 2, -2147483648, -2147483648} -xvcvspsxws ({1, nan, nan, nan}) = {1, -2147483648, -2147483648, -2147483648} - -xvcvspuxds ({1, 2, 3, nan}) = {2, 0} -xvcvspuxds ({nan, 2, 3, nan}) = {2, 0} -xvcvspuxds ({1, 2, nan, nan}) = {2, 0} -xvcvspuxds ({nan, 2, nan, nan}) = {2, 0} - -xvcvspuxws ({1, nan, 3, 4}) = {1, 0, 3, 4} -xvcvspuxws ({1, 2, nan, 4}) = {1, 2, 0, 4} -xvcvspuxws ({nan, 2, nan, 4}) = {0, 2, 0, 4} -xvcvspuxws ({1, nan, nan, 4}) = {1, 0, 0, 4} -xvcvspuxws ({1, 2, 3, nan}) = {1, 2, 3, 0} -xvcvspuxws ({nan, 2, 3, nan}) = {0, 2, 3, 0} -xvcvspuxws ({1, nan, 3, nan}) = {1, 0, 3, 0} -xvcvspuxws ({nan, nan, 3, nan}) = {0, 0, 3, 0} -xvcvspuxws ({1, 2, nan, nan}) = {1, 2, 0, 0} -xvcvspuxws ({nan, 2, nan, nan}) = {0, 2, 0, 0} -xvcvspuxws ({1, nan, nan, nan}) = {1, 0, 0, 0} - -xvcvdpsxws ({1, nan}) = {0, 1, 0, -2147483648} - -xvcvdpuxws ({1, nan}) = {0, 1, 0, 0} - -xvcvdpsxds ({1, nan}) = {1, -9223372036854775808} - -xvcvdpuxds ({1, nan}) = {1, 0} -``` -Steps to reproduce: -1. Compile the attached vsx_f2i_nan_test_program_101423.cpp with either `powerpc64le-linux-gnu-g++` or `clang --target=powerpc64le-linux-gnu` -2. Run the compiled vsx_f2i_nan_test_program_101423.cpp program using qemu-ppc64le -3. The vsx_f2i_nan_test_program_101423 program will return the results of the xvcvspsxws, xvcvdpsxws, xvcvspsxds, xvcvdpsxds, xvcvspuxws, xvcvdpuxds, xvcvspuxds, or xvcvdpuxws instruction. -Additional information: -Attachments: -- [vsx_f2i_nan_test_program_101423.cpp](/uploads/749395aee2da1dcc86790804106d30ea/vsx_f2i_nan_test_program_101423.cpp) -- [vsx_f2i_nan_test_program_101423_qemu_6.2.0_output.txt](/uploads/c883c4d04730a9c5a7e301e5d487ae2b/vsx_f2i_nan_test_program_101423_qemu_6.2.0_output.txt) - output of running vsx_f2i_nan_test_program_101423 with QEMU 6.2.0 -- [vsx_f2i_nan_test_program_101423_qemu_8.0.4_output.txt](/uploads/9451e3419f8a4f3ef2274b2ccc7ef22d/vsx_f2i_nan_test_program_101423_qemu_8.0.4_output.txt) - output of running vsx_f2i_nan_test_program_101423 with QEMU 8.0.4 diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1955 b/results/classifier/zero-shot-user-mode/output/instruction/1955 deleted file mode 100644 index e3f118732..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1955 +++ /dev/null @@ -1,43 +0,0 @@ -instruction: 0.814 -runtime: 0.102 -syscall: 0.085 - -instruction: 0.950 -graphic: 0.840 -semantic: 0.801 -device: 0.645 -other: 0.493 -socket: 0.420 -network: 0.394 -mistranslation: 0.346 -boot: 0.280 -vnc: 0.269 -assembly: 0.183 -KVM: 0.107 - -powerpc instruction 'mffsl' not emulated on POWER8 -Description of problem: -Since 2019, the function feenableexcept() in GNU libc makes use of the "mffsl" instruction. -See https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/feenablxcpt.c;h=b111ceaa4e2e1864fcbe043ccda34e03e9f14062;hb=HEAD#l28 -and https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/fenv_libc.h;h=a2a12d914b47e99746003482b349a0675cc5ad34;hb=HEAD#l57 - -In the emulated Debian system, executables that make use of this instruction crash with SIGILL. -Likewise, under gdb (in the emulated system), there is a SIGILL at the 'mffsl' instruction. - -From the comments in the above glibc source, added by Paul A. Clarke <pc@us.ibm.com>: - "Nicely, it turns out that the 'mffsl' instruction will decode to - 'mffs' on architectures older than "power9" because the additional - bits set for 'mffsl' are "don't care" for 'mffs'. 'mffs' is a superset - of 'mffsl'." - -This is indeed what I observe by compiling and running the attached program foo.c on a hardware machine with a POWER8 CPU: That program does not crash with a SIGILL. -Steps to reproduce: -1. Either run the attached 'test-fenv-except-tracking-5.ppc' (32-bit) program under qemu-system-ppc. -2. Or run the the attached 'test-fenv-except-tracking-5.ppc64' (64-bit) program under qemu-system-ppc64 with -cpu POWER8. -3. Or compile and run the attached foo.c and run it under QEMU. -Additional information: -[test-fenv-except-tracking-5.ppc.xz](/uploads/8222ebac115e8a865d5e520b25d423ff/test-fenv-except-tracking-5.ppc.xz) - -[test-fenv-except-tracking-5.ppc64.xz](/uploads/d0522723541a46e11ab55b8f45dfb574/test-fenv-except-tracking-5.ppc64.xz) - -[foo.c](/uploads/35d8b3b1e5b39ecb6a2a899132858ded/foo.c) diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1967248 b/results/classifier/zero-shot-user-mode/output/instruction/1967248 deleted file mode 100644 index ae7ea8c72..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/1967248 +++ /dev/null @@ -1,44 +0,0 @@ -instruction: 0.455 -runtime: 0.355 -syscall: 0.191 - - - -qemu: uncaught target signal 5 (Trace/breakpoint trap) - -I'm getting core dumped when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. - -And I found that QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signal. - -0xa602 <_start> movs r0, #22 0xa604 <_start+2> addw r1, pc, #186 ; 0xba -0xa608 <_start+6> bkpt 0x00ab - -$readelf -h hello -ELF Header: - Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 - Class: ELF32 - Data: 2's complement, little endian - Version: 1 (current) - OS/ABI: UNIX - System V - ABI Version: 0 - Type: EXEC (Executable file) - Machine: ARM - Version: 0x1 - Entry point address: 0xa603 - Start of program headers: 52 (bytes into file) - Start of section headers: 144128 (bytes into file) - Flags: 0x5000200, Version5 EABI, soft-float ABI - Size of this header: 52 (bytes) - Size of program headers: 32 (bytes) - Number of program headers: 5 - Size of section headers: 40 (bytes) - Number of section headers: 16 - Section header string table index: 14 - -$qemu-arm --version -qemu-arm version 6.2.0 -Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers - - -And I have check that the bug(https://bugs.launchpad.net/qemu/+bug/1873898) is fixed. -But it's coredump. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2035 b/results/classifier/zero-shot-user-mode/output/instruction/2035 deleted file mode 100644 index a384f9381..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2035 +++ /dev/null @@ -1,60 +0,0 @@ -instruction: 0.419 -syscall: 0.296 -runtime: 0.285 - - - -TCG Plugin exit callback not executing -Description of problem: -I cannot get the plugin exit callback to register/execute. I should see "Goodbye from plugin" but dont. I have also tried using `qemu_plugin_outs` without success. - -**Update: If I make my test binary an infinite loop and kill it with CTRL-C, then the callback is called as expected. Am I just using it wrong?** -Steps to reproduce: -1. Configured QEMU with `--target-list=riscv32-linux-user,riscv64-linux-user --enable-plugins --disable-system` -2. Compiled plugin with -``` -gcc -I./qemu/include/qemu `pkg-config --libs glib-2.0` -O0 -fvisibility=hidden -Wall -shared -fPIC `pkg-config --cflags glib-2.0` -``` -3. Compiled test binary (just a hello world) with `riscv64-unknown-elf-gcc test_qemu.c -o test_qemu` -4. Ran ./qemu/build/qemu-riscv64 -plugin ./test_plugin.so -d plugin ./test_qemu -Additional information: -test_plugin.c -``` -#include <inttypes.h> -#include <assert.h> -#include <stdlib.h> -#include <string.h> -#include <unistd.h> -#include <stdio.h> -#include <qemu-plugin.h> - -QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION; - -static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb) -{ - int n_insns = qemu_plugin_tb_n_insns(tb); - printf("> New TB of size %d\n", n_insns); - - for (int i = 0; i < n_insns; i++) { - struct qemu_plugin_insn * insn = qemu_plugin_tb_get_insn(tb, i); - char * disassembly = qemu_plugin_insn_disas(insn); - printf(" > Instruciton: %s\n", disassembly); - } -} - -static void plugin_exit(qemu_plugin_id_t id, void *p) -{ - printf("> Goodbye from plugin. %d\n", id); -} - -QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id, - const qemu_info_t *info, - int argc, char **argv) -{ - printf("> Hello From Plugin!\n"); - qemu_plugin_register_vcpu_tb_trans_cb(id, vcpu_tb_trans); - qemu_plugin_register_atexit_cb(id, plugin_exit, NULL); - printf("> Everything was registered\n"); - return 0; -} -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2072564 b/results/classifier/zero-shot-user-mode/output/instruction/2072564 deleted file mode 100644 index 77a98d984..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2072564 +++ /dev/null @@ -1,51 +0,0 @@ -instruction: 0.437 -runtime: 0.426 -syscall: 0.137 - - - -qemu-aarch64-static segfaults running ldconfig.real (amd64 host) - -This affects the qemu-user-static 1:8.2.2+ds-0ubuntu1 package on Ubuntu 24.04, running on a amd64 host. - -When running docker containers with Ubuntu 22.04 in them, emulating arm64 with qemu-aarch64-static, invocations of ldconfig (actually ldconfig.real) segfault. For example: - -$ docker run -ti --platform linux/arm64/v8 ubuntu:22.04 -root@8861ff640a1c:/# /sbin/ldconfig.real -Segmentation fault - -If you copy the ldconfig.real binary to the host, and run it directly via qemu-aarch64-static: - -$ gdb --args qemu-aarch64-static ./ldconfig.real -GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git -Copyright (C) 2024 Free Software Foundation, Inc. -License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> -This is free software: you are free to change and redistribute it. -There is NO WARRANTY, to the extent permitted by law. -Type "show copying" and "show warranty" for details. -This GDB was configured as "x86_64-linux-gnu". -Type "show configuration" for configuration details. -For bug reporting instructions, please see: -<https://www.gnu.org/software/gdb/bugs/>. -Find the GDB manual and other documentation resources online at: - <http://www.gnu.org/software/gdb/documentation/>. - -For help, type "help". -Type "apropos word" to search for commands related to "word"... -Reading symbols from qemu-aarch64-static... -Reading symbols from /home/dim/.cache/debuginfod_client/86579812b213be0964189499f62f176bea817bf2/debuginfo... -(gdb) r -Starting program: /usr/bin/qemu-aarch64-static ./ldconfig.real -[Thread debugging using libthread_db enabled] -Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". -[New Thread 0x7ffff76006c0 (LWP 28378)] - -Thread 1 "qemu-aarch64-st" received signal SIGSEGV, Segmentation fault. -0x00007fffe801645b in ?? () -(gdb) disassemble -No function contains program counter for selected frame. - -It looks like this is a known qemu regression after v8.1.1: -https://gitlab.com/qemu-project/qemu/-/issues/1913 - -Downgrading the package to qemu-user-static_8.0.4+dfsg-1ubuntu3_amd64.deb fixes the segfault. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2078 b/results/classifier/zero-shot-user-mode/output/instruction/2078 deleted file mode 100644 index 2b00a6ccb..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2078 +++ /dev/null @@ -1,40 +0,0 @@ -instruction: 0.490 -runtime: 0.352 -syscall: 0.159 - - - -Qemu crashes with SIGFPE on certain trapping arithmetic operations on m68k target -Description of problem: -I recently ported NetBSD to the Qemu m68k "virt" platform, and this was discovered when running NetBSD's automated tests. Certain arithmetic operation that will trap in the guest will crash Qemu. First case encountered is below. -Steps to reproduce: -1. Compile and run the following program in the m68k guest: - -``` -virt68k:thorpej 3$ cat crash-qemu.c -#include <limits.h> -#include <stdlib.h> - -int divisor = -1; - -int -main(int argc, char *argv[]) -{ - - if (argc > 1) - divisor = atoi(argv[1]); - - return INT_MIN / divisor; -} -virt68k:thorpej 4$ -``` - -Another minimal case would be: - -``` -move.l #-2147483648,%d0 -move.l #-1,%d1 -divsl.l %d1,%d1:%d0 -``` -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2089 b/results/classifier/zero-shot-user-mode/output/instruction/2089 deleted file mode 100644 index 5205bdfb6..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2089 +++ /dev/null @@ -1,33 +0,0 @@ -instruction: 0.557 -runtime: 0.329 -syscall: 0.113 - - - -aarch64: incorrect emulation of sqshrn instruction -Description of problem: -`sqshrn` instruction test fails with qemu-aarch64, but passes on real aarch64 hardware. -Steps to reproduce: -1. Build [inline_asm_tests](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/) and run with qemu-aarch64 -2. Observe two failures - -``` -[ RUN ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 -frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6697: Failure -Expected equality of these values: - res1 - Which is: 4294967188 - MakeUInt128(0x94U, 0U) - Which is: 148 -[ FAILED ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 (5 ms) -[ RUN ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 -frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6793: Failure -Expected equality of these values: - res3 - Which is: 4294967168 - MakeUInt128(0x0000000000000080ULL, 0x0000000000000000ULL) - Which is: 128 -[ FAILED ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 (2 ms) -``` -Additional information: -[Direct link to SignedSaturatingShiftRightNarrowInt16x1 test source](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc;l=6692;drc=4ee2c3035fa5dc0b7a48b6c6dc498296be071861) diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2101 b/results/classifier/zero-shot-user-mode/output/instruction/2101 deleted file mode 100644 index 7ef4d8d47..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2101 +++ /dev/null @@ -1,23 +0,0 @@ -instruction: 0.637 -syscall: 0.221 -runtime: 0.143 - - - -[qemu-user/qemu-x86_64] run x86_64 'ls /' on aarch64 platform get wrong result -Description of problem: -``` - qemu-x86_64 -L /tmp/ls-x86_64/root-x86_64-ls /tmp/ls-x86_64/root-x86_64-ls/bin/ls -l / - ``` -get wrong result -Steps to reproduce: -1. copy /usr/bin/ls and the so library files it depends on from x86_64 platform to aarch64 platform -2. qemu-x86_64 -L /path/to/x86_64/lib/root/dir /path/to/ls / -l -Additional information: -Actual test script: -``` -# host -curl -Ls https://github.com/tcler/kiss-vm-ns/raw/master/utils/archive-ld-program.sh | sudo bash /dev/stdin ls -scp ls.x86_64.ash root@jiyin-fedora-39_aarch64: -ssh root@jiyin-fedora-39_aarch64 ./ls.x86_64.ash -l / -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2119 b/results/classifier/zero-shot-user-mode/output/instruction/2119 deleted file mode 100644 index 9b3e21732..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2119 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.485 -runtime: 0.319 -syscall: 0.196 - - - -target/riscv/gdbstub.c：The V registers in gdb debugging mode can only be accessed when the single-letter V is enabled diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2122 b/results/classifier/zero-shot-user-mode/output/instruction/2122 deleted file mode 100644 index e0b23eae3..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2122 +++ /dev/null @@ -1,13 +0,0 @@ -instruction: 0.822 -syscall: 0.101 -runtime: 0.077 - - - -qemu-user-static segfault running ldconfig on host x86_64 with client arm64 -Description of problem: -qemu segfault -Steps to reproduce: -1. download ubuntu jammy arm64 rootfs (I assume any will do) -2. mount it (with /proc from host so apt is happy) -3. execute an apt uninstall that triggers libc-bin processing diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2123 b/results/classifier/zero-shot-user-mode/output/instruction/2123 deleted file mode 100644 index 75ab17848..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2123 +++ /dev/null @@ -1,37 +0,0 @@ -instruction: 0.586 -runtime: 0.301 -syscall: 0.113 - - - -Invalid subprocess commands spawns successfully when running under QEMU -Description of problem: -When executing a subprocess from with a non-existing command EQMU still spawns a process. - -Consider this small rust program for instance: -```rust -use std::process::Command; - -fn main() { - match Command::new("thisdoesnotexist").spawn() { - Ok(child) => { - println!("Child process id is {}", child.id()); - } - Err(_) => { - println!("This should happen"); - } - } -} -``` - -**Executing with `qemu-aarch64`:** -```shell -qemu-aarch64 ./rust-app -Child process id is 20182 -``` - -**Executing regularly:** -```shell -./rust-app -This should happen -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2127 b/results/classifier/zero-shot-user-mode/output/instruction/2127 deleted file mode 100644 index a946c6791..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2127 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.450 -syscall: 0.342 -runtime: 0.207 - - - -test-aio-multithread.c:371:test_multi_fair_mutex: assertion failed (counter == atomic_counter): (316636 == 316637) diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2136 b/results/classifier/zero-shot-user-mode/output/instruction/2136 deleted file mode 100644 index cceb835e3..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2136 +++ /dev/null @@ -1,41 +0,0 @@ -instruction: 0.729 -syscall: 0.172 -runtime: 0.099 - - - -on loongarch host, LSX vec get wrong result -Description of problem: -on loongarch host, the lsx insns get wrong result. -Steps to reproduce: -1. build linux-user on loongarch host with '--configure --target-list ='loongarch64-linux-user'' -2. build test code 'gcc --static test.c -o test' -3. run './build/qemu-loongarch64 test' -Additional information: -run 'qemu-loongarch64 test' -the result is - -`0: 2f2f2f2f -1: 0 -2: 2f2f2f2f -3: 0 -4: ffffffff -5: 0 -6: ffffffff -7: ffffffff` - -and the 6 or 7 may be ffffff or 0. - -run 'test' on loongarch host or run qemu-loongarch64 on x86_64 host. -the result is - -`0: 2f2f2f2f -1: 0 -2: 2f2f2f2f -3: 0 -4: 0 -5: 0 -6: 0 -7: 0` - -for more infomation see log.txt diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2156 b/results/classifier/zero-shot-user-mode/output/instruction/2156 deleted file mode 100644 index 6ffdf705a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2156 +++ /dev/null @@ -1,21 +0,0 @@ -instruction: 0.681 -syscall: 0.189 -runtime: 0.130 - - - -Userland QEMU segfaults when emulating itself thrice -Description of problem: -See title. -``` -$ qemu-x86_64-static qemu-x86_64-static qemu-x86_64-static /bin/true -qemu-x86_64-static: QEMU internal SIGSEGV {code=ACCERR, addr=0x7f9ae80001a0} -[1] 15705 segmentation fault (core dumped) qemu-x86_64-static qemu-x86_64-static qemu-x86_64-static /bin/true -``` -Steps to reproduce: -1. Execute command above -Additional information: -Coredump (~322MB uncompressed) -[qemu_qemu-x86_64-static_20240208-123447_15705.core.xz](/uploads/a6723aaf956dfd1efc434303e62c25e2/qemu_qemu-x86_64-static_20240208-123447_15705.core.xz) - -SHA1: 31c2b06a61f63dca5199b64b767aa2fdeefbeec6 diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2175 b/results/classifier/zero-shot-user-mode/output/instruction/2175 deleted file mode 100644 index 53340f1bb..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2175 +++ /dev/null @@ -1,44 +0,0 @@ -instruction: 0.538 -syscall: 0.232 -runtime: 0.230 - - - -Intel BLSI CF computation bug -Description of problem: -CF flag computation of BLSI instruction is wrong. It seems #1370 was not completely fixed. -Steps to reproduce: -1. Compile `example.c` using this command: `gcc -o example.bin example.c`. My gcc version is 12.3.0, but other versions may work. -``` -int main() { - __asm__ ( - "movq $0x1, %r8\n" - "mov $0xedbf530a, %r9\n" - "push $0x1\n" - "popf\n" - "blsi %r9d, %r8d\n" - "pushf\n" - "pop %rax\n" - "pop %rbp\n" - "ret\n" - ); - - return 0; -} -``` -2. Run `./example.bin`. Then check the return code using `echo $?`. It should be 3. -``` -$ ./example.bin -$ echo $? -3 -``` -3. Run `./qemu-x86_64 ./example.bin`. Then check the return code using `echo $?`. It should be 2. -``` -$ ./qemu-x86_64 ./example.bin -$ echo $? -2 -``` - -The return code of `./example.bin` contains the value of the `RFLAGS` register after executing the `BLSI` instruction. -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2208 b/results/classifier/zero-shot-user-mode/output/instruction/2208 deleted file mode 100644 index 2321226f3..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2208 +++ /dev/null @@ -1,94 +0,0 @@ -instruction: 0.384 -syscall: 0.341 -runtime: 0.276 - - - -PC is not updated for each instruction in TCG plugins -Description of problem: -I have checkout the `master` branch (the latest available commit on my machine is *7d4e29ef80*) to test the new functions that allow plugins to read registers. See https://gitlab.com/qemu-project/qemu/-/issues/1706 that has been closed last Friday. - -I am using a simple hello-world binary for ARM for my tests: - -```bash -% ./qemu-aarch64 hello-world.out -Hello World! -``` - -I run this binary with the *execlog* plugin enabled, and with the `-one-insn-per-tb` option: - -```bash -% ./qemu-aarch64 -d plugin -plugin ./contrib/plugins/libexeclog.so,reg=pc -one-insn-per-tb hello-world.out -``` - -Here is the end of the execution: - -```raw -0, 0x40e470, 0x54000040, "b.eq #0x40e478", pc -> 0x00000000000040e474 -0, 0x40e474, 0xd65f03c0, "ret ", pc -> 0x00000000000040d38c -0, 0x40d38c, 0xf945fab5, "ldr x21, [x21, #0xbf0]", load, 0x00490bf0, pc -> 0x00000000000040d390 -0, 0x40d390, 0xf9404fe0, "ldr x0, [sp, #0x98]", load, 0x7f635a9e7f28, pc -> 0x00000000000040d394 -0, 0x40d394, 0xf94002a1, "ldr x1, [x21]", load, 0x0048f9e8, pc -> 0x00000000000040d398 -0, 0x40d398, 0xeb010000, "subs x0, x0, x1", pc -> 0x00000000000040d39c -0, 0x40d39c, 0xd2800001, "movz x1, #0", pc -> 0x00000000000040d3a0 -0, 0x40d3a0, 0x540006e1, "b.ne #0x40d47c", pc -> 0x00000000000040d3a4 -0, 0x40d3a4, 0x2a1903e0, "mov w0, w25", pc -> 0x00000000000040d3a8 -0, 0x40d3a8, 0xa94153f3, "ldp x19, x20, [sp, #0x10]", load, 0x7f635a9e7ea0, pc -> 0x00000000000040d3ac -0, 0x40d3ac, 0xa9425bf5, "ldp x21, x22, [sp, #0x20]", load, 0x7f635a9e7eb0, pc -> 0x00000000000040d3b0 -0, 0x40d3b0, 0xa94363f7, "ldp x23, x24, [sp, #0x30]", load, 0x7f635a9e7ec0, pc -> 0x00000000000040d3b4 -0, 0x40d3b4, 0xa9446bf9, "ldp x25, x26, [sp, #0x40]", load, 0x7f635a9e7ed0, pc -> 0x00000000000040d3b8 -0, 0x40d3b8, 0xa8ca7bfd, "ldp x29, x30, [sp], #0xa0", load, 0x7f635a9e7e90, pc -> 0x00000000000040d3bc -0, 0x40d3bc, 0xd65f03c0, "ret ", pc -> 0x000000000000405d80 -0, 0x405d80, 0xeb13029f, "cmp x20, x19", pc -> 0x000000000000405d84 -0, 0x405d84, 0x91000694, "add x20, x20, #1", pc -> 0x000000000000405d88 -0, 0x405d88, 0x54ffff81, "b.ne #0x405d78", pc -> 0x000000000000405d8c -0, 0x405d8c, 0x2a1703e0, "mov w0, w23", pc -> 0x000000000000405d90 -0, 0x405d90, 0x94004c20, "bl #0x418e10", pc -> 0x000000000000418e10 -0, 0x418e10, 0x93407c02, "sxtw x2, w0", pc -> 0x000000000000418e14 -0, 0x418e14, 0x900003c4, "adrp x4, #0x490000", pc -> 0x000000000000418e18 -0, 0x418e18, 0xf946f084, "ldr x4, [x4, #0xde0]", load, 0x00490de0, pc -> 0x000000000000418e1c -0, 0x418e1c, 0xd53bd043, "mrs x3, tpidr_el0", pc -> 0x000000000000418e20 -0, 0x418e20, 0xaa0203e0, "mov x0, x2", pc -> 0x000000000000418e24 -0, 0x418e24, 0xd2800bc8, "movz x8, #0x5e", pc -> 0x000000000000418e28 -0, 0x418e28, 0xd4000001, "svc #0" -``` - -Now, here is the same part of the execution but without the `-one-insn-per-tb` option: - -```raw -0, 0x40e470, 0x54000040, "b.eq #0x40e478" -0, 0x40e474, 0xd65f03c0, "ret ", pc -> 0x00000000000040d38c -0, 0x40d38c, 0xf945fab5, "ldr x21, [x21, #0xbf0]", load, 0x00490bf0 -0, 0x40d390, 0xf9404fe0, "ldr x0, [sp, #0x98]", load, 0x7f4d42108f28 -0, 0x40d394, 0xf94002a1, "ldr x1, [x21]", load, 0x0048f9e8 -0, 0x40d398, 0xeb010000, "subs x0, x0, x1" -0, 0x40d39c, 0xd2800001, "movz x1, #0" -0, 0x40d3a0, 0x540006e1, "b.ne #0x40d47c", pc -> 0x00000000000040d3a4 -0, 0x40d3a4, 0x2a1903e0, "mov w0, w25" -0, 0x40d3a8, 0xa94153f3, "ldp x19, x20, [sp, #0x10]", load, 0x7f4d42108ea0 -0, 0x40d3ac, 0xa9425bf5, "ldp x21, x22, [sp, #0x20]", load, 0x7f4d42108eb0 -0, 0x40d3b0, 0xa94363f7, "ldp x23, x24, [sp, #0x30]", load, 0x7f4d42108ec0 -0, 0x40d3b4, 0xa9446bf9, "ldp x25, x26, [sp, #0x40]", load, 0x7f4d42108ed0 -0, 0x40d3b8, 0xa8ca7bfd, "ldp x29, x30, [sp], #0xa0", load, 0x7f4d42108e90 -0, 0x40d3bc, 0xd65f03c0, "ret ", pc -> 0x000000000000405d80 -0, 0x405d80, 0xeb13029f, "cmp x20, x19" -0, 0x405d84, 0x91000694, "add x20, x20, #1" -0, 0x405d88, 0x54ffff81, "b.ne #0x405d78", pc -> 0x000000000000405d8c -0, 0x405d8c, 0x2a1703e0, "mov w0, w23" -0, 0x405d90, 0x94004c20, "bl #0x418e10", pc -> 0x000000000000418e10 -0, 0x418e10, 0x93407c02, "sxtw x2, w0" -0, 0x418e14, 0x900003c4, "adrp x4, #0x490000" -0, 0x418e18, 0xf946f084, "ldr x4, [x4, #0xde0]", load, 0x00490de0 -0, 0x418e1c, 0xd53bd043, "mrs x3, tpidr_el0" -0, 0x418e20, 0xaa0203e0, "mov x0, x2" -0, 0x418e24, 0xd2800bc8, "movz x8, #0x5e" -0, 0x418e28, 0xd4000001, "svc #0" -``` - -The [documentation](https://www.qemu.org/docs/master/devel/tcg-plugins.html) says: - -> This plugin can also dump registers when they change value. Specify the name of the registers with multiple reg options. - -The `pc` register changes for each instruction. I would expect the plugin to produce the same output with or without the `-one-insn-per-tb` option. -Additional information: -The code that prints "pc -> 0x......" is in `insn_check_regs()` in `contrib/plugins/execlog.c`. It uses the new `qemu_plugin_read_register()` function and compares the new value to the previous value. The code seems OK. It means that the implementation of `qemu_plugin_read_register()` gets the same value several times in a row, instead of a new value each time. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2302 b/results/classifier/zero-shot-user-mode/output/instruction/2302 deleted file mode 100644 index a62c8a543..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2302 +++ /dev/null @@ -1,31 +0,0 @@ -instruction: 0.846 -runtime: 0.088 -syscall: 0.066 - - - -qemu-x86_64 crashes with "Illegal Instruction" on SPECCPU2017 Benchmarks -Description of problem: -I am running qemu-x86_64 with SPEC CPU 2017 benchmarks, and the compiled benchmarks such as Perlbench will crash unexpectedly. I have changed to three other machines to run it and still get crashes on two of them, I don't know what's the problem and want some help. -Steps to reproduce: -1. Compile SPEC CPU 2017 basic Perlbench binary. -2. Use the above command line to run it. -Additional information: -I have added some debugging flags to qemu-x86_64 to test it. The "-d in_asm" flag gives me the instructions before the crash like this: -``` ----------------- -IN: Perl_lex_start -0x555555678a79: 48 89 83 a8 00 00 00 movq %rax, 0xa8(%rbx) -0x555555678a80: e9 01 ff ff ff jmp 0x555555678986 - ----------------- -IN: Perl_lex_start -0x555555678986: 48 8b 50 10 movq 0x10(%rax), %rdx -0x55555567898a: 41 83 e4 16 andl $0x16, %r12d -0x55555567898e: 48 89 93 d0 00 00 00 movq %rdx, 0xd0(%rbx) -0x555555678995: 48 89 93 c0 00 00 00 movq %rdx, 0xc0(%rbx) -0x55555567899c: 62 .byte 0x62 - -qemu: uncaught target signal 4 (Illegal instruction) - core dumped -Illegal instruction (core dumped) -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2304 b/results/classifier/zero-shot-user-mode/output/instruction/2304 deleted file mode 100644 index 277d37b36..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2304 +++ /dev/null @@ -1,44 +0,0 @@ -instruction: 0.531 -syscall: 0.244 -runtime: 0.225 - - - -Disabling SVE via `-cpu max,sve=off` leaves SVE2 advertised by `getauxval` -Description of problem: -The documentation on https://qemu-project.gitlab.io/qemu/system/arm/cpu-features.html suggests that it should be possible to disable SVE support by passing `-cpu max,sve=off` on the command line, however this appears to only disable the SVE support advertised in the return value from `getauxval(AT_HWCAP)`. In particular it leaves SVE2 reported as enabled. This leaves the feature set advertised by `getauxval` in an inconsistent state since SVE is mandatory if SVE2 is available. - -This may also affect other feature dependencies for example FEAT_SVE_BITPerm also requiring SVE2 to be available, I've not checked exhaustively. - -For example, given the following code: - - #include <sys/auxv.h> - #include <stdio.h> - - int main() { - unsigned long hwcap = getauxval(AT_HWCAP); - unsigned long hwcap2 = getauxval(AT_HWCAP2); - - if (hwcap & HWCAP_SVE) { - printf("have sve!\n"); - } else { - printf("don't have sve!\n"); - } - if (hwcap2 & HWCAP2_SVE2) { - printf("have sve2!\n"); - } else { - printf("don't have sve2!\n"); - } - } - -We can observe the following: - - $ aarch64-linux-gnu-gcc test.c -static - $ ../qemu-aarch64 -cpu max ./a.out - have sve! - have sve2! - $ ../qemu-aarch64 -cpu max,sve=off ./a.out - don't have sve! - have sve2! - -I don't believe that there is a `-cpu ...,sve2=off` option, so I would expect that disabling SVE also prevents SVE2 from being advertised as available. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2309 b/results/classifier/zero-shot-user-mode/output/instruction/2309 deleted file mode 100644 index 9c7655eb7..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2309 +++ /dev/null @@ -1,37 +0,0 @@ -instruction: 0.588 -runtime: 0.249 -syscall: 0.163 - - - -qemu-aarch64 hangs running cargo test after libc6 upgrade to 2.36-9+deb12u6 -Description of problem: -qemu-aarch64 seems to hang with 100% cpu usage without any indication. -with -p 12345 for gdb debugging, gdb could not interrupt the remote with ctrl-c. -Steps to reproduce: -1. Ensure the test env has 2.36-9+deb12u6 -2. Install the latest rust toolchain. -3. mkdir test_test && cargo init -4. ensure src/main.rs has -``` -fn main() { - println!("Hello, world!"); -} - -#[test] -fn test() { - println!("hAAA!"); -} -``` -5. create .cargo/config.toml -``` -[target.aarch64-unknown-linux-gnu] -linker = "aarch64-linux-gnu-gcc" -runner = "qemu-aarch64 -L /usr/aarch64-linux-gnu" -rustflags = ["-C", "target-cpu=neoverse-n1"] -``` -6. cargo test --target aarch64-unknown-linux-gnu -Additional information: -The issue does not seem to occur with libc6:2.36-9+deb12u4 - -The same binary runs fine on a real arm64 target with the upgraded libc6 version 2.36-9+deb12u6. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2317 b/results/classifier/zero-shot-user-mode/output/instruction/2317 deleted file mode 100644 index 391343455..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2317 +++ /dev/null @@ -1,44 +0,0 @@ -instruction: 0.666 -runtime: 0.180 -syscall: 0.154 - - - -SH4: ADDV instruction not emulated properly -Description of problem: -ADDV opcode is emulated incorrectly. - -The documentation says: - -`ADDV Rm, Rn Rn + Rm -> Rn, overflow -> T` - -What Qemu actually emulates: - -`ADDV Rm, Rn Rn + Rm -> Rm, overflow -> T` -Steps to reproduce: -```c -#include <stdio.h> - -int main(void) -{ - register unsigned int a asm("r8") = 0x7fffffff; - register unsigned int b asm("r9") = 1; - register unsigned int c asm("r10"); - - asm volatile("clrt\n" - "addv %2,%0\n" - "movt %1\n" - : "+r"(a), "=r"(c) : "r"(b) :); - - printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c); - - return 0; -} - -``` -Additional information: -Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints: -`Values: a=0x80000000 b=0x1 c=0x1` - -Running with Qemu (and GCC 13.0), the same program prints: -`Values: a=0x7fffffff b=0x80000000 c=0x1` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2318 b/results/classifier/zero-shot-user-mode/output/instruction/2318 deleted file mode 100644 index ea5b83370..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2318 +++ /dev/null @@ -1,40 +0,0 @@ -instruction: 0.706 -runtime: 0.182 -syscall: 0.112 - - - -SH4: SUBV instruction not emulated properly -Description of problem: -SUBV opcode is emulated incorrectly. - -The documentation says: - -`SUBV Rm, Rn Rn - Rm -> Rn, underflow -> T` - -Qemu seems to perform the subtraction correctly, but will not detect an underflow. -Steps to reproduce: -```c -#include <stdio.h> - -int main(void) -{ - register unsigned int a asm("r8") = 0x80000001; - register unsigned int b asm("r9") = 0x2; - register unsigned int c asm("r10"); - - asm volatile("subv %2,%0\n" - "movt %1\n" - : "+r"(a), "=r"(c) : "r"(b) :); - - printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c); - - return 0; -} -``` -Additional information: -Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints: -`Values: a=0x7fffffff b=0x2 c=0x1` - -Running with Qemu (and GCC 13.0), the same program prints: -`Values: a=0x7fffffff b=0x2 c=0x0` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2319 b/results/classifier/zero-shot-user-mode/output/instruction/2319 deleted file mode 100644 index 5dde2435f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2319 +++ /dev/null @@ -1,23 +0,0 @@ -instruction: 0.509 -runtime: 0.259 -syscall: 0.232 - - - -SPARC32-bit SDIV of negative divisor gives wrong result -Description of problem: -SDIV of negative divisor gives wrong result because of typo in helper_sdiv(). This is true for QEMU 9.0.0 and earlier. - -Place -1 in the Y register and -128 in another reg, then -120 in another register and do SDIV into a result register, instead of the proper value of 1 for the result, the incorrect value of 0 is produced. - -There is a typo in target/sparc/helper.c that causes the divisor to be consider unsigned, this patch fixes it: - -\*\*\* helper.c.ori Tue Apr 23 16:23:45 2024 --- helper.c Mon Apr 29 20:14:07 2024 - ---- - -\*\*\* 121,127 \*\*\*\* return (uint32_t)(b32 \< 0 ? INT32_MAX : INT32_MIN) | (-1ull \<\< 32); } - -! a64 /= b; r = a64; if (unlikely(r != a64)) { return (uint32_t)(a64 \< 0 ? INT32_MIN : INT32_MAX) | (-1ull \<\< 32); --- 121,127 ---- return (uint32_t)(b32 \< 0 ? INT32_MAX : INT32_MIN) | (-1ull \<\< 32); } - -! a64 /= b32; r = a64; if (unlikely(r != a64)) { return (uint32_t)(a64 \< 0 ? INT32_MIN : INT32_MAX) | (-1ull \<\< 32); diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2336 b/results/classifier/zero-shot-user-mode/output/instruction/2336 deleted file mode 100644 index a383e5e1f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2336 +++ /dev/null @@ -1,29 +0,0 @@ -instruction: 0.605 -runtime: 0.274 -syscall: 0.121 - - - -qemu-x86_64 crash on LoongArch -Description of problem: - -Steps to reproduce: -1. build a static hello test on x86_64 machine. -2. build qemu-x86_64 on LoongArch. -3. run 'qemu-x86_64 hello 'on LoongArch. -Additional information: -1 result - -[root@localhost qemu]# ./build/qemu-x86_64 ~/hello -Bus error (core dumped) - -2 Since commit 45bf0e7aa648369cf8ab2333bd20144806fc1be3 - -3 full log with -d in_asm,op,out_asm,strace -see log.txt - -[log.txt](/uploads/9a0e3250bfafa6db31d6688b8c60feb7/log.txt) - -[qemu-x86_64](/uploads/728fc4f4633054097b6028cd99a20e8b/qemu-x86_64) - -[hello](/uploads/d7dec3bdb844273a8e26464ed418c1a0/hello) diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2353 b/results/classifier/zero-shot-user-mode/output/instruction/2353 deleted file mode 100644 index 204c60cf1..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2353 +++ /dev/null @@ -1,62 +0,0 @@ -instruction: 0.375 -runtime: 0.353 -syscall: 0.272 - - - -linux-user: may map interpreter at address 0 with nonzero guest_base -Description of problem: -QEMU's user-mode emulation will, under certain conditions, map the ELF interpreter at guest address 0. This is not only a violation of Linux's policy never to map anything at the first page of any virtual address space, but also a cause of confusion (and segfaults) within certain libcs; though I only tested with musl. Musl [interprets a NULL base address](https://elixir.bootlin.com/musl/v1.2.4/source/ldso/dlstart.c#L105) as the dynamic linker being invoked directly, causing it to compute its base address incorrectly. - -The problem arises in `load_elf_image()`, which chooses a `load_addr` of 0 for the ELF interpreter (i.e. the musl dynamic loader). This is passed to `target_mmap()`. I do not know whether `target_mmap()` is meant to follow the POSIX rule that (in absence of `MAP_FIXED`) "All implementations interpret an *addr* value of 0 as granting the implementation complete freedom in selecting *pa*" or if 0 is requesting 0. - -QEMU's usermode mmap() implementation translates the guest address to a host address (this is effectively a no-op with `guest_base == 0`) and passes it along to the host Linux. This means that, when `guest_base == 0`, a NULL input address means "put it anywhere," but when `guest_base != 0`, NULL means "put it at (guest address) 0." -Steps to reproduce: -1. Download a rootfs of Alpine Linux AArch64. -2. Install `gcc` (with `apk add gcc`) in the rootfs. `gcc` is not compiled as PIC, making QEMU use a nonzero `guest_base`. -3. Attempt to run `gcc` within the rootfs via QEMU. -Additional information: -I am interested in submitting a MR that fixes this issue, but I do not know which of 4 possible solutions is preferred: - -1. Modify `load_elf_image()` to ensure that `load_addr` is never NULL. -2. Modify `target_mmap()` so that NULLs are passed to the kernel as NULLs. -3. Modify the guest<->host translation facilities (`g2h_untagged` et al) to translate NULL as NULL. Overwhelmingly, a NULL pointer semantically means "there is no pointer here" and not "a pointer to the zeroth address," so treating these as valid addresses in the translation functions is arguably going against the grain. -4. When a nonzero `guest_base` is selected, reserve the first page of the guest VA space, so that the host kernel cannot accidentally put anything there. - -Here is my local patch that implements item 2 above, which indeed stops the segfaults for me: -<details><summary>Patch</summary> - -```diff -diff --git a/linux-user/mmap.c b/linux-user/mmap.c -index be3b9a6..dad29ef 100644 ---- a/linux-user/mmap.c -+++ b/linux-user/mmap.c -@@ -559,7 +559,7 @@ static abi_long mmap_h_eq_g(abi_ulong start, abi_ulong len, - int host_prot, int flags, int page_flags, - int fd, off_t offset) - { -- void *p, *want_p = g2h_untagged(start); -+ void *p, *want_p = start ? g2h_untagged(start) : 0; - abi_ulong last; - - p = mmap(want_p, len, host_prot, flags, fd, offset); -@@ -609,7 +609,7 @@ static abi_long mmap_h_lt_g(abi_ulong start, abi_ulong len, int host_prot, - int mmap_flags, int page_flags, int fd, - off_t offset, int host_page_size) - { -- void *p, *want_p = g2h_untagged(start); -+ void *p, *want_p = start ? g2h_untagged(start) : 0; - off_t fileend_adj = 0; - int flags = mmap_flags; - abi_ulong last, pass_last; -@@ -739,7 +739,7 @@ static abi_long mmap_h_gt_g(abi_ulong start, abi_ulong len, - int flags, int page_flags, int fd, - off_t offset, int host_page_size) - { -- void *p, *want_p = g2h_untagged(start); -+ void *p, *want_p = start ? g2h_untagged(start) : 0; - off_t host_offset = offset & -host_page_size; - abi_ulong last, real_start, real_last; - bool misaligned_offset = false; -``` -</details> diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2372 b/results/classifier/zero-shot-user-mode/output/instruction/2372 deleted file mode 100644 index 527c7c34a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2372 +++ /dev/null @@ -1,115 +0,0 @@ -instruction: 0.510 -runtime: 0.277 -syscall: 0.213 - - - -A bug in AArch64 UMOPA/UMOPS (4-way) instruction -Description of problem: -umopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. A source register’s element size is 16 bits, while a destination register’s element size is 64 bits in case of the 4-way variant of this instruction. Before performing matrix multiplication, each element should be zero-extended to a 64-bit element. - -However, the current implementation of the helper function fails to convert the element type correctly. Below is the helper function implementation: -``` -// target/arm/tcg/sme_helper.c -#define DEF_IMOP_64(NAME, NTYPE, MTYPE) \ -static uint64_t NAME(uint64_t n, uint64_t m, uint64_t a, uint8_t p, bool neg) \ -{ \ - uint64_t sum = 0; \ - /* Apply P to N as a mask, making the inactive elements 0. */ \ - n &= expand_pred_h(p); \ - sum += (NTYPE)(n >> 0) * (MTYPE)(m >> 0); \ - sum += (NTYPE)(n >> 16) * (MTYPE)(m >> 16); \ - sum += (NTYPE)(n >> 32) * (MTYPE)(m >> 32); \ - sum += (NTYPE)(n >> 48) * (MTYPE)(m >> 48); \ - return neg ? a - sum : a + sum; \ -} - -DEF_IMOP_64(umopa_d, uint16_t, uint16_t) -``` -When the multiplication is performed, each element, such as `(NTYPE)(n >> 0)`, is automatically converted to `int32_t`, so the computation result has a type `int32_t`. The result is then converted to `uint64_t`, and it is added to `sum`. It seems the elements should be casted to `uint64_t` **before** performing the multiplication. -Steps to reproduce: -1. Write `test.c`. -``` -#include <stdio.h> - -char i_P1[4] = { 0xff, 0xff, 0xff, 0xff }; -char i_P5[4] = { 0xff, 0xff, 0xff, 0xff }; -char i_Z0[32] = { // Set only the first element as non-zero - 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, -}; -char i_Z20[32] = { // Set only the first element as non-zero - 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, -}; -char i_ZA2H[128] = { 0x0, }; -char o_ZA2H[128]; - -void __attribute__ ((noinline)) show_state() { - for (int i = 0; i < 8; i++) { - for (int j = 0; j < 16; j++) { - printf("%02x ", o_ZA2H[16*i+j]); - } - printf("\n"); - } -} - -void __attribute__ ((noinline)) run() { - __asm__ ( - ".arch armv9.3-a+sme\n" - "smstart\n" - "adrp x29, i_P1\n" - "add x29, x29, :lo12:i_P1\n" - "ldr p1, [x29]\n" - "adrp x29, i_P5\n" - "add x29, x29, :lo12:i_P5\n" - "ldr p5, [x29]\n" - "adrp x29, i_Z0\n" - "add x29, x29, :lo12:i_Z0\n" - "ldr z0, [x29]\n" - "adrp x29, i_Z20\n" - "add x29, x29, :lo12:i_Z20\n" - "ldr z20, [x29]\n" - "adrp x29, i_ZA2H\n" - "add x29, x29, :lo12:i_ZA2H\n" - "mov x15, 0\n" - "ld1d {za2h.d[w15, 0]}, p1, [x29]\n" - "add x29, x29, 32\n" - "ld1d {za2h.d[w15, 1]}, p1, [x29]\n" - "add x29, x29, 32\n" - "mov x15, 2\n" - "ld1d {za2h.d[w15, 0]}, p1, [x29]\n" - "add x29, x29, 32\n" - "ld1d {za2h.d[w15, 1]}, p1, [x29]\n" - ".inst 0xa1f43402\n" // umopa za2.d, p5/m, p1/m, z0.h, z20.h - "adrp x29, o_ZA2H\n" - "add x29, x29, :lo12:o_ZA2H\n" - "mov x15, 0\n" - "st1d {za2h.d[w15, 0]}, p1, [x29]\n" - "add x29, x29, 32\n" - "st1d {za2h.d[w15, 1]}, p1, [x29]\n" - "add x29, x29, 32\n" - "mov x15, 2\n" - "st1d {za2h.d[w15, 0]}, p1, [x29]\n" - "add x29, x29, 32\n" - "st1d {za2h.d[w15, 1]}, p1, [x29]\n" - "smstop\n" - ".arch armv8-a\n" - ); -} - -int main(int argc, char **argv) { - run(); - show_state(); - return 0; -} -``` -2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. -3. Run `QEMU` using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`. -4. The program, runs on top of the buggy QEMU, prints the first 8 bytes of `ZA2H` as `01 00 fe ff ff ff ff ff`. It should print `01 00 fe ff 00 00 00 00` after the bug is fixed. -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2373 b/results/classifier/zero-shot-user-mode/output/instruction/2373 deleted file mode 100644 index 06a8b9ac7..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2373 +++ /dev/null @@ -1,101 +0,0 @@ -instruction: 0.437 -runtime: 0.340 -syscall: 0.223 - - - -A bug in AArch64 FMOPA/FMOPS (widening) instruction -Description of problem: -fmopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. A source register’s element size is 16 bits, while a destination register’s element size is 64 bits in the case of widening variant of this instruction. Before the matrix multiplication is performed, each element should be converted to a 64-bit floating point. FPCR flags are considered when converting floating point values. Especially, when the FZ (or FZ16) flag is set, denormalized values are converted into zero. When the floating point size is 16 bits, FZ16 should be considered; otherwise, FZ flag should be used. - -However, the current implementation only considers FZ flag, not FZ16 flag, so it computes the wrong value. -Steps to reproduce: -1. Write `test.c`. -``` -#include <stdio.h> - -char i_P2[4] = { 0xff, 0xff, 0xff, 0xff }; -char i_P5[4] = { 0xff, 0xff, 0xff, 0xff }; -char i_Z0[32] = { // Set only the first element as non-zero - 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, -}; -char i_Z16[32] = { // Set only the first element as non-zero - 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, -}; -char i_ZA3H[128] = { 0x0, }; -uint64_t i_fpcr = 0x0001000000; // FZ = 1; -char o_ZA3H[128]; - -void __attribute__ ((noinline)) show_state() { - for (int i = 0; i < 8; i++) { - for (int j = 0; j < 16; j++) { - printf("%02x ", o_ZA3H[16*i+j]); - } - printf("\n"); - } -} - -void __attribute__ ((noinline)) run() { - __asm__ ( - ".arch armv9.3-a+sme\n" - "smstart\n" - "adrp x29, i_P2\n" - "add x29, x29, :lo12:i_P2\n" - "ldr p2, [x29]\n" - "adrp x29, i_P5\n" - "add x29, x29, :lo12:i_P5\n" - "ldr p5, [x29]\n" - "adrp x29, i_Z0\n" - "add x29, x29, :lo12:i_Z0\n" - "ldr z0, [x29]\n" - "adrp x29, i_Z16\n" - "add x29, x29, :lo12:i_Z16\n" - "ldr z16, [x29]\n" - "adrp x29, i_ZA3H\n" - "add x29, x29, :lo12:i_ZA3H\n" - "mov x15, 0\n" - "ld1w {za3h.s[w15, 0]}, p2, [x29]\n" - "add x29, x29, 32\n" - "ld1w {za3h.s[w15, 1]}, p2, [x29]\n" - "add x29, x29, 32\n" - "mov x15, 2\n" - "ld1w {za3h.s[w15, 0]}, p2, [x29]\n" - "add x29, x29, 32\n" - "ld1w {za3h.s[w15, 1]}, p2, [x29]\n" - "adrp x29, i_fpcr\n" - "add x29, x29, :lo12:i_fpcr\n" - "ldr x29, [x29]\n" - "msr fpcr, x29\n" - ".inst 0x81a0aa03\n" // fmopa za3.s, p2/m, p5/m, z16.h, z0.h - "adrp x29, o_ZA3H\n" - "add x29, x29, :lo12:o_ZA3H\n" - "mov x15, 0\n" - "st1w {za3h.s[w15, 0]}, p2, [x29]\n" - "add x29, x29, 32\n" - "st1w {za3h.s[w15, 1]}, p2, [x29]\n" - "add x29, x29, 32\n" - "mov x15, 2\n" - "st1w {za3h.s[w15, 0]}, p2, [x29]\n" - "add x29, x29, 32\n" - "st1w {za3h.s[w15, 1]}, p2, [x29]\n" - ".arch armv8-a\n" - ); -} - -int main(int argc, char **argv) { - run(); - show_state(); - return 0; -} -``` -2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. -3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`. -4. The program, runs on top of the buggy QEMU, prints only zero bytes. It should print `00 01 7e 2f + 00 .. (rest of bytes) .. 00` after the bug is fixed. -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2374 b/results/classifier/zero-shot-user-mode/output/instruction/2374 deleted file mode 100644 index fd24df501..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2374 +++ /dev/null @@ -1,117 +0,0 @@ -instruction: 0.390 -runtime: 0.332 -syscall: 0.278 - - - -A bug in AArch64 FMOPA/FMOPS (non-widening) instruction -Description of problem: -fmopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. Depending on the instruction encoding, the element size of operands is either 32 bits or 64 bits. When the computation produces a NaN as a result, the default NaN should be generated. - -However, the current implementation of 32-bit variant of this instruction does not generate default NaNs, because invalid float_status pointer is passed: -``` -// target/arm/tcg/sme_helper.c -void HELPER(sme_fmopa_s)(void *vza, void *vzn, void *vzm, void *vpn, - void *vpm, void *vst, uint32_t desc) -{ -... - float_status fpst; - - /* - * Make a copy of float_status because this operation does not - * update the cumulative fp exception status. It also produces - * default nans. - */ - fpst = *(float_status *)vst; - set_default_nan_mode(true, &fpst); - -... - *a = float32_muladd(n, *m, *a, 0, vst); // &fpst should be used -... -} -``` -Steps to reproduce: -1. Write `test.c`. -``` -#include <stdio.h> - -char i_P0[4] = { 0xff, 0xff, 0xff, 0xff }; -char i_P6[4] = { 0xff, 0xff, 0xff, 0xff }; -char i_Z9[32] = { // Set only the first element as NaN, but it is not default NaN. - 0xff, 0xff, 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, -}; -char i_Z27[32] = { - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, - 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, -}; -char i_ZA1H[128] = { 0x0, }; -char o_ZA1H[128]; - -void __attribute__ ((noinline)) show_state() { - for (int i = 0; i < 8; i++) { - for (int j = 0; j < 16; j++) { - printf("%02x ", o_ZA1H[16*i+j]); - } - printf("\n"); - } -} - -void __attribute__ ((noinline)) run() { - __asm__ ( - ".arch armv9.3-a+sme\n" - "smstart\n" - "adrp x29, i_P0\n" - "add x29, x29, :lo12:i_P0\n" - "ldr p0, [x29]\n" - "adrp x29, i_P6\n" - "add x29, x29, :lo12:i_P6\n" - "ldr p6, [x29]\n" - "adrp x29, i_Z9\n" - "add x29, x29, :lo12:i_Z9\n" - "ldr z9, [x29]\n" - "adrp x29, i_Z27\n" - "add x29, x29, :lo12:i_Z27\n" - "ldr z27, [x29]\n" - "adrp x29, i_ZA1H\n" - "add x29, x29, :lo12:i_ZA1H\n" - "mov x15, 0\n" - "ld1w {za1h.s[w15, 0]}, p0, [x29]\n" - "add x29, x29, 32\n" - "ld1w {za1h.s[w15, 1]}, p0, [x29]\n" - "add x29, x29, 32\n" - "mov x15, 2\n" - "ld1w {za1h.s[w15, 0]}, p0, [x29]\n" - "add x29, x29, 32\n" - "ld1w {za1h.s[w15, 1]}, p0, [x29]\n" - ".inst 0x809bc121\n" // fmopa za1.s, p0/m, p6/m, z9.s, z27.s - "adrp x29, o_ZA1H\n" - "add x29, x29, :lo12:o_ZA1H\n" - "mov x15, 0\n" - "st1w {za1h.s[w15, 0]}, p0, [x29]\n" - "add x29, x29, 32\n" - "st1w {za1h.s[w15, 1]}, p0, [x29]\n" - "add x29, x29, 32\n" - "mov x15, 2\n" - "st1w {za1h.s[w15, 0]}, p0, [x29]\n" - "add x29, x29, 32\n" - "st1w {za1h.s[w15, 1]}, p0, [x29]\n" - ".arch armv8-a\n" - ); -} - -int main(int argc, char **argv) { - run(); - show_state(); - return 0; -} -``` -2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. -3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`. -4. The program, runs on top of the buggy QEMU, prints 8 non-default NaNs (ff ff ff ff). It should print 8 default NaNs (00 00 c0 7f) after the bug is fixed. -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2375 b/results/classifier/zero-shot-user-mode/output/instruction/2375 deleted file mode 100644 index e9073282d..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2375 +++ /dev/null @@ -1,91 +0,0 @@ -instruction: 0.376 -runtime: 0.368 -syscall: 0.256 - - - -A bug in AArch64 FJCVTZS instruction -Description of problem: -fjcvtzs instruction converts a double-precision floating-point value in the source register into a 32-bit signed integer, and stores the result in the destination register. The contents of the FPCR register influence the exception result. Especially, when FPCR.FZ (Flushing denormalized numbers to Zero) is set and an input is a denormalized number, the PSTATE.Z flag should be cleared even if the conversion result is zero. - -However, because the helper function for this instruction does not properly check the denormalized case, the Z flag will have an incorrect value: -``` -// target/arm/vfp_helper.c -uint64_t HELPER(fjcvtzs)(float64 value, void *vstatus) -{ - float_status *status = vstatus; - uint32_t inexact, frac; - uint32_t e_old, e_new; - - e_old = get_float_exception_flags(status); - set_float_exception_flags(0, status); - frac = float64_to_int32_modulo(value, float_round_to_zero, status); - e_new = get_float_exception_flags(status); - set_float_exception_flags(e_old | e_new, status); - - if (value == float64_chs(float64_zero)) { - /* While not inexact for IEEE FP, -0.0 is inexact for JavaScript. */ - inexact = 1; - } else { - /* Normal inexact or overflow or NaN */ - inexact = e_new & (float_flag_inexact | float_flag_invalid); // float_flag_input_denormal should also be checked. - } - - /* Pack the result and the env->ZF representation of Z together. */ - return deposit64(frac, 32, 32, inexact); -} -``` -Steps to reproduce: -1. Write `test.c`. -``` -#include <stdint.h> -#include <stdio.h> -#include <string.h> - -char i_D27[8] = { 0x0, 0xff, 0xfc, 0x0, 0x0, 0x0, 0x0, 0x0 }; -uint64_t i_fpcr = 0x01000000; // FZ = 1; -char o_X28[8]; -uint64_t o_nzcv; - -void __attribute__ ((noinline)) show_state() { - char Z = ((o_nzcv >> 30) & 1); - - printf("PSTATE.Z: %d\n", Z); - printf("X28: "); - for (int i = 0; i < 8; i++) { - printf("%02x ", o_X28[i]); - } - printf("\n"); -} - -void __attribute__ ((noinline)) run() { - __asm__ ( - "adrp x29, i_D27\n" - "add x29, x29, :lo12:i_D27\n" - "ldr d27, [x29]\n" - "adrp x29, i_fpcr\n" - "add x29, x29, :lo12:i_fpcr\n" - "ldr x29, [x29]\n" - "msr fpcr, x29\n" - ".inst 0x1e7e037c\n" // fjcvtzs w28, d27 - "mrs x26, nzcv\n" - "adrp x29, o_nzcv\n" - "add x29, x29, :lo12:o_nzcv\n" - "str x26, [x29]\n" - "adrp x29, o_X28\n" - "add x29, x29, :lo12:o_X28\n" - "str x28, [x29]\n" - ); -} - -int main(int argc, char **argv) { - run(); - show_state(); - return 0; -} -``` -2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. -3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ ./test.bin`. -4. The program, runs on top of the buggy QEMU, prints the value of Z as `01`. It should print `00` after the bug is fixed. -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2376 b/results/classifier/zero-shot-user-mode/output/instruction/2376 deleted file mode 100644 index bb9fac824..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2376 +++ /dev/null @@ -1,120 +0,0 @@ -instruction: 0.479 -runtime: 0.324 -syscall: 0.198 - - - -A bug in ARM VCMLA.f16/VCMLA.f32 instructions -Description of problem: -The vcmla instruction performs complex-number operations on the vector registers. There is a bug in which this instruction modifies the contents of an irrelevant vector register. - -The reason is simple out-of-bound; the helper functions should correctly check the number of modified elements: -``` -// target/arm/tcg/vec_helper.c -void HELPER(gvec_fcmlah_idx)(void *vd, void *vn, void *vm, void *va, - void *vfpst, uint32_t desc) -{ - uintptr_t opr_sz = simd_oprsz(desc); - float16 *d = vd, *n = vn, *m = vm, *a = va; - float_status *fpst = vfpst; - intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1); - uint32_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1); - intptr_t index = extract32(desc, SIMD_DATA_SHIFT + 2, 2); - uint32_t neg_real = flip ^ neg_imag; - intptr_t elements = opr_sz / sizeof(float16); - intptr_t eltspersegment = 16 / sizeof(float16); // This should be fixed; - intptr_t i, j; - - ... -} - -... - -void HELPER(gvec_fcmlas_idx)(void *vd, void *vn, void *vm, void *va, - void *vfpst, uint32_t desc) -{ - uintptr_t opr_sz = simd_oprsz(desc); - float32 *d = vd, *n = vn, *m = vm, *a = va; - float_status *fpst = vfpst; - intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1); - uint32_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1); - intptr_t index = extract32(desc, SIMD_DATA_SHIFT + 2, 2); - uint32_t neg_real = flip ^ neg_imag; - intptr_t elements = opr_sz / sizeof(float32); - intptr_t eltspersegment = 16 / sizeof(float32); // This should be fixed; - intptr_t i, j; - - ... -} -``` -Steps to reproduce: -1. Write `test.c`. -``` -#include <stdint.h> -#include <stdio.h> -#include <string.h> - -// zero inputs should produce zero output -char i_D4[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; -char i_D8[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; -char i_D30[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; -char i_D31[8] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; // this should never be touched -char o_D30[8]; -char o_D31[8]; - -void __attribute__ ((noinline)) show_state() { - printf("D30: "); - for (int i = 0; i < 8; i++) { - printf("%02x ", o_D30[i]); - } - printf("\n"); - printf("D31: "); - for (int i = 0; i < 8; i++) { - printf("%02x ", o_D31[i]); - } - printf("\n"); -} - -void __attribute__ ((noinline)) run() { - __asm__ ( - "movw r7, #:lower16:i_D4\n" - "movt r7, #:upper16:i_D4\n" - "vldr d4, [r7]\n" - "movw r7, #:lower16:i_D8\n" - "movt r7, #:upper16:i_D8\n" - "vldr d8, [r7]\n" - "movw r7, #:lower16:i_D30\n" - "movt r7, #:upper16:i_D30\n" - "vldr d30, [r7]\n" - "movw r7, #:lower16:i_D31\n" - "movt r7, #:upper16:i_D31\n" - "vldr d31, [r7]\n" - "adr r7, Lbl_thumb + 1\n" - "bx r7\n" - ".thumb\n" - "Lbl_thumb:\n" - ".inst 0xfed8e804\n" // vcmla.f32 d30, d8, d4[0], #90 - "adr r7, Lbl_arm\n" - "bx r7\n" - ".arm\n" - "Lbl_arm:\n" - "movw r7, #:lower16:o_D30\n" - "movt r7, #:upper16:o_D30\n" - "vstr d30, [r7]\n" - "movw r7, #:lower16:o_D31\n" - "movt r7, #:upper16:o_D31\n" - "vstr d31, [r7]\n" - ); -} - -int main(int argc, char **argv) { - run(); - show_state(); - return 0; -} -``` -2. Compile `test.bin` using this command: `arm-linux-gnueabihf-gcc-12 -O2 -no-pie -marm -march=armv7-a+vfpv4 ./test.c -o ./test.bin`. -3. Run QEMU using this command: `qemu-arm -L /usr/arm-linux-gnueabihf/ ./test.bin`. -4. The program, runs on top of the buggy QEMU, prints the value of D31 as `00 00 c0 7f 00 00 c0 7f`. It should print `ff ff ff ff ff ff ff ff` after the bug is fixed. -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2386 b/results/classifier/zero-shot-user-mode/output/instruction/2386 deleted file mode 100644 index 79d658962..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2386 +++ /dev/null @@ -1,49 +0,0 @@ -instruction: 0.625 -runtime: 0.218 -syscall: 0.157 - - - -RISCV - Incorrect behaviour of the SLL instruction -Description of problem: -`SLL` (and probably other similar instructions) produce incorrect results. To quote the [RISCV ISA manual](https://drive.google.com/file/d/1uviu1nH-tScFfgrovvFCrj7Omv8tFtkp/view): - -> SLL, SRL, and SRA perform logical left, logical right, and arithmetic right shifts on the value in register -rs1 by the shift amount held in the lower 5 bits of register rs2. - -This instruction should perform a logical shift left by the shift amount from the lower 5 bits held in the third operand, however, it doesn't seem to be the case. As can be seen from the result of the snippet below: `55c3585000000000`, it seems that it calculates the correct value, but then shifts it by another 32 bits to the left: - -```python -correct_shift_res = (0xDB4D6868655C3585 << (0x69C99AB9B9401024 & 0b11111)) & (2 ** 64 - 1) -incorrect_qemu_produced = (correct_shift_res << 32) & (2 ** 64 - 1) -``` -Steps to reproduce: -1. Compile the attached source file: `riscv64-linux-gnu-gcc -static repro.c -o ./repro.elf` - -```c -#include <stdint.h> -#include <stdio.h> - -int main() { - uint64_t a = 0x69C99AB9B9401024; - uint64_t b = 0xDB4D6868655C3585; - uint64_t c; - - asm volatile("sll %0, %1, %2" : "=r"(c) : "r"(b), "r"(a)); - - printf("s8 : %lx\n", c); - printf("expected: %lx\n", 0xb4d6868655c35850); - - return 0; -} -``` - -2. Run qemu: `./qemu-riscv64 ./repro.elf` -3. You will see the output and what the result of the computation should really be: - -``` -s8 : 55c3585000000000 -expected: b4d6868655c35850 -``` -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2410 b/results/classifier/zero-shot-user-mode/output/instruction/2410 deleted file mode 100644 index 35334b966..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2410 +++ /dev/null @@ -1,98 +0,0 @@ -instruction: 0.345 -syscall: 0.328 -runtime: 0.327 - - - -linux-user: `Setsockopt` with IP_OPTIONS returns "Protocol not available" error -Description of problem: -It seems that call to `setsockopt(sd, SOL_IP, IP_OPTIONS,_)` behaves differently on RISC-V Qemu than on x64 Linux. -On Linux syscall returns 0, but on Qemu it fails with `Protocol not available`. -According [man](https://man7.org/linux/man-pages/man7/ip.7.html) `IP_OPTIONS` on `SOCK_STREAM` socket "should work". -Steps to reproduce: -1. Use below toy program `setsockopt.c` and compile it without optimizations like: -``` - gcc -Wall -W -Wextra -std=gnu17 -pedantic setsockopt.c -o setsockopt -``` - -``` -#include <sys/types.h> -#include <sys/socket.h> -#include <arpa/inet.h> -#include <netinet/in.h> -#include <unistd.h> -#include <stdio.h> -#include <stdlib.h> -#include <string.h> - -int main() { - { - int sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); - if(sd < 0) { - perror("Opening stream socket error"); - exit(1); - } - else - printf("Opening stream socket....OK.\n"); - - struct sockaddr_in local_address = {AF_INET, htons(1234), {inet_addr("255.255.255.255")}, {0}}; - int err = connect(sd, (struct sockaddr*)&local_address, (socklen_t)16); - - if (err < 0) { - perror("Connect error"); - close(sd); - } - else - printf("Connect...OK.\n"); - } - { - int sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); - if(sd < 0) { - perror("Opening stream socket error"); - exit(1); - } - else - printf("Opening stream socket....OK.\n"); - - char option[4] = {0}; - if(setsockopt(sd, SOL_IP, IP_OPTIONS, (char *)option, sizeof(option)) < 0) { - perror("setsockopt error"); - close(sd); - exit(1); - } - else - printf("setsockopt...OK.\n"); - - struct sockaddr_in local_address = {AF_INET, htons(1234), {inet_addr("255.255.255.255")}, {0}}; - int err = connect(sd, (struct sockaddr*)&local_address, (socklen_t)16); - - if (err < 0) { - perror("Connect error"); - close(sd); - } - else - printf("Connect...OK.\n"); - } - return 0; -} -``` - - -2. Run program on Qemu and compare output with output from x64 build. In my case it looks like: -``` -root@AMDC4705:~/runtime/connect$ ./setsockopt-x64 -Opening stream socket....OK. -Connect error: Network is unreachable -Opening stream socket....OK. -setsockopt...OK. -Connect error: Network is unreachable - -root@AMDC4705:/runtime/connect# ./setsockopt-riscv -Opening stream socket....OK. -Connect error: Network is unreachable -Opening stream socket....OK. -setsockopt error: Protocol not available -``` -Additional information: -In above demo option `value` is quite artificial. However I tried passing many different `option` arguments (with same `SOL_IP` + `IP_OPTIONS` combination) but always ended up with `setsockopt` failure. -From the other hand on x64 it worked fine. Then I realized that appropriate path in Qemu was unimplemented: https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2141 diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2419 b/results/classifier/zero-shot-user-mode/output/instruction/2419 deleted file mode 100644 index b6acda493..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2419 +++ /dev/null @@ -1,24 +0,0 @@ -instruction: 0.666 -runtime: 0.181 -syscall: 0.152 - - - -ldapr_stlr_i instructions doesn't consider signed offset -Description of problem: -The format ldapr_stlr_i models the load acquire / store release immediate instructions. \ -These instructions has a bug in the sign extension calculation of the imm field. \ -imm should be defined as s9 instead of 9. - -@ldapr_stlr_i .. ...... .. . imm:9 .. rn:5 rt:5 &ldapr_stlr_i - -Should be changed to: - -@ldapr_stlr_i .. ...... .. . imm:s9 .. rn:5 rt:5 &ldapr_stlr_i -Steps to reproduce: -1. Run ARM target -2. Generate any ldapr_stlr_i instructions (for example: LDAPUR) -3. When the imm value is negative, the immediate calculation is done wrong. In case the calculation leads to an undefined location, QEMU will fail. -Additional information: -In trans_LDAPR_i (translate-a64.c), when imm field is negative, the value of a->imm will be 512-x instead of x. \ -I already fixed the issue by adding the s9 to the imm field. This made a call to sextend32 for imm instead of extend32 in the generated file build/libqemu-aarch64-softmmu.fa.p/decode-a64.c.inc diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2422 b/results/classifier/zero-shot-user-mode/output/instruction/2422 deleted file mode 100644 index eaaefc1d1..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2422 +++ /dev/null @@ -1,75 +0,0 @@ -instruction: 0.635 -runtime: 0.186 -syscall: 0.179 - - - -`vill` not set after reserved `vsetvli` instruction usage -Description of problem: -The ["AVL encoding" section of the RISC-V V Spec 1.0](https://github.com/riscv/riscv-isa-manual/blob/main/src/v-st-ext.adoc#avl-encoding) states that a `vsetvli x0,x0,...` that changes VLMAX is reserved and "Implementations may set `vill`" in this case. QEMU does not set `vill` in this case. Doing so would help detect code generation issues and non-portable code. - -Here is the quote from the spec: - -> When `rs1=x0` and `rd=x0`, the instruction operates as if the current -> vector length in `vl` is used as the AVL, and the resulting value is -> written to `vl`, but not to a destination register. This form can -> only be used when VLMAX and hence `vl` is not actually changed by the -> new SEW/LMUL ratio. Use of the instruction with a new SEW/LMUL ratio -> that would result in a change of VLMAX is reserved. -> Use of the instruction is also reserved if `vill` was 1 beforehand. -> Implementations may set `vill` in either case. - -Note, I have not checked QEMU's behaviour for the other case mentioned in the quote: "Use of the instruction is also reserved if `vill` was 1 beforehand". -Steps to reproduce: -1. Create `test.c` -```C -#include <assert.h> - -/* Position of vill in vtype. */ - -#define VILL_BIT (__riscv_xlen - 1) - -/* Return true if vill is 1. */ - -int vill_set_p () -{ - __UINT64_TYPE__ vtype; - asm volatile ("csrr %0, vtype" : "=r"(vtype)); - - return (vtype >> VILL_BIT) & 1; -} - -/* Return true if vill is 0. */ - -int vill_clear_p () -{ - return !vill_set_p (); -} - -int main () -{ - int vl; - - assert (vill_clear_p ()); - - /* Valid: vl = VLMAX. */ - asm volatile ("vsetvli %0,zero,e64,m8,ta,ma\n" : "=r"(vl)); - assert (vill_clear_p ()); - - /* Valid: vl and VLMAX not changed. */ - asm volatile ("vsetvli zero,zero,e64,m8,ta,ma\n"); - assert (vill_clear_p ()); - - /* Reserved: Reduce VLMAX. */ - asm volatile ("vsetvli zero,zero,e64,m1,ta,ma\n"); - assert (vill_set_p ()); - - return 0; -} -``` -2. Build `test.c` with `riscv32-unknown-elf-gcc test.c -o test -march=rv64gcv -mabi=lp64d` -3. Run qemu with `qemu-riscv64 -cpu rv64,v=true test` -4. The final assertion fails because executing the reserved `vsetvli` did not set `vill` -``` -assertion "vill_set_p ()" failed: file "test.c", line 40, function: main -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2474 b/results/classifier/zero-shot-user-mode/output/instruction/2474 deleted file mode 100644 index 30f4e9e68..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2474 +++ /dev/null @@ -1,102 +0,0 @@ -instruction: 0.381 -runtime: 0.334 -syscall: 0.285 - - - -x86_64: strange translation of "vpgatherqq" -Description of problem: -The translate of instruction "vpgatherqq" is confusing. - -It happens when register xmm4 is in the middle, like "vpgatherqq %xmmi,0x0(,%xmm4,1),%xmmj". -Steps to reproduce: -1. Make a simple embedded assembly code named test.c: -``` -int main() -{ - asm("vpgatherqq %xmm6,0x123(,%xmm2,4),%xmm7"); - asm("vpgatherqq %xmm6,0x123(,%xmm3,4),%xmm7"); - asm("vpgatherqq %xmm6,0x123(,%xmm4,4),%xmm7"); - asm("vpgatherqq %xmm6,0x123(,%xmm5,4),%xmm7"); - return 0; -} -``` -and compile it: -``` -gcc -o test test.c -static -``` - -2. Run it with QEMU, print the micro ops: -``` -qemu-x86_64 -d op -D a.out test -``` -We can get output like this (only contain vpgatherqq): -``` - ---- 000000000040174d 0000000000000000 - mov_i64 loc2,$0x123 - add_i64 loc14,env,$0x3d0 #This is xmm2 - add_i64 loc16,env,$0x4d0 - add_i64 loc18,env,$0x510 - call vpgatherqq_xmm,$0x0,$0,env,loc18,loc16,loc14,loc2,$0x2 - mov_vec v128,e8,tmp20,v128$0x0 - st_vec v128,e8,tmp20,env,$0x4e0 - mov_vec v128,e8,tmp22,v128$0x0 - st_vec v128,e8,tmp22,env,$0x520 - - ---- 0000000000401757 0000000000000000 - mov_i64 loc2,$0x123 - add_i64 loc23,env,$0x410 #This is xmm3 - add_i64 loc25,env,$0x4d0 - add_i64 loc26,env,$0x510 - call vpgatherqq_xmm,$0x0,$0,env,loc26,loc25,loc23,loc2,$0x2 - mov_vec v128,e8,tmp27,v128$0x0 - st_vec v128,e8,tmp27,env,$0x4e0 - mov_vec v128,e8,tmp28,v128$0x0 - st_vec v128,e8,tmp28,env,$0x520 - - ---- 0000000000401761 0000000000000000 - mov_i64 loc2,$0x123 - add_i64 loc29,env,$0x310 #This is xmm4 ??? - add_i64 loc31,env,$0x4d0 - add_i64 loc32,env,$0x510 - call vpgatherqq_xmm,$0x0,$0,env,loc32,loc31,loc29,loc2,$0x2 - mov_vec v128,e8,tmp33,v128$0x0 - st_vec v128,e8,tmp33,env,$0x4e0 - mov_vec v128,e8,tmp34,v128$0x0 - st_vec v128,e8,tmp34,env,$0x520 - - ---- 000000000040176b 0000000000000000 - mov_i64 loc2,$0x123 - add_i64 loc35,env,$0x490 #This is xmm5 - add_i64 loc37,env,$0x4d0 - add_i64 loc38,env,$0x510 - call vpgatherqq_xmm,$0x0,$0,env,loc38,loc37,loc35,loc2,$0x2 - mov_vec v128,e8,tmp39,v128$0x0 - st_vec v128,e8,tmp39,env,$0x4e0 - mov_vec v128,e8,tmp40,v128$0x0 - st_vec v128,e8,tmp40,env,$0x520 -``` -3. - -Since the register xmms are continuous within the structure CPUArchState, the offset of xmm2, xmm3, xmm4, xmm5 should be a arithmetic sequence. - -From the output, we can infer that the common difference should be 0x40 and the offset of xmm4 should be 0x450 but not 0x310. - -I used GDB to track it, the location where the change occurred is: - -target/i386/tcg/translate.c, gen_lea_modrm_0(), line 2215: -``` - if (rm == 4) { - int code = x86_ldub_code(env, s); - scale = (code >> 6) & 3; - index = ((code >> 3) & 7) | REX_X(s); - if (index == 4) { - index = -1; /* no index */ - } - base = (code & 7) | REX_B(s); - havesib = 1; - } -``` -This code turned 4 into -1, and -1 do explain the offset 0x310 (xmm0 has offset 0x350). -Additional information: -Monitoring the function "helper_vpgatherqq_xmm" can draw similar conclusions: it used wrong value but not xmm4. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2483 b/results/classifier/zero-shot-user-mode/output/instruction/2483 deleted file mode 100644 index 2645cac45..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2483 +++ /dev/null @@ -1,26 +0,0 @@ -instruction: 0.537 -runtime: 0.277 -syscall: 0.186 - - - -m68k: jsr (sp) doesn't work as expected -Description of problem: -Consider the following code (disassembly from ghidra). This copies the current `SP` to `A1` then copies 0x68 bytes from the address pointed at by `A0` to the address pointed at by `A1` with increment. This should end up with a copy of some bytes and `SP` pointing at the first. - -``` - ff8241e6 22 4f movea.l SP,A1 - ff8241e8 70 68 moveq #0x68,D0 - LAB_ff8241ea XREF[1]: ff8241ee(j) - ff8241ea 12 d8 move.b (A0)+,(A1)+ - ff8241ec 53 80 subq.l #0x1,D0 - ff8241ee 66 fa bne.b LAB_ff8241ea - ff8241f0 4e 97 jsr (SP) -``` - -`SP` is `0x3bfc` at the `jsr` so we'd expect to jump to `0x3bfc` and put the address to return to at `0x3bf8` so the `jsr` can return I think? -What currently happens in QEMU is the return address is put at `0xb3f8` and `PC` also becomes `0x3bf8` and the return address starts being executed as code and things go off the rails. - -Forgive the screenshot but this is what it looks like with GDB connected. Dumping the memory where the `PC` is shows that the return address is actually there and we can see there is garbage before the instructions it should be executing. - -{width=289 height=759} diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2485 b/results/classifier/zero-shot-user-mode/output/instruction/2485 deleted file mode 100644 index 01431ab6d..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2485 +++ /dev/null @@ -1,53 +0,0 @@ -instruction: 0.552 -runtime: 0.306 -syscall: 0.143 - - - -getifaddrs linked with musl libc hangs on big-endian targets -Description of problem: -When the following C program (borrowed from curl's `configure`) is compiled for { m68k, ppc, ppc64, s390x } (possibly others, like or1k and sparc) and linked against musl libc, it hangs inside musl when run. Copying the same binaries to real hardware results in success. - -```c -#include <stdlib.h> -#include <ifaddrs.h> - -int -main (void) -{ - - struct ifaddrs *ifa = 0; - int error; - - error = getifaddrs(&ifa); - if (error || !ifa) - exit(1); - else - exit(0); - - return 0; -} -``` -Steps to reproduce: -1. Compile the above program and link it with musl libc (pre-built toolchains are available [here](https://musl.cc/)) -2. Run the appropriate `qemu-*` (e.g. `qemu-m68k ./test` or `qemu-ppc ./test`) -3. Observe that the process hangs. -Additional information: -This has come up elsewhere: - -* https://bugs.gentoo.org/914256 -* https://www.openwall.com/lists/musl/2018/05/30/4 -* Likely affects or1k but I can't test that at the moment (need to debug an unrelated issue with that toolchain) -* Likely affects sparc but that port/toolchain is also a WIP - -Here are some static sample binaries for the above program: - -* https://temp.zv.io/qemu-bug.tar.xz (no guarantees of continued existence months or years later) - -GitLab labels seem to be missing: - -* ~"kind::Bug" -* ~"linux-user" -* ~"target: ppc" -* ~"target: m68k" -* ~"target: s390x" diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2486 b/results/classifier/zero-shot-user-mode/output/instruction/2486 deleted file mode 100644 index 7dda61177..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2486 +++ /dev/null @@ -1,18 +0,0 @@ -instruction: 0.463 -syscall: 0.304 -runtime: 0.232 - - - -RISC-V Regression: QEMU_CPU=f=false,zfinx=true gives misleading error message -Description of problem: -The f extension looks like it should be toggle-able using qemu_cpu since it doesn't throw error messages when specified. -Disabling the extension using f=false does not actually disable it as shown by the zfinx error message. -Eg. Unsupported extension is explicitly rejected -``` -> QEMU_CPU=rv64,j=false ./qemu-riscv64 test.out -qemu-riscv64: can't apply global rv64-riscv-cpu.j=false: Property 'rv64-riscv-cpu.j' not found -``` -Steps to reproduce: -1. Compile any riscv binary like: `int main() {}` -2. Execute using `QEMU_CPU=rv64,zfinx=true,f=false ./qemu-riscv64 test.out` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2495 b/results/classifier/zero-shot-user-mode/output/instruction/2495 deleted file mode 100644 index 60c640f21..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2495 +++ /dev/null @@ -1,78 +0,0 @@ -instruction: 0.380 -syscall: 0.314 -runtime: 0.306 - - - -A bug in x86-64 MMX instructions -Description of problem: -It seems QEMU emits invalid TCG when lifting MMX instructions with redundant REX prefixes. For example, when lifting `490f7ec0 (movq r8, mm0)`, QEMU generates the following valid TCG. - -``` - ---- 00000000004011f2 0000000000000000 - call enter_mmx,$0x0,$0,env - ld_i64 loc0,env,$0x270 - mov_i64 r8,loc0 - mov_i64 rip,$0x4011f6 - exit_tb $0x0 - set_label $L0 - exit_tb $0x7f84f82ec143 -``` - -However, after changing the value of the rex prefix to `4f` , so the instruction becomes `4f0f7ec0 (rex.WRXB movq r8, mm0)`, the lifted TCG is changed to: - -``` - ---- 00000000004011f2 0000000000000000 - call enter_mmx,$0x0,$0,env - ld_i64 loc0,env,$0x2f0 // The offset to MM0 is changed - mov_i64 r8,loc0 - mov_i64 rip,$0x4011f6 - exit_tb $0x0 - set_label $L0 - exit_tb $0x7f98e82ec143 -``` - -I have observed this bug in numerous MMX instructions. For example, `410fdaff (rex.B pminub mm7, mm7)` is lifted to the wrong TCGs. - -It seems this bug looks similar to #2474. -Steps to reproduce: -1. Write `test.c` -``` -#include <stdint.h> -#include <stdio.h> -#include <string.h> - -uint8_t i_R8[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; -uint8_t i_MM0[8] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; -uint8_t o_R8[8]; - -void __attribute__ ((noinline)) show_state() { - printf("R8: "); - for (int i = 0; i < 8; i++) { - printf("%02x ", o_R8[i]); - } - printf("\n"); -} - -void __attribute__ ((noinline)) run() { - __asm__ ( - ".intel_syntax noprefix\n" - "mov r8, qword ptr [rip + i_R8]\n" - "movq mm0, qword ptr [rip + i_MM0]\n" - ".byte 0x4f, 0x0f, 0x7e, 0xc0\n" - "mov qword ptr [rip + o_R8], r8\n" - ".att_syntax\n" - ); -} - -int main(int argc, char **argv) { - run(); - show_state(); - return 0; -} -``` -2. Compile `test.bin` using this command: `gcc-12 -O2 -no-pie ./test.c -o ./test.bin` -3. Run QEMU using this command: `qemu-x86_64 ./test.bin` -4. The program, runs on top of the buggy QEMU, prints the value of R8 as `00 00 00 00 00 00 00 00`. It should print `ff ff ff ff ff ff ff ff` after the bug is fixed. -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2497 b/results/classifier/zero-shot-user-mode/output/instruction/2497 deleted file mode 100644 index b2fe447fc..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2497 +++ /dev/null @@ -1,9 +0,0 @@ -instruction: 0.885 -runtime: 0.065 -syscall: 0.051 - - - -m68k: fpu: FPIAR register is not implemented -Description of problem: -QEMU doesn't currently implement the `FPIAR` register in the FPU which is fine in most cases but test code (like that in 147bug) that is testing if instructions like `fmove` are working correctly by writing to the register and reading it back don't get the value written when reading it back and detect a failure. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2498 b/results/classifier/zero-shot-user-mode/output/instruction/2498 deleted file mode 100644 index 620cc2c02..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2498 +++ /dev/null @@ -1,57 +0,0 @@ -instruction: 0.414 -runtime: 0.308 -syscall: 0.277 - - - -m68k: fpu: fmovem with multiple control registers has incorrect in memory order -Description of problem: -It looks like the order of reading/writing registers is currently incorrect for `fmovem` with multiple fpu control registers. - -According to the manual: - -``` -The -registers are always moved in the same order, regardless of the addressing mode -used; the floating-point control register is moved first, followed by the floating-point -status register, and the floating-point instruction address register is moved last. -``` - -Current QEMU reads/writes them in the reverse order which is fine for most things but the test cases in 147bug compare against data that is in its binary and expects the data generated in memory by the CPU to match what is in it's binary. - -Maybe something like this is needed: - -``` diff -commit 466e8ead0115b6535e89aa2715f171112444b294 (HEAD -> m68kdt) -Author: Daniel Palmer <daniel@thingy.jp> -Date: Tue Aug 13 09:52:54 2024 +0900 - - fix fmovem ordering - -diff --git a/target/m68k/translate.c b/target/m68k/translate.c -index 92dc9d8563..64ff2df06e 100644 ---- a/target/m68k/translate.c -+++ b/target/m68k/translate.c -@@ -4924,8 +4924,8 @@ static void gen_op_fmove_fcr(CPUM68KState *env, DisasContext *s, - */ - - if (is_write && mode == 4) { -- for (i = 2; i >= 0; i--, mask >>= 1) { -- if (mask & 1) { -+ for (i = 2; i >= 0; i--, mask <<= 1) { -+ if (mask & 0b100) { - gen_qemu_store_fcr(s, addr, 1 << i); - if (mask != 1) { - tcg_gen_subi_i32(addr, addr, opsize_bytes(OS_LONG)); -@@ -4934,8 +4934,8 @@ static void gen_op_fmove_fcr(CPUM68KState *env, DisasContext *s, - } - tcg_gen_mov_i32(AREG(insn, 0), addr); - } else { -- for (i = 0; i < 3; i++, mask >>= 1) { -- if (mask & 1) { -+ for (i = 2; i >= 0; i--, mask <<= 1) { -+ if (mask & 0b100) { - if (is_write) { - gen_qemu_store_fcr(s, addr, 1 << i); - } else { -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2499 b/results/classifier/zero-shot-user-mode/output/instruction/2499 deleted file mode 100644 index 501b58048..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2499 +++ /dev/null @@ -1,36 +0,0 @@ -instruction: 0.827 -runtime: 0.117 -syscall: 0.056 - - - -m68k: fpu: fsave/frestore should be enabled for 68020/68030 -Description of problem: -valid 68020/68030 code can use `fsave`/`frestore` instructions to save/restore the state of an external 68881/68882 but currently QEMU only allows these instructions on 68040 and everyone else gets an f-line exception. - -I guess something like this to allow frestore/fsave. m68k programmers reference manual says they are 68881/68882/68040 and there don's seem to be any differences. - -``` diff -diff --git a/target/m68k/translate.c b/target/m68k/translate.c -index d5d2322329..92dc9d8563 100644 ---- a/target/m68k/translate.c -+++ b/target/m68k/translate.c -@@ -5455,7 +5455,7 @@ DISAS_INSN(frestore) - gen_exception(s, s->base.pc_next, EXCP_PRIVILEGE); - return; - } -- if (m68k_feature(s->env, M68K_FEATURE_M68040)) { -+ if (m68k_feature(s->env, M68K_FEATURE_FPU)) { - SRC_EA(env, addr, OS_LONG, 0, NULL); - /* FIXME: check the state frame */ - } else { -@@ -5472,7 +5472,7 @@ DISAS_INSN(fsave) - return; - } - -- if (m68k_feature(s->env, M68K_FEATURE_M68040)) { -+ if (m68k_feature(s->env, M68K_FEATURE_FPU)) { - /* always write IDLE */ - TCGv idle = tcg_constant_i32(0x41000000); - DEST_EA(env, insn, OS_LONG, idle, NULL); -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2500 b/results/classifier/zero-shot-user-mode/output/instruction/2500 deleted file mode 100644 index b3781b8f2..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2500 +++ /dev/null @@ -1,10 +0,0 @@ -instruction: 0.913 -runtime: 0.064 -syscall: 0.022 - - - -m68k: mmu: 68030 mmu instructions are missing -Description of problem: -The 68030 has some mmu instructions like `pmove` that are only valid for the 68030 (and maybe the external mmu for the 68020??). -QEMU doesn't currently implement `pmove` and the encoding of `pmove` seems to be the same as an f-line instruction that should generate an f-line exception on everything except the 68030 so currently an f-line exception happens instead of the intended load/store to the mmu. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2504 b/results/classifier/zero-shot-user-mode/output/instruction/2504 deleted file mode 100644 index 891050ac5..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2504 +++ /dev/null @@ -1,13 +0,0 @@ -instruction: 0.582 -runtime: 0.277 -syscall: 0.141 - - - -linux-user: qemu-x86_64 run /bin/XX got some error on LoongArch machine -Description of problem: -on LoongArch host, chroot x86_64-rootfs then run 'ls' got some error. -Steps to reproduce: -[chrootlog.txt](/uploads/2b77e7d9216396491ef4dc42bf24acc0/chrootlog.txt) -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2505 b/results/classifier/zero-shot-user-mode/output/instruction/2505 deleted file mode 100644 index 84bcd660c..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2505 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.445 -runtime: 0.328 -syscall: 0.227 - - - -Interpreter ELF flags ignored when selecting CPU diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2525 b/results/classifier/zero-shot-user-mode/output/instruction/2525 deleted file mode 100644 index f918de4bc..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2525 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.484 -syscall: 0.313 -runtime: 0.203 - - - -bFLT triggers accel/tcg/user-exec.c:505: page_set_flags: Assertion `have_mmap_lock()' failed. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2536 b/results/classifier/zero-shot-user-mode/output/instruction/2536 deleted file mode 100644 index 3c4c106a4..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2536 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.666 -syscall: 0.230 -runtime: 0.105 - - - -Dynamic translation issue of arm instruction VFNMA and VFNMS diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2580 b/results/classifier/zero-shot-user-mode/output/instruction/2580 deleted file mode 100644 index 63814c27c..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2580 +++ /dev/null @@ -1,18 +0,0 @@ -instruction: 0.431 -runtime: 0.400 -syscall: 0.169 - - - -qemu-aarch64_be 9.1.0 fails to run any Linux programs due to unreachable in gdb_find_static_feature() -Description of problem: -``` -❯ cat empty.c -void _start() {} -❯ clang empty.c -target aarch64_be-linux -nostdlib -fuse-ld=lld -❯ qemu-aarch64_be ./a.out -** -ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached -Bail out! ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached -fish: Job 1, 'qemu-aarch64_be ./a.out' terminated by signal SIGABRT (Abort) -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2590 b/results/classifier/zero-shot-user-mode/output/instruction/2590 deleted file mode 100644 index 52a1c973c..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2590 +++ /dev/null @@ -1,29 +0,0 @@ -instruction: 0.664 -runtime: 0.228 -syscall: 0.108 - - - -qemu-x86_64: gdb doesn't read symbols from dynamically linked shared libraries. -Description of problem: -GDB fails to load dynamically linked shared libraries when connecting to qemu-x86_64, causing it to not recognize symbols from the shared libraries. As a result, breakpoints in shared library functions (e.g, `break printf`) do not work. -Steps to reproduce: -1. Start the debug server: `./qemu-x86_64 -g PORT ./x86_64-binary` -2. Connect GDB to the debug server: -``` -$ gdb-multiarch ./x86_64-binary -(gdb) set verbose on -(gdb) target remote :PORT -``` -3. GDB displays a warning and fails to load shared libraries: -``` -(gdb) target remote :PORT -Remote debugging using :PORT -warning: platform-specific solib_create_inferior_hook did not load initial shared libraries. -(gdb) info sharedlibrary -No shared libraries loaded at this time. -``` -Additional information: -This issue does not occur when using gdbserver on a native x86_64 machine and connecting to it from gdb-multiarch on an ARM64 machine, indicating the issue is likely related to QEMU rather than GDB. - -GDB correctly recognizes symbols from the target binary (e.g., the `main` function), and breakpoints at these symbols function as expected. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2592 b/results/classifier/zero-shot-user-mode/output/instruction/2592 deleted file mode 100644 index 1ecbba726..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2592 +++ /dev/null @@ -1,43 +0,0 @@ -instruction: 0.742 -runtime: 0.151 -syscall: 0.107 - - - -qemu-aarch64 cannot properly support some python functions from the `time` module -Description of problem: -When a function is run in python (for example, `time.time()`), python returns the following error: -``` -Traceback (most recent call last): - File "<string>", line 1, in <module> -OSError: [Errno 0] Error -``` -I am absolutely sure that this problem is related to `qemu-aarch64`, because the same python build works perfectly in aarch64 machine. In addition, python for arm architecture with `qemu-arm` does not have such a problem. -Steps to reproduce: -Note, this instruction specifies the stage of installation of that very python. But since it is compiled for Termux, you will have to use some scripts. -1. Create a simple codespace environment. -2. Run the following commands through the terminal: -``` -git clone https://github.com/termux-pacman/glibc-packages -cd glibc-packages -./get-build-package.sh -sudo mkdir /data -sudo chown codespace /data -sudo chgrp codespace /data -sudo apt update -sudo apt install patchelf -./scripts/setup-cgct.sh -``` -3. Run the following command. Note that the installation phase will start there. You should stop the script when the installation phase is complete. -``` -./build-package.sh -I -w --library glibc gpkg/gobject-introspection -``` -4. Install standard qemu via apt. -5. Run the following command: -``` -qemu-aarch64 /data/data/com.termux/files/usr/glibc/bin/python3.12 -c "import time; time.time()" -``` -Additional information: -- For some reason this error only occurs in the environment from GitHub. On my computer this error does not occur. - - Here is a log of one of the github actions, which shows an attempt to compile packages with python on different architectures - https://github.com/termux-pacman/glibc-packages/actions/runs/11023254502. -For reference, I use qemu for more flexible compilation of packages. And in github actions, qemu is installed here - https://github.com/termux-pacman/glibc-packages/blob/main/.github/workflows/build.yml#L35. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2595 b/results/classifier/zero-shot-user-mode/output/instruction/2595 deleted file mode 100644 index c74893c0e..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2595 +++ /dev/null @@ -1,141 +0,0 @@ -instruction: 0.344 -runtime: 0.344 -syscall: 0.312 - - - -Incorrect behavior with 64-bit element SDOT and UDOT instructions on ARM SVE when sve-default-vector-length>=64 -Description of problem: -The behavior of SDOT and UDOT instructions are incorrect when the Zresult.D register is used, which is the 64-bit svdot_lane\_{s,u}64 intrinsic in ACLE. - -I have tested the same code using [Arm Instruction Emulator](https://developer.arm.com/Tools%20and%20Software/Arm%20Instruction%20Emulator) (which is deprecated though) and gem5 which produced correct result, I believe that the SDOT and UDOT implementation in qemu is incorrect. -Steps to reproduce: -1. Get Arm Gnu toolchain from [Arm GNU Toolchain Downloads – Arm Developer](https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads), for x86 Linux hosts, download arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz and extract it. Alternatively, use any compiler that is able to cross compile for armv8.2-a+sve targets. -2. Compile the following program with these compiler arguments - - ``` - arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc -O3 -march=armv8.2-a+sve dot_lane.c -o dot_lane - ``` - - ```c - #include <stdio.h> - #include <arm_sve.h> - - int64_t a[32] = { 0 }; - int16_t b[128]; - int16_t c[128]; - int64_t r[32]; - int64_t expected_r[32]; - - #define IMM 0 - - int main(void) - { - for (size_t i = 0; i < 128; i++) { - b[i] = 1; - c[i] = i / 4; - } - - svint64_t av = svld1(svptrue_b64(), a); - svint16_t bv = svld1(svptrue_b16(), b); - svint16_t cv = svld1(svptrue_b16(), c); - - svint64_t result = svdot_lane_s64(av, bv, cv, IMM); - - svst1(svptrue_b64(), r, result); - - for (size_t i = 0; i < svcntd(); i++) { - expected_r[i] = - (int64_t)b[i * 4 + 0] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 0] + - (int64_t)b[i * 4 + 1] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 1] + - (int64_t)b[i * 4 + 2] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 2] + - (int64_t)b[i * 4 + 3] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 3] + - a[i]; - } - - printf("%12s", "r: "); - for (size_t i = 0; i < svcntd(); i++) { - printf("%4ld", r[i]); - } - printf("\n"); - printf("%12s", "expected_r: "); - for (size_t i = 0; i < svcntd(); i++) { - printf("%4ld", expected_r[i]); - } - printf("\n\t\t"); - for (size_t i = 0; i < svcntd(); i++) { - if (r[i] != expected_r[i]) { - printf("%4c", '^'); - } else { - printf("%4c", ' '); - } - } - printf("\n"); - printf("idx:\t\t"); - for (size_t i = 0; i < svcntd(); i++) { - if (r[i] != expected_r[i]) { - printf("%4d", i); - } else { - printf("%4c", ' '); - } - } - printf("\n"); - - return 0; - } - ``` -3. Execute it with the following commands: - - ``` - qemu-aarch64 -cpu max,sve-default-vector-length=16 -L arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/../aarch64-none-linux-gnu/libc dot_lane - ``` - - Change the value of `sve-default-vector-length` to 32, 64, 128, 256 and observe the outputs, we should see that for `sve-default-vector-length` \>= 64, the result is incorrect. - - `sve-default-vector-length=16` - - ``` - r: 0 0 - expected_r: 0 0 - - idx: - ``` - - `sve-default-vector-length=32` - - ``` - r: 0 0 8 8 - expected_r: 0 0 8 8 - - idx: - ``` - - `sve-default-vector-length=64` - - ``` - r: 0 0 8 8 8 8 24 24 - expected_r: 0 0 8 8 16 16 24 24 - ^ ^ - idx: 4 5 - ``` - - `sve-default-vector-length=128` - - ``` - r: 0 0 8 8 8 8 24 24 24 24 40 40 40 40 56 56 - expected_r: 0 0 8 8 16 16 24 24 32 32 40 40 48 48 56 56 - ^ ^ ^ ^ ^ ^ - idx: 4 5 8 9 12 13 - ``` - - `sve-default-vector-length=256` - - ``` - r: 0 0 8 8 8 8 24 24 24 24 40 40 40 40 56 56 56 56 72 72 72 72 88 88 88 88 104 104 104 104 120 120 - expected_r: 0 0 8 8 16 16 24 24 32 32 40 40 48 48 56 56 64 64 72 72 80 80 88 88 96 96 104 104 112 112 120 120 - ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ - idx: 4 5 8 9 12 13 16 17 20 21 24 25 28 29 - ``` -4. By passing `-S` to the compiler, we can see that sdot (or udot if using `svdot_lane_u64()`) is produced in assembly (`sdot z0.d, z1.h, z2.h[0]`), which is correct behavior according to [Intrinsics – Arm Developer](https://developer.arm.com/architectures/instruction-sets/intrinsics/svdot_lane%5B_s64%5D). -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2596 b/results/classifier/zero-shot-user-mode/output/instruction/2596 deleted file mode 100644 index 093f01572..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2596 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.379 -syscall: 0.327 -runtime: 0.294 - - - -linux-user elf parsing endianness issue (Invalid note in PT_GNU_PROPERTY) diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2598 b/results/classifier/zero-shot-user-mode/output/instruction/2598 deleted file mode 100644 index 93f83637a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2598 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.551 -syscall: 0.288 -runtime: 0.161 - - - -linux-user on riscv64 host: Unable to find a guest_base to satisfy all guest address mapping requirements 00000000-ffffffff diff --git a/results/classifier/zero-shot-user-mode/output/instruction/261 b/results/classifier/zero-shot-user-mode/output/instruction/261 deleted file mode 100644 index 1d9023948..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/261 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.427 -runtime: 0.349 -syscall: 0.224 - - - -broken signal handling in nios2 user-mode emulation diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2628 b/results/classifier/zero-shot-user-mode/output/instruction/2628 deleted file mode 100644 index 17f9d854e..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2628 +++ /dev/null @@ -1,26 +0,0 @@ -instruction: 0.611 -syscall: 0.276 -runtime: 0.113 - - - -dpkg-deb in userspace emulation crashes in compression routine (armv7, aarch64, s390) on some machines -Description of problem: -chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_s390x.deb Version - -dpkg-deb: error: subprocess was killed by signal (Aborted), core dumped - -chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_arm64.deb Version - -dpkg-deb: error: subprocess was killed by signal (Segmentation fault), core dumped - -chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_armhf.deb Version - -dpkg-deb: error: subprocess was killed by signal (Segmentation fault), core dumped -Steps to reproduce: -1. debootstrap --arch=arm64 stable /scratch/debian-stable -2. chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_arm64.deb Version -Additional information: -Working environment: Debian 12 x86_64 Linux 6.1.0-25-amd64 qemu 7.2.13 AMD E-450 APU - -chroot can be created on this machine, when transferred to the broken machine (including the qemu binary used for emulation) dpkg cannot extract packages and crashes diff --git a/results/classifier/zero-shot-user-mode/output/instruction/263 b/results/classifier/zero-shot-user-mode/output/instruction/263 deleted file mode 100644 index 6931cea5f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/263 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.662 -syscall: 0.208 -runtime: 0.130 - - - -readdir() returns NULL (errno=EOVERFLOW) for 32-bit user-static qemu on 64-bit host diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2647 b/results/classifier/zero-shot-user-mode/output/instruction/2647 deleted file mode 100644 index e91bd387a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2647 +++ /dev/null @@ -1,53 +0,0 @@ -instruction: 0.706 -syscall: 0.150 -runtime: 0.144 - - - -A code error in accel/tcg/user-exec.c -Description of problem: -accel/tcg/user-exec.c: -``` -static int probe_access_internal(CPUArchState *env, vaddr addr, - int fault_size, MMUAccessType access_type, - bool nonfault, uintptr_t ra) -{ - int acc_flag; - bool maperr; - - switch (access_type) { - case MMU_DATA_STORE: - acc_flag = PAGE_WRITE_ORG; - break; - case MMU_DATA_LOAD: - acc_flag = PAGE_READ; - break; - case MMU_INST_FETCH: - acc_flag = PAGE_EXEC; - break; - default: - g_assert_not_reached(); - } - - if (guest_addr_valid_untagged(addr)) { - int page_flags = page_get_flags(addr); - if (page_flags & acc_flag) { - if ((acc_flag == PAGE_READ || acc_flag == PAGE_WRITE) - && cpu_plugin_mem_cbs_enabled(env_cpu(env))) { - return TLB_MMIO; - } - return 0; /* success */ - } - maperr = !(page_flags & PAGE_VALID); - } else { - maperr = true; - } - - if (nonfault) { - return TLB_INVALID_MASK; - } - - cpu_loop_exit_sigsegv(env_cpu(env), addr, access_type, maperr, ra); -} -``` -The conditional judgment "acc_flag == PAGE_WRITE" seems to have an issue, because acc_flag can only be PAGE_WRITE_ORG, PAGE_READ or PAGE_EXEC from the previous code. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2655 b/results/classifier/zero-shot-user-mode/output/instruction/2655 deleted file mode 100644 index 3594694c2..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2655 +++ /dev/null @@ -1,45 +0,0 @@ -instruction: 0.626 -runtime: 0.246 -syscall: 0.128 - - - -A problem in target/riscv/vector_helper.c: vext_ldff() -Description of problem: -I‘m confused about a behavior in function vext_ldff() in target/riscv/vector_helper.c: -``` -static inline void -vext_ldff(...) -{ -... - for (i = env->vstart; i < env->vl; i++) { -... - if (i == 0) { - probe_pages(env, addr, nf << log2_esz, ra, MMU_DATA_LOAD); - } else { -... - flags = probe_access_flags(env, addr, offset, MMU_DATA_LOAD, - mmu_index, true, &host, 0); -... - if (flags & ~TLB_WATCHPOINT) { - vl = i; - goto ProbeSuccess; - } -... - } - } -ProbeSuccess: -... -} -``` -If the current instruction has a memory callback by plugin, the function probe_access_flags() will return TLB_MMIO when the page is exist. - -In this case, the function will always set vl to 1, goto ProbeSuccess, and only load the first element. Does it meet expectations? - -This problem occurred in both linux-user mode and full-system mode. - -Maybe we can add extra parameter to probe_access_flags(), in order to change the behavior of inner functions. -Steps to reproduce: -1. Make a binary with instruction vle(x)ff.v, what I am using is https://github.com/chipsalliance/riscv-vector-tests. -2. Write a plugin to add memory callbacks. -3. Observe the behavior of the function. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/266 b/results/classifier/zero-shot-user-mode/output/instruction/266 deleted file mode 100644 index 3a66c9632..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/266 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.894 -syscall: 0.062 -runtime: 0.044 - - - -'mtfsf' instruction can clear FI incorrectly diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2672 b/results/classifier/zero-shot-user-mode/output/instruction/2672 deleted file mode 100644 index 6580108ed..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2672 +++ /dev/null @@ -1,26 +0,0 @@ -instruction: 0.805 -runtime: 0.108 -syscall: 0.087 - - - -Skipping a jal instruction in riscv64 baremetal emulation -Description of problem: -The binary contains an illegal instruction after a jal. Normally the jal should be taken but the illegal instructi[aia_tests2.elf](/uploads/b8b646b01d7bcc15b51c36ddbffacac7/aia_tests2.elf)on next to the jal is executed generating and illegal instruction exception: - -``` -0x80006070: 00200513 addi a0,zero,2 -0x80006074: 89cff0ef jal ra,-3940 # 0x80005110 - ----------------- -IN: _Z15int_switch_modehh -0x80006078: 0000 illegal - ----------------- -IN: mtvec_table -0x8000e600: 64d0406f j 20044 # 0x8001344c -``` -Steps to reproduce: -1. Execute the same binary with QEMU. -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2683 b/results/classifier/zero-shot-user-mode/output/instruction/2683 deleted file mode 100644 index 349beb581..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2683 +++ /dev/null @@ -1,45 +0,0 @@ -instruction: 0.673 -runtime: 0.166 -syscall: 0.161 - - - -TCG: probe_access() has inconsistent behavior -Description of problem: -In full-system mode, probe_access() will return NULL when the flag is TLB_MMIO. - -accel/tcg/cputlb.c: probe_access_internal() -``` - if (unlikely(flags & ~(TLB_WATCHPOINT | TLB_NOTDIRTY | TLB_CHECK_ALIGNED)) - || (access_type != MMU_INST_FETCH && force_mmio)) { - *phost = NULL; - return TLB_MMIO; - } -``` -But in linux-user mode, it will return correct address when the flag is TLB_MMIO. - -accel/tcg/user-exec.c: probe_access() -``` - return size ? g2h(env_cpu(env), addr) : NULL; -``` -This will lead to some different behaviors, like cbo.zero in RISC-V. - -target/riscv/op_helper.c: helper_cbo_zero() -``` - mem = probe_write(env, address, cbozlen, mmu_idx, ra); - - if (likely(mem)) { - memset(mem, 0, cbozlen); - } else { - for (int i = 0; i < cbozlen; i++) { - cpu_stb_mmuidx_ra(env, address + i, 0, mmu_idx, ra); - } - } -``` -When the current instruction has memory callback by plugin: - -Full-system mode uses slow-path(cpu_stb_mmuidx_ra) and inject mem_cbs correctly. - -Linux-user mode uses fast-path(memset) and doesn't inject callbacks. - -To ensure consistent results, probe_access() should return NULL when the flag is TLB_MMIO in linux-user mode. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2696 b/results/classifier/zero-shot-user-mode/output/instruction/2696 deleted file mode 100644 index 43f5a4ab5..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2696 +++ /dev/null @@ -1,18 +0,0 @@ -instruction: 0.656 -runtime: 0.197 -syscall: 0.147 - - - -qemu-hexagon 9.2.0-rc1 hits unreachable assertion in decode_insns() on invalid instruction -Description of problem: -``` -❯ cat start.s -.globl _start -_start: .word 0 -❯ clang start.s -target hexagon-linux -nostdlib -fuse-ld=lld -❯ qemu-hexagon ./a.out -** -ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached -Bail out! ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2738 b/results/classifier/zero-shot-user-mode/output/instruction/2738 deleted file mode 100644 index c503b3b60..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2738 +++ /dev/null @@ -1,16 +0,0 @@ -instruction: 0.496 -syscall: 0.256 -runtime: 0.247 - - - -golang 1.23 build hangs when running under qemu-user on x86_64 host -Description of problem: -Forwarded from https://github.com/golang/go/issues/70329. - -# -Steps to reproduce: -1. Setup qemu-user binfmt for a foreign ISA, for example, installs qemu-user-static-aarch64 on Fedora. -2. Build the Dockerfile for specified arch: `podman build --arch aarch64 .` -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/275 b/results/classifier/zero-shot-user-mode/output/instruction/275 deleted file mode 100644 index b4f48cd5e..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/275 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.510 -syscall: 0.328 -runtime: 0.162 - - - -Error in user-mode calculation of ELF aux vector's AT_PHDR diff --git a/results/classifier/zero-shot-user-mode/output/instruction/276 b/results/classifier/zero-shot-user-mode/output/instruction/276 deleted file mode 100644 index 9f23e4749..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/276 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.530 -syscall: 0.265 -runtime: 0.205 - - - -Error in user-mode calculation of ELF program's brk diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2761 b/results/classifier/zero-shot-user-mode/output/instruction/2761 deleted file mode 100644 index dde7fe90f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2761 +++ /dev/null @@ -1,14 +0,0 @@ -instruction: 0.663 -runtime: 0.208 -syscall: 0.129 - - - -Emulation of x86_64 binary on ARM64 fails with "Unable to find a guest_base to satisfy all guest address mapping requirements" -Description of problem: -Virtualisation fails with error "Unable to find a guest_base to satisfy all guest address mapping requirements" - -``` -file /nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash -/nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.10.0, BuildID[sha1]=2938b076ebbc4ea582b8eb1ea5c3f65d7a1b6261, stripped -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2775 b/results/classifier/zero-shot-user-mode/output/instruction/2775 deleted file mode 100644 index 01b542c4a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2775 +++ /dev/null @@ -1,140 +0,0 @@ -instruction: 0.360 -runtime: 0.349 -syscall: 0.291 - - - -internal assertion failure in sparc64 codegen: translate.c:5695:sparc_tr_insn_start: code should not be reached -Description of problem: -qemu crashes with internal assertion: - -ERROR:../target/sparc/translate.c:5695:sparc_tr_insn_start: code should not be reached -Steps to reproduce: -1. boot emulated NetBSD/sparc64 system -2. cd /usr/tests && atf-run|atf-report - -not 100% reproducable, but happens often -Additional information: -last output: -``` -IN: -0x4102ce80: sethi %hi(0x29e0000), %g1 -0x4102ce84: b,a 0x40d78220 - ----------------- -IN: -0x41029fc0: sethi %hi(0x1e30000), %g1 -0x41029fc4: b,a 0x40e9ccc0 - ----------------- -IN: -0x4102b5e0: sethi %hi(0x23b8000), %g1 -0x4102b5e4: b,a 0x40e9dc20 - ----------------- -IN: -0x4102a6e0: sethi %hi(0x1ff8000), %g1 -0x4102a6e4: b,a 0x40e9cbc0 - ----------------- -IN: -0x410230e0: sethi %hi(0x278000), %g1 -0x410230e4: b,a 0x40e25d60 - ----------------- -IN: -0x41026920: sethi %hi(0x1088000), %g1 -0x41026924: b,a 0x40d77da0 - ----------------- -IN: -0x41024140: sethi %hi(0x690000), %g1 -0x41024144: b,a 0x40e25f00 - ----------------- -IN: -0x00245c20: sethi %hi(0xc8000), %g1 -0x00245c24: sethi %hi(0x40d77c00), %g1 -0x00245c28: jmp %g1 + 0x1a0 ! 0x40d77da0 -0x00245c2c: nop - ----------------- -IN: -0x00245ba0: sethi %hi(0xa8000), %g1 -0x00245ba4: b,a %xcc, 0x245920 - ----------------- -IN: -0x00245ba0: sethi %hi(0xa8000), %g1 -0x00245ba4: sethi %hi(0x40d76c00), %g1 -0x00245ba8: jmp %g1 + 0x80 ! 0x40d76c80 -0x00245bac: nop - ----------------- -IN: -0x00245e60: sethi %hi(0x158000), %g1 -0x00245e64: b,a %xcc, 0x245920 - ----------------- -IN: -0x00245e60: sethi %hi(0x158000), %g1 -0x00245e64: sethi %hi(0x40d76400), %g1 -0x00245e68: jmp %g1 + 0x260 ! 0x40d76660 -0x00245e6c: nop - ----------------- -IN: -0x002465a0: sethi %hi(0x328000), %g1 -0x002465a4: sethi %hi(0x40d69000), %g1 -0x002465a8: jmp %g1 + 0x198 ! 0x40d69198 -0x002465ac: nop - -** -ERROR:../target/sparc/translate.c:5695:sparc_tr_insn_start: code should not be reached -``` - -gdb says: -``` -#0 0x000079343d6ebbfa in _lwp_kill () from /usr/lib/libc.so.12 -#1 0x000079343d6f7034 in abort () - at /home/martin/current/src/lib/libc/stdlib/abort.c:74 -#2 0x000079343e06a03a in g_assertion_message[cold] () - from /usr/pkg/lib/libglib-2.0.so.0 -#3 0x000079343e03c719 in g_assertion_message_expr () - from /usr/pkg/lib/libglib-2.0.so.0 -#4 0x0000000000a23345 in sparc_tr_insn_start (dcbase=<optimized out>, - cs=<optimized out>) at ../target/sparc/translate.c:5695 -#5 0x0000000000aa932f in translator_loop (cpu=cpu@entry=0x7933fac3be40, - tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, - max_insns=max_insns@entry=0x7933fa5d3d44, pc=pc@entry=1206519, - host_pc=host_pc@entry=0x7933f52a58f7, - ops=ops@entry=0xfac3c0 <sparc_tr_ops>, db=db@entry=0x7933fa5d3b80) - at ../accel/tcg/translator.c:152 -#6 0x0000000000a368ca in gen_intermediate_code (cs=cs@entry=0x7933fac3be40, - tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, - max_insns=max_insns@entry=0x7933fa5d3d44, pc=pc@entry=1206519, - host_pc=host_pc@entry=0x7933f52a58f7) at ../target/sparc/translate.c:5816 -#7 0x0000000000aa7e90 in setjmp_gen_code (env=env@entry=0x7933fac3e5e0, - tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, - pc=pc@entry=1206519, host_pc=0x7933f52a58f7, - max_insns=max_insns@entry=0x7933fa5d3d44, ti=<optimized out>) - at ../accel/tcg/translate-all.c:278 -#8 0x0000000000aa835d in tb_gen_code (cpu=cpu@entry=0x7933fac3be40, - pc=pc@entry=1206519, cs_base=cs_base@entry=1206523, flags=2181038080, - cflags=cflags@entry=-16777216) at ../accel/tcg/translate-all.c:358 -#9 0x0000000000aa135b in cpu_exec_loop (cpu=cpu@entry=0x7933fac3be40, - sc=sc@entry=0x7933fa5d3e80) at ../accel/tcg/cpu-exec.c:993 -#10 0x0000000000aa1788 in cpu_exec_setjmp (cpu=cpu@entry=0x7933fac3be40, - sc=sc@entry=0x7933fa5d3e80) at ../accel/tcg/cpu-exec.c:1039 -#11 0x0000000000aa1f8d in cpu_exec (cpu=cpu@entry=0x7933fac3be40) - at ../accel/tcg/cpu-exec.c:1065 -#12 0x0000000000abb53d in tcg_cpu_exec (cpu=cpu@entry=0x7933fac3be40) - at ../accel/tcg/tcg-accel-ops.c:78 -#13 0x0000000000abb6ae in mttcg_cpu_thread_fn (arg=arg@entry=0x7933fac3be40) - at ../accel/tcg/tcg-accel-ops-mttcg.c:95 -#14 0x0000000000c7f750 in qemu_thread_start (args=0x79343aef7520) - at ../util/qemu-thread-posix.c:541 -#15 0x000079343d98c145 in pthread__create_tramp (cookie=0x79343c583000) - at /home/martin/current/src/lib/libpthread/pthread.c:595 -#16 0x000079343d5d1310 in ?? () from /usr/lib/libc.so.12 -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/280 b/results/classifier/zero-shot-user-mode/output/instruction/280 deleted file mode 100644 index 2a8ff5210..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/280 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.457 -runtime: 0.322 -syscall: 0.222 - - - -(ARM64) qemu-x86_64+schroot(Debian bullseye) can't run chrome and can't load HTML diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2802 b/results/classifier/zero-shot-user-mode/output/instruction/2802 deleted file mode 100644 index 28c9620b2..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2802 +++ /dev/null @@ -1,32 +0,0 @@ -instruction: 0.829 -syscall: 0.093 -runtime: 0.079 - - - -Sparc: fdtox/fqtox instructions incorrectly select destination register -Description of problem: -This bug report is mostly for informational purposes as I will be posting a fix for the bug. - -The `fdtox` and `fqtox` instructions incorrectly select the destination register when the destination register is higher than `f31`. -Steps to reproduce: -1. Install Sparc cross compiler `gcc-12-sparc64-linux-gnu`(in Debian) -2. Compile the test program using `sparc64-linux-gnu-gcc-12 -m64 -o test_program -static test_program.c` -3. Run the test program using `qemu-sparc64-static ./test_program` -4. Expected output is 60. Prints 0 instead. -Additional information: -Test program to test the issue: - -```c -#include <stdio.h> - -int main(int argc, char** argv) { - long long truncated = 0; - __asm__("fdtox %0,%%f32\n\t" :: "f"(60.0)); - __asm__("fmovd %%f32,%0\n\t" : "=f"(truncated)); - printf("%lld\n", truncated); - return 0; -} -``` - -The issue is caused by the commit 0bba7572d4. Where certain changes were made in the way destination registers are selected(moving the DFPREG/QFPREG to decodetree). diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2825 b/results/classifier/zero-shot-user-mode/output/instruction/2825 deleted file mode 100644 index cd9ba3ad7..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2825 +++ /dev/null @@ -1,43 +0,0 @@ -instruction: 0.609 -runtime: 0.267 -syscall: 0.125 - - - -execveat with file descriptor and empty filename returns ENOENT when cross architectures -Description of problem: -On my x86_64 debian host (with binfmt_misc configured), when calling execveat with a fd , and empty pathname "", and flag AT_EMPTY_PATH. Then only x86_64 and x86 can be called normally, while programs of other architectures (arm64, arm, riscv64, etc.) will return ENOENT errors. - -I first encountered this problem when trying to run lxc-attach with qemu-aarch64. Its reference is [lxc/stable-6.0/src/include/fexecve.c#L30](https://github.com/lxc/lxc/blob/stable-6.0/src/include/fexecve.c#L30), which is the implementation of the fexecve function. So I wrote a simple test and compiled it with `x86_64/aarch64-linux-gnu-gcc -static test.c -o test`. execveat works fine when running natively or using qemu-x86_64/qemu-i386. When running versions for other architectures, using AT_EMPTY_PATH will result in ENOENT (No such file or directory); use /proc/self/fd/%d as the pathname and execve, it will work fine (like the rest part of the fexecve function). If binfmt_misc is turned off and run forign architectures ver, both calls will result in ENOEXEC (Exec format error). -Steps to reproduce: -1. Install qemu-user and binfmt_misc. Install gcc-aarch64-linux-gnu/gcc-riscv64-linux-gnu etc. -2. Compile test.c with host gcc, then compile forign architectures ver with gcc-aarch64-linux-gnu/gcc-riscv64-linux-gnu etc. like `gcc -static test.c -o test` and `aarch64-linux-gnu-gcc -static test.c -o test-aarch64` -3. Run different versions of test -4. To disable/enable binfmt, you can `echo 0 > /proc/sys/fs/binfmt_misc/qemu-aarch64` or `echo 1 > /proc/sys/fs/binfmt_misc/qemu-aarch64` -5. Sample outputs - -``` -rrex@debian:~/Downloads$ ./test -****Running to prepare execve -fd=3 -File size: 772296 bytes - -execveat with AT_EMPTY_PATH: -**Running in execve - -execveat with fd path: /proc/self/fd/3 -**Running in execve - -rrex@debian:~/Downloads$ qemu-aarch64 ./test-aarch64 -****Running to prepare execve -fd=3 -File size: 706104 bytes - -execveat with AT_EMPTY_PATH: -!!execveat a fd failed with errno: No such file or directory - -execveat with fd path: /proc/self/fd/3 -**Running in execve -``` -Additional information: -# diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2846 b/results/classifier/zero-shot-user-mode/output/instruction/2846 deleted file mode 100644 index ece517f99..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2846 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.363 -syscall: 0.331 -runtime: 0.306 - - - -linux-user hangs if fd_trans_lock is held during fork diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2865 b/results/classifier/zero-shot-user-mode/output/instruction/2865 deleted file mode 100644 index 78cf436fa..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2865 +++ /dev/null @@ -1,58 +0,0 @@ -instruction: 0.821 -syscall: 0.096 -runtime: 0.083 - - - -loongarch64: wrong implementation of `xvldi` instruction -Description of problem: -Consider this sample program. - -```c++ -#include <cstdio> -#include <cstdint> -#include <lsxintrin.h> -#include <lasxintrin.h> - -void dump_u32(__m256i x) { - uint32_t tmp[32/4]; - __lasx_xvst(x, tmp, 0); - putchar('['); - for (int i=0; i < 32/4; i++) { - if (i > 0) { - putchar(' '); - } - - printf("%08x", tmp[i]); - } - puts("]"); -} - -int main() { - __m256i const1 = __lasx_xvldi(-3832); - dump_u32(const1); -} -``` - -The magic constants here means: replicate in 32-bit words a byte (0x4) shifted left by 8. We should have a vector of words 0x800, and indeed, the program run on a real hardware prints expected: - -``` -[00000800 00000800 00000800 00000800 00000800 00000800 00000800 00000800] -``` - -The same program run under Qemu prints: - -``` -[08000800 00000000 08000800 00000000 08000800 00000000 08000800 00000000] -``` -Additional information: -I grabbed the latest sources, it seems there's bug in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`, in function `vldi_get_value`. - -```c - case 1: - /* data: {2{16'0, imm[7:0], 8'0}} */ - data = (t << 24) | (t << 8); - break; -``` - -There should be `(t << (8+32)) | t << 8`. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2971 b/results/classifier/zero-shot-user-mode/output/instruction/2971 deleted file mode 100644 index 9d9b4ed13..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/2971 +++ /dev/null @@ -1,50 +0,0 @@ -instruction: 0.525 -runtime: 0.324 -syscall: 0.151 - - - -loongarch64 crashes caused by lenient instruction decoding of vldi and xvldi -Description of problem: -Lenient instruction decoding of `vldi` and `xvldi` leads to Qemu crashes. - -The decoding of `vldi` and `xvldi` instruction allows for instructions with illegal immediates. - -`target/loongarch/insns.decode`: - -``` -vldi 0111 00111110 00 ............. ..... @v_i13 -xvldi 0111 01111110 00 ............. ..... @v_i13 -``` - -This is considered in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`: - -```C - /* - * imm bit [11:8] is mode, mode value is 0-12. - * other values are invalid. - */ -``` - -However, an assertion error is raised when this condition is violated and qemu crashes: - -``` -** -ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached -Bail out! ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached -``` - -On hardware (Loongson 3A5000), these instructions cause a SIGILL. -Steps to reproduce: -1. compile the `test_inv_vldi` test program for loongarch64 (see additional information) -2. run `qemu-loongarch64-static ./test_inv_vldi` -Additional information: -I will post a patch for this issue to the mailing list soon. - -`test_inv_vldi` source code: - -```C -int main(int argc, char** argv) { - asm volatile(".4byte 0x73e3a000"); -} -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/306 b/results/classifier/zero-shot-user-mode/output/instruction/306 deleted file mode 100644 index 6a632a749..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/306 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.499 -syscall: 0.331 -runtime: 0.170 - - - -Option to constrain linux-user exec() to emulated CPU only diff --git a/results/classifier/zero-shot-user-mode/output/instruction/311 b/results/classifier/zero-shot-user-mode/output/instruction/311 deleted file mode 100644 index c7c69ba07..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/311 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.354 -runtime: 0.331 -syscall: 0.315 - - - -qemu user mode: rt signals not implemented for sparc guests diff --git a/results/classifier/zero-shot-user-mode/output/instruction/312 b/results/classifier/zero-shot-user-mode/output/instruction/312 deleted file mode 100644 index 58a162018..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/312 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.836 -runtime: 0.094 -syscall: 0.069 - - - -QEMU emulation of fmadds instruction on powerpc64le is buggy diff --git a/results/classifier/zero-shot-user-mode/output/instruction/333 b/results/classifier/zero-shot-user-mode/output/instruction/333 deleted file mode 100644 index df76a0b5d..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/333 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.767 -runtime: 0.123 -syscall: 0.110 - - - -random errors on aarch64 when executing __aarch64_cas8_acq_rel diff --git a/results/classifier/zero-shot-user-mode/output/instruction/361 b/results/classifier/zero-shot-user-mode/output/instruction/361 deleted file mode 100644 index 8e05d355e..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/361 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.804 -syscall: 0.105 -runtime: 0.091 - - - --cpu host results in unsupported AVX512 instructions diff --git a/results/classifier/zero-shot-user-mode/output/instruction/364 b/results/classifier/zero-shot-user-mode/output/instruction/364 deleted file mode 100644 index 4e5b0c585..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/364 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.857 -syscall: 0.074 -runtime: 0.069 - - - -qemu-aarch64: incorrect signed comparison in ldsmax instructions diff --git a/results/classifier/zero-shot-user-mode/output/instruction/381 b/results/classifier/zero-shot-user-mode/output/instruction/381 deleted file mode 100644 index 5cdd062a2..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/381 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.591 -syscall: 0.233 -runtime: 0.176 - - - -ERROR:target/arm/translate-a64.c:13229:disas_simd_two_reg_misc_fp16: code should not be reached diff --git a/results/classifier/zero-shot-user-mode/output/instruction/390 b/results/classifier/zero-shot-user-mode/output/instruction/390 deleted file mode 100644 index 6494fa94f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/390 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.908 -syscall: 0.048 -runtime: 0.044 - - - -target/ppc: atomic path of Load Quadword instruction require address with write permission diff --git a/results/classifier/zero-shot-user-mode/output/instruction/419 b/results/classifier/zero-shot-user-mode/output/instruction/419 deleted file mode 100644 index f285d3488..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/419 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.379 -runtime: 0.346 -syscall: 0.275 - - - -bsd-user dumps core for all binaries emulated diff --git a/results/classifier/zero-shot-user-mode/output/instruction/422 b/results/classifier/zero-shot-user-mode/output/instruction/422 deleted file mode 100644 index ce0d3136f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/422 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.688 -runtime: 0.205 -syscall: 0.106 - - - -Unable to execute MIPS MSA code due to illegal instruction diff --git a/results/classifier/zero-shot-user-mode/output/instruction/427 b/results/classifier/zero-shot-user-mode/output/instruction/427 deleted file mode 100644 index 17e59b087..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/427 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.845 -runtime: 0.083 -syscall: 0.073 - - - -TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction diff --git a/results/classifier/zero-shot-user-mode/output/instruction/442 b/results/classifier/zero-shot-user-mode/output/instruction/442 deleted file mode 100644 index f397cdcf1..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/442 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.388 -runtime: 0.333 -syscall: 0.279 - - - -Firebird crashes on qemu-m68k-user with pthread_mutex_init error diff --git a/results/classifier/zero-shot-user-mode/output/instruction/447 b/results/classifier/zero-shot-user-mode/output/instruction/447 deleted file mode 100644 index 9d132b523..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/447 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.787 -syscall: 0.158 -runtime: 0.055 - - - -qemu-arm: Unable to reserve 0xffff0000 bytes of virtual address space at 0x1000 (Success) for use as guest address space (check yourvirtual memory ulimit setting, min_mmap_addr or reserve less using -R option) diff --git a/results/classifier/zero-shot-user-mode/output/instruction/456 b/results/classifier/zero-shot-user-mode/output/instruction/456 deleted file mode 100644 index eaa7f66be..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/456 +++ /dev/null @@ -1,35 +0,0 @@ -instruction: 0.490 -runtime: 0.340 -syscall: 0.170 - - - -Qemu User (x86_64) Hangs after futex function not implemented error -Description of problem: -Qemu User hangs on futex call with the following last strace -``` -futex(0x0000004001a01654,FUTEX_PRIVATE_FLAG|FUTEX_UNLOCK_PI,0,NULL,NULL,0) = -1 errno=38 (Function not implemented) -``` -This is the last call until giving a SIGINT with CTRL + C where the following strace is output -``` -futex(0x00000040b0085180,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,2,NULL,NULL,0) = -1 errno=4 (Interrupted system call) ---- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL, si_pid=0, si_uid=0} --- - -``` -Steps to reproduce: -1. Install steamcmd https://developer.valvesoftware.com/wiki/SteamCMD -2. In the steamcmd shell install Valheim dedicated server with `app_update 896660` -3. Navigate to the downloaded app `cd ~/Steam/steamapps/common/Valheim\ dedicated\ server/` -4. Run `qemu-x86_64 valheim_server.x86_64` -5. The process hangs as per description. -Additional information: -The issue was originally encountered on a raspberry pi ARM64 host using the ubuntu 5.2.0 version of qemu. Installed cross libararies: -* libc6-amd64-cross -* libgcc-s1-amd64-cross - -It was then replicated on the x86 host fedora with a build of the qemu master branch. -The full qemu -strace output is provided below -[qemu_strace_output.log](/uploads/96e0e31b1e63191a94d73f05023c5173/qemu_strace_output.log) - -The expected output found when running `strace ./valheim_server.x86_64` without qemu on the x86_64 host is attached below -[expected_output.log](/uploads/b3b25618103de8a3b9c0ef227bbffc9c/expected_output.log) diff --git a/results/classifier/zero-shot-user-mode/output/instruction/494 b/results/classifier/zero-shot-user-mode/output/instruction/494 deleted file mode 100644 index 02b0cad16..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/494 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.595 -runtime: 0.296 -syscall: 0.109 - - - -cmake crashes on qemu-alpha-user with Illegal Instruction diff --git a/results/classifier/zero-shot-user-mode/output/instruction/508 b/results/classifier/zero-shot-user-mode/output/instruction/508 deleted file mode 100644 index 0eb2ff71c..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/508 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.715 -syscall: 0.187 -runtime: 0.098 - - - -x86_64 cmpxchg behavior in qemu tcg does not match the real CPU diff --git a/results/classifier/zero-shot-user-mode/output/instruction/514 b/results/classifier/zero-shot-user-mode/output/instruction/514 deleted file mode 100644 index b9dbd2db7..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/514 +++ /dev/null @@ -1,31 +0,0 @@ -instruction: 0.720 -runtime: 0.146 -syscall: 0.134 - - - -MTE reports false positive for "str" instruction with the SP as the base register. -Description of problem: -When PE executes "sp"-based store instruction with offset I got tag check fault exception. But according to arm spec. load or store that uses "sp" register should generate Tag Unchecked access. -Steps to reproduce: -Clang version: clang version 12.0.1. -I compiled my code using "-target aarch64-linux -march=armv8+memtag -fsanitize=memtag" for Clang. Clang generates following code: -``` -0000000000000c14 <test_func>: - c14: a9bc7bfd stp x29, x30, [sp, #-64]! - c18: f9000bf7 str x23, [sp, #16] - ... -``` -Whole stack was mapped in translation tables as Tagged memory."SCTLR" register was configured to trigger synchronous exception on tag mismatch. -When cpu executes firs instruction "stp x29, x30, [sp, #-64]!" I got tag check fault exception: "0b010001 When FEAT_MTE is implemented Synchronous Tag Check Fault": -ESR_EL1=0x96000051. - -According to ARM specification load or store that uses "sp" register should generate Tag Unchecked access: -``` -A Tag Unchecked access will be generated for a load or store that uses either of the following: -• A base register only, with the SP as the base register. -• A base register plus immediate offset addressing form, with the SP as the base register. -``` -Looks like qemu erroneously generates tag mismatch exceptions for SP-based loads and stores with immediate offset. -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/562107 b/results/classifier/zero-shot-user-mode/output/instruction/562107 deleted file mode 100644 index 1bcdb2d18..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/562107 +++ /dev/null @@ -1,18 +0,0 @@ -instruction: 0.420 -syscall: 0.329 -runtime: 0.252 - - - -QEmu GDB stub uses IPv6 instead of v4 (or both) - -This bug has been reported by several people already. - -See http://migeel.sk/blog/2009/04/21/gdb-and-qemu-on-windows/ -and http://qemu-forum.ipi.fi/viewtopic.php?f=5&t=5579&p=16248&hilit=gdb+ipv6#p16248 - - -Seems like a very easy fix. - -Regards, -Matthijs ter Woord \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/577 b/results/classifier/zero-shot-user-mode/output/instruction/577 deleted file mode 100644 index f3eb3aeb5..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/577 +++ /dev/null @@ -1,31 +0,0 @@ -instruction: 0.516 -syscall: 0.243 -runtime: 0.241 - - - -getdtablesize() returns wrong value in qemu user mode on Linux/alpha -Description of problem: -The `getdtablesize()` function returns a value that is too large. Namely, `getdtablesize() - 1` ought to be a valid file descriptor, but is not. -Steps to reproduce: -[foo.c](/uploads/7a9e99d3811fe4a7eef183ed98c966a4/foo.c) - -1. -``` -# apt install g++-10-alpha-linux-gnu -``` -2. -``` -$ alpha-linux-gnu-gcc-10 -Wall -static foo.c -``` -[a.out](/uploads/4fffa6dd2332885f51e4030dcbe25644/a.out) - -3. Transfer the a.out file to a Linux/alpha machine; execute it there. The return code is 0. -4. -``` -$ QEMU_LD_PREFIX=/usr/alpha-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-alpha ./a.out ; echo $? -``` -Expected: `0` -Actual: `1` -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/578 b/results/classifier/zero-shot-user-mode/output/instruction/578 deleted file mode 100644 index 16f8fca7c..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/578 +++ /dev/null @@ -1,36 +0,0 @@ -instruction: 0.462 -runtime: 0.308 -syscall: 0.229 - - - -getdomainname() is not implemented in QEMU user mode on Linux/sparc64 -Description of problem: -The `getdomainname()` function fails, instead of succeeding. -Steps to reproduce: -[foo.c](/uploads/7586c9aab788855b232a5c2f6aaeb4fc/foo.c) - -1. -``` -# apt install g++-10-sparc64-linux-gnu -# mkdir -p /usr/sparc64-linux-gnu/etc -# touch /usr/sparc64-linux-gnu/etc/ld.so.cache -``` -2. -``` -$ sparc64-linux-gnu-gcc-10 -Wall -static foo.c -``` -[a.out](/uploads/39d291b95caa182d74b0b622a82667e8/a.out) - -3. Transfer the a.out file to a Linux/sparc64 machine; execute it there. It prints -``` -result: (none) -``` -4. -``` -$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-sparc64 ./a.out -``` -Expected: `result: (none)` -Actual: `getdomainname: Function not implemented` -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/579 b/results/classifier/zero-shot-user-mode/output/instruction/579 deleted file mode 100644 index 5958b9215..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/579 +++ /dev/null @@ -1,56 +0,0 @@ -instruction: 0.552 -runtime: 0.275 -syscall: 0.173 - - - -chown() fails when it should succeed in QEMU user mode on Linux/sparc64 -Description of problem: -The `chown()` function fails, instead of succeeding, in a particular situation. -Steps to reproduce: -[foo.c](/uploads/630d9b83671a071f4ded4da43b6c1b9b/foo.c) - -1. -``` -# apt install g++-10-sparc64-linux-gnu -# mkdir -p /usr/sparc64-linux-gnu/etc -# touch /usr/sparc64-linux-gnu/etc/ld.so.cache -``` -2. -``` -$ sparc64-linux-gnu-gcc-10 -Wall -static foo.c -``` -[a.out](/uploads/bbab43a1b78e6d16ee13e0eff5e963a5/a.out) - -3. Transfer the a.out file to a Linux/sparc64 machine; execute these commands there: -``` -$ id -``` -Verify that you are in 2 or more groups. -``` -$ touch file -$ ln -s file link -$ ln -s link link2 -$ ./a.out; echo $? -``` -It prints `0`. - -4. -``` -$ id -``` -Verify that you are in 2 or more groups. -``` -$ touch file -$ ln -s file link -$ ln -s link link2 -$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-sparc64 ./a.out; echo $? -``` -Expected: `0` -Actual: -``` -chown: Operation not permitted -1 -``` -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/616 b/results/classifier/zero-shot-user-mode/output/instruction/616 deleted file mode 100644 index e4682eac6..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/616 +++ /dev/null @@ -1,113 +0,0 @@ -instruction: 0.412 -syscall: 0.320 -runtime: 0.268 - - - -overflow condition code determined incorrectly after addition on s390x -Description of problem: -The following program foo.c -[foo.c](/uploads/78f5f799af6e3c400a6a42634f3f0e63/foo.c) - -``` -#include <stdio.h> - -int overflow_32 (int x, int y) -{ - int sum; - return ! __builtin_add_overflow (x, y, &sum); -} - -int overflow_64 (long long x, long long y) -{ - long sum; - return ! __builtin_add_overflow (x, y, &sum); -} - -int a1 = -2147483648; -int b1 = -2147483648; -long long a2 = -9223372036854775808L; -long long b2 = -9223372036854775808L; - -int main () -{ - { - int a = a1; - int b = b1; - printf ("a = 0x%x, b = 0x%x\n", a, b); - printf ("no_overflow = %d\n", overflow_32 (a, b)); - } - { - long long a = a2; - long long b = b2; - printf ("a = 0x%llx, b = 0x%llx\n", a, b); - printf ("no_overflow = %d\n", overflow_64 (a, b)); - } -} -``` - -should print - -``` -a = 0x80000000, b = 0x80000000 -no_overflow = 0 -a = 0x8000000000000000, b = 0x8000000000000000 -no_overflow = 0 -``` - -However, when compiled as an s390x program and executed through -qemu 6.1.0 (Linux user-mode), it prints 'no_overflow = 1' twice. - -``` -$ s390x-linux-gnu-gcc-10 --version -s390x-linux-gnu-gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0 -``` - -``` -$ s390x-linux-gnu-gcc-10 -static foo.c -$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out -a = 0x80000000, b = 0x80000000 -no_overflow = 1 -a = 0x8000000000000000, b = 0x8000000000000000 -no_overflow = 1 -``` - -``` -$ s390x-linux-gnu-gcc-10 -O2 -static foo.c -$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out -a = 0x80000000, b = 0x80000000 -no_overflow = 1 -a = 0x8000000000000000, b = 0x8000000000000000 -no_overflow = 1 -``` - -The code generated by 's390x-linux-gnu-gcc-10 -O2' makes use of the -'o' (overflow / ones) condition code: - -``` -overflow_64: - lgr %r1,%r2 ;; copy a into %r1 - lghi %r2,0 - agr %r1,%r3 ;; add a and b - bnor %r14 ;; if no overflow, return %r2 = 0 - lghi %r2,1 - br %r14 ;; otherwise, return %r2 = 1 -``` - -Either the bug is in GCC, that is, GCC produces code that uses the CPU's -overflow condition code when it shouldn't. - -Or the bug is in QEMU, that is, QEMU does not set the overflow condition -code correctly. - -This can be decided by running the above program on real Linux/s390x hardware -(to which I don't have access). -Steps to reproduce: -[foo.static.s390x](/uploads/ac41abf4c54baf9ca96ba82d75a24ad6/foo.static.s390x) -(foo.static.s390x is attached, the result of "s390x-linux-gnu-gcc-10 -static -O2 foo.c -o foo.static.s390x") - -1. `qemu-s390x foo.static.s390x` -Additional information: -If the bug is really in QEMU, the attached patch fixes it. - -[0001-s390x-Fix-determination-of-overflow-condition-code-a.patch](/uploads/552917079ccd25f1861d682fc9dee3e8/0001-s390x-Fix-determination-of-overflow-condition-code-a.patch) diff --git a/results/classifier/zero-shot-user-mode/output/instruction/625 b/results/classifier/zero-shot-user-mode/output/instruction/625 deleted file mode 100644 index bed4f4248..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/625 +++ /dev/null @@ -1,29 +0,0 @@ -instruction: 0.690 -runtime: 0.184 -syscall: 0.126 - - - -qemu-hppa floating point POWER function is incorrect -Description of problem: -The floating point power function produces incorrect values, and possibly stack misshapes as well. -Steps to reproduce: -1. $ hppa1.1-unknown-linux-gnu-gcc pow.c -o pow -lm -static -2. $ qemu-hppa pow -3. the expected result is 10.0 ^ 6.0 = 6000000.0, instead of 403.45 -Additional information: -Example C source to reproduce, pow.c: -``` -#include <stdio.h> -#include <math.h> -int main() -{ - double base, expo, res; - base=10.0; - expo=6.0; - // res sould be 1e+6 - res = pow(base, expo); - printf("%.1lf^%.1lf = %.2lf\n", base, expo, res); - return 0; -} -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/633 b/results/classifier/zero-shot-user-mode/output/instruction/633 deleted file mode 100644 index ac05340c3..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/633 +++ /dev/null @@ -1,38 +0,0 @@ -instruction: 0.427 -runtime: 0.297 -syscall: 0.276 - - - -i686-arm-user-static - Allocating guest commpage: Operation not permitted -Steps to reproduce: -1. Run the test case linked earlier. -2. You'll see `apt update` failing: - -``` -Get:1 http://archive.raspberrypi.org/debian buster InRelease [32.6 kB] -Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB] -Err:1 http://archive.raspberrypi.org/debian buster InRelease - At least one invalid signature was encountered. -Err:2 http://raspbian.raspberrypi.org/raspbian buster InRelease - At least one invalid signature was encountered. -Reading package lists... Done -W: GPG error: http://archive.raspberrypi.org/debian buster InRelease: At least one invalid signature was encountered. -E: The repository 'http://archive.raspberrypi.org/debian buster InRelease' is not signed. -N: Updating from such a repository can't be done securely, and is therefore disabled by default. -N: See apt-secure(8) manpage for repository creation and user configuration details. -W: GPG error: http://raspbian.raspberrypi.org/raspbian buster InRelease: At least one invalid signature was encountered. -E: The repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' is not signed. -N: Updating from such a repository can't be done securely, and is therefore disabled by default. -N: See apt-secure(8) manpage for repository creation and user configuration details. -``` -Additional information: -Setting `sysctl vm.mmap_min_addr=53248` makes it work (as opposed to the system default of 65536). - -Bisecting the bug linked earlier also breaks this in a slightly different way. Everything works at 87b74e8b6edd287ea2160caa0ebea725fa8f1ca1. After that, apt update appears to work, but the package lists end up empty, so nothing can be installed. Then after 975ac4559c4c00010e05f7a3e782eeb9497837ea, the output is as provided above. - -apt launches /usr/lib/apt/methods/gpgv and passes it some commands through stdin. gpgv launches /usr/bin/apt-key, which fails with `Allocating guest commpage: Operation not permitted`. Running gpgv directly and sending the same commands works without any issues. The problem only occurs when gpgv is run through apt. (I don't meant the normal system gpgv binary, but the transport method binary that comes with apt) - -Getting any output is tricky because by the time apt-key is launched, gpgv redirects stdout and stderr to /dev/null and communication takes place through fd 3. https://salsa.debian.org/apt-team/apt/-/blob/2.2.4/apt-pkg/contrib/gpgv.cc#L355 https://salsa.debian.org/apt-team/apt/-/blob/main/methods/gpgv.cc#L186 - -I had to do some ugly things with different versions of qemu and wrapper scripts to see the commpage error, but hopefully there's enough information provided here that it won't be necessary. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/654 b/results/classifier/zero-shot-user-mode/output/instruction/654 deleted file mode 100644 index cc6d1faae..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/654 +++ /dev/null @@ -1,29 +0,0 @@ -instruction: 0.476 -syscall: 0.401 -runtime: 0.123 - - - -Strace Log Output Mangled -Description of problem: -The syscall log entries from the strace logging capability can be interrupted by other log messages before the full syscall line is -complete. -This makes parsing the strace syscall lines from the log output difficult. -Steps to reproduce: -1. Run the supplied command with a simple dynamically linked binary, or a binary that performs mmaps -2. Notice that the strace 'mmap' syscall log entries in the trace file are interrupted by the page log output -Additional information: -I have attached an example log from a dynamically linked 'hello world' binary, which demonstrates the bug in the mmap syscall strace entries. [output.trace](/uploads/88c83273582d00241fbf95af735dcc61/output.trace) - - -I believe this bug caused by a couple of things: -Firstly, in the linux-user/syscall.c file: the strace syscall entry is not output atomically, but instead split across two calls: -The first half is at `print_syscall`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13153 -And the return value (and new line) is printed in `print_syscall_ret`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13160 - -In the case of the mmap syscall, the function `log_page_dump` is called between these two functions resulting in the mangled log output: -https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/mmap.c#L633 -There may be other syscalls that behave similarly, but this was noticed due to the mmap behavior. - - -Internally to the `print_syscall` and `print_syscall_ret` functions, `qemu_log` is called multiple times to compose the full log entry, and it seems that it is inside `qemu_log` that the logfile lock is obtained and dropped - so theoretically another thread can output to the log during the printing of a single syscall entry between these `qemu_log` calls. I do not know if this actually happens in practice besides the mmap scenario described above. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/690 b/results/classifier/zero-shot-user-mode/output/instruction/690 deleted file mode 100644 index a07c8759e..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/690 +++ /dev/null @@ -1,25 +0,0 @@ -instruction: 0.654 -runtime: 0.223 -syscall: 0.123 - - - -32bit qemu-arm can't run GCC due to failure to allocate memory range for guest (Allocating guest commpage error) -Description of problem: -I'm running ARM binaries using 32 bit qemu-arm-static on x86_64 host. Since version 5.1 (include latest 6.1), QEMU cannot run GCC and some other things with an error `Allocating guest commpage: Operation not permitted`. The problem is NOT reproducible on QEMU 5.0, so probably the problem was caused by a [rework of init_guest_space or the following commits](https://gitlab.com/qemu-project/qemu/-/commit/ee94743034bfb443cf246eda4971bdc15d8ee066) a year ago. - -Also the problem is not reproducible for all users. It is known that it is reproduced on all Arch Linux host machines and some Debian, and probably depends on some kernel build parameters. - -The sysctl `vm.mmap_min_addr` parameter also affects the problem. The error varies depending on its value: -``` -[0 ... 53248] - No error at all -[53249 ... 61440] - Cannot allocate memory -[61441 ... 65536 and higher] - Operation not permitted -``` -Steps to reproduce: -1. Download and extract attached tarball: [qemu-test-gcc.tgz](/uploads/0031fdf6705183626f646b78a281dd2a/qemu-test-gcc.tgz) -2. `$ make # will build the docker container` -3. `$ make run # will enter the container` -4. Once in the container, run: `# /qemu-arm-static-50 /bin/bash /runme.sh` -Additional information: -A detailed description of the problem and feedback from other users is here: https://bugs.launchpad.net/qemu/+bug/1891748 diff --git a/results/classifier/zero-shot-user-mode/output/instruction/693 b/results/classifier/zero-shot-user-mode/output/instruction/693 deleted file mode 100644 index 943f1c0f7..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/693 +++ /dev/null @@ -1,16 +0,0 @@ -instruction: 0.597 -syscall: 0.217 -runtime: 0.186 - - - -Qemu increased memory usage with TCG -Description of problem: -The issue is that instances that are supposed to use only a small amount of memory (like 256MB) suddenly use a much higher amount of RSS when running the accel=tcg, around 512MB in the above example. This was not happening with qemu-4.2 (on Ubuntu 20.04). This is also not happening when using accel=kvm instead. The issue has been first noticed on Debian 11 (Bullseye) with the versions above, but it is happening in the same way on Centos 8 Stream, Ubuntu 21.10 and a pre-release version of Ubuntu 22.04. It also also seen when testing with qemu-6.1 built from source. -Steps to reproduce: -1. Deploy devstack (https://opendev.org/openstack/devstack) with VIRT_TYPE=qemu on a VM -2. Start an instance with cirros image and a flavor allocating 256MB -3. Do a ps and see a RSS size of about 512MB being used after the instance has finished booting -4. Expected result (seen with qemu-4.2 or VIRT_TYPE=kvm): RSS stays < 256MB -Additional information: -I can try to find a smaller commandline for manual reproduction if needed. The above sample is generated by OpenStack Nova via libvirt. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/697 b/results/classifier/zero-shot-user-mode/output/instruction/697 deleted file mode 100644 index 8fd5be135..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/697 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.489 -runtime: 0.341 -syscall: 0.171 - - - -linux-user create default CPU type before parsing the ELF header for specific CPU type diff --git a/results/classifier/zero-shot-user-mode/output/instruction/704 b/results/classifier/zero-shot-user-mode/output/instruction/704 deleted file mode 100644 index 3c4af19f0..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/704 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.541 -syscall: 0.277 -runtime: 0.182 - - - -linux-user: misaligned address for type 'struct linux_dirent64' diff --git a/results/classifier/zero-shot-user-mode/output/instruction/714 b/results/classifier/zero-shot-user-mode/output/instruction/714 deleted file mode 100644 index ed21203db..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/714 +++ /dev/null @@ -1,49 +0,0 @@ -instruction: 0.518 -syscall: 0.249 -runtime: 0.234 - - - -Command line arguments are not passed correctly with user-space semihosting -Description of problem: -The emulated process always receives a value of 1 for `argc`, with `argv[0]` returning seemingly random characters (in Ubuntu packaged qemu 5.2), but correlating with command-line input (output below from master built qemu 6.1): -``` -$ qemu-arm -cpu cortex-m7 ./a.out 123 test -argc: 1 -argv: - - @@@ - -$ qemu-arm -cpu cortex-m7 ./a.out -argc: 1 -argv: - [0] @ -``` -Steps to reproduce: -1. Compile the following program with [ARM embedded toolchain](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads): -```cpp -#include <iostream> - -int main(int argc, char* argv[]) { - std::cout << "argc: " << argc << "\n"; - std::cout << "argv: \n"; - - for (int i = 0; i < argc; i++) - std::cout << " [" << i << "] " << argv[i] << "\n"; - return 0; -} -``` - -``` -$ $CXX --version -arm-none-eabi-g++ (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release) -Copyright (C) 2020 Free Software Foundation, Inc. -This is free software; see the source for copying conditions. There is NO -warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - -$ $CXX main.cpp --specs=rdimon.specs -mcpu=cortex-m7 -``` - -2. Run in user-space (semihosted): -``` -$ qemu-arm -cpu cortex-m7 ./a.out -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/739785 b/results/classifier/zero-shot-user-mode/output/instruction/739785 deleted file mode 100644 index 114c65fb2..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/739785 +++ /dev/null @@ -1,40 +0,0 @@ -instruction: 0.489 -runtime: 0.280 -syscall: 0.231 - - - -qemu-i386 user mode can't fork (bash: fork: Invalid argument) - -Good time of day everybody, - -I have been trying to make usermode qemu on ARM with plugapps (archlinux) with archlinux i386 chroot to work. - -1. I installed arch linux in a virtuabox and created a chroot for it with mkarchroot. Transferred it to my pogo plug into /i386/ -2. I comiled qemu-i386 static and put it into /i386/usr/bin/ -./configure --static --disable-blobs --disable-system --target-list=i386-linux-user -make - -3. I also compiled linux kernel 2.6.38 with CONFIG_BINFMT_MISC=y and installed it. -uname -a -Linux Plugbox 2.6.38 #4 PREEMPT Fri Mar 18 22:19:10 CDT 2011 armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board GNU/Linux - -4. Added the following options into /etc/rc.local -/sbin/modprobe binfmt_misc -/bin/mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc -echo ':qemu-i386:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff\xff:/usr/bin/qemu-i386:' >/proc/sys/fs/binfmt_misc/register - -5. Also copied ld-linux.so.3 (actually ld-2.13.so because ld-linux.so.3 is a link to that file) from /lib/ to /i386/lib/ - -6.Now i chroot into /i386 and I get this: -[root@Plugbox i386]# chroot . -[II aI hnve ao n@P /]# pacman -Suy -bash: fork: Invalid argument - -7.I also downloaded linux-user-test-0.3 from qemu website and ran the test: -[root@Plugbox linux-user-test-0.3]# make -./qemu-linux-user.sh -[qemu-i386] -../qemu-0.14.0/i386-linux-user/qemu-i386 -L ./gnemul/qemu-i386 i386/ls -l dummyfile -BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! -make: *** [test] Error 127 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/754 b/results/classifier/zero-shot-user-mode/output/instruction/754 deleted file mode 100644 index 348bbde68..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/754 +++ /dev/null @@ -1,213 +0,0 @@ -instruction: 0.351 -syscall: 0.341 -runtime: 0.308 - - - -qem_m68k : trapcs instruction causes the non-execution of the following 2 instructions -Description of problem: -In try to run following code : -``` -8004615a: 204f moveal %sp,%a0 -8004615c: b1c7 cmpal %d7,%a0 -8004615e: 55fc trapcs -80046160: 4e56 0000 linkw %fp,#0 -80046164: 2f14 movel %a4@,%sp@- -80046166: 288e movel %fp,%a4@ -80046168: c74d exg %a3,%a5 -8004616a: 48e7 3030 moveml %d2-%d3/%a2-%a3,%sp@- -8004616e: 7001 moveq #1,%d0 -80046170: 3b40 816c movew %d0,%a5@(-32404) -80046174: 7218 moveq #24,%d1 -80046176: 3b41 816a movew %d1,%a5@(-32406) -8004617a: 242d 8004 movel %a5@(-32764),%d2 -8004617e: 2b42 815c movel %d2,%a5@(-32420) -80046182: 206d 8008 moveal %a5@(-32760),%a0 -80046186: 2268 8010 moveal %a0@(-32752),%a1 -8004618a: 2b49 8158 movel %a1,%a5@(-32424) -8004618e: 42ad 8154 clrl %a5@(-32428) -80046192: 246d 8154 moveal %a5@(-32428),%a2 -80046196: 2b4a 8160 movel %a2,%a5@(-32416) -8004619a: 2b4a 8164 movel %a2,%a5@(-32412) -8004619e: 422d 8168 clrb %a5@(-32408) -800461a2: 7604 moveq #4,%d3 -800461a4: 2b43 8150 movel %d3,%a5@(-32432) -800461a8: 2668 8010 moveal %a0@(-32752),%a3 -800461ac: 2b4b 814c movel %a3,%a5@(-32436) -800461b0: 2268 8010 moveal %a0@(-32752),%a1 -800461b4: 266d 8008 moveal %a5@(-32760),%a3 -800461b8: 206b 8008 moveal %a3@(-32760),%a0 -800461bc: 4e90 jsr %a0@ -800461be: 2b48 8148 movel %a0,%a5@(-32440) -800461c2: 4cdf 0c0c moveml %sp@+,%d2-%d3/%a2-%a3 -800461c6: c74d exg %a3,%a5 -800461c8: 289f movel %sp@+,%a4@ -800461ca: 4e5e unlk %fp -800461cc: 4e75 rts -``` -When I run qemu-m68k -cpu m68020 -d in_asm,cpu, I have : -``` ----------------- -IN: -0x8004615a: moveal %sp,%a0 -0x8004615c: cmpal %d7,%a0 -0x8004615e: trapcs -0x80046160: linkw %fp,#0 -0x80046164: movel %a4@,%sp@- -0x80046166: movel %fp,%a4@ -0x80046168: exg %a3,%a5 -0x8004616a: moveml %d2-%d3/%a2-%a3,%sp@- -0x8004616e: moveq #1,%d0 -0x80046170: movew %d0,%a5@(-32404) -0x80046174: moveq #24,%d1 -0x80046176: movew %d1,%a5@(-32406) -0x8004617a: movel %a5@(-32764),%d2 -0x8004617e: movel %d2,%a5@(-32420) -0x80046182: moveal %a5@(-32760),%a0 -0x80046186: moveal %a0@(-32752),%a1 -0x8004618a: movel %a1,%a5@(-32424) -0x8004618e: clrl %a5@(-32428) -0x80046192: moveal %a5@(-32428),%a2 -0x80046196: movel %a2,%a5@(-32416) -0x8004619a: movel %a2,%a5@(-32412) -0x8004619e: clrb %a5@(-32408) -0x800461a2: moveq #4,%d3 -0x800461a4: movel %d3,%a5@(-32432) -0x800461a8: moveal %a0@(-32752),%a3 -0x800461ac: movel %a3,%a5@(-32436) -0x800461b0: moveal %a0@(-32752),%a1 -0x800461b4: moveal %a5@(-32760),%a3 -0x800461b8: moveal %a3@(-32760),%a0 -0x800461bc: jsr %a0@ - -Trace 0: 0x7f83a807e780 [00000000/8004615a/00000000/00000000] -D0 = 00000012 A0 = 8004615a F0 = 7fff ffffffffffffffff ( nan) -D1 = 00000001 A1 = 800466d6 F1 = 7fff ffffffffffffffff ( nan) -D2 = 00000000 A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) -D3 = 00000000 A3 = 8000c3b0 F3 = 7fff ffffffffffffffff ( nan) -D4 = 00000000 A4 = 8004604c F4 = 7fff ffffffffffffffff ( nan) -D5 = 00000000 A5 = 3ffd7000 F5 = 7fff ffffffffffffffff ( nan) -D6 = 00000004 A6 = 80046038 F6 = 7fff ffffffffffffffff ( nan) -D7 = 80042050 A7 = 80045ff4 F7 = 7fff ffffffffffffffff ( nan) -PC SR = 0004 T:0 I:0 UI --Z-- -FPSR = 00000000 ---- - FPCR = 0000 X RN - - ----------------- -IN: -0x80046358: lea %a1@(0,%d0:l),%a0 -0x8004635c: rts - -Trace 0: 0x7f83a807eac0 [00000000/80046358/00000000/00000000] -D0 = 00000001 A0 = 80046358 F0 = 7fff ffffffffffffffff ( nan) -D1 = 00000018 A1 = 00000000 F1 = 7fff ffffffffffffffff ( nan) -D2 = ffffffff A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) -D3 = 00000004 A3 = 8000c040 F3 = 7fff ffffffffffffffff ( nan) -D4 = 00000000 A4 = 8004604c F4 = 7fff ffffffffffffffff ( nan) -D5 = 00000000 A5 = 8000c3b0 F5 = 7fff ffffffffffffffff ( nan) -D6 = 00000004 A6 = 80046038 F6 = 7fff ffffffffffffffff ( nan) -D7 = 80042050 A7 = 80045fe0 F7 = 7fff ffffffffffffffff ( nan) -PC = 80046358 SR = 0004 T:0 I:0 UI --Z-- -FPSR = 00000000 ---- - FPCR = 0000 X RN ----------------- -``` -Stack pointer is 80045fe0, it should be 80045FD8. - -When I run with options -cpu m68020 -d in_asm,cpu,op -singlestep, I have : -``` ----------------- -IN: -0x8004615e: trapcs -0x80046160: linkw %fp,#0 -Disassembler disagrees with translator over instruction decoding -Please report this to qemu-devel@nongnu.org - -OP: - ld_i32 tmp0,env,$0xfffffffffffffff8 - brcond_i32 tmp0,$0x0,lt,$L0 - - ---- 8004615e 00000000 - mov_i32 tmp0,$0x0 - call flush_flags,$0x0,$0,env,CC_OP - setcond_i32 tmp2,CC_C,tmp0,ne - neg_i32 tmp2,tmp2 - mov_i32 tmp0,$0x56 - mov_i32 PC,$0x80046162 - exit_tb $0x0 - set_label $L0 - exit_tb $0x7fba001a75c3 - -D0 = 00000012 A0 = 80045ff4 F0 = 7fff ffffffffffffffff ( nan) -D1 = 00000001 A1 = 800466d6 F1 = 7fff ffffffffffffffff ( nan) -D2 = 00000000 A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) -D3 = 00000000 A3 = 8000c3b0 F3 = 7fff ffffffffffffffff ( nan) -D4 = 00000000 A4 = 8004604c F4 = 7fff ffffffffffffffff ( nan) -D5 = 00000000 A5 = 3ffd5000 F5 = 7fff ffffffffffffffff ( nan) -D6 = 00000004 A6 = 80046038 F6 = 7fff ffffffffffffffff ( nan) -D7 = 80042050 A7 = 80045ff4 F7 = 7fff ffffffffffffffff ( nan) -PC = 8004615e SR = 0000 T:0 I:0 UI ----- -FPSR = 00000000 ---- - FPCR = 0000 X RN ----------------- -IN: -0x80046162: orib #20,%d0 - -OP: - ld_i32 tmp0,env,$0xfffffffffffffff8 - brcond_i32 tmp0,$0x0,lt,$L0 - - ---- 80046162 00000000 - mov_i32 tmp0,$0x14 - ext8s_i32 tmp3,D0 - or_i32 tmp4,tmp3,tmp0 - and_i32 D0,D0,$0xffffff00 - ext8u_i32 tmp6,tmp4 - or_i32 D0,D0,tmp6 - ext8s_i32 CC_N,tmp4 - discard CC_C - discard CC_Z - discard CC_V - mov_i32 CC_OP,$0xb - mov_i32 PC,$0x80046166 - exit_tb $0x0 - set_label $L0 - exit_tb $0x7fba001a7683 - -D0 = 00000012 A0 = 80045ff4 F0 = 7fff ffffffffffffffff ( nan) -D1 = 00000001 A1 = 800466d6 F1 = 7fff ffffffffffffffff ( nan) -D2 = 00000000 A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) -D3 = 00000000 A3 = 8000c3b0 F3 = 7fff ffffffffffffffff ( nan) -D4 = 00000000 A4 = 8004604c F4 = 7fff ffffffffffffffff ( nan) -D5 = 00000000 A5 = 3ffd5000 F5 = 7fff ffffffffffffffff ( nan) -D6 = 00000004 A6 = 80046038 F6 = 7fff ffffffffffffffff ( nan) -D7 = 80042050 A7 = 80045ff4 F7 = 7fff ffffffffffffffff ( nan) -PC = 80046162 SR = 0000 T:0 I:0 UI ----- -FPSR = 00000000 ---- - FPCR = 0000 X RN ----------------- -IN: -0x80046166: movel %fp,%a4@ - -OP: - ld_i32 tmp0,env,$0xfffffffffffffff8 - brcond_i32 tmp0,$0x0,lt,$L0 - -... -``` -I can see that instructions -``` -0x80046160: linkw %fp,#0 -0x80046164: movel %a4@,%sp@- -``` -are not executed -and an extra instruction -``` -0x80046162: orib #20,%d0 -``` -is executed -Steps to reproduce: -Run chroot qemu-m68k qemu-m68k-static -cpu m68020 -d in_asm,cpu -D log1.txt ./test -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/instruction/796480 b/results/classifier/zero-shot-user-mode/output/instruction/796480 deleted file mode 100644 index d0eb978d3..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/796480 +++ /dev/null @@ -1,51 +0,0 @@ -instruction: 0.568 -runtime: 0.266 -syscall: 0.167 - - - -Addresses with 4GB differences are consider as one single address in QEMU - -THIS IS THE ISSUE OF USER MODE EMULATION -Information about guest and host -********************************** -guest: 64 bit x86 user mode binary -host: 32 bit Linux OS -uname -a :Linux KICS-HPCNL-32blue 2.6.33.3-85.fc13.i686.PAE #1 SMP -architecture: intel64 -Bug Description -**************** -for memory reference instructions, suppose I have two addresses in guest address space(64 bit) -0x220000000 -0x320000000 -as lower 32 bit part of both addresses are same, when particular instructions are translated into host code(32 bit) -in both above cases the value is loaded from same memory and we get same value. where actual behaviour was to get two different values. -here is the program which i used to test: -#include <stdio.h> -#include <stdlib.h> -#include <limits.h> -#define SIZE 4294967298 /* 4Gib*/ - -int main() { - char *array; - unsigned int i; - - array = malloc(sizeof(char) * SIZE); - if(array == NULL) { - fprintf(stderr, "Could not allocate that much memory"); - return 1; } - array[0] = 'a'; - array[SIZE-2] = 'z'; - printf("array[SIZE-2] = %c array[0] = %c\n",array[SIZE-2], array[0]); - return 0; -} -I have 8 gib RAM -I compiled this program on 64 bit linux and run this on 32 bit linux with qemu -QEMU command line and output -********************************** -$x86_64-linux-user/qemu-x86_64 ~/ar_x86 -output: array[SIZE-1] = z,array[0] = z -Release information -******************** -x86_64 binary is tested with latest release : qemu-0.14.1 -and with current development tree as well( live code of QEMU using git) \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/799 b/results/classifier/zero-shot-user-mode/output/instruction/799 deleted file mode 100644 index f37252798..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/799 +++ /dev/null @@ -1,53 +0,0 @@ -instruction: 0.693 -runtime: 0.158 -syscall: 0.149 - - - -TCG Optimizer crashes on AArch64 SVE2 instruction -Description of problem: -QEMU crashes due to an assertion in the TCG optimizer when optimizing an SVE2 instruction: -``` -Unrecognized operation 145 in do_constant_folding. -../tcg/optimize.c:458: tcg fatal error -``` -Steps to reproduce: -1. Compile the following minimized reproducer: (a pre-compiled image is provided for convenience - [reproducer.img](/uploads/0bddbfac55306a297fee59dd2f6923cf/reproducer.img)) -```asm -.org 0x0 -entry: - mrs x1, cptr_el3 - orr x9, x1, #0x100 - msr cptr_el3, x9 - - msr cptr_el2, xzr - - mov x1, #0x3 - mrs x9, cpacr_el1 - bfi x9, x1, #16, #2 - bfi x9, x1, #20, #2 - msr cpacr_el1, x9 - - mov x9, 512 - mov x0, x9 - asr x0, x0, 7 - sub x9, x0, #1 - msr zcr_el1, x9 - - mov x9, 512 - mov x0, x9 - asr x0, x0, 7 - sub x9, x0, #1 - msr zcr_el2, x9 - - mov x9, 512 - mov x0, x9 - asr x0, x0, 7 - sub x9, x0, #1 - msr zcr_el3, x9 - - uqxtnt z11.s, z22.d -``` -2. Execute it using the command line given above. -Additional information: -I tested latest master as well, and the problem persists. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/805 b/results/classifier/zero-shot-user-mode/output/instruction/805 deleted file mode 100644 index 48a742954..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/805 +++ /dev/null @@ -1,20 +0,0 @@ -instruction: 0.487 -runtime: 0.357 -syscall: 0.156 - - - -qemu-hexagon: [binary]: Error mapping file: Invalid argument -Description of problem: -Running a (32bit) hexagon binary on a 64bit/32bit system gives the following error: -`qemu-hexagon: hexagon-hello-world: Error mapping file: Invalid argument` -Steps to reproduce: -``` -./qemu-hexagon <hexagon-binary> -qemu-hexagon: hexagon-hello-world: Error mapping file: Invalid argument -``` -Additional information: -A similar problem has been reported on the mailing list: -https://www.mail-archive.com/qemu-devel@nongnu.org/msg836466.html - -Unfortunately without a solution. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/817 b/results/classifier/zero-shot-user-mode/output/instruction/817 deleted file mode 100644 index 3aac578e5..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/817 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.544 -syscall: 0.277 -runtime: 0.179 - - - -linux-user: waitid leaves target siginfo uninitialized when info.si_pid is zero diff --git a/results/classifier/zero-shot-user-mode/output/instruction/824 b/results/classifier/zero-shot-user-mode/output/instruction/824 deleted file mode 100644 index 3e6ea8710..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/824 +++ /dev/null @@ -1,18 +0,0 @@ -instruction: 0.929 -runtime: 0.045 -syscall: 0.027 - - - -x86_64 Translation Block error (cmp eax, 0x6; jnle 0x524) -Description of problem: -`Qemu` produces a Translation block of 4 instructions: -``` -0x0000558a53039ffc: 83f806 (cmp eax, 0x6) -0x0000558a53039fff: 0f (nothing) -0x0000558a53039ffc: 83f806 (cmp eax, 0x6) -0x0000558a53039fff: 0f8f1e050000 (jnle 0x524) -``` -This problem occurs several time with different addresses but the same pattern: -- 1st and 3th instructions are the same (both addresses and opcodes); -- 2nd is the prefix of the 4th (same addresses). diff --git a/results/classifier/zero-shot-user-mode/output/instruction/826 b/results/classifier/zero-shot-user-mode/output/instruction/826 deleted file mode 100644 index 5cab9b97f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/826 +++ /dev/null @@ -1,22 +0,0 @@ -instruction: 0.924 -runtime: 0.039 -syscall: 0.037 - - - -AArch64 SVE2 LDNT1SB (vector plus scalar) load address incorrectly calculated -Description of problem: -During execution of the following SVE2 instruction: -`ldnt1sb {z6.d}, p3/z, [z14.d, x9]` -with the following register state: -``` -(gdb) p $p3 -$1 = {0x7, 0x0, 0x74, 0x0, 0x43, 0x0, 0x29, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x66, 0xe4, 0x64, 0x0, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0xb0, 0x8b, 0x49, 0x34, 0xfc, 0x7f, 0x0, 0x0, 0xe0, 0x71, 0x30, 0x1, 0x0, 0x0, 0x0, 0x0} -(gdb) p $z14.d.u -$2 = {0x3bdeaa30, 0x3bdeaa33, 0x3bdeaa36, 0x3bdeaa39, 0x3bdeaa3c, 0x3bdeaa3f, 0x3bdeaa42, 0x3bdeaa45} -(gdb) p $x9 -$3 = 0x0 -``` -QEMU produces a data abort due to an address fault on address `0x5EE45E4E`, which it clearly should not have tried to load. -Additional information: -A quick look at the implementation of the LDNT1SB instruction in QEMU points to the following commit: https://gitlab.com/qemu-project/qemu/-/commit/cf327449816d5643106445420a0b06b0f38d4f01 which simply redirects to SVE's LD1SB handler. As these instructions use a new flavor of SVE scatter/gather loads (vector plus scalar) which SVE LD1SB does not support, I wonder if the LD1SB handler simply decodes it as the wrong instruction and treats it as a (scalar plus vector) instruction, which LD1SB does support, but whose address calculation is completely different. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/829 b/results/classifier/zero-shot-user-mode/output/instruction/829 deleted file mode 100644 index d6274ac30..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/829 +++ /dev/null @@ -1,20 +0,0 @@ -instruction: 0.521 -syscall: 0.339 -runtime: 0.141 - - - -user space emulation: openat() seems to defeat sysroot path translation -Description of problem: -It appears that the user space emulation code is doing some path manipulation of some syscalls to sometimes prefix them with the sysroot. This seems to be interacting badly sometimes with certain usage patterns. This was noticed because a test suite of various libc calls was failing under `qemu-arm`, and a `strace` of the qemu-arm process revealed that the translated paths were being inconsistently applied. - -In particular, the sequence which fails is: -* create a file in `/tmp/`. -* open `/tmp` itself. This succeeds, but `strace` reveals that it actually opened `SYSROOT/tmp/`. -* `openat(tmpfd, tmpfile_name)` then fails, as the fd provided to openat is actually inside the sysroot, not at `/tmp` as expected. -Steps to reproduce: -1. Get toolchain https://toolchains.bootlin.com/downloads/releases/toolchains/armv7-eabihf/tarballs/armv7-eabihf--uclibc--bleeding-edge-2021.11-1.tar.bz2 -2. Compile attached test program [test_openat.c](/uploads/69eb997256ff29d2178be85531c6b3c6/test_openat.c) -3. Try to run under `qemu-arm`. - -This code passes in non-emulated situations, but fails under user-space emulation. Presumably it would also pass under full system emulation. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/833 b/results/classifier/zero-shot-user-mode/output/instruction/833 deleted file mode 100644 index 461ff02fe..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/833 +++ /dev/null @@ -1,48 +0,0 @@ -instruction: 0.386 -runtime: 0.363 -syscall: 0.252 - - - -linux-user: sendmsg fails to send messages without iov -Description of problem: -When run via qemu `sendmsg` fails to send messages which contain a zero length `iov` but _do_ contain ancillary data. This works fine on plain Linux. - -A practical example: the `ell` library relies on this for setting the IV on a kernel crypto (`AF_ALG`) socket: https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/cipher.c#n526 - -A message without data but only ancillary data is used to set the IV. -Steps to reproduce: -See [qemu_ancillary.c](/uploads/84ee20aa3b9178022847d6cd7fcf0048/qemu_ancillary.c) for a self contained testcase which sends two mesages (one with `msg_iovlen=0`, one with `msg_iovlen=1`). - -(Test case is to be considered GPL, as I've copied bits from `ell`) - -Native: -``` -$ strace -esendmsg ./a.out -sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 0 -sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 16 -+++ exited with 0 +++ -``` - - -Qemu (observe missing sendmsg call): -``` -$ strace -esendmsg ~/debug/qemu/build/qemu-x86_64 ./a.out -sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 16 -+++ exited with 0 +++ -``` - -For a practical reproducer: - -1. Compile and run `ell`'s `test-cipher` test case: - -``` -$ ~/debug/qemu/build/qemu-x86_64 ./unit/test-cipher -TEST: unsupported -TEST: aes -TEST: aes_ctr -test-cipher: unit/test-cipher.c:102: test_aes_ctr: Assertion `!r' failed. -Aborted (core dumped) -``` - -A strace will look similar. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/834 b/results/classifier/zero-shot-user-mode/output/instruction/834 deleted file mode 100644 index fc4f86cfd..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/834 +++ /dev/null @@ -1,65 +0,0 @@ -instruction: 0.445 -runtime: 0.288 -syscall: 0.267 - - - -linux-user: fails to deliver signals raised during pselect -Description of problem: -When run via qemu a program which blocks signals but unmasks them during `pselect` does not catch these signals when returning from `pselect`. - -Used as reference on expected behavior: [The new pselect() system call](https://lwn.net/Articles/176911/) -Steps to reproduce: -A minimal test case below mimics behavior as encountered in the test suite of `p11-kit` ([link](https://github.com/p11-glue/p11-kit)) (which attempts to catch `SIGTERM` in a similar way and results in lingering processes after running the test suite). - -```C -#include <stdio.h> -#include <unistd.h> -#include <signal.h> -#include <sys/select.h> - -static void handler(int sig) -{ - puts("SIGNAL"); -} - -int main(int argc, char *argv[]) -{ - struct sigaction sa; - - fd_set rfds; - sigset_t emptyset, blockset; - - sigemptyset (&blockset); - sigemptyset (&emptyset); - sigaddset (&blockset, SIGUSR1); - - sa.sa_handler = handler; - sigemptyset(&sa.sa_mask); - sa.sa_flags = 0; - sigaction(SIGUSR1, &sa, NULL); - - sigprocmask (SIG_BLOCK, &blockset, NULL); - - FD_ZERO(&rfds); - - while(1) { - pselect(0, &rfds, NULL, NULL, NULL, &emptyset); - } - - return 0; -} -``` - -Running this without qemu should print _SIGNAL_ when sent `SIGUSR1`: - -``` -$ ./a.out & -[1] 1683587 -$ kill -USR1 %1 -$ SIGNAL -``` - -When run with `qemu-x86_64` however, it does not (also qemu's `-strace` confirms the signal isn't received whereas a strace of qemu shows it's in fact delivered). - -The pselect call itself _is_ interrupted, but the signal goes missing. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/837 b/results/classifier/zero-shot-user-mode/output/instruction/837 deleted file mode 100644 index 41d6909df..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/837 +++ /dev/null @@ -1,36 +0,0 @@ -instruction: 0.526 -syscall: 0.266 -runtime: 0.208 - - - -x86 user: icebp/int1 raises wrong signal -Description of problem: -This is a relatively minor inaccuracy. When `icebp` (`F1`) is executed, it raises `SIGILL` in QEMU, where the behavior on baremetal Linux (on an old Intel Core i5-430m) is to raise `SIGTRAP`. - -Specifically, on the architectural level, `icebp` raises `#DB` without affecting `dr6`. - -This also happens on an AArch64 host. -``` -$ ./icebp -Trace/breakpoint trap -$ qemu-x86_64 ./icebp -qemu: uncaught target signal 4 (Illegal instruction) - core dumped -Illegal instruction -``` -Steps to reproduce: -1. Compile this file using `gcc -nostdlib -static icebp.S -o icebp`, optionally with `-m32` to test i386 -``` - .globl _start -_start: - .byte 0xF1 // gas doesn't assemble this instruction opcode but it disassembles it -#ifdef __x86_64__ - mov $60, %eax - syscall -#else - mov $1, %eax - int $0x80 -#endif -``` -2. Run on baremetal. Notice how it raises `SIGTRAP` according to the shell job control message -3. Run on qemu-user. Notice how it raises `SIGILL`. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/886621 b/results/classifier/zero-shot-user-mode/output/instruction/886621 deleted file mode 100644 index e35689512..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/886621 +++ /dev/null @@ -1,298 +0,0 @@ -instruction: 0.396 -runtime: 0.338 -syscall: 0.266 - - - -Mac OS X Lion: segmentation fault - - -Process: qemu [5680] -Path: /usr/local/xeos-build/qemu/bin/qemu -Identifier: qemu -Version: ??? (???) -Code Type: X86-64 (Native) -Parent Process: make [5677] - -Date/Time: 2011-11-05 18:53:25.574 +0100 -OS Version: Mac OS X 10.7.2 (11C74) -Report Version: 9 -Sleep/Wake UUID: 3C81B8F7-0321-4621-923C-AB655F2CC701 - -Interval Since Last Report: 503994 sec -Crashes Since Last Report: 35 -Per-App Crashes Since Last Report: 9 -Anonymous UUID: 28E7367A-4697-43A4-8D12-005F1917DFD3 - -Crashed Thread: 0 Dispatch queue: com.apple.main-thread - -Exception Type: EXC_BAD_ACCESS (SIGSEGV) -Exception Codes: KERN_INVALID_ADDRESS at 0x000000000000003a - -VM Regions Near 0x3a: ---> - __TEXT 0000000107c75000-0000000107ebc000 [ 2332K] r-x/rwx SM=COW /usr/local/xeos-build/qemu/bin/qemu - -Application Specific Information: -objc[5680]: garbage collection is OFF - -Thread 0 Crashed:: Dispatch queue: com.apple.main-thread -0 qemu 0x0000000107d9d0ed 0x107c75000 + 1212653 -1 qemu 0x0000000107dabc39 0x107c75000 + 1272889 -2 ??? 0x000000010c3b007c 0 + 4500160636 - -Thread 1:: Dispatch queue: com.apple.libdispatch-manager -0 libsystem_kernel.dylib 0x00007fff85abb7e6 kevent + 10 -1 libdispatch.dylib 0x00007fff8e7b15be _dispatch_mgr_invoke + 923 -2 libdispatch.dylib 0x00007fff8e7b014e _dispatch_mgr_thread + 54 - -Thread 2: -0 libsystem_kernel.dylib 0x00007fff85abb192 __workq_kernreturn + 10 -1 libsystem_c.dylib 0x00007fff85886594 _pthread_wqthread + 758 -2 libsystem_c.dylib 0x00007fff85887b85 start_wqthread + 13 - -Thread 3: -0 libsystem_kernel.dylib 0x00007fff85abb192 __workq_kernreturn + 10 -1 libsystem_c.dylib 0x00007fff85886594 _pthread_wqthread + 758 -2 libsystem_c.dylib 0x00007fff85887b85 start_wqthread + 13 - -Thread 4: -0 libsystem_kernel.dylib 0x00007fff85abb192 __workq_kernreturn + 10 -1 libsystem_c.dylib 0x00007fff85886594 _pthread_wqthread + 758 -2 libsystem_c.dylib 0x00007fff85887b85 start_wqthread + 13 - -Thread 5: -0 libsystem_kernel.dylib 0x00007fff85abb036 __sigwait + 10 -1 libsystem_c.dylib 0x00007fff8583aaab sigwait + 68 -2 qemu 0x0000000107d221ef 0x107c75000 + 709103 -3 libsystem_c.dylib 0x00007fff858848bf _pthread_start + 335 -4 libsystem_c.dylib 0x00007fff85887b75 thread_start + 13 - -Thread 0 crashed with X86 Thread State (64-bit): - rax: 0x5433ade07f7c29e7 rbx: 0x0000000000000010 rcx: 0x0000000000000000 rdx: 0x0000000000002000 - rdi: 0x0000000000000010 rsi: 0x0000000000000000 rbp: 0x00007fff678714a0 rsp: 0x00007fff67871470 - r8: 0x0000000109fe8000 r9: 0x0000000000000fff r10: 0x00007fa7c185c01d r11: 0x0000000000000246 - r12: 0x00000001087ae368 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000001f80 - rip: 0x0000000107d9d0ed rfl: 0x0000000000010202 cr2: 0x000000000000003a -Logical CPU: 6 - -Binary Images: - 0x107c75000 - 0x107ebbff7 +qemu (??? - ???) <FECE8C8E-BD8E-34F1-B222-32D79C7A0037> /usr/local/xeos-build/qemu/bin/qemu - 0x1087cb000 - 0x1088b5fe7 +libglib-2.0.0.dylib (2704.0.0 - compatibility 2704.0.0) <5E6151CC-61F8-3335-A6FA-EFDD71474FA6> /usr/local/macmade/sw/glib/lib/libglib-2.0.0.dylib - 0x108917000 - 0x10891ffff +libintl.8.dylib (9.1.0 - compatibility 9.0.0) <7D75E177-3172-2F78-1E08-1118A3D2D2A9> /usr/local/webstart/sw/gettext/lib/libintl.8.dylib - 0x108928000 - 0x108949fff +libpng12.0.dylib (23.0.0 - compatibility 23.0.0) <FDE69E98-1D25-EEA1-99CF-F0A04A9AD7FF> /usr/local/webstart/sw/lib-png/lib/libpng12.0.dylib - 0x10895a000 - 0x10897aff7 +libjpeg.62.dylib (63.0.0 - compatibility 63.0.0) <AD465C8A-66A4-E794-CA9A-96FB1B4D6CF0> /usr/local/webstart/sw/lib-jpeg/lib/libjpeg.62.dylib - 0x108987000 - 0x108a67ff7 +libiconv.2.dylib (8.0.0 - compatibility 8.0.0) <54A03BBE-E505-9FF1-79AA-D4D5139BBF9C> /usr/local/webstart/sw/lib-iconv/lib/libiconv.2.dylib - 0x7fff67875000 - 0x7fff678a9ac7 dyld (195.5 - ???) <4A6E2B28-C7A2-3528-ADB7-4076B9836041> /usr/lib/dyld - 0x7fff8547d000 - 0x7fff8547efff libDiagnosticMessagesClient.dylib (??? - ???) <3DCF577B-F126-302B-BCE2-4DB9A95B8598> /usr/lib/libDiagnosticMessagesClient.dylib - 0x7fff8582b000 - 0x7fff8582efff com.apple.help (1.3.2 - 42) <AB67588E-7227-3993-927F-C9E6DAC507FD> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help - 0x7fff8582f000 - 0x7fff85835fff libmacho.dylib (800.0.0 - compatibility 1.0.0) <D86F63EC-D2BD-32E0-8955-08B5EAFAD2CC> /usr/lib/system/libmacho.dylib - 0x7fff85836000 - 0x7fff85913fef libsystem_c.dylib (763.12.0 - compatibility 1.0.0) <FF69F06E-0904-3C08-A5EF-536FAFFFDC22> /usr/lib/system/libsystem_c.dylib - 0x7fff85914000 - 0x7fff85914fff com.apple.audio.units.AudioUnit (1.7.1 - 1.7.1) <04C10813-CCE5-3333-8C72-E8E35E417B3B> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit - 0x7fff85915000 - 0x7fff8591bfff IOSurface (??? - ???) <06FA3FDD-E6D5-391F-B60D-E98B169DAB1B> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface - 0x7fff85964000 - 0x7fff85972fff com.apple.NetAuth (1.0 - 3.0) <F384FFFD-70F6-3B1C-A886-F5B446E456E7> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth - 0x7fff85aa4000 - 0x7fff85ac4fff libsystem_kernel.dylib (1699.22.73 - compatibility 1.0.0) <69F2F501-72D8-3B3B-8357-F4418B3E1348> /usr/lib/system/libsystem_kernel.dylib - 0x7fff85ac5000 - 0x7fff85b10ff7 com.apple.SystemConfiguration (1.11.1 - 1.11) <F832FE21-5509-37C6-B1F1-48928F31BE45> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration - 0x7fff85c2a000 - 0x7fff85c39ff7 com.apple.opengl (1.7.5 - 1.7.5) <2945F1A6-910C-3596-9988-5701B04BD821> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL - 0x7fff85c3a000 - 0x7fff85c3eff7 com.apple.CommonPanels (1.2.5 - 94) <0BB2C436-C9D5-380B-86B5-E355A7711259> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels - 0x7fff85ebb000 - 0x7fff85fbefff libsqlite3.dylib (9.6.0 - compatibility 9.0.0) <7F60B0FF-4946-3639-89AB-B540D318B249> /usr/lib/libsqlite3.dylib - 0x7fff85fbf000 - 0x7fff86063fef com.apple.ink.framework (1.3.2 - 110) <F69DBD44-FEC8-3C14-8131-CC0245DBBD42> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink - 0x7fff860c5000 - 0x7fff860cafff libpam.2.dylib (3.0.0 - compatibility 3.0.0) <D952F17B-200A-3A23-B9B2-7C1F7AC19189> /usr/lib/libpam.2.dylib - 0x7fff860dd000 - 0x7fff86147fff com.apple.framework.IOKit (2.0 - ???) <87D55F1D-CDB5-3D13-A5F9-98EA4E22F8EE> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit - 0x7fff86148000 - 0x7fff8614ffff libcopyfile.dylib (85.1.0 - compatibility 1.0.0) <172B1985-F24A-34E9-8D8B-A2403C9A0399> /usr/lib/system/libcopyfile.dylib - 0x7fff8627e000 - 0x7fff862abfe7 libSystem.B.dylib (159.1.0 - compatibility 1.0.0) <095FDD3C-3961-3865-A59B-A5B0A4B8B923> /usr/lib/libSystem.B.dylib - 0x7fff862ac000 - 0x7fff86314ff7 com.apple.Symbolication (1.2 - 89) <1D7F9E72-B1B6-30CF-AC8A-23A763930A92> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication - 0x7fff86315000 - 0x7fff86316ff7 libsystem_blocks.dylib (53.0.0 - compatibility 1.0.0) <8BCA214A-8992-34B2-A8B9-B74DEACA1869> /usr/lib/system/libsystem_blocks.dylib - 0x7fff8633a000 - 0x7fff8634cff7 libbsm.0.dylib (??? - ???) <349BB16F-75FA-363F-8D98-7A9C3FA90A0D> /usr/lib/libbsm.0.dylib - 0x7fff8634d000 - 0x7fff863b5ff7 com.apple.audio.CoreAudio (4.0.1 - 4.0.1) <7966E3BE-376B-371A-A21D-9BD763C0BAE7> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio - 0x7fff86411000 - 0x7fff86423ff7 libsasl2.2.dylib (3.15.0 - compatibility 3.0.0) <6245B497-784B-355C-98EF-2DC6B45BF05C> /usr/lib/libsasl2.2.dylib - 0x7fff86428000 - 0x7fff86462fff libncurses.5.4.dylib (5.4.0 - compatibility 5.4.0) <387DE593-9CC5-38C7-911B-A5F2264D34F2> /usr/lib/libncurses.5.4.dylib - 0x7fff86463000 - 0x7fff864a2ff7 libGLImage.dylib (??? - ???) <2D1D8488-EC5F-3229-B983-CFDE0BB37586> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib - 0x7fff864a3000 - 0x7fff86545ff7 com.apple.securityfoundation (5.0 - 55005) <0D59908C-A61B-389E-AF37-741ACBBA6A94> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation - 0x7fff86546000 - 0x7fff865cbff7 com.apple.Heimdal (2.1 - 2.0) <C92E327E-CB5F-3C9B-92B0-F1680095C8A3> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal - 0x7fff865cc000 - 0x7fff865d0fff libCGXType.A.dylib (600.0.0 - compatibility 64.0.0) <5EEAD17D-006C-3855-8093-C7A4A97EE0D0> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib - 0x7fff865d1000 - 0x7fff8664cff7 com.apple.print.framework.PrintCore (7.1 - 366.1) <3F140DEB-9F87-3672-97CC-F983752581AC> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore - 0x7fff8664d000 - 0x7fff86654ff7 com.apple.CommerceCore (1.0 - 17) <AA783B87-48D4-3CA6-8FF6-0316396022F4> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore - 0x7fff86655000 - 0x7fff86655fff com.apple.Accelerate.vecLib (3.7 - vecLib 3.7) <C06A140F-6114-3B8B-B080-E509303145B8> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib - 0x7fff86656000 - 0x7fff8665afff libmathCommon.A.dylib (2026.0.0 - compatibility 1.0.0) <FF83AFF7-42B2-306E-90AF-D539C51A4542> /usr/lib/system/libmathCommon.A.dylib - 0x7fff8665b000 - 0x7fff86768fff libJP2.dylib (??? - ???) <6052C973-9354-35CB-AAB9-31D00D8786F9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib - 0x7fff86769000 - 0x7fff867acff7 libRIP.A.dylib (600.0.0 - compatibility 64.0.0) <2B1571E1-8E87-364E-BC36-C9C9B5D3EAC4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib - 0x7fff867ad000 - 0x7fff86d91fff libBLAS.dylib (??? - ???) <C34F6D88-187F-33DC-8A68-C0C9D1FA36DF> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib - 0x7fff86d92000 - 0x7fff86da4ff7 libz.1.dylib (1.2.5 - compatibility 1.0.0) <30CBEF15-4978-3DED-8629-7109880A19D4> /usr/lib/libz.1.dylib - 0x7fff87016000 - 0x7fff8701cfff libGFXShared.dylib (??? - ???) <343AE6C0-EB02-333C-8D35-DF6093B92758> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib - 0x7fff8701d000 - 0x7fff87290fff com.apple.CoreImage (7.82 - 1.0.1) <282801B6-5D80-3E2C-88A4-00FE29906D5A> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage - 0x7fff872da000 - 0x7fff87315fff com.apple.LDAPFramework (3.0 - 120.1) <0C23534F-A8E7-3144-B2B2-50F9875101E2> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP - 0x7fff87322000 - 0x7fff87524fff libicucore.A.dylib (46.1.0 - compatibility 1.0.0) <38CD6ED3-C8E4-3CCD-89AC-9C3198803101> /usr/lib/libicucore.A.dylib - 0x7fff87a4c000 - 0x7fff87a4dfff libsystem_sandbox.dylib (??? - ???) <8D14139B-B671-35F4-9E5A-023B4C523C38> /usr/lib/system/libsystem_sandbox.dylib - 0x7fff87b4f000 - 0x7fff87b4ffff libkeymgr.dylib (23.0.0 - compatibility 1.0.0) <61EFED6A-A407-301E-B454-CD18314F0075> /usr/lib/system/libkeymgr.dylib - 0x7fff87b50000 - 0x7fff87ba7fff libTIFF.dylib (??? - ???) <FF0D9A24-6956-3F03-81EA-3EEAD22C9DB8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib - 0x7fff87c87000 - 0x7fff8839a587 com.apple.CoreGraphics (1.600.0 - ???) <A9F2451E-6F60-350E-A6E5-539669B53074> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics - 0x7fff8839b000 - 0x7fff883b1ff7 com.apple.ImageCapture (7.0 - 7.0) <69E6E2E1-777E-332E-8BCF-4F0611517DD0> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture - 0x7fff883b2000 - 0x7fff883b9fff com.apple.NetFS (4.0 - 4.0) <B9F41443-679A-31AD-B0EB-36557DAF782B> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS - 0x7fff883d7000 - 0x7fff884b5fff com.apple.ImageIO.framework (3.1.1 - 3.1.1) <13E549F8-5BD6-3BAE-8C33-1D0BD269C081> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO - 0x7fff884b6000 - 0x7fff884b6fff com.apple.Cocoa (6.6 - ???) <021D4214-9C23-3CD8-AFB2-F331697A4508> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa - 0x7fff884b7000 - 0x7fff884b7fff com.apple.ApplicationServices (41 - 41) <03F3FA8F-8D2A-3AB6-A8E3-40B001116339> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices - 0x7fff884b8000 - 0x7fff8861efff com.apple.CFNetwork (520.2.5 - 520.2.5) <406712D9-3F0C-3763-B4EB-868D01F1F042> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork - 0x7fff8861f000 - 0x7fff88943fff com.apple.HIToolbox (1.8 - ???) <A3BE7C59-52E6-3A7F-9B30-24B7DD3E95F2> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox - 0x7fff88944000 - 0x7fff88961ff7 com.apple.openscripting (1.3.3 - ???) <A64205E6-D3C5-3E12-B1A0-72243151AF7D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting - 0x7fff88962000 - 0x7fff88c3aff7 com.apple.security (7.0 - 55010) <93713FF4-FE86-3B4C-8150-5FCC7F3320C8> /System/Library/Frameworks/Security.framework/Versions/A/Security - 0x7fff88c5b000 - 0x7fff88cbbfff libvDSP.dylib (325.4.0 - compatibility 1.0.0) <3A7521E6-5510-3FA7-AB65-79693A7A5839> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib - 0x7fff88cbf000 - 0x7fff88d43ff7 com.apple.ApplicationServices.ATS (317.5.0 - ???) <FE629F2D-6BC0-3A58-9844-D8B9A6808A00> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS - 0x7fff88d81000 - 0x7fff88e48ff7 com.apple.ColorSync (4.7.0 - 4.7.0) <F325A9D7-7203-36B7-8C1C-B6A4D5CC73A8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync - 0x7fff88e59000 - 0x7fff88e6dff7 com.apple.LangAnalysis (1.7.0 - 1.7.0) <04C31EF0-912A-3004-A08F-CEC27030E0B2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis - 0x7fff88e6e000 - 0x7fff88e79ff7 com.apple.speech.recognition.framework (4.0.19 - 4.0.19) <7ADAAF5B-1D78-32F2-9FFF-D2E3FBB41C2B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition - 0x7fff88f54000 - 0x7fff88f55fff libunc.dylib (24.0.0 - compatibility 1.0.0) <C67B3B14-866C-314F-87FF-8025BEC2CAAC> /usr/lib/system/libunc.dylib - 0x7fff89095000 - 0x7fff89148fff com.apple.CoreText (220.11.0 - ???) <4EA8E2DF-542D-38D5-ADB9-C0DAA73F898B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText - 0x7fff8932e000 - 0x7fff894cdfff com.apple.QuartzCore (1.7 - 270.0) <E8FC9AA4-A5CB-384B-AD29-7190A1387D3E> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore - 0x7fff894f6000 - 0x7fff89530fe7 com.apple.DebugSymbols (2.1 - 87) <E9000AB8-CCE4-3636-871D-E17703814B68> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols - 0x7fff89531000 - 0x7fff8958cff7 com.apple.HIServices (1.10 - ???) <BAB8B422-7047-3D2D-8E0A-13FCF153E4E7> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices - 0x7fff89a1d000 - 0x7fff89a6bfff libauto.dylib (??? - ???) <D8AC8458-DDD0-3939-8B96-B6CED81613EF> /usr/lib/libauto.dylib - 0x7fff89a6c000 - 0x7fff89ac0ff7 com.apple.ScalableUserInterface (1.0 - 1) <1873D7BE-2272-31A1-8F85-F70C4D706B3B> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface - 0x7fff89ac1000 - 0x7fff89ae0fff libresolv.9.dylib (46.0.0 - compatibility 1.0.0) <33263568-E6F3-359C-A4FA-66AD1300F7D4> /usr/lib/libresolv.9.dylib - 0x7fff89b26000 - 0x7fff89b65fff com.apple.AE (527.7 - 527.7) <B82F7ABC-AC8B-3507-B029-969DD5CA813D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE - 0x7fff89fd5000 - 0x7fff8a1a9fff com.apple.CoreFoundation (6.7.1 - 635.15) <FE4A86C2-3599-3CF8-AD1A-822F1FEA820F> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation - 0x7fff8a1aa000 - 0x7fff8a1d3fff libJPEG.dylib (??? - ???) <64D079F9-256A-323B-A837-84628B172F21> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib - 0x7fff8a929000 - 0x7fff8a94dfff com.apple.Kerberos (1.0 - 1) <1F826BCE-DA8F-381D-9C4C-A36AA0EA1CB9> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos - 0x7fff8a94e000 - 0x7fff8a94efff com.apple.CoreServices (53 - 53) <043C8026-8EDD-3241-B090-F589E24062EF> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices - 0x7fff8a94f000 - 0x7fff8a9c4ff7 libc++.1.dylib (19.0.0 - compatibility 1.0.0) <C0EFFF1B-0FEB-3F99-BE54-506B35B555A9> /usr/lib/libc++.1.dylib - 0x7fff8af21000 - 0x7fff8afa4fef com.apple.Metadata (10.7.0 - 627.20) <E00156B0-663A-35EF-A307-A2CEB00F1845> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata - 0x7fff8b02d000 - 0x7fff8b036ff7 libsystem_notify.dylib (80.1.0 - compatibility 1.0.0) <A4D651E3-D1C6-3934-AD49-7A104FD14596> /usr/lib/system/libsystem_notify.dylib - 0x7fff8b06d000 - 0x7fff8b10cfff com.apple.LaunchServices (480.21 - 480.21) <6BFADEA9-5BC1-3B53-A013-488EB7F1AB57> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices - 0x7fff8b10d000 - 0x7fff8b14efff com.apple.QD (3.12 - ???) <4F3C5629-97C7-3E55-AF3C-ACC524929DA2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD - 0x7fff8b14f000 - 0x7fff8b251ff7 libxml2.2.dylib (10.3.0 - compatibility 10.0.0) <D46F371D-6422-31B7-BCE0-D80713069E0E> /usr/lib/libxml2.2.dylib - 0x7fff8b2f6000 - 0x7fff8b2f9fff libCoreVMClient.dylib (??? - ???) <E034C772-4263-3F48-B083-25A758DD6228> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib - 0x7fff8b2fd000 - 0x7fff8b402ff7 libFontParser.dylib (??? - ???) <B9A53808-C97E-3293-9C33-1EA9D4E83EC8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib - 0x7fff8b41e000 - 0x7fff8b449ff7 libxslt.1.dylib (3.24.0 - compatibility 3.0.0) <8051A3FC-7385-3EA9-9634-78FC616C3E94> /usr/lib/libxslt.1.dylib - 0x7fff8b49e000 - 0x7fff8b4a3fff libcompiler_rt.dylib (6.0.0 - compatibility 1.0.0) <98ECD5F6-E85C-32A5-98CD-8911230CB66A> /usr/lib/system/libcompiler_rt.dylib - 0x7fff8b656000 - 0x7fff8b65bfff libcache.dylib (47.0.0 - compatibility 1.0.0) <B7757E2E-5A7D-362E-AB71-785FE79E1527> /usr/lib/system/libcache.dylib - 0x7fff8b65c000 - 0x7fff8b695fe7 libssl.0.9.8.dylib (44.0.0 - compatibility 0.9.8) <79AAEC98-1258-3DA4-B1C0-4120049D390B> /usr/lib/libssl.0.9.8.dylib - 0x7fff8b696000 - 0x7fff8b69bff7 libsystem_network.dylib (??? - ???) <5DE7024E-1D2D-34A2-80F4-08326331A75B> /usr/lib/system/libsystem_network.dylib - 0x7fff8b6c6000 - 0x7fff8b6d1ff7 libc++abi.dylib (14.0.0 - compatibility 1.0.0) <8FF3D766-D678-36F6-84AC-423C878E6D14> /usr/lib/libc++abi.dylib - 0x7fff8b909000 - 0x7fff8bd36fff libLAPACK.dylib (??? - ???) <4F2E1055-2207-340B-BB45-E4F16171EE0D> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib - 0x7fff8bd37000 - 0x7fff8bd42fff com.apple.CommonAuth (2.1 - 2.0) <BFDD0A8D-4BEA-39EC-98B3-2E083D7B1ABD> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth - 0x7fff8bd43000 - 0x7fff8bd76ff7 com.apple.GSS (2.1 - 2.0) <9A2C9736-DA10-367A-B376-2C7A584E6C7A> /System/Library/Frameworks/GSS.framework/Versions/A/GSS - 0x7fff8bd77000 - 0x7fff8bd78ff7 libremovefile.dylib (21.0.0 - compatibility 1.0.0) <C6C49FB7-1892-32E4-86B5-25AD165131AA> /usr/lib/system/libremovefile.dylib - 0x7fff8bd79000 - 0x7fff8bd7dfff libdyld.dylib (195.5.0 - compatibility 1.0.0) <F1903B7A-D3FF-3390-909A-B24E09BAD1A5> /usr/lib/system/libdyld.dylib - 0x7fff8bdac000 - 0x7fff8bdc8ff7 com.apple.GenerationalStorage (1.0 - 125) <31F60175-E38D-3C63-8D95-32CFE7062BCB> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage - 0x7fff8bdcd000 - 0x7fff8bdf5ff7 com.apple.CoreVideo (1.7 - 70.1) <98F917B2-FB53-3EA3-B548-7E97B38309A7> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo - 0x7fff8bdf6000 - 0x7fff8be0dfff com.apple.MultitouchSupport.framework (220.62.1 - 220.62.1) <F21C79C0-4B5A-3645-81A6-74F8EFA900CE> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport - 0x7fff8be0e000 - 0x7fff8be34ff7 com.apple.framework.familycontrols (3.0 - 300) <41A6DFC2-EAF5-390A-83A1-C8832528705C> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls - 0x7fff8c071000 - 0x7fff8c155def libobjc.A.dylib (228.0.0 - compatibility 1.0.0) <C5F2392D-B481-3A9D-91BE-3D039FFF4DEC> /usr/lib/libobjc.A.dylib - 0x7fff8c156000 - 0x7fff8c17dfff com.apple.PerformanceAnalysis (1.10 - 10) <2A058167-292E-3C3A-B1F8-49813336E068> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis - 0x7fff8c17e000 - 0x7fff8c1c0ff7 libcommonCrypto.dylib (55010.0.0 - compatibility 1.0.0) <A5B9778E-11C3-3F61-B740-1F2114E967FB> /usr/lib/system/libcommonCrypto.dylib - 0x7fff8c3ff000 - 0x7fff8c452fff libFontRegistry.dylib (??? - ???) <57FBD85F-41A6-3DB9-B5F4-FCC6B260F1AD> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib - 0x7fff8c461000 - 0x7fff8c4fbff7 com.apple.SearchKit (1.4.0 - 1.4.0) <4E70C394-773E-3A4B-A93C-59A88ABA9509> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit - 0x7fff8d20f000 - 0x7fff8d24aff7 libsystem_info.dylib (??? - ???) <9C8C2DCB-96DB-3471-9DCE-ADCC26BE2DD4> /usr/lib/system/libsystem_info.dylib - 0x7fff8d24b000 - 0x7fff8d250fff libGIF.dylib (??? - ???) <393E2DB5-9479-39A6-A75A-B5F20B852532> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib - 0x7fff8d251000 - 0x7fff8d268fff com.apple.CFOpenDirectory (10.7 - 144) <9709423E-8484-3B26-AAE8-EF58D1B8FB3F> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory - 0x7fff8d269000 - 0x7fff8d26efff com.apple.OpenDirectory (10.7 - 146) <91A87249-6A2F-3F89-A8DE-0E95C0B54A3A> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory - 0x7fff8d26f000 - 0x7fff8d2c1ff7 libGLU.dylib (??? - ???) <3C9153A0-8499-3DC0-AAA4-9FA6E488BE13> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib - 0x7fff8d2c2000 - 0x7fff8d789fff FaceCoreLight (1.4.7 - compatibility 1.0.0) <E9D2A69C-6E81-358C-A162-510969F91490> /System/Library/PrivateFrameworks/FaceCoreLight.framework/Versions/A/FaceCoreLight - 0x7fff8d78a000 - 0x7fff8d792fff libsystem_dnssd.dylib (??? - ???) <7749128E-D0C5-3832-861C-BC9913F774FA> /usr/lib/system/libsystem_dnssd.dylib - 0x7fff8d793000 - 0x7fff8d7bcfff com.apple.CoreServicesInternal (113.8 - 113.8) <C1A3CF1B-BC45-3FC6-82B3-1511EBBA9D51> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal - 0x7fff8d823000 - 0x7fff8d838fff com.apple.speech.synthesis.framework (4.0.74 - 4.0.74) <C061ECBB-7061-3A43-8A18-90633F943295> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis - 0x7fff8e34d000 - 0x7fff8e371ff7 com.apple.RemoteViewServices (1.2 - 39) <862849C8-84C1-32A1-B87E-B29E74778C9F> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices - 0x7fff8e508000 - 0x7fff8e51bff7 libCRFSuite.dylib (??? - ???) <034D4DAA-63F0-35E4-BCEF-338DD7A453DD> /usr/lib/libCRFSuite.dylib - 0x7fff8e7a7000 - 0x7fff8e7a9ff7 com.apple.print.framework.Print (7.1 - 247.1) <8A4925A5-BAA3-373C-9B5D-03E0270C6B12> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print - 0x7fff8e7aa000 - 0x7fff8e7adff7 com.apple.securityhi (4.0 - 1) <B37B8946-BBD4-36C1-ABC6-18EDBC573F03> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI - 0x7fff8e7ae000 - 0x7fff8e7bcfff libdispatch.dylib (187.7.0 - compatibility 1.0.0) <712AAEAC-AD90-37F7-B71F-293FF8AE8723> /usr/lib/system/libdispatch.dylib - 0x7fff8e7bd000 - 0x7fff8e7befff liblangid.dylib (??? - ???) <CACBE3C3-2F7B-3EED-B50E-EDB73F473B77> /usr/lib/liblangid.dylib - 0x7fff8e7cc000 - 0x7fff8e7e9fff libPng.dylib (??? - ???) <3C70A94C-9442-3E11-AF51-C1B0EF81680E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib - 0x7fff8e7ea000 - 0x7fff8e7eafff com.apple.Accelerate (1.7 - Accelerate 1.7) <82DDF6F5-FBC3-323D-B71D-CF7ABC5CF568> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate - 0x7fff8e7eb000 - 0x7fff8e801fff libGL.dylib (??? - ???) <6A473BF9-4D35-34C6-9F8B-86B68091A9AF> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib - 0x7fff8e810000 - 0x7fff8e81aff7 liblaunch.dylib (392.18.0 - compatibility 1.0.0) <39EF04F2-7F0C-3435-B785-BF283727FFBD> /usr/lib/system/liblaunch.dylib - 0x7fff8e95f000 - 0x7fff8e9f5ff7 libvMisc.dylib (325.4.0 - compatibility 1.0.0) <642D8D54-F9F5-3FBB-A96C-EEFE94C6278B> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib - 0x7fff8e9f6000 - 0x7fff8ec10fef com.apple.CoreData (104 - 358.12) <33B1FA75-7970-3751-9DCC-FF809D3E1FA2> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData - 0x7fff8ef91000 - 0x7fff8f2aaff7 com.apple.Foundation (6.7.1 - 833.20) <D922F590-FDA6-3D89-A271-FD35E2290624> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation - 0x7fff8f2ab000 - 0x7fff8f38cfff com.apple.CoreServices.OSServices (478.29 - 478.29) <B487110E-C942-33A8-A494-3BDEDB88B1CD> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices - 0x7fff8f3c8000 - 0x7fff8f3d5fff libCSync.A.dylib (600.0.0 - compatibility 64.0.0) <931F40EB-CA75-3A90-AC97-4DB8E210BC76> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib - 0x7fff8f44d000 - 0x7fff8f4c0fff libstdc++.6.dylib (52.0.0 - compatibility 7.0.0) <6BDD43E4-A4B1-379E-9ED5-8C713653DFF2> /usr/lib/libstdc++.6.dylib - 0x7fff8f7e3000 - 0x7fff8f7e3fff com.apple.Carbon (153 - 153) <895C2BF2-1666-3A59-A669-311B1F4F368B> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon - 0x7fff8fb82000 - 0x7fff8fc9aff7 com.apple.DesktopServices (1.6.1 - 1.6.1) <4418EAA6-7163-3A77-ABD3-F8289796C81A> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv - 0x7fff8fc9d000 - 0x7fff8fc9ffff com.apple.TrustEvaluationAgent (2.0 - 1) <1F31CAFF-C1C6-33D3-94E9-11B721761DDF> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent - 0x7fff8fca0000 - 0x7fff8fdf9fff com.apple.audio.toolbox.AudioToolbox (1.7.1 - 1.7.1) <4877267E-F736-3019-85D3-40A32A042A80> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox - 0x7fff8fef9000 - 0x7fff8ff39ff7 libcups.2.dylib (2.9.0 - compatibility 2.0.0) <B7173CA4-CE16-3BAB-8D83-185FCEFA15F5> /usr/lib/libcups.2.dylib - 0x7fff8ff9c000 - 0x7fff900a8fff libcrypto.0.9.8.dylib (44.0.0 - compatibility 0.9.8) <3A8E1F89-5E26-3C8B-B538-81F5D61DBF8A> /usr/lib/libcrypto.0.9.8.dylib - 0x7fff900a9000 - 0x7fff900b7ff7 libkxld.dylib (??? - ???) <65BE345D-6618-3D1A-9E2B-255E629646AA> /usr/lib/system/libkxld.dylib - 0x7fff900b8000 - 0x7fff900beff7 libunwind.dylib (30.0.0 - compatibility 1.0.0) <1E9C6C8C-CBE8-3F4B-A5B5-E03E3AB53231> /usr/lib/system/libunwind.dylib - 0x7fff900cb000 - 0x7fff90204fef com.apple.vImage (5.1 - 5.1) <EB634387-CD15-3246-AC28-5FB368ACCEA2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage - 0x7fff9020d000 - 0x7fff9023dff7 com.apple.DictionaryServices (1.2.1 - 158.2) <3FC86118-7553-38F7-8916-B329D2E94476> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices - 0x7fff9024e000 - 0x7fff90343fff libiconv.2.dylib (7.0.0 - compatibility 7.0.0) <5C40E880-0706-378F-B864-3C2BD922D926> /usr/lib/libiconv.2.dylib - 0x7fff90344000 - 0x7fff9038aff7 libcurl.4.dylib (7.0.0 - compatibility 7.0.0) <EAF61ADC-DC00-34CE-B23E-7238ED54E31D> /usr/lib/libcurl.4.dylib - 0x7fff9038b000 - 0x7fff903a8ff7 libxpc.dylib (77.17.0 - compatibility 1.0.0) <72A16104-2F23-3C22-B474-1953F06F9376> /usr/lib/system/libxpc.dylib - 0x7fff90b3e000 - 0x7fff90b3ffff libdnsinfo.dylib (395.6.0 - compatibility 1.0.0) <718A135F-6349-354A-85D5-430B128EFD57> /usr/lib/system/libdnsinfo.dylib - 0x7fff90b40000 - 0x7fff90e5cff7 com.apple.CoreServices.CarbonCore (960.18 - 960.18) <6020C3FB-6125-3EAE-A55D-1E77E38BEDEA> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore - 0x7fff90e9b000 - 0x7fff90e9bfff com.apple.vecLib (3.7 - vecLib 3.7) <9A58105C-B36E-35B5-812C-4ED693F2618F> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib - 0x7fff90fe4000 - 0x7fff90feafff com.apple.DiskArbitration (2.4.1 - 2.4.1) <CEA34337-63DE-302E-81AA-10D717E1F699> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration - 0x7fff91024000 - 0x7fff91027fff libRadiance.dylib (??? - ???) <CD89D70D-F177-3BAE-8A26-644EA7D5E28E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib - 0x7fff91220000 - 0x7fff91222fff libquarantine.dylib (36.0.0 - compatibility 1.0.0) <4C3BFBC7-E592-3939-B376-1C2E2D7C5389> /usr/lib/system/libquarantine.dylib - 0x7fff91223000 - 0x7fff9128bfff com.apple.CoreSymbolication (2.1 - 71) <0715BF39-D53C-3BFE-BBEA-B8EBF7274850> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication - 0x7fff9128c000 - 0x7fff912eefff com.apple.coreui (1.2.1 - 164.1) <F7972630-F696-3FC5-9FCF-A6E1C8771078> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI - 0x7fff912ef000 - 0x7fff9135ffff com.apple.datadetectorscore (3.0 - 179.4) <2A822A13-94B3-3A43-8724-98FDF698BB12> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore - 0x7fff91367000 - 0x7fff91394ff7 com.apple.opencl (1.50.63 - 1.50.63) <DB335C5C-3ABD-38C8-B6A5-8436EE1484D3> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL - 0x7fff91395000 - 0x7fff91f96ff7 com.apple.AppKit (6.7.2 - 1138.23) <5CD2C850-4F52-3BA2-BA11-3107DFD2D23C> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit - 0x7fff91f97000 - 0x7fff91f99fff libCVMSPluginSupport.dylib (??? - ???) <61D89F3C-C64D-3733-819F-8AAAE4E2E993> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib - -External Modification Summary: - Calls made by other processes targeting this process: - task_for_pid: 2 - thread_create: 0 - thread_set_state: 0 - Calls made by this process: - task_for_pid: 0 - thread_create: 0 - thread_set_state: 0 - Calls made by all processes on this machine: - task_for_pid: 103153 - thread_create: 1 - thread_set_state: 0 - -VM Region Summary: -ReadOnly portion of Libraries: Total=144.3M resident=100.5M(70%) swapped_out_or_unallocated=43.8M(30%) -Writable regions: Total=185.9M written=3692K(2%) resident=23.0M(12%) swapped_out=0K(0%) unallocated=162.9M(88%) - -REGION TYPE VIRTUAL -=========== ======= -CG backing stores 1496K -CG image 4K -CG raster data 64K -CG shared images 3480K -CoreGraphics 16K -CoreServices 4112K -MALLOC 67.1M -MALLOC guard page 32K -MALLOC_LARGE (reserved) 25.3M reserved VM address space (unallocated) -Memory tag=242 12K -STACK GUARD 24K -Stack 66.5M -VM_ALLOCATE 16.1M -__CI_BITMAP 80K -__DATA 21.1M -__IMAGE 1256K -__LINKEDIT 48.1M -__TEXT 96.2M -__UNICODE 544K -mapped file 32.2M -shared memory 308K -=========== ======= -TOTAL 383.7M -TOTAL, minus reserved VM space 358.4M - -Model: MacBookPro8,3, BootROM MBP81.0047.B24, 4 processors, Intel Core i7, 2.3 GHz, 8 GB, SMC 1.70f3 -Graphics: AMD Radeon HD 6750M, AMD Radeon HD 6750M, PCIe, 1024 MB -Graphics: Intel HD Graphics 3000, Intel HD Graphics 3000, Built-In, 512 MB -Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80AD, 0x484D54333531533642465238432D48392020 -Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80AD, 0x484D54333531533642465238432D48392020 -AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xD6), Broadcom BCM43xx 1.0 (5.100.98.75.18) -Bluetooth: Version 4.0.1f4, 2 service, 11 devices, 1 incoming serial ports -Network Service: Wi-Fi, AirPort, en1 -Serial ATA Device: APPLE SSD TS512C, 500.28 GB -Serial ATA Device: MATSHITADVD-R UJ-898 -USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8509, 0xfa200000 / 3 -USB Device: hub_device, 0x0424 (SMSC), 0x2514, 0xfa100000 / 2 -USB Device: BRCM2070 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0xfa110000 / 5 -USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x821a, 0xfa113000 / 7 -USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0253, 0xfa120000 / 4 -USB Device: hub_device, 0x0424 (SMSC), 0x2514, 0xfd100000 / 2 -USB Device: Freecom Hard Drive XS, 0x07ab (Freecom Computer Peripherals), 0xfc8e, 0xfd120000 / 5 -USB Device: IR Receiver, apple_vendor_id, 0x8242, 0xfd110000 / 3 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/instruction/909 b/results/classifier/zero-shot-user-mode/output/instruction/909 deleted file mode 100644 index 17bf85ca7..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/909 +++ /dev/null @@ -1,17 +0,0 @@ -instruction: 0.529 -runtime: 0.314 -syscall: 0.157 - - - -qemu-mipsn32(el) user mode emulator fails to execute any recently built n32 binaries -Description of problem: -**Note: Before trying to reproduce this issue, have a look at issue 843 - the binfmt-misc magic for n32 needs to be fixed.** - -Trying to chroot into a mips n32 installation fails with -``` -/bin/bash: error while loading shared libraries: /lib32/libc.so.6: cannot read file data -``` -however, bash, libc.so.6, and qemu all exist and have the proper abi - -The problem occurs for both big and little endian N32 ABI. O32 and N64 work fine. The same N32 binaries also work fine on native hardware. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/911 b/results/classifier/zero-shot-user-mode/output/instruction/911 deleted file mode 100644 index 7d7d9199f..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/911 +++ /dev/null @@ -1,23 +0,0 @@ -instruction: 0.462 -syscall: 0.333 -runtime: 0.205 - - - -Unable to strace execve calls in mipsel user mode -Description of problem: -Used 6.2.0 ZIP and git to build, configured with -``` -./configure --target-list=mipsel-linux-user --static --disable-system --enable-linux-user -``` - -When trying to strace a mipsel-arch application, I cannot see traces for the `execve` syscall. It looks like the call to `safe_execve` is not returning, so the strace printout is never completed. I'm assuming this has to do with `execve` syscall not returning on success, but older versions appeared to be able to do it. I tried it with QEMU 4.2.1 from the package manager on Ubuntu and I saw the `execve` syscall (see qemu-4.2.1.log). -Steps to reproduce: -1. Build mipsel app: ` mipsel-linux-gnu-gcc -o test.mipsel test.c` (Test code is attached as `test.c`) -2. Run qemu-mipsel: `./build/qemu-mipsel -L /usr/mipsel-linux-gnu/ -strace ../test.mipsel` -3. Note that even though the app uses both `system` and `popen` to create subprocesses, no `execve` syscall is shown in the strace output. -Additional information: -[qemu-6.2.90.log](/uploads/ca03e6f40b3b0ea79a042786a123760a/qemu-6.2.90.log) -[qemu-6.2.0.log](/uploads/ca15057398377d49b396e9e77a5cb639/qemu-6.2.0.log) -[qemu-4.2.1.log](/uploads/1087250dd9fc4d8d106d2cbc58c2b14a/qemu-4.2.1.log) -[test.c](/uploads/9d242a724b10b296cfd7a945ae4d6c4d/test.c) diff --git a/results/classifier/zero-shot-user-mode/output/instruction/922 b/results/classifier/zero-shot-user-mode/output/instruction/922 deleted file mode 100644 index 0e9b62e3b..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/922 +++ /dev/null @@ -1,26 +0,0 @@ -instruction: 0.698 -runtime: 0.168 -syscall: 0.134 - - - -QEMU 7.0.0-rc0: Random segfaults when running grep using qemu-arm-static -Description of problem: -I'm running ARM binaries using 32 bit qemu-arm-static on x86_64 host. Sometimes when running grep via qemu, I get a random segmentation fault. Sometimes it happens faster, sometimes it takes several thousand iterations, but sooner or later it happens and really annoying. - -This problem is also reproduced on 6.2, 5.2 and 5.1 releases, and NOT reproduced on 5.0 - -I wrote small test to demonstrate this bug. -Steps to reproduce: -1. Download the test environment: [qemu-test-segfault.tar.bz2](/uploads/8f52617d46ba1e5bf29fc273cd07131d/qemu-test-segfault.tar.bz2) -2. `$ make # To build the docker container` -3. `$ make shell # To run ARM bash` -4. Inside a container, run `while true; do /qemu /bin/grep -E f text > /dev/null; [ $? -ne 0 ] && break; done`. After a while you will get segfault: -``` -[root@0d81b08f032b /]# /qemu --version -qemu-arm version 6.2.90 -Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers -[root@0d81b08f032b /]# while true; do /qemu /bin/grep -E f text > /dev/null; [ $? -ne 0 ] && break; done -Segmentation fault (core dumped) -[root@0d81b08f032b /]# -``` diff --git a/results/classifier/zero-shot-user-mode/output/instruction/927 b/results/classifier/zero-shot-user-mode/output/instruction/927 deleted file mode 100644 index 21b82ff93..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/927 +++ /dev/null @@ -1,38 +0,0 @@ -instruction: 0.498 -syscall: 0.358 -runtime: 0.144 - - - -linux-user: openat on /proc/self/exe can return a closed file descriptor -Description of problem: -`open("/proc/self/exe", ...)` returns a closed file descriptor if qemu-user was executed as an interpreter, passing a file descriptor in the `AT_EXECFD` auxval. - -When the `AT_EXECFD` auxval is nonzero the user program is loaded through `load_elf_binary()` (in `linux-user/elfload.c`) which ultimately calls `load_elf_image()` with that same file descriptor, and `load_elf_image()` closes the file descriptor before returning. - -`do_openat` in `linux-user/syscall.c` will return that file descriptor to the user if the opened path satisfies `is_proc_myself(pathname, "exe")`, which is obviously wrong both in that the file descriptor is closed as part of the initialization process of qemu itself, and that the user program would then close that file descriptor and thus the next invocation of `open` would have the same problem. -Steps to reproduce: -This program prints `3 3` in a x86_64 docker container on my machine (arm64 macos, which docker desktop handles by running containers in a native linux VM under qemu-user). - -```c -#include <fcntl.h> -#include <stdio.h> - -int main(int argc, char **argv) { - int selfexe = open("/proc/self/exe", O_RDONLY | O_CLOEXEC); - if (selfexe < 0) { - perror("open self"); - return 1; - } - - int devnull = open("/dev/null", O_WRONLY | O_CLOEXEC); - if (devnull < 0) { - perror("open devnull"); - return 1; - } - - printf("%d %d\n", selfexe, devnull); -} -``` -Additional information: -Thanks to @pm215 for helping me pinpoint the exact issue I was encountering. diff --git a/results/classifier/zero-shot-user-mode/output/instruction/947 b/results/classifier/zero-shot-user-mode/output/instruction/947 deleted file mode 100644 index fbabfbaae..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/947 +++ /dev/null @@ -1,19 +0,0 @@ -instruction: 0.760 -runtime: 0.142 -syscall: 0.098 - - - -TCG AARCH64 Segmentation fault when helper function is called -Description of problem: -Segmentation fault in the TCG thread. -The issue occurs in the generated code when branching to (helper)lookup_tb_ptr (see op longs). -It seems that the generated instruction don't load the upper32 of the address of lookup_tb_ptr in the register before branching to it. According to LLDB, the program tries to access 0x1cffe060 while the right address 0x7ff71cffe060 (see debugger logs). -Additional information: -The issue seems to be located at https://gitlab.com/qemu-project/qemu/-/blob/master/tcg/aarch64/tcg-target.c.inc#L1091 -`t2 = t1 & ~(0xffffUL << s1);`. -The fix would be `t2 = t1 & ~(0xffffULL << s1);` - - -[lldb.log](/uploads/6a1d57eaecae4a375c6ada7384489876/lldb.log) -[qemu_segmentation.log](/uploads/e3c2d6d42291ff7d1ff8d37341e3da1d/qemu_segmentation.log) diff --git a/results/classifier/zero-shot-user-mode/output/instruction/95 b/results/classifier/zero-shot-user-mode/output/instruction/95 deleted file mode 100644 index 69c03bac0..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/95 +++ /dev/null @@ -1,7 +0,0 @@ -instruction: 0.416 -syscall: 0.331 -runtime: 0.253 - - - -linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs running gnutls28, coreutils configure check code) diff --git a/results/classifier/zero-shot-user-mode/output/instruction/952 b/results/classifier/zero-shot-user-mode/output/instruction/952 deleted file mode 100644 index 8cf31e133..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/952 +++ /dev/null @@ -1,103 +0,0 @@ -instruction: 0.430 -runtime: 0.334 -syscall: 0.236 - - - -qemu: uncaught target signal 5 (Trace/breakpoint trap) -Description of problem: -I'm getting core dumped when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. - -And I found that QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signal. - -0xa602 <_start> movs r0, #22 - 0xa604 <_start+2> addw r1, pc, #186 ; 0xba -0xa608 <_start+6> bkpt 0x00ab - -$readelf -h hello - -ELF Header: - Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 - Class: ELF32 - Data: 2's complement, little endian - Version: 1 (current) - OS/ABI: UNIX - System V - ABI Version: 0 - Type: EXEC (Executable file) - Machine: ARM - Version: 0x1 - Entry point address: 0xa603 - Start of program headers: 52 (bytes into file) - Start of section headers: 144128 (bytes into file) - Flags: 0x5000200, Version5 EABI, soft-float ABI - Size of this header: 52 (bytes) - Size of program headers: 32 (bytes) - Number of program headers: 5 - Size of section headers: 40 (bytes) - Number of section headers: 16 - Section header string table index: 14 - -And I have check that the bug(https://bugs.launchpad.net/qemu/+bug/1873898) is fixed. - -But it's coredump. - -I found that bkpt instruction is not recognized, the bkpt is in 0x0000a608. - -host： -``` -$qemu-arm -g 12345 hello -``` -service: -``` -$gdb-multiarch hello -(gdb) target remote localhost:12345 -Remote debugging using localhost:12345 -0x0000a602 in _start () -(gdb) ni -0x0000a604 in _start () -(gdb) -0x0000a608 in _start () -(gdb) -0x0000a608 in _start () -``` -Another way to check: -``` -$gdb qemu-arm -(gdb) run hello -(gdb) bt -#0 0x00007ffff79474ba in __GI___sigsuspend (set=set@entry=0x7fffffffd9d8) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26 -#1 0x000055555573bfff in dump_core_and_abort (target_sig=target_sig@entry=5) at ../linux-user/signal.c:772 -#2 0x000055555573c3c8 in handle_pending_signal (cpu_env=cpu_env@entry=0x555555da5940, sig=sig@entry=5, k=k@entry=0x555555e60e00) at ../linux-user/signal.c:1099 -#3 0x000055555573de8c in process_pending_signals (cpu_env=cpu_env@entry=0x555555da5940) at ../linux-user/signal.c:1175 -#4 0x0000555555622070 in cpu_loop (env=0x555555da5940) at ../linux-user/arm/cpu_loop.c:472 -#5 0x0000555555603cf4 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../linux-user/main.c:883 -(gdb) up -#1 0x000055555573bfff in dump_core_and_abort (target_sig=target_sig@entry=5) at ../linux-user/signal.c:772 -772 sigsuspend(&act.sa_mask); -(gdb) -#2 0x000055555573c3c8 in handle_pending_signal (cpu_env=cpu_env@entry=0x555555da5940, sig=sig@entry=5, k=k@entry=0x555555e60e00) at ../linux-user/signal.c:1099 -1099 dump_core_and_abort(sig); -(gdb) -#3 0x000055555573de8c in process_pending_signals (cpu_env=cpu_env@entry=0x555555da5940) at ../linux-user/signal.c:1175 -1175 handle_pending_signal(cpu_env, sig, &ts->sync_signal); -(gdb) -#4 0x0000555555622070 in cpu_loop (env=0x555555da5940) at ../linux-user/arm/cpu_loop.c:472 -472 process_pending_signals(env); -(gdb) l -467 default: -468 error: -469 EXCP_DUMP(env, "qemu: unhandled CPU exception 0x%x - aborting\n", trapnr); -470 abort(); -471 } -472 process_pending_signals(env); -473 } -474 } -475 -476 void target_cpu_copy_regs(CPUArchState *env, struct target_pt_regs *regs) -(gdb) p cpu_exec(cs) -$2 = 7 -``` -Here process_pending_signals(env) gives SIGTRAP?? - -Here is my binary: -[hello](/uploads/7225e1f1c5a61ace40f90d5d2401a758/hello) diff --git a/results/classifier/zero-shot-user-mode/output/instruction/984 b/results/classifier/zero-shot-user-mode/output/instruction/984 deleted file mode 100644 index 466f91cf6..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/984 +++ /dev/null @@ -1,29 +0,0 @@ -instruction: 0.800 -syscall: 0.122 -runtime: 0.078 - - - -QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word -Description of problem: -~~The QEMU softfloat float64_to_floatx80 implementation is broken and does not produce correct results.~~ QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word. - -``` -IN = 1234.567890 (0x40934a4584f4c6e7) -OUT = 1234.567871 (0x40099a522c0000000000) -``` - -This bug was introduced in the QEMU commit qemu/qemu@8ae5719 as part of the switchover to FloatParts, and is still present in the latest tag (v7.0.0-rc4 as of now). - -Prior to the offending commit: - -``` -IN = 1234.567890 (0x40934a4584f4c6e7) -OUT = 1234.567890 (0x40099a522c27a6373800) -``` - -This breaks the i386 emulation of `fldl st(0)` (`helper_fldl_ST0`). -Steps to reproduce: -Call `float64_to_floatx80` with the input value of `1234.567890 (0x40934a4584f4c6e7)` and see the returned result. -Additional information: -See https://github.com/zephyrproject-rtos/sdk-ng/issues/461 diff --git a/results/classifier/zero-shot-user-mode/output/instruction/998 b/results/classifier/zero-shot-user-mode/output/instruction/998 deleted file mode 100644 index 89d88290a..000000000 --- a/results/classifier/zero-shot-user-mode/output/instruction/998 +++ /dev/null @@ -1,66 +0,0 @@ -instruction: 0.397 -runtime: 0.325 -syscall: 0.278 - - - -AArch64: SCTLR_EL1.BT0 set incorrectly in user mode -Description of problem: -PACIASP normally acts as a BTI landing pad, but not in every situation. When SCTLR_EL1.BT is set, PACIASP checks that the indirect branch originates from X16 or X17 when the indirect branch is taken from a BTI guarded area. Linux sets this bit, ideally QEMU-user should too. This sample program should crash with a SIGILL if QEMU is working correctly, otherwise it will crash with a SIGSEGV. - - #include <stdint.h> - #include <stdlib.h> - #include <unistd.h> - #include <string.h> - #include <stdio.h> - #include <sys/mman.h> - - // PACIASP is a valid BTI landing pad, but there are some conditions - // under Linux which sets SCTLR_ELx.BT0 = 1. In this mode, a branch - // onto a PACIASP landing pad is only valid if it originates from - // x16 or x17 (i.e. br x17 is OK, br x3 is not). - // More info on page D5-4851 of the Arm Architecture Reference Manual (ARM DDI 0487H.a). - - // Sample function which starts with a paciasp instruction - // (comes from -mbranch-protection=pac-ret+leaf) - void indirect_fn(int i) { - // paciasp instruction inserted here - should crash with SIGILL here if everything's operating OK. - i = i+1; - // Can't access this function from the copied location, so will segfault. - fprintf(stderr, "reachable\n"); - } - - int main(int argc, char **argv) { - // It's difficult to get a whole binary BTI compatible without the appropriate crtbegin etc - // so instead map a page and copy the sample function there. - void *e = mmap(0, getpagesize(), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); - if (e == MAP_FAILED) { - return 1; - } - memcpy(e, (void*)indirect_fn, 64); - mprotect(e, getpagesize(), PROT_READ | PROT_EXEC | PROT_BTI); - - // paciasp is a valid landing pad if the branch comes from an unprotected area, - // so to ensure that we're protected - assemble an intermediate shim that's also PROT_BTI. - void *f = mmap(0, getpagesize(), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); - if (f == MAP_FAILED) { - return 1; - } - uint32_t *x = (uint32_t*)f; - x[0] = 0xd503245fuL; // bti c - x[1] = 0xd61f0060uL; // br x1 - n.b. must be BR - mprotect(f, getpagesize(), PROT_READ | PROT_EXEC | PROT_BTI); - - // Jump to the shim - asm volatile ( - "mov x3, %0\n" - "mov x2, %1\n" - "blr x2\n" - : : "p"(e), "p"(f) : "x2", "x3"); - - // Execution should not reach here - return 1; - } -Steps to reproduce: -1. Compile with `clang-12 -g --sysroot=/work/home/fedora-rootfs/fedora_aarch64 -o sample --target=aarch64-linux-gnu -mbranch-protection=pac-ret+leaf -march=armv8-a -O1 -g sample.c` or similar. -2. Run with `../qemu/build/qemu-aarch64 --cpu max -L ~/fedora-rootfs/fedora_aarch64 sample` |