diff options
Diffstat (limited to 'results/classifier/zero-shot-user-mode/output/syscall')
85 files changed, 0 insertions, 3940 deletions
diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1007 b/results/classifier/zero-shot-user-mode/output/syscall/1007 deleted file mode 100644 index 4bfb2f238..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1007 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.646 -instruction: 0.321 -runtime: 0.032 - - - -qemu-user: add execveat syscall support diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1010 b/results/classifier/zero-shot-user-mode/output/syscall/1010 deleted file mode 100644 index 16d296fb6..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1010 +++ /dev/null @@ -1,84 +0,0 @@ -syscall: 0.355 -runtime: 0.330 -instruction: 0.315 - - - -Errors on 9p mounts -Description of problem: -I'm trying to run Docker VMs with [Lima](https://github.com/lima-vm/lima), which uses QEMU. I'm trying to expose my home directory on macOS to the Ubuntu VM using `9p`. This is how the mount point looks like inside the Ubuntu VM: - -``` -root@lima-docker:~# mount | grep Users -mount0 on /Users/carlos type 9p (rw,relatime,dirsync,fscache,cachetag=4294894070,access=user,trans=virtio,version=9p2000.u) -root@lima-docker:~# -``` - -The problem I'm seeing is that doing an `ls -l /Users/carlos` gives a "Timer expired" error, and no output: - -``` -root@lima-docker:~# ls -l /Users/carlos -ls: reading directory '/Users/carlos': Timer expired -total 0 -``` - -Under `strace`, it seems that the timer error is raised by the `getdents64` system call: - -``` -root@lima-docker:~# strace -f ls -l /Users/carlos -[..] -openat(AT_FDCWD, "/Users/carlos", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 -newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=1984, ...}, AT_EMPTY_PATH) = 0 -mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffa16bf000 -getdents64(3, 0xffffa16bf040, 131072) = -1 ETIME (Timer expired) -[..] -``` - -I've also tried the `9p2000.L` protocol instead, and the results are a bit better. I do get a directory listing, but I see "xxx" errors: - -``` -root@lima-docker:~# ls -l /Users/carlos -ls: /Users/carlos: Network dropped connection on reset -ls: /Users/carlos/Music: Network dropped connection on reset -ls: /Users/carlos/Pictures: Network dropped connection on reset -ls: /Users/carlos/Desktop: Network dropped connection on reset -ls: /Users/carlos/Library: Network dropped connection on reset -ls: /Users/carlos/Public: Network dropped connection on reset -ls: /Users/carlos/Movies: Network dropped connection on reset -ls: /Users/carlos/Applications: Network dropped connection on reset -ls: /Users/carlos/Dropbox: Network dropped connection on reset -ls: /Users/carlos/Maildir: Network dropped connection on reset -ls: /Users/carlos/Documents: Network dropped connection on reset -ls: /Users/carlos/Downloads: Network dropped connection on reset -total 0 -drwx------ 5 carlos dialout 160 Dec 6 10:31 Applications -drwx------ 4 carlos dialout 128 Apr 28 14:40 Desktop -drwx------ 12 carlos dialout 384 Apr 30 08:44 Documents -drwx------ 164 carlos dialout 5248 Apr 29 13:50 Downloads -drwx------ 8 carlos dialout 256 Sep 4 2021 Dropbox -drwx------ 82 carlos dialout 2624 Apr 8 14:05 Library -drwxr-xr-x 3 carlos dialout 96 Nov 12 12:28 Maildir -drwx------ 4 carlos dialout 128 Jul 19 2021 Movies -drwx------ 4 carlos dialout 128 Aug 19 2021 Music -drwx------ 4 carlos dialout 128 Jul 19 2021 Pictures -drwxr-xr-x 4 carlos dialout 128 Jul 19 2021 Public -``` - -The errors in this case seem to come from the `lgetxattr`system call: - -``` -root@lima-docker:~# strace -f ls -l /Users/carlos -[..] -statx(AT_FDCWD, "/Users/carlos/Downloads", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_SIZE, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFDIR|0700, stx_size=5248, ...}) = 0 -lgetxattr("/Users/carlos/Downloads", "security.selinux", 0xaaaaec72da70, 255) = -1 ENETRESET (Network dropped connection on reset) -write(2, "ls: ", 4ls: ) = 4 -write(2, "/Users/carlos/Downloads", 23/Users/carlos/Downloads) = 23 -write(2, ": Network dropped connection on "..., 37: Network dropped connection on reset) = 37 -[..] -``` - -I've reported this to the Lima folks at https://github.com/lima-vm/lima/issues/831, and they suggested opening an issue here. Any ideas? -Steps to reproduce: -1. If you have Lima installed (I'm using version 0.10.0): `limactl start --name=docker ./lima-templates/docker.yaml` -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1022 b/results/classifier/zero-shot-user-mode/output/syscall/1022 deleted file mode 100644 index 3f13ef235..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1022 +++ /dev/null @@ -1,39 +0,0 @@ -syscall: 0.371 -runtime: 0.369 -instruction: 0.261 - - - -RISC-V: Simulation terminated with seg fault when encountering `vsra.vx` -Description of problem: -QEMU simulation terminated with segmentation fault. Here is the backtrace of the simulation - -``` -(gdb) r -Starting program: qemu/build/qemu-riscv64 -cpu rv64,vext_spec=v1.0,v=true,Zfh=true,Zve32f=true,Zve64f=true,vlen=128 -B 0x100000 a.out -Missing separate debuginfos, use: yum debuginfo-install glibc-2.28-164.el8_5.3.x86_64 -[Thread debugging using libthread_db enabled] -Using host libthread_db library "/lib64/libthread_db.so.1". -[New Thread 0x7ffff4edd700 (LWP 3239772)] - -Thread 1 "qemu-riscv64" received signal SIGSEGV, Segmentation fault. -0x00007fffe8004fad in code_gen_buffer () -Missing separate debuginfos, use: yum debuginfo-install glib2-2.56.4-156.el8.x86_64 gmp-6.1.2-10.el8.x86_64 gnutls-3.6.16-4.el8.x86_64 libffi-3.1-22.el8.x86_64 libidn2-2.2.0-1.el8.x86_64 libtasn1-4.13-3.el8.x86_64 libunistring-0.9.9-3.el8.x86_64 p11-kit-0.23.22-1.el8.x86_64 pcre-8.42-6.el8.x86_64 -(gdb) bt -#0 0x00007fffe8004fad in code_gen_buffer () -#1 0x00005555556a0b9b in cpu_tb_exec (tb_exit=<synthetic pointer>, itb=<optimized out>, cpu=0x7fffe8005000 <code_gen_buffer+20435>) at ../accel/tcg/cpu-exec.c:358 -#2 cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=0x7fffe8005000 <code_gen_buffer+20435>) at ../accel/tcg/cpu-exec.c:848 -#3 cpu_exec (cpu=cpu@entry=0x555555eed3d0) at ../accel/tcg/cpu-exec.c:1007 -#4 0x00005555555e6d30 in cpu_loop (env=0x555555ef56f0) at ../linux-user/riscv/cpu_loop.c:37 -#5 0x00005555555df9f7 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../linux-user/main.c:909 -``` -Steps to reproduce: -1. Checkout to QEMU's latest master (`ec11dc41eec5142b4776db1296972c6323ba5847`) -2. `mkdir build ; cd build ; ../configure ; make -j24` -3. `qemu-riscv64 -cpu rv64,vext_spec=v1.0,v=true,Zfh=true,Zve32f=true,Zve64f=true,vlen=128 -B 0x100000 ./a.out` -Additional information: -Attaching code (output.c) and binary (a.out) - -[a.out](/uploads/0ecfb436a439619527ef645bdc781a48/a.out) - -[output.c](/uploads/cd492b4c9468f0b48412e76e7f6fcf91/output.c) diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1033 b/results/classifier/zero-shot-user-mode/output/syscall/1033 deleted file mode 100644 index 833617b1c..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1033 +++ /dev/null @@ -1,33 +0,0 @@ -syscall: 0.503 -instruction: 0.335 -runtime: 0.162 - - - -fakeroot under qemu fails with 'semop(1): encountered an error: Function not implemented' -Description of problem: -Appears to be the same issue as that discussed and reportedly fixed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965109 - -Running raspberry pi os in a chroot (using schroot). Execution of fakeroot as part of dpkg-buildpackage results in: - -``` -dpkg-buildpackage: info: source package clementine -dpkg-buildpackage: info: source version 1.4.0rc1-836-g4665916ba~bullseye -dpkg-buildpackage: info: source distribution bullseye -dpkg-buildpackage: info: source changed by David Sansome <me@davidsansome.com> -dpkg-buildpackage: info: host architecture armhf - dpkg-source --before-build . - fakeroot debian/rules clean -semop(1): encountered an error: Function not implemented -dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit status 1 -``` - -This is the same error as reported in bug 965109, but I'm running the most recent version of qemu - I built it from the git repo, so it should include the fix for 965109. -Steps to reproduce: -1. Setup (s)chroot with arm architecture (although the architecture may not matter) -2. Run fakeroot in the chroot -3. Observe the failure related to the semop syscall -Additional information: -- Not sure what other information I can provide to be helpful. -- The command line listed above is what I gather from ps; it's how qemu-arm-static is called by schroot. I've not been able to figure out _how_ schroot calls qemu-arm-static, I only know it does. -- I compiled qemu from source using my own user id, and ran into an issue with make install, so I manually used install to deploy the executable to /usr/local/bin... And then had to symlink that to /usr/bin as schroot apparently hardcodes the location of qemu-arm-static (at least it did not pick up the version I'd placed in /usr/local/bin). diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1044 b/results/classifier/zero-shot-user-mode/output/syscall/1044 deleted file mode 100644 index 4d2020b34..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1044 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.495 -runtime: 0.315 -instruction: 0.190 - - - -Warning: libevent-loop-base.a the table of contents is empty diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1051 b/results/classifier/zero-shot-user-mode/output/syscall/1051 deleted file mode 100644 index 58c9dc677..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1051 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.642 -runtime: 0.217 -instruction: 0.141 - - - -or1k tcg SIGILL diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1075272 b/results/classifier/zero-shot-user-mode/output/syscall/1075272 deleted file mode 100644 index cc1d54279..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1075272 +++ /dev/null @@ -1,19 +0,0 @@ -syscall: 0.679 -instruction: 0.191 -runtime: 0.130 - - - -socket type mapping wrong for mips app-level emulation - -linux-user/syscall.c's do_socket function contains socket type remapping to work around the nonsensically-permuted MIPS socket types. However, it fails to account for the SOCK_NONBLOCK and SOCK_CLOEXEC flags that may be or'd onto the type. Thus, a call from the application such as: - -socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) - -will fail to have the type permutation performed, and will be passed to the system as: - -socket(AF_INET, SOCK_DGRAM, IPPROTO_TCP) - -resulting in EPROTONOSUPPORT. - -To fix this, the flag bits should be masked off of the type before the permutation. They also need remapping themselves (since MIPS uses different values for these flags bits). \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1111 b/results/classifier/zero-shot-user-mode/output/syscall/1111 deleted file mode 100644 index a0defe191..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1111 +++ /dev/null @@ -1,24 +0,0 @@ -syscall: 0.692 -instruction: 0.250 -runtime: 0.058 - - - -Calling FUTEX_LOCK_PI with qemu-x86_64-static caused ENOSYS error. -Description of problem: -When I executed the command "perf bench futex lock-pi" in amd64 docker image on s390x, I got the following error. -``` -perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented -perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented -perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented -perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented -``` - -I searched for this error message in the source code of perf-bench. I think that the following system call caused ENOSYS error. -` syscall(SYS_futex, uaddr, FUTEX_LOCK_PI | opflags, val, timeout, uaddr2, val3)` -Steps to reproduce: -1. Execute the command "perf bench futex lock-pi" in amd64 docker image on s390x -2. -3. -Additional information: - diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1172613 b/results/classifier/zero-shot-user-mode/output/syscall/1172613 deleted file mode 100644 index 7a35c43aa..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1172613 +++ /dev/null @@ -1,69 +0,0 @@ -syscall: 0.362 -instruction: 0.351 -runtime: 0.287 - - - -[qemu 1.4.1] inconsistent behavior on different architecture - -Running with qemu 1.4.1 and eglibc 2.17 on Debian Linux 7.0 for amd64 - ----------------- armhf ---------------- -$ arm-linux-gnueabihf-gcc hello.c -$ qemu-arm ./a.out -/lib/ld-linux-armhf.so.3: No such file or directory - -$ qemu-arm arm-linux-gnueabihf/lib/ld-2.17.so ./a.out -./a.out: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory - -$ qemu-arm arm-linux-gnueabihf/lib/ld-2.17.so --library-path arm-linux-gnueabihf/lib ./a.out -Hello, world ! - ----------------- powerpc64 ---------------- -$ powerpc64-linux-gcc hello.c - -$ qemu-ppc64 ./a.out -/lib64/ld64.so.1: No such file or directory - -[BAD BEHAVIOR !!!] -$ qemu-ppc64 powerpc64-linux/lib64/ld-2.17.so ./a.out -Invalid data memory access: 0x00000041988fd008 -NIP 000000400001cb2c LR 000000400001cc30 CTR 0000000000000000 XER 0000000000000000 -MSR 8000000002006000 HID0 0000000060000000 HF 8000000002006000 idx 0 -TB 00000000 00000000 -GPR00 0000000000000000 000000400083a220 0000004000041230 00000043309bd010 -GPR04 0000004000026f12 000000000000000b 000000000000002e 000000000000002e -GPR08 0000000000000030 000000008803fffc 00000041988fcff4 0000000000000037 -GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 -GPR16 0000000000000000 000000400003a4d8 000000400083a6d0 000000400083a6d8 -GPR20 000000400003a898 000000000000000a 0000000000000000 00000043309bd010 -GPR24 0000004000037b60 00000000cfe8ced7 000000400003a430 0000000010000261 -GPR28 00000001980bfff4 0000000000000000 000000004401ffff 000000002200ffff -CR 22242224 [ E E E G E E E G ] RES ffffffffffffffff -FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 -FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 -FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 -FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 -FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 -FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 -FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 -FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 -FPSCR 0000000000000000 -qemu: uncaught target signal 11 (Segmentation fault) - core dumped -Segmentation fault - -$ qemu-ppc64 powerpc64-linux/lib64/ld-2.17.so --library-path powerpc64-linux/lib64 ./a.out -Hello, world ! - ----------------- sparc64 ---------------- -$ sparc64-linux-gcc hello.c - -$ qemu-sparc64 ./a.out -/lib64/ld-linux.so.2: No such file or directory - -[BAD BEHAVIOR !!!] -$ qemu-sparc64 sparc64-linux/lib64/ld-2.17.so ./a.out -Segmentation fault - -$ qemu-sparc64 sparc64-linux/lib64/ld-2.17.so --library-path sparc64-linux/lib64 ./a.out -Hello, world ! \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1187319 b/results/classifier/zero-shot-user-mode/output/syscall/1187319 deleted file mode 100644 index e1cc7a10d..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1187319 +++ /dev/null @@ -1,14 +0,0 @@ -syscall: 0.395 -instruction: 0.367 -runtime: 0.238 - - - -Ctrl-Alt-- and Ctrl-Alt-+ have no effect in SDL - -The manual page mentions Ctrl-Alt-- for shrinking a window and Ctrl-Alt-+ for enlarging it. Pressing these keys do not seem to have any effect. - -I tried -/= with and without holding shift and the numpad. By the way, the numpad plus and min do not have any effect in GTK either. - -Keyboard layout: US int with AltGr dead keys -version: 1.5.0 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1238 b/results/classifier/zero-shot-user-mode/output/syscall/1238 deleted file mode 100644 index 546d0fb70..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1238 +++ /dev/null @@ -1,125 +0,0 @@ -syscall: 0.357 -runtime: 0.324 -instruction: 0.319 - - - -qemu-mipsn32el and qemu-mipsn32 problems with coreutils-9*, fadvise64 or fallocate related? -Description of problem: -- Recently about 15 of the ca. 250 packages in our system set fail during `make install`. A typical error is -> `/usr/bin/install: error deallocating '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin/troff': Invalid argument` -- Given the timing and the involved binaries (most of the times `install`, but also `cp`), I suspect this was triggered by coreutils-9 -- The problem seems to only occur on ext4 (our release engineering box), but not on btrfs (my home development box) -- The problem seems to be limited to n32 (both big and little endian) - -Here's a run with strace functionality enabled: - -``` -dilfridge-mips64el-n32 /var/tmp/portage/sys-apps/groff-1.22.4/work/groff-1.22.4 # /usr/bin/qemu-mipsn32el -strace /usr/bin/install troff '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin' -3216 brk(NULL) = 0x40032000 -3216 mmap(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f7ba000 -3216 uname(0x3fffebb0) = 0 -3216 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory) -3216 openat(AT_FDCWD,"/etc/ld.so.cache",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 -3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe280) = 0 -3216 mmap(NULL,11294,PROT_READ,MAP_PRIVATE,3,0) = 0x3f7b7000 -3216 close(3) = 0 -3216 openat(AT_FDCWD,"/lib32/libacl.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 -3216 read(3,0x3fffe4c4,512) = 512 -3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe220) = 0 -3216 mmap(NULL,197008,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f786000 -3216 mmap(0x3f790000,131472,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f790000 -3216 munmap(0x3f786000,40960) = 0 -3216 munmap(0x3f7b1000,20880) = 0 -3216 mprotect(0x3f797000,98304,PROT_NONE) = 0 -3216 mmap(0x3f7af000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xf000) = 0x3f7af000 -3216 close(3) = 0 -3216 openat(AT_FDCWD,"/lib32/libattr.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 -3216 read(3,0x3fffe4b4,512) = 512 -3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe210) = 0 -3216 mmap(NULL,196864,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f75f000 -3216 mmap(0x3f760000,131328,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f760000 -3216 munmap(0x3f75f000,4096) = 0 -3216 munmap(0x3f781000,57600) = 0 -3216 mprotect(0x3f764000,110592,PROT_NONE) = 0 -3216 mmap(0x3f77f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xf000) = 0x3f77f000 -3216 close(3) = 0 -3216 openat(AT_FDCWD,"/lib32/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 -3216 read(3,0x3fffe4a4,512) = 512 -3216 pread64(3,1073734640,32,34504,1065377824,0) = 32 -3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe200) = 0 -3216 mmap(NULL,2056864,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f569000 -3216 mmap(0x3f570000,1991328,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f570000 -3216 munmap(0x3f569000,28672) = 0 -3216 munmap(0x3f757000,33440) = 0 -3216 mprotect(0x3f73c000,61440,PROT_NONE) = 0 -3216 mmap(0x3f74b000,28672,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1cb000) = 0x3f74b000 -3216 mmap(0x3f752000,17056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x3f752000 -3216 close(3) = 0 -3216 mmap(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f569000 -3216 set_thread_area(0x3f570580) = 0 -3216 set_tid_address(1062637704,1065348616,1065377824,0,-1,0) = 3216 -3216 set_robust_list(1062637712,12,1065377824,0,-1,0) = -1 errno=89 (Function not implemented) -3216 Unknown syscall 6331 -3216 mprotect(0x3f74b000,16384,PROT_READ) = 0 -3216 mprotect(0x3f77f000,4096,PROT_READ) = 0 -3216 mprotect(0x3f7af000,4096,PROT_READ) = 0 -3216 mprotect(0x4002e000,4096,PROT_READ) = 0 -3216 mprotect(0x3f7fc000,8192,PROT_READ) = 0 -3216 getrlimit(3,1073737152,1064664656,1062638996,1064337736,1064664656) = 0 -3216 munmap(0x3f7b7000,11294) = 0 -3216 getrandom(1064649956,4,1,1064337736,2130640639,1077952576) = 4 -3216 brk(NULL) = 0x40032000 -3216 brk(0x40053000) = 0x40053000 -3216 brk(0x40054000) = 0x40054000 -3216 openat(AT_FDCWD,"/usr/lib/locale/locale-archive",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 -3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffed58) = 0 -3216 mmap(NULL,2097152,PROT_READ,MAP_PRIVATE,3,0) = 0x3f369000 -3216 close(3) = 0 -3216 geteuid() = 0 -3216 umask(0) = 18 -3216 openat(AT_FDCWD,"/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin",O_RDONLY|O_DIRECTORY|O_LARGEFILE|O_PATH) = 3 -3216 statx(AT_FDCWD,"troff",AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 -3216 statx(3,"troff",AT_NO_AUTOMOUNT|AT_SYMLINK_NOFOLLOW,STATX_BASIC_STATS,0x3fffe998) = 0 -3216 unlinkat(3,"troff",0) = 0 -3216 openat(AT_FDCWD,"troff",O_RDONLY|O_LARGEFILE) = 4 -3216 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 -3216 openat(3,"troff",O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE,0600) = 5 -3216 ioctl(5,FICLONE,4) = -1 errno=122 (Operation not supported) -3216 statx(5,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 -3216 lseek(4,0,SEEK_DATA) = 0 -3216 fadvise64(4,0,0,2,1664557525,0) = -1 errno=22 (Invalid argument) -3216 lseek(4,0,SEEK_HOLE) = 716800 -3216 lseek(4,0,SEEK_SET) = 0 -3216 mmap(NULL,139264,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f347000 -3216 read(4,0x3f348000,131072) = 131072 -3216 write(5,0x3f348000,122880) = 122880 -3216 read(4,0x3f348000,131072) = 131072 -3216 lseek(5,12288,SEEK_CUR) = 135168 -3216 fallocate(5,FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE,122880,4290510848) = -1 errno=22 (Invalid argument) -3216 openat(AT_FDCWD,"/usr/share/locale/locale.alias",O_RDONLY|O_CLOEXEC) = 6 -3216 statx(6,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe2c8) = 0 -3216 read(6,0x400333a0,4096) = 2998 -3216 read(6,0x400333a0,4096) = 0 -3216 close(6) = 0 -3216 openat(AT_FDCWD,"/usr/share/locale/C.UTF-8/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) -3216 openat(AT_FDCWD,"/usr/share/locale/C.utf8/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) -3216 openat(AT_FDCWD,"/usr/share/locale/C/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) -3216 write(2,0x3fffc888,18)/usr/bin/install: = 18 -3216 write(2,0x3fffc8b8,79)error deallocating '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin/troff' = 79 -3216 openat(AT_FDCWD,"/usr/share/locale/C.UTF-8/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) -3216 openat(AT_FDCWD,"/usr/share/locale/C.utf8/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) -3216 openat(AT_FDCWD,"/usr/share/locale/C/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) -3216 write(2,0x3fffc428,18): Invalid argument = 18 -3216 write(2,0x3fffc858,1) - = 1 -3216 close(5) = 0 -3216 close(4) = 0 -3216 munmap(0x3f347000,139264) = 0 -3216 lseek(0,0,SEEK_CUR) = -1 errno=29 (Illegal seek) -3216 close(0) = 0 -3216 close(1) = 0 -3216 close(2)dilfridge-mips64el-n32 /var/tmp/portage/sys-apps/groff-1.22.4/work/groff-1.22.4 # -``` - -More information and debugging on request. Any advice is appreciated. diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1261 b/results/classifier/zero-shot-user-mode/output/syscall/1261 deleted file mode 100644 index d026fe7a9..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1261 +++ /dev/null @@ -1,31 +0,0 @@ -syscall: 0.753 -instruction: 0.197 -runtime: 0.050 - - - -qemu-user syscall 439 (faccessat2) not implemented - loongarch64 -Description of problem: -On LoongArch64 architecture faccessat syscall is missing and only faccessat2 is present, but it is not handled in linux-user/syscall -Steps to reproduce: -1. Launch a simple bash test script (call it test.sh): if [[ -r test.sh ]] ; then echo OK ; else echo ERROR ; fi -2. The result is "ERROR" even if the file "test.sh" exists and it is readeable -3. The correct result should be "OK" -Additional information: -test.sh: - ``` - if [[ -r test.sh ]] ; then echo OK ; else echo ERROR ; fi - ``` -qemu-loongarch -strace log: - ``` -[...] -12579 statx(255,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x0000004000802a50) = 0 -12579 lseek(255,0,SEEK_CUR) = 0 -12579 read(255,0x2016d490,56) = 56 -12579 Unknown syscall 439 -12579 write(1,0x20172010,6) = 6 -12579 read(255,0x2016d490,56) = 0 -12579 rt_sigprocmask(SIG_BLOCK,0x0000004000802b60,0x0000004000802be0) = 0 -12579 rt_sigprocmask(SIG_SETMASK,0x0000004000802be0,NULL) = 0 -12579 exit_group(0) - ``` diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1267955 b/results/classifier/zero-shot-user-mode/output/syscall/1267955 deleted file mode 100644 index 5653b5f2b..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1267955 +++ /dev/null @@ -1,48 +0,0 @@ -syscall: 0.573 -instruction: 0.298 -runtime: 0.129 - - - -[i386] Parity Flag Not Set On xor %eax,%eax - -Tested against qemu-1.7.0 as well as qemu-1.7.50 on Debian Sid - -Steps To Reproduce - -$ cat > prog.hex << EOF - -7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 -02 00 03 00 01 00 00 00 54 80 04 08 34 00 00 00 -00 00 00 00 00 00 00 00 34 00 20 00 01 00 28 00 -00 00 00 00 01 00 00 00 00 00 00 00 00 80 04 08 -00 80 04 08 76 00 00 00 76 00 00 00 05 00 00 00 -00 10 00 00 - -31 c0 -9c - -b8 04 00 00 00 -bb 01 00 00 00 -89 e1 -ba 04 00 00 00 -cd 80 - -b8 01 00 00 00 -bb 00 00 00 00 -cd 80 - -EOF - -$ xxd -p -r prog.hex > prog -$ chmod 700 prog - -$ ./prog | hexdump -vC -00000000 46 02 00 00 |F...| -00000004 - -$ qemu-i386 ./prog | hexdump -vC -00000000 42 02 00 00 |B...| -00000004 - -On the other hand if [xor %eax, %eax] (31 c0) is replaced with sub %eax,%eax (29 c0), then the parity flag is set correctly. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/127 b/results/classifier/zero-shot-user-mode/output/syscall/127 deleted file mode 100644 index 4996824d4..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/127 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.452 -instruction: 0.317 -runtime: 0.230 - - - -linux-user missing cmsg IP_PKTINFO support ("Unsupported ancillary data: 0/8") diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1294898 b/results/classifier/zero-shot-user-mode/output/syscall/1294898 deleted file mode 100644 index fc39c40e4..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1294898 +++ /dev/null @@ -1,84 +0,0 @@ -syscall: 0.435 -runtime: 0.284 -instruction: 0.281 - - - -gtk: menubar visible in fullscreen mode with gtk3 - -Using the gtk UI, compiled with gtk3, the menu bar is fully visible in full screen mode. On gtk2 it's hidden. The set_size_request call isn't abided on gtk3 it seems. - -Simple fix is: - -diff --git a/ui/gtk.c b/ui/gtk.c -index 66e886f..7b3bd3d 100644 ---- a/ui/gtk.c -+++ b/ui/gtk.c -@@ -805,7 +805,7 @@ static void gd_menu_full_screen(GtkMenuItem *item, void *opaque) - - if (!s->full_screen) { - gtk_notebook_set_show_tabs(GTK_NOTEBOOK(s->notebook), FALSE); -- gtk_widget_set_size_request(s->menu_bar, 0, 0); -+ gtk_widget_hide(s->menu_bar); - gtk_widget_set_size_request(s->drawing_area, -1, -1); - gtk_window_fullscreen(GTK_WINDOW(s->window)); - if (gd_on_vga(s)) { -@@ -815,7 +815,7 @@ static void gd_menu_full_screen(GtkMenuItem *item, void *opaque) - } else { - gtk_window_unfullscreen(GTK_WINDOW(s->window)); - gd_menu_show_tabs(GTK_MENU_ITEM(s->show_tabs_item), s); -- gtk_widget_set_size_request(s->menu_bar, -1, -1); -+ gtk_widget_show(s->menu_bar); - gtk_widget_set_size_request(s->drawing_area, - surface_width(s->ds), - surface_height(s->ds)); - - -The problem with that is that hiding the menu bar means all its associated accelerators are no longer usable, so there's way to exit fullscreen mode. That's kind of a problem :) - -We can install the accelerators on the window, but make sure the menu item still shows the accelerator short cut. Example with the fullscreen accelerator: - -diff --git a/ui/gtk.c b/ui/gtk.c -index 66e886f..fbce2b0 100644 ---- a/ui/gtk.c -+++ b/ui/gtk.c -@@ -799,7 +799,7 @@ static void gd_menu_show_tabs(GtkMenuItem *item, void *opaque) - } - } - --static void gd_menu_full_screen(GtkMenuItem *item, void *opaque) -+static void gd_do_full_screen(void *opaque) - { - GtkDisplayState *s = opaque; - -@@ -828,6 +828,11 @@ static void gd_menu_full_screen(GtkMenuItem *item, void *opaque) - gd_update_cursor(s, FALSE); - } - -+static void gd_menu_full_screen(GtkMenuItem *item, void *opaque) -+{ -+ gd_do_full_screen(opaque); -+} -+ - static void gd_menu_zoom_in(GtkMenuItem *item, void *opaque) - { - GtkDisplayState *s = opaque; -@@ -1304,10 +1309,11 @@ static GtkWidget *gd_create_menu_view(GtkDisplayState *s, GtkAccelGroup *accel_g - gtk_menu_set_accel_group(GTK_MENU(view_menu), accel_group); - - s->full_screen_item = gtk_menu_item_new_with_mnemonic(_("_Fullscreen")); -- gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s->full_screen_item), -- "<QEMU>/View/Full Screen"); -- gtk_accel_map_add_entry("<QEMU>/View/Full Screen", GDK_KEY_f, -- HOTKEY_MODIFIERS); -+ gtk_accel_group_connect(accel_group, GDK_KEY_f, HOTKEY_MODIFIERS, 0, -+ g_cclosure_new_swap(G_CALLBACK(gd_do_full_screen), s, NULL)); -+ gtk_accel_label_set_accel( -+ GTK_ACCEL_LABEL(gtk_bin_get_child(GTK_BIN(s->full_screen_item))), -+ GDK_KEY_f, HOTKEY_MODIFIERS); - gtk_menu_shell_append(GTK_MENU_SHELL(view_menu), s->full_screen_item); - - separator = gtk_separator_menu_item_new(); - - -However gtk_accel_label_set_accel, which shows the accel key sequence in the menu, is gtk 3.8+ :/ So older versions wouldn't have any visual indication of the shortcuts. Maybe that's not a problem, SDL didn't have any indication of shortcuts either. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1361 b/results/classifier/zero-shot-user-mode/output/syscall/1361 deleted file mode 100644 index bbc28d139..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1361 +++ /dev/null @@ -1,26 +0,0 @@ -syscall: 0.432 -instruction: 0.356 -runtime: 0.212 - - - -ppc64le linux user emulation w/ 64KiB pages seems broken since v5.0.0 -Description of problem: -[Our (snmalloc's)](https://github.com/microsoft/snmalloc) CI includes running a PowerPC64 little-endian Linux build inside qemu, running with 64KiB pages as, at least, Debian runs them by default. As reported [over there](https://github.com/microsoft/snmalloc/issues/576), this broke when GitHub's CI runners moved from Ubuntu Focal (20.04) to Jammy (22.04), bringing qemu from v4.2 to v6.2. - -The failing test case appears to die of an erroneous `SIGSEGV` `SEGV_MAPERR`: -``` ---- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0x0000004001be5000} --- -``` -despite that address nominally being mapped by the last memory syscall to touch that area -``` -openat(AT_FDCWD,"/usr/powerpc64le-linux-gnu/lib/libstdc++.so.6",O_RDONLY|O_CLOEXEC) = 4 -[...] -mmap(0x0000004001bd0000,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,4,0x2f0000) = 0x4001bd0000 -``` - -Bisection reveals that the breakage first occurred with 4dcf078f094d436866ef793aa25c96fba85ac8d0, though I suspect this is merely the commit that exposes some underlying bug rather than being the actual root cause. -Steps to reproduce: -Run a ppc64el Linux executable under `qemu-user` with `-p 65536`. -Additional information: -Please advise what more would be useful. diff --git a/results/classifier/zero-shot-user-mode/output/syscall/140 b/results/classifier/zero-shot-user-mode/output/syscall/140 deleted file mode 100644 index 53e856b20..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/140 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.418 -instruction: 0.331 -runtime: 0.251 - - - -linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert) diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1470170 b/results/classifier/zero-shot-user-mode/output/syscall/1470170 deleted file mode 100644 index 4fa36dba1..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1470170 +++ /dev/null @@ -1,46 +0,0 @@ -syscall: 0.673 -instruction: 0.240 -runtime: 0.086 - - - -Unsupported syscalls 370 and 355 - -Qemu seems to be missing syscalls 370 and 355 when running qemu usermode arm. These are used by systemd or some similar new package. This can be detected by creating an debian sid armhf with qemu debootstrap. When the system is launched with "systemd-nspawn -bD sid-arm" this happens (newest git as of today): - -pawning container sid-arm on /home/jpakkane/qemutest/sid-arm. -Press ^] three times within 1s to kill container. -Failed to create directory /home/jpakkane/qemutest/sid-arm//sys/fs/selinux: Read-only file system -Failed to create directory /home/jpakkane/qemutest/sid-arm//sys/fs/selinux: Read-only file system -/etc/localtime is not a symlink, not updating container timezone. -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 384 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -qemu: Unsupported syscall: 370 -systemd 221 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN) -Detected virtualization systemd-nspawn. -Detected architecture arm. - -Welcome to Debian GNU/Linux stretch/sid! - -Set hostname to <manos>. -qemu: Unsupported syscall: 355 -Failed to allocate manager object: Function not implemented -[!!!!!!] Failed to allocate manager object, freezing. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1478 b/results/classifier/zero-shot-user-mode/output/syscall/1478 deleted file mode 100644 index 2076c5ad6..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1478 +++ /dev/null @@ -1,72 +0,0 @@ -syscall: 0.374 -runtime: 0.335 -instruction: 0.291 - - - -Qemu 7.2.0 i386: core2: init crash (glibc) -Description of problem: -The toolchain-builder project (a side project of Buildroot to build pre-built toolchains) reported an issue with Qemu 7.2.0 for x86-core2--glibc--bleeding-edge toolchain, see: - -https://gitlab.com/buildroot.org/toolchains-builder/-/jobs/3731683337 - -Reverting back to Qemu 7.1.0, the system boot correctly with the same system image. -I reproduced the issue with the current Qemu master (6b433719eabf0abc74cff0cfd5687f0137c4198a) - -Here is the boot log obtained with Qemu 7.2.0: - ``` -Run /sbin/init as init process -random: fast init done -EXT4-fs (vda): warning: mounting unchecked fs, running e2fsck is recommended -EXT4-fs (vda): re-mounted. Opts: (null). Quota mode: disabled. -Starting syslogd: OK -traps: syslogd[52] general protection fault ip:b7e21465 sp:bfe59e6c error:0 in libc.so.6[b7d9b000+123000] -Starting klogd: OK -traps: klogd[56] general protection fault ip:b7e94465 sp:bf8f069c error:0 in libc.so.6[b7e0e000+123000] -Running sysctl: traps: logger[62] general protection fault ip:b7e48b6c sp:bfd7d194 error:0 in libc.so.6[b7e05000+123000] -Segmentation fault -traps: logger[64] general protection fault ip:b7dd3b6c sp:bf9b8604 error:0 in libc.so.6[b7d90000+123000] -Segmentation fault - -traps: init[100] general protection fault ip:b7dda465 sp:bfd5f42c error:0 in libc.so.6[b7d54000+123000] -Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b -CPU: 0 PID: 1 Comm: init Not tainted 5.15.18 #1 -Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 -Call Trace: - dump_stack_lvl+0x32/0x41 - dump_stack+0xd/0x10 - panic+0x90/0x206 - do_exit.cold+0xa9/0xa9 - do_group_exit+0x2a/0x90 - get_signal+0x115/0x7e0 - arch_do_signal_or_restart+0x90/0x5a0 - ? put_pid+0xc/0x20 - ? kernel_clone+0x10b/0x3d0 - exit_to_user_mode_prepare+0xf8/0x1c0 - syscall_exit_to_user_mode+0x1b/0x40 - do_int80_syscall_32+0x41/0x90 - entry_INT80_32+0xf0/0xf0 -EIP: 0xb7de5d88 -Code: 37 01 00 00 65 ff 15 10 00 00 00 89 d0 5a 5b 5e 5f 5d c3 66 90 66 90 66 90 66 90 66 90 66 90 66 90 90 59 b8 be 00 00 00 cd 80 <51> 3d 01 f0 ff ff 0f 83 06 e9 f6 ff c3 e8 81 a0 06 00 05 9a a0 0e -EAX: 00000064 EBX: 0059aa1c ECX: 00561f5b EDX: 00000008 -ESI: 0059cc20 EDI: bfd5fa64 EBP: 0059b138 ESP: bfd5fa20 -DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000246 -Kernel Offset: disabled ----[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- - ``` -I did a git bisect on qemu sources up to this commit: - -https://gitlab.com/qemu-project/qemu/-/commit/958e1dd1300f37f18b2161dfb4eb806fc8c19b44 -Steps to reproduce: -Build the Buildroot qemu_x86_defconfig with BR2_x86_core2 target architecture variant added manually -1. git clone https://gitlab.com/buildroot.org/buildroot.git -2. git switch --detach c419ef62d84b5be65599452ab84f7ed719bbe470 -3. make qemu_x86_defconfig -4. make menuconfig (enable BR2_x86_core2) -5. make -6. ./output/images/start-qemu.sh -Additional information: -System built with gcc options: - ``` -i686-buildroot-linux-gnu-gcc.br_real' '--sysroot' 'output/host/i686-buildroot-linux-gnu/sysroot' '-fstack-protector-strong' '-fPIE' '-pie' '-Wl,-z,now' '-Wl,-z,relro' - ``` diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1512 b/results/classifier/zero-shot-user-mode/output/syscall/1512 deleted file mode 100644 index 55d92a74f..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1512 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.465 -instruction: 0.304 -runtime: 0.231 - - - -AVX/AVX2 not correcly detected in user mode diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1516408 b/results/classifier/zero-shot-user-mode/output/syscall/1516408 deleted file mode 100644 index 41a1cba47..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1516408 +++ /dev/null @@ -1,37 +0,0 @@ -syscall: 0.561 -instruction: 0.328 -runtime: 0.111 - - - -sh4: Unsupported syscall: 186 - -Hello! - -I'm currently testing qemu as a possibility to set up a buildd for the Debian sh4 port. - -I set up qemu and an sh4 chroot as described in the Debian Wiki [1]. This seems to be working mostly fine (besides the fact that qemu segfaults on an amd64 host while it runs fine on an i386 host, I'll file a separate bug report). However, when installing python3.4 in the sh4 chroot, qemu repeatedly printed an error message about an unimplemented syscall: 186: - -qemu: Unsupported syscall: 186 - -From the source code in linux-user/sh4/syscall_nr.h it's apparent that 186 is defined as - -#define TARGET_NR_sigaltstack 186 - -Looking at the implementation part, it becomes obvious that this syscall is not enabled for sh4: - -#if defined(TARGET_I386) || defined(TARGET_ARM) || defined(TARGET_MIPS) || \ - defined(TARGET_SPARC) || defined(TARGET_PPC) || defined(TARGET_ALPHA) || \ - defined(TARGET_M68K) || defined(TARGET_S390X) || defined(TARGET_OPENRISC) - ret = do_sigaltstack(arg1, arg2, get_sp_from_cpustate((CPUArchState *)cpu_env)); - break; -#else - goto unimplemented; -#endif - -Is there any particular reason why TARGET_NR_sigaltstack is not enabled on sh4? If not, could you enable it? - -Thanks, -Adrian - -> [1] https://wiki.debian.org/QemuUserEmulation \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1550503 b/results/classifier/zero-shot-user-mode/output/syscall/1550503 deleted file mode 100644 index ffe6ec309..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1550503 +++ /dev/null @@ -1,19 +0,0 @@ -syscall: 0.542 -instruction: 0.365 -runtime: 0.093 - - - -target-arm/helper.c:5493: bad test ? - -[qemu/target-arm/helper.c:5493]: (style) Expression '(X & 0x1f) != 0xf80f0000' is always true. - -Source code is - - (env->uncached_cpsr & CPSR_M) != CPSR_USER && - -but - -./qemu/target-arm/cpu.h:#define CPSR_M (0x1fU) - -./qemu/target-arm/cpu.h:#define CPSR_USER (CPSR_NZCV | CPSR_Q | CPSR_GE) \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1606 b/results/classifier/zero-shot-user-mode/output/syscall/1606 deleted file mode 100644 index 3e3ba29f3..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1606 +++ /dev/null @@ -1,35 +0,0 @@ -syscall: 0.437 -instruction: 0.315 -runtime: 0.249 - - - -riscv: fence.i is not functional -Description of problem: -The attached user-level test is designed to do the following (in iteration): - - - Thread P0 on CPU0 changes some text/code, while - - - Thread P1 on CPU1 checks/reads the code, fence.i, then executes the same code. - -Results (in stdout) indicates that CPU1 has read the new code (1:x5=a009) but executed the old one (1:x7=1) (against the specification). -Steps to reproduce: -1. echo 2 > /proc/sys/vm/nr_hugepages -2. ./CoRF+fence.i -Additional information: -Example output: -```[CoRF+fence.i.c](/uploads/c150ca0910783cc4bfc3886789b64c28/CoRF+fence.i.c) -Test CoRF+fence.i Allowed -Histogram (4 states) -25784 :>1:x5=0xa009; 1:x7=2; -24207 *>1:x5=0xa009; 1:x7=1; <-- THIS LINE -8 :>1:x5=0xa019; 1:x7=1; -1 :>1:x5=0xa019; 1:x7=2; -Ok -Witnesses -Positive: 24207 Negative 25793 -Condition exists (1:x5=0xa009 /\ 1:x7=1) is validated -Observation CoRF+fence.i Sometimes 24207 25793 -Time CoRF+fence.i 0.85 -Hash= -``` diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1643619 b/results/classifier/zero-shot-user-mode/output/syscall/1643619 deleted file mode 100644 index d6e3e343b..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1643619 +++ /dev/null @@ -1,38 +0,0 @@ -syscall: 0.497 -instruction: 0.382 -runtime: 0.122 - - - -netlink broken on big-endian mips - -Debian QEMU version 2.7.0, but the bug also appears in current git master (commit c36ed06e9159) - -As the summary says, netlink is completely broken on big-endian mips running qemu-user. - -Running 'ip route' from within a Debian chroot with QEMU simply hangs. Running amd64 strace on qemu-mips-static shows that it's waiting for a netlink response from the kernel which never comes. - -[...] -[pid 11249] socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 3 -[pid 11249] setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0 -[pid 11249] setsockopt(3, SOL_SOCKET, SO_RCVBUF, [1048576], 4) = 0 -[pid 11249] bind(3, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0 -[pid 11249] getsockname(3, {sa_family=AF_NETLINK, nl_pid=11249, nl_groups=00000000}, [12]) = 0 -[pid 11249] time([1479745823]) = 1479745823 -[pid 11249] sendto(3, {{len=671088640, type=0x1a00 /* NLMSG_??? */, flags=NLM_F_REQUEST|NLM_F_MULTI|0x100, seq=539046744, pid=0}, "\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\35\0\0\0\1"}, 40, 0, NULL, 0) = 40 -[pid 11249] recvmsg(3, - -Notice the len in the buffer passed to the kernel is 0x28000000 which looks byteswapped. - -Removing the call to fd_trans_unregister in the NR_socket syscall in do_syscall fixes this for me, but I don't understand why the fd translation was immediately unregistered after being registered just before in do_socket - presumably it was added for a reason. - ---- a/linux-user/syscall.c -+++ b/linux-user/syscall.c -@@ -9331,7 +9331,6 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1, - #ifdef TARGET_NR_socket - case TARGET_NR_socket: - ret = do_socket(arg1, arg2, arg3); -- fd_trans_unregister(ret); - break; - #endif - #ifdef TARGET_NR_socketpair \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1667401 b/results/classifier/zero-shot-user-mode/output/syscall/1667401 deleted file mode 100644 index 769f7cfff..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1667401 +++ /dev/null @@ -1,73 +0,0 @@ -syscall: 0.366 -instruction: 0.327 -runtime: 0.306 - - - -qemu-ppc segfaults(SIGSEGV) on pthread_create - -qemu-ppc running on x86-64 hardware leads to a segfault when running the -attached program (test.c). It simply creates a pthread, joins it and exits. - -It was compiled as follows on a Debian testing system: -> powerpc-linux-gnuspe-gcc-6 -static -Wall -g -o test -pthread test.c - -Sample execution (expected output is "Hello - World!"): -> qemu-ppc -cpu e500 ./test -[...output...] -Hello - qemu-ppc: /build/qemu-_M2UL5/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. -qemu-ppc: /build/qemu-_M2UL5/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. -[1] 25747 segmentation fault qemu-ppc -cpu e500 test -[...end output...] - -The same behavior is observed when running on a PPC 604: - -> powerpc-linux-gnu-gcc -Wall -g -o test -pthread test.c -> qemu-ppc ./test -[... as above ...] - -Version information: -powerpc-linux-gnu-gcc -v => gcc version 6.3.0 20170124 (Debian 6.3.0-5) -qemu-ppc -version => qemu-ppc version 2.8.0(Debian 1:2.8+dfsg-2) - -The same experiment was conducted again using qemu from the git repository (commit: 796b288f7be875045670f963ce99991b3c8e96ac): -~/tools/qemu/build/ppc-linux-user/qemu-ppc -version => qemu-ppc version 2.8.50 (v2.8.0-1417-g796b288f7b-dirty) -[...output...] -Hello - qemu-ppc: [...redacted...]/tools/qemu/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. -qemu-ppc: [...redacted...]/tools/qemu/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. -[1] 25996 segmentation fault ~/tools/qemu/build/ppc-linux-user/qemu-ppc -cpu e500 test -[...end output...] - - -Executing with -strace option yields a surprising entry (see second clone() syscall below): -[...] -26007 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0xf67fde60,parent_tidptr=0xf67fe368,tls=0xf68057d0,child_tidptr=0xf67fe368) = 26009 -26007 clone(0,child_stack=0xf67fde60,parent_tidptr=0xf67fe368,tls=0xf68057d0,child_tidptr=0xf67fe368) = -1 errno=22 (Invalid argument) - - -test.c works just fine if the pthread_create & pthread_join calls are removed -(i.e. when compiled with -DNO_PTHREAD_CREATE). - -At first glance, the issue seems specific to PPC because compiling and running -for x86_64 using qemu-x86_64 works fine. - - -Additional info: -> lddtree =qemu-ppc -qemu-ppc => /usr/bin/qemu-ppc (interpreter => /lib64/ld-linux-x86-64.so.2) - libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 - libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 - ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 - libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 - libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 - librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 - libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 - libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 - libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 - libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 - -> /lib/x86_64-linux-gnu/libc.so.6 -GNU C Library (Debian GLIBC 2.24-9) stable release version 2.24, by Roland McGrath et al. - -> uname -a -Linux [...redacted...] 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64 GNU/Linux \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1689367 b/results/classifier/zero-shot-user-mode/output/syscall/1689367 deleted file mode 100644 index 79ef9e170..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1689367 +++ /dev/null @@ -1,32 +0,0 @@ -syscall: 0.645 -instruction: 0.267 -runtime: 0.087 - - - -In qemu chroot, repeating "qemu: Unsupported syscall: 384" messages. sys_getrandom ? - -On exec of an armv7 qemu chroot on my local x86_64 desktop, launched via - - /usr/sbin/qemu-binfmt-conf.sh - -from - - qemu-linux-user-2.9.0-374.1.x86_64 - -on the host, inside the chroot any compile activity is laced with repetitions of - - qemu: Unsupported syscall: 384 - -messages. - -This wasn't always the case -- but, TBH, it's been ~ 6 months since I used this env, and there have been scads of usual pkg updates in the interim. These messages appear to be non-fatal, with no particular effect at all; at least not so far ... - -From a chat in #IRC, - - [10:05] davidgiluk clever/pgnd: I see it as getrandom - [10:05] davidgiluk pgnd: https://fedora.juszkiewicz.com.pl/syscalls.html sort it on the ARM table and you can easily see it - [10:05] clever arch/arm/tools/syscall.tbl:384 common getrandom sys_getrandom - [10:06] davidgiluk pgnd: my *guess* is that something is calling getrandom, getting told it's not implemented and then falling back to using /dev/urandom - [10:10] pgnd davidgiluk: If that *is* the case, is it to be considered a problem, or just informational? - [10:12] davidgiluk pgnd: As long as it's falling back probably informational; but someone should probably go and wire up sys_getrandom at some point \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1704638 b/results/classifier/zero-shot-user-mode/output/syscall/1704638 deleted file mode 100644 index 7579f26a1..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1704638 +++ /dev/null @@ -1,71 +0,0 @@ -syscall: 0.348 -instruction: 0.329 -runtime: 0.322 - - - -weak symbol access makes qemu in user mode hang for mips, mips64 - -A program that is statically linked and invokes a weak pointer should crash (because the weak pointer evaluates to NULL). - -With qemu in user mode, for mips and mips64, it hangs. The process needs to be killed with "kill -9". - -How to reproduce for mips: -- Compile the program: mips-linux-gnu-gcc-5 -O -Wall -static -o testpthsigmask-mips testpthsigmask.c -pthread -- Set environment variables for running qemu-mips. -- ~/inst-qemu/2.9.0/bin/qemu-mips testpthsigmask-mips - -How to reproduce for mips64: -- Compile the program: mips64-linux-gnuabi64-gcc-5 -O -Wall -static -o testpthsigmask-mips64 testpthsigmask.c -lpthread -- Set environment variables for running qemu-mips64. -- ~/inst-qemu/2.9.0/bin/qemu-mips64 testpthsigmask-mips64 - -When I attach gdb to the process, I see that it is hanging inside 'gen_intermediate_code': - -$ gdb /home/bruno/inst-qemu/2.9.0/bin/qemu-mips 9726 -... -Reading symbols from /home/bruno/inst-qemu/2.9.0/bin/qemu-mips...done. -Attaching to program: /home/bruno/inst-qemu/2.9.0/bin/qemu-mips, process 9726 -... -(gdb) info threads - Id Target Id Frame -* 1 Thread 0x7f1e7e535740 (LWP 9726) "qemu-mips" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 - 2 Thread 0x7f1e7d0ad700 (LWP 9727) "qemu-mips" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 -(gdb) where -#0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 -#1 0x00007f1e7d6f1dbd in __GI___pthread_mutex_lock (mutex=mutex@entry=0x55de1c7ff830 <tcg_ctx+272>) at ../nptl/pthread_mutex_lock.c:80 -#2 0x000055de1c527199 in qemu_mutex_lock (mutex=mutex@entry=0x55de1c7ff830 <tcg_ctx+272>) - at /media/develdata/devel/build/qemu-2.9.0/util/qemu-thread-posix.c:60 -#3 0x000055de1c435083 in tb_lock () at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:167 -#4 cpu_restore_state (cpu=cpu@entry=0x55de1e915cb0, retaddr=retaddr@entry=94412445741769) at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:350 -#5 0x000055de1c4658d0 in handle_cpu_signal (old_set=0x7ffe5ffd8ea8, is_write=0, address=0, pc=94412445741767) - at /media/develdata/devel/build/qemu-2.9.0/user-exec.c:124 -#6 cpu_mips_signal_handler (host_signum=host_signum@entry=11, pinfo=pinfo@entry=0x7ffe5ffd8eb0, puc=puc@entry=0x7ffe5ffd8d80) - at /media/develdata/devel/build/qemu-2.9.0/user-exec.c:229 -#7 0x000055de1c4803be in host_signal_handler (host_signum=11, info=0x7ffe5ffd8eb0, puc=0x7ffe5ffd8d80) - at /media/develdata/devel/build/qemu-2.9.0/linux-user/signal.c:646 -#8 <signal handler called> -#9 __bswap_32 (__bsx=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/byteswap.h:47 -#10 bswap32 (x=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/bswap.h:21 -#11 ldl_be_p (ptr=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/bswap.h:434 -#12 cpu_ldl_code (env=0x55de1e91df48, ptr=0) at /media/develdata/devel/build/qemu-2.9.0/include/exec/cpu_ldst_useronly_template.h:68 -#13 gen_intermediate_code (env=env@entry=0x55de1e91df48, tb=tb@entry=0x7f1e7b288e58) - at /media/develdata/devel/build/qemu-2.9.0/target/mips/translate.c:19962 -#14 0x000055de1c4352e6 in tb_gen_code (cpu=cpu@entry=0x55de1e915cb0, pc=pc@entry=0, cs_base=cs_base@entry=0, flags=flags@entry=162, cflags=<optimized out>, - cflags@entry=0) at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:1295 -#15 0x000055de1c436a7a in tb_find (tb_exit=0, last_tb=0x0, cpu=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/cpu-exec.c:365 -#16 cpu_exec (cpu=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/cpu-exec.c:673 -#17 0x000055de1c466278 in cpu_loop (env=0x55de1e91df48) at /media/develdata/devel/build/qemu-2.9.0/linux-user/main.c:2236 -#18 0x000055de1c433103 in main (argc=<optimized out>, argv=0x7ffe5ffd9de8, envp=<optimized out>) - at /media/develdata/devel/build/qemu-2.9.0/linux-user/main.c:4860 -(gdb) thread 2 -[Switching to thread 2 (Thread 0x7f1e7d0ad700 (LWP 9727))] -#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 -38 ../sysdeps/unix/sysv/linux/x86_64/syscall.S: Datei oder Verzeichnis nicht gefunden. -(gdb) where -#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 -#1 0x000055de1c527605 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/futex.h:26 -#2 qemu_event_wait (ev=ev@entry=0x55de1e82c124 <rcu_call_ready_event>) at /media/develdata/devel/build/qemu-2.9.0/util/qemu-thread-posix.c:399 -#3 0x000055de1c52d41e in call_rcu_thread (opaque=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/util/rcu.c:249 -#4 0x00007f1e7d6ef6ba in start_thread (arg=0x7f1e7d0ad700) at pthread_create.c:333 -#5 0x00007f1e7d4253dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1716292 b/results/classifier/zero-shot-user-mode/output/syscall/1716292 deleted file mode 100644 index 1253cd970..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1716292 +++ /dev/null @@ -1,36 +0,0 @@ -syscall: 0.526 -instruction: 0.387 -runtime: 0.087 - - - -User mode emulation returns wrong value for write(fd, NULL, 0) - -QEMU version: latest master (fcea73709b966a7ded9efa7b106ea50c7fe9025c) -OS version: Ubuntu 14.04.3 -Configured with: ../configure --target-list=x86_64-linux-user - -QEMU Linux usermode emulation does not handle write() syscalls with zero length and a null pointer correctly: on Linux this returns 0, but in emulation this returns -1. - -I ran into this while using an aarch64 abuild-tar from Alpine Linux in user-mode emulation; here's the minimized reproduction test case: - -zhuowei@zhuowei-tablet:/tmp$ cat writezerobytes.c -#include <stdio.h> -#include <unistd.h> -#include <fcntl.h> - -int main() { - ssize_t ret = write(STDOUT_FILENO, NULL, 0); - fprintf(stderr, "write returned %ld\n", ret); - return 0; -} -zhuowei@zhuowei-tablet:/tmp$ gcc -o writezerobytes writezerobytes.c -zhuowei@zhuowei-tablet:/tmp$ uname -a -Linux zhuowei-tablet 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11 12:48:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux -zhuowei@zhuowei-tablet:/tmp$ ./writezerobytes -write returned 0 -zhuowei@zhuowei-tablet:/tmp$ /media/zhuowei/redhd/docs/repos/qemu/build4/x86_64-linux-user/qemu-x86_64 ./writezerobytes -write returned -1 -zhuowei@zhuowei-tablet:/tmp$ /media/zhuowei/redhd/docs/repos/qemu/build4/x86_64-linux-user/qemu-x86_64 --version -qemu-x86_64 version 2.10.50 (v2.10.0-471-gfcea737-dirty) -Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1728116 b/results/classifier/zero-shot-user-mode/output/syscall/1728116 deleted file mode 100644 index 506e203ec..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1728116 +++ /dev/null @@ -1,53 +0,0 @@ -syscall: 0.549 -instruction: 0.269 -runtime: 0.182 - - - -Empty /proc/self/auxv (linux-user) - -The userspace Linux API virtualization used to fake access to /proc/self/auxv, to provide meaningful data for the guest process. - -For newer qemu versions, this fails: The openat() is intercepted, but there's no content: /proc/self/auxv has length zero (i.e. reading from it returns 0 bytes). - -Good: - -$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c -256 /proc/self/auxv - -Bad: - -$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c -0 /proc/self/auxv - -This worked in 2.7.1, and fails in 2.10.1. - -This causes e.g. any procps-ng-based tool to segfault while reading from /proc/self/auxv in an endless loop (probably worth another bug report...) - -Doing a "git bisect" shows that this commit: https://github.com/qemu/qemu/commit/7c4ee5bcc introduced the problem. - -It might be a simple logic (subtraction in the wrong direction?) or sign-ness error: Adding some logging (to v2.10.1) - -diff --git a/linux-user/syscall.c b/linux-user/syscall.c -index 9b6364a..49285f9 100644 ---- a/linux-user/syscall.c -+++ b/linux-user/syscall.c -@@ -7469,6 +7469,9 @@ static int open_self_auxv(void *cpu_env, int fd) - abi_ulong len = ts->info->auxv_len; - char *ptr; - -+ gemu_log(TARGET_ABI_FMT_lu"\n", len); -+ gemu_log(TARGET_ABI_FMT_ld"\n", len); -+ - /* - * Auxiliary vector is stored in target process stack. - * read in whole auxv vector and copy it to file - -shows this output: - -$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c -18446744073709551264 --352 -0 - -And 352 could be the expected length. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1734792 b/results/classifier/zero-shot-user-mode/output/syscall/1734792 deleted file mode 100644 index 80481203e..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1734792 +++ /dev/null @@ -1,13 +0,0 @@ -syscall: 0.926 -instruction: 0.067 -runtime: 0.008 - - - -linux-user mode does not support memfd_create syscall - -qemu-x86_66 GIT HEAD fails on a userspace application that requires memfd_create with: - -"qemu: Unsupported syscall: 319". - -memfd_create support needs to be implemented in QEMU. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1760 b/results/classifier/zero-shot-user-mode/output/syscall/1760 deleted file mode 100644 index 9751ab99a..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1760 +++ /dev/null @@ -1,59 +0,0 @@ -syscall: 0.584 -instruction: 0.269 -runtime: 0.148 - - - -qemu8-i386 gets wrong arguments for 32-bit old mmap syscall (_NR_mmap = 90) -Description of problem: -qemu8-i386 does not decode syscall arguments correctly for system call _NR_mmap = 90 on i386. -``` -$ strace ./oldmmap -execve("./oldmmap", ["./oldmmap"], 0x7fff46ba6d40 /* 61 vars */) = 0 -[ Process PID=405233 runs in 32 bit mode. ] -mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7fa7000 -exit(5) = ? -+++ exited with 5 +++ - -$ build/qemu-i386 -strace ./oldmmap -405254 mmap(0x40800058,0,PROT_NONE,0,0,0) = 0x3fffb000 -405254 exit(5) -``` -Steps to reproduce: -1. gcc -m32 -o oldmmap -nostartfiles -nostdlib oldmmap.S # build 32-bit executable -2. strace ./oldmmap # run under strace -3. build/qemu-i386 -strace ./oldmmap # run under "qemu-i386 -strace" -4. Notice that qemu-i386 did not report the same arguments to the _NR_map syscall as /usr/bin/strace did. -Additional information: -``` -$ cat oldmmap.S -MAP_FIXED= 0x10 -MAP_PRIVATE= 0x02 -MAP_ANONYMOUS= 0x20 - -PROT_READ= 1 -PROT_WRITE= 2 -PROT_EXEC= 4 - -_NR_exit = 1 -_NR_mmap = 90 // oldmmap: %ebx -> array of 6 arguments - - .globl _start -_start: - push $0 // offset - push $-1 // fd - push $MAP_PRIVATE|MAP_ANONYMOUS // flags - push $PROT_READ|PROT_WRITE // protection - push $2<<12 // length - push $0 // addr (kernel chooses) - mov %esp,%ebx - mov $_NR_mmap,%eax - int $0x80 - nop - - mov $5,%ebx - mov $_NR_exit,%eax - int $0x80 - hlt -$ -``` diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1763536 b/results/classifier/zero-shot-user-mode/output/syscall/1763536 deleted file mode 100644 index 09d2b70b9..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1763536 +++ /dev/null @@ -1,89 +0,0 @@ -syscall: 0.377 -runtime: 0.342 -instruction: 0.281 - - - -go build fails under qemu-ppc64le-static (qemu-user) - -I am using qemu-user (built static) in a docker container environment. When running multi-threaded go commands in the container (go build for example) the process may hang, report segfaults or other errors. I built qemu-ppc64le from the upstream git (master). - -I see the problem running on a multi core system with Intel i7 processors. -# cat /proc/cpuinfo | grep "model name" -model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz -model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz -model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz -model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz -model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz -model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz -model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz -model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz - -Steps to reproduce: -1) Build qemu-ppc64le as static and copy into docker build directory named it qemu-ppc64le-static. - -2) Add hello.go to docker build dir. - -package main -import "fmt" -func main() { - fmt.Println("hello world") -} - -3) Create the Dockerfile from below: - -FROM ppc64le/golang:1.10.1-alpine3. -COPY qemu-ppc64le-static /usr/bin/ -COPY hello.go /go - -4) Build container -$ docker build -t qemutest -f Dockerfile ./go - -5) Run test -$ docker run -it qemutest - -/go # /usr/bin/qemu-ppc64le-static --version -qemu-ppc64le version 2.11.93 (v2.12.0-rc3-dirty) -Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers - -/go # go version -go version go1.10.1 linux/ppc64le - -/go # go build hello.go -fatal error: fatal error: stopm holding locksunexpected signal during runtime execution - -panic during panic -[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1003528c] - -runtime stack: -runtime: unexpected return pc for syscall.Syscall6 called from 0xc42007f500 -stack: frame={sp:0xc4203be840, fp:0xc4203be860} stack=[0x4000b7ecf0,0x4000b928f0) - -syscall.Syscall6(0x100744e8, 0x3d, 0xc42050c140, 0x20, 0x18, 0x10422b80, 0xc4203be968[signal , 0x10012d88SIGSEGV: segmentation violation, 0xc420594000 code=, 0x00x1 addr=0x0 pc=0x1003528c) -] - -runtime stack: - /usr/local/go/src/syscall/asm_linux_ppc64x.s:61runtime.throw(0x10472d19, 0x13) - + /usr/local/go/src/runtime/panic.go:0x6c616 +0x68 - - -runtime.stopm() - /usr/local/go/src/runtime/proc.go:1939goroutine +10x158 - [runtime.exitsyscall0semacquire(0xc42007f500) - /usr/local/go/src/runtime/proc.go:3129 +]: -0x130 -runtime.mcall(0xc42007f500) - /usr/local/go/src/runtime/asm_ppc64x.s:183 +0x58sync.runtime_Semacquire -(0xc4201fab1c) - /usr/local/go/src/runtime/sema.go:56 +0x38 - ----- -Note the results may differ between attempts, hangs and other faults sometimes happen. ----- -If I run "go: single threaded I don't see the problem, for example: - -/go # GOMAXPROCS=1 go build -p 1 hello.go -/go # ./hello -hello world - -I see the same issue with arm64. I don't think this is a go issue, but don't have a real evidence to prove that. This problem looks similar to other problem I have seen reported against qemu running multi-threaded applications. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1785203 b/results/classifier/zero-shot-user-mode/output/syscall/1785203 deleted file mode 100644 index 02d1e8bb6..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1785203 +++ /dev/null @@ -1,49 +0,0 @@ -syscall: 0.399 -instruction: 0.308 -runtime: 0.293 - - - -accel/tcg/translate-all.c:2511: page_check_range: Assertion `start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)' failed. - -qemu-riscv64 version 2.12.93 crashes when mincore() is called with invalid pointer with the following message: - -qemu-riscv64: /opt/qemu/accel/tcg/translate-all.c:2511: page_check_range: Assertion `start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)' failed. -qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x600014ef - -Testcase: - -#include <sys/mman.h> - -int main (void) -{ - unsigned char v; - return mincore ((void *) 0x00000010000000000, 1, &v); -} - -Backtrace: - -#0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 -#1 0x000000006000140a in abort () at abort.c:79 -#2 0x00000000600012ec in __assert_fail_base ( - fmt=0x6024eae8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", - assertion=0x601b9758 "start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)", - file=0x601b9658 "/opt/qemu/accel/tcg/translate-all.c", line=2511, - function=0x601b9810 <__PRETTY_FUNCTION__.23867> "page_check_range") at assert.c:92 -#3 0x000000006010e10e in __assert_fail ( - assertion=assertion@entry=0x601b9758 "start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)", file=file@entry=0x601b9658 "/opt/qemu/accel/tcg/translate-all.c", line=line@entry=2511, - function=function@entry=0x601b9810 <__PRETTY_FUNCTION__.23867> "page_check_range") - at assert.c:101 -#4 0x000000006003e916 in page_check_range (start=start@entry=1099511627776, len=len@entry=1, - flags=flags@entry=1) at /opt/qemu/accel/tcg/translate-all.c:2511 -#5 0x0000000060057717 in access_ok (size=1, addr=1099511627776, type=0) - at /opt/qemu/linux-user/qemu.h:567 -#6 lock_user (copy=0, len=1, guest_addr=1099511627776, type=0) - at /opt/qemu/linux-user/qemu.h:567 -#7 do_syscall (cpu_env=cpu_env@entry=0x622fca28, num=232, arg1=1099511627776, arg2=1, - arg3=274886298751, arg4=0, arg5=274886298808, arg6=66518, arg7=0, arg8=0) - at /opt/qemu/linux-user/syscall.c:11635 -#8 0x0000000060066c5c in cpu_loop (env=env@entry=0x622fca28) - at /opt/qemu/linux-user/riscv/cpu_loop.c:55 -#9 0x0000000060002156 in main (argc=<optimized out>, argv=0x7fffffffed68, - envp=<optimized out>) at /opt/qemu/linux-user/main.c:819 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1785734 b/results/classifier/zero-shot-user-mode/output/syscall/1785734 deleted file mode 100644 index 545f10f26..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1785734 +++ /dev/null @@ -1,81 +0,0 @@ -syscall: 0.440 -instruction: 0.319 -runtime: 0.240 - - - -movdqu partial write at page boundary - -In TCG mode, when a 16-byte write instruction (such as movdqu) is executed at a page boundary and causes a page fault, a partial write is executed in the first page. See the attached code for an example. - -Tested on the qemu-3.0.0-rc1 release. - - -% gcc -m32 qemu-bug2.c && ./a.out && echo && qemu-i386 ./a.out -*(0x70000ff8+ 0) = aa -*(0x70000ff8+ 1) = aa -*(0x70000ff8+ 2) = aa -*(0x70000ff8+ 3) = aa -*(0x70000ff8+ 4) = aa -*(0x70000ff8+ 5) = aa -*(0x70000ff8+ 6) = aa -*(0x70000ff8+ 7) = aa -*(0x70000ff8+ 8) = 55 -*(0x70000ff8+ 9) = 55 -*(0x70000ff8+10) = 55 -*(0x70000ff8+11) = 55 -*(0x70000ff8+12) = 55 -*(0x70000ff8+13) = 55 -*(0x70000ff8+14) = 55 -*(0x70000ff8+15) = 55 -page fault: addr=0x70001000 err=0x7 -*(0x70000ff8+ 0) = aa -*(0x70000ff8+ 1) = aa -*(0x70000ff8+ 2) = aa -*(0x70000ff8+ 3) = aa -*(0x70000ff8+ 4) = aa -*(0x70000ff8+ 5) = aa -*(0x70000ff8+ 6) = aa -*(0x70000ff8+ 7) = aa -*(0x70000ff8+ 8) = 55 -*(0x70000ff8+ 9) = 55 -*(0x70000ff8+10) = 55 -*(0x70000ff8+11) = 55 -*(0x70000ff8+12) = 55 -*(0x70000ff8+13) = 55 -*(0x70000ff8+14) = 55 -*(0x70000ff8+15) = 55 - -*(0x70000ff8+ 0) = aa -*(0x70000ff8+ 1) = aa -*(0x70000ff8+ 2) = aa -*(0x70000ff8+ 3) = aa -*(0x70000ff8+ 4) = aa -*(0x70000ff8+ 5) = aa -*(0x70000ff8+ 6) = aa -*(0x70000ff8+ 7) = aa -*(0x70000ff8+ 8) = 55 -*(0x70000ff8+ 9) = 55 -*(0x70000ff8+10) = 55 -*(0x70000ff8+11) = 55 -*(0x70000ff8+12) = 55 -*(0x70000ff8+13) = 55 -*(0x70000ff8+14) = 55 -*(0x70000ff8+15) = 55 -page fault: addr=0x70001000 err=0x6 -*(0x70000ff8+ 0) = 77 -*(0x70000ff8+ 1) = 66 -*(0x70000ff8+ 2) = 55 -*(0x70000ff8+ 3) = 44 -*(0x70000ff8+ 4) = 33 -*(0x70000ff8+ 5) = 22 -*(0x70000ff8+ 6) = 11 -*(0x70000ff8+ 7) = 0 -*(0x70000ff8+ 8) = 55 -*(0x70000ff8+ 9) = 55 -*(0x70000ff8+10) = 55 -*(0x70000ff8+11) = 55 -*(0x70000ff8+12) = 55 -*(0x70000ff8+13) = 55 -*(0x70000ff8+14) = 55 -*(0x70000ff8+15) = 55 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1791796 b/results/classifier/zero-shot-user-mode/output/syscall/1791796 deleted file mode 100644 index 0931ae635..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1791796 +++ /dev/null @@ -1,129 +0,0 @@ -syscall: 0.340 -runtime: 0.336 -instruction: 0.324 - - - -unimplemented thread syscalls in nios2 user-mode emulation - -This bug is reported against the 3.0 release. - -I noticed that the GCC test gcc.dg/torture/tls/tls-test.c is failing when run in user-mode qemu for nios2 target. The problem appears to be that the thread-related syscalls are unimplemented in qemu. Here is output from running with -strace: - -22484 brk(NULL) = 0x00005000 -22484 uname(0x7fffef5a) = 0 -22484 faccessat(AT_FDCWD,"/etc/ld.so.preload",R_OK,0x5) = -1 errno=2 (No such file or directory) -22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./tls/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) -22484 fstatat64(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./tls",0x7fffe870,0) = -1 errno=2 (No such file or directory) -22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 -22484 read(3,0x7fffe954,512) = 512 -22484 fstat64(3,0x7fffe870) = 0 -22484 mmap2(NULL,803596,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f716000 -22484 mmap2(0x7f7d8000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xc1) = 0x7f7d8000 -22484 close(3) = 0 -22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 -22484 read(3,0x7fffe948,512) = 512 -22484 mmap2(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x7f714000 -22484 fstat64(3,0x7fffe864) = 0 -22484 mmap2(NULL,120700,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f6f6000 -22484 mprotect(0x7f70e000,4096,PROT_NONE) = 0 -22484 mmap2(0x7f70f000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x18) = 0x7f70f000 -22484 mmap2(0x7f712000,6012,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f712000 -22484 close(3) = 0 -22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 -22484 read(3,0x7fffe93c,512) = 512 -22484 fstat64(3,0x7fffe858) = 0 -22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 -22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 -22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 -22484 close(3) = 0 -22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 -22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 -22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 -22484 mprotect(0x00003000,4096,PROT_READ) = 0 -22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 -22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 -22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) -22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 -22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) -22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 -22484 getrlimit(3,2147480732,3,0,62512,47) = 0 -22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 -22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 -22484 brk(NULL) = 0x00005000 -22484 brk(0x00026000) = 0x00026000 -22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 -22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) -22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) -22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 -22484 exit(0) - = 0 -22484 fstat64(1,0x7fffef48) = 0 -22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 - = 42 -22484 exit_group(1) -sandra@build2-trusty-cs:/scratch/sandra/nios2-linux-trunk3$ -22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 -22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 -22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 -22484 close(3) = 0 -22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 -22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 -22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 -22484 mprotect(0x00003000,4096,PROT_READ) = 0 -22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 -22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 -22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) -22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 -22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) -22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 -22484 getrlimit(3,2147480732,3,0,62512,47) = 0 -22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 -22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 -22484 brk(NULL) = 0x00005000 -22484 brk(0x00026000) = 0x00026000 -22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 -22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) -22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) -22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 -22484 exit(0) - = 0 -22484 fstat64(1,0x7fffef48) = 0 -22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 - = 42 -22484 exit_group(1) -sandra@build2-trusty-cs:/scratch/sandra/nios2-linux-trunk3$ -22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 -22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 -22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 -22484 close(3) = 0 -22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 -22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 -22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 -22484 mprotect(0x00003000,4096,PROT_READ) = 0 -22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 -22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 -22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) -22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 -22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) -22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 -22484 getrlimit(3,2147480732,3,0,62512,47) = 0 -22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 -22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 -22484 brk(NULL) = 0x00005000 -22484 brk(0x00026000) = 0x00026000 -22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 -22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) -22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) -22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 -22484 exit(0) - = 0 -22484 fstat64(1,0x7fffef48) = 0 -22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 - = 42 -22484 exit_group(1) - -Note that set_robust_list and clone are reported as unimplemented. - -I've reported the problems with the signal syscalls separately here. -https://bugs.launchpad.net/qemu/+bug/1791763 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1799200 b/results/classifier/zero-shot-user-mode/output/syscall/1799200 deleted file mode 100644 index c9f04c2e6..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1799200 +++ /dev/null @@ -1,46 +0,0 @@ -syscall: 0.366 -instruction: 0.331 -runtime: 0.303 - - - -null pointer dereference in tcg_emit_op - -I am insert a custom tcg helper function in i386_tr_insn_start for trace the instructions. - -most of time the qemu runed ok ,but when execute some special software will lead to crash. - - -the below is the insert code: -======================================================================================= - - 8514 static void i386_tr_insn_start(DisasContextBase *dcbase, CPUState *cpu) - 8515 { - 8516 DisasContext *dc = container_of(dcbase, DisasContext, base); - 8517 TCGv_ptr ptr= tcg_const_ptr((void*)cpu); // inserted hepler code - 8518 gen_helper_mad_exec(ptr);// insert helper code - 8519 tcg_gen_insn_start(dc->base.pc_next, dc->cc_op); - 8520 } -====================================================================================== - -below is the callstack - -#0 0x000055555581df5e in tcg_emit_op (opc=opc@entry=INDEX_op_movi_i64) at /root/qemu/tcg/tcg.c:2205 -#1 0x0000555555825911 in tcg_gen_op2 (opc=opc@entry=INDEX_op_movi_i64, a1=140734736923704, a2=a2@entry=792) at /root/qemu/tcg/tcg-op.c:53 -#2 0x000055555581d713 in tcg_const_i64 (opc=INDEX_op_movi_i64, a2=792, a1=0x7378) at /root/qemu/tcg/tcg-op.h:109 -#3 0x000055555581d713 in tcg_const_i64 (arg=792, ret=<optimized out>) at /root/qemu/tcg/tcg-op.h:579 -#4 0x000055555581d713 in tcg_const_i64 (val=val@entry=792) at /root/qemu/tcg/tcg.c:1314 -#5 0x000055555582732d in tcg_gen_addi_i64 (ret=0xd18, arg1=0x378, arg2=arg2@entry=792) at /root/qemu/tcg/tcg-op.c:1200 -#6 0x000055555590ffaf in gen_sse (b=792, a=<optimized out>, r=<optimized out>) at /root/qemu/tcg/tcg-op.h:1258 -#7 0x000055555590ffaf in gen_sse (env=env@entry=0x5555567424d0, s=s@entry=0x7fffea99a610, b=b@entry=366, pc_start=pc_start@entry=4513509698, rex_r=rex_r@entry=0) at /root/qemu/target/i386/translate.c:3150 -#8 0x0000555555911d7f in disas_insn (s=s@entry=0x7fffea99a610, cpu=<optimized out>) at /root/qemu/target/i386/translate.c:8336 -#9 0x00005555559207a0 in i386_tr_translate_insn (dcbase=0x7fffea99a610, cpu=<optimized out>) at /root/qemu/target/i386/translate.c:8543 -#10 0x0000555555892649 in translator_loop (ops=0x55555622dee0 <i386_tr_ops>, db=0x7fffea99a610, cpu=0x55555673a220, tb=<optimized out>) at /root/qemu/accel/tcg/translator.c:110 -#11 0x00005555559209ef in gen_intermediate_code (cpu=cpu@entry=0x55555673a220, tb=tb@entry=0x7fff70682040 <code_gen_buffer+208150547>) at /root/qemu/target/i386/translate.c:8605 -#12 0x0000555555891437 in tb_gen_code (cpu=cpu@entry=0x55555673a220, pc=pc@entry=4513506448, cs_base=cs_base@entry=0, flags=flags@entry=4244147, cflags=cflags@entry=0) at /root/qemu/accel/tcg/translate-all.c:1728 -#13 0x000055555588f97b in cpu_exec (cf_mask=0, tb_exit=0, last_tb=0x0, cpu=0x0) at /root/qemu/accel/tcg/cpu-exec.c:410 -#14 0x000055555588f97b in cpu_exec (cpu=cpu@entry=0x55555673a220) at /root/qemu/accel/tcg/cpu-exec.c:734 -#15 0x000055555584b152 in tcg_cpu_exec (cpu=0x55555673a220) at /root/qemu/cpus.c:1405 -#16 0x000055555584d1b8 in qemu_tcg_rr_cpu_thread_fn (arg=<optimized out>) at /root/qemu/cpus.c:1505 -#17 0x00007ffff2585e25 in start_thread () at /lib64/libpthread.so.0 -#18 0x00007ffff22afbad in clone () at /lib64/libc.so.6 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1819 b/results/classifier/zero-shot-user-mode/output/syscall/1819 deleted file mode 100644 index f39ed8e83..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1819 +++ /dev/null @@ -1,16 +0,0 @@ -syscall: 0.455 -instruction: 0.405 -runtime: 0.140 - - - -segmentation fault for rpm -qa command on centos:centos7 linux/arm/v7 architecture for docker container in shell. -Description of problem: - -Steps to reproduce: -1. docker pull centos:centos7@sha256:6887440ab977f751d6675157b73e42428d8ac05cf244c5d09ba036cc22d40d13 //pull an image centos:centos7 linux/arm/v7 tag -2. docker run -it b22fdcc90005 //docker run in interactive mode just pulled image -3. on shell run command -\> rpm -qa. -4. docker run -it b22fdcc90005 - - WARNING: The requested image's platform (linux/arm/v7) does not match the detected host platform (linux/amd64) and no specific platform was requested \[root@e23bc92686e8 /\]# rpm -qa Segmentation fault (core dumped) diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1821006 b/results/classifier/zero-shot-user-mode/output/syscall/1821006 deleted file mode 100644 index 41a2e43e2..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1821006 +++ /dev/null @@ -1,41 +0,0 @@ -syscall: 0.568 -instruction: 0.260 -runtime: 0.172 - - - -qemu: Unsupported syscall: 382 - -I used - -qemu-user-static/stable,stable,now 1:2.8+dfsg-6+deb9u5 amd64 [installed] - -When I try to build an image of a docker for an arm, an error occurs. - -This affects the operation of applications. - - -Dockerfile - -ARG ARCH -FROM ${ARCH}/debian:buster-slim - -RUN \ - printf "Install dependencies...\n" && \ - apt-get update && \ - apt-get install -y --no-install-recommends ca-certificates curl - -RUN curl https://google.com - -EOF - -The command that I run - -docker build --build-arg ARCH=arm32v7 --file ./Dockerfile -t test . - - -root@unit6:/lib/binfmt.d# cat qemu-arm-static.conf -:qemu-arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:F - -Here is a related discussion. -https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923479 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1858461 b/results/classifier/zero-shot-user-mode/output/syscall/1858461 deleted file mode 100644 index 814e0c990..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1858461 +++ /dev/null @@ -1,29 +0,0 @@ -syscall: 0.766 -instruction: 0.138 -runtime: 0.096 - - - -Please refactor linux-user/mips/cpu_loop.c - -Hello. I am working with qemu on test images. I've added a new syscall (436) to qemu but received ENOSYS from mips application. - -Please open "linux-user/mips/cpu_loop.c". I've added at the end of "mips_syscall_args" the following: - -``` -MIPS_SYS(sys_getdents64_x32, 3) -``` - -But - -``` -syscall_num = env->active_tc.gpr[2] - 4000; -if (syscall_num >= sizeof(mips_syscall_args)) { - ret = -TARGET_ENOSYS; -``` - -returns -TARGET_ENOSYS - -We can see that "linux-user/mips/cpu_loop.c" differs a lot from "linux-user/arm/cpu_loop.c". Arm has it's own "ARM_NR_BASE" and etc. - -Can you please refactor mips cpu loop in the same way as arm? Thank you. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1861341 b/results/classifier/zero-shot-user-mode/output/syscall/1861341 deleted file mode 100644 index 85a6c0c11..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1861341 +++ /dev/null @@ -1,36 +0,0 @@ -syscall: 0.782 -instruction: 0.156 -runtime: 0.061 - - - -ARM QEMU: Unknown syscall 397 - -QEMU is reporting - -``` -Unknown syscall 397 -``` - -(statx if I read tables right) when used via flatpak for ARM images on x86_64. This has been reproduced on Fedora and Gentoo. - -To reproduce: - -- get flatpak KDE 5.12 for arm: - -flatpak install --user org.kde.Sdk/arm/5.12 org.kde.Platform/arm/5.12 - - -- run qmake inside Sdk: - -QEMU_STRACE=1 flatpak run --filesystem=host --command=qmake org.kde.Sdk/arm/5.12 . - - -You will get a host of messages with unknown syscall. In practice, qmake will fail to find .pro files if you have them in that folder and libraries in the system. - -As far as I understand, Flatpak images are built on AARCH64 hardware. - -My config on Gentoo: - -kernel: 4.19.86-gentoo x86_64 -app-emulation/qemu: ~4.2.0-r1 , same with 4.0.0 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1861605 b/results/classifier/zero-shot-user-mode/output/syscall/1861605 deleted file mode 100644 index 3b953ee68..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1861605 +++ /dev/null @@ -1,22 +0,0 @@ -syscall: 0.468 -instruction: 0.385 -runtime: 0.147 - - - -LL/SC broken for MIPS after 7dd547e5ab6b31e7a0cfc182d3ad131dd55a948f - -In that commit the env->llval value is loaded as an unsigned value (instead of sign-extended as before and therefore the CMPXCHG in gen_st_cond() in translate.c fails. - -I have committed a fix for this issue as https://github.com/CTSRD-CHERI/qemu/commit/a18d80c629989d002794f558968e1561edaf3dfd - -An alternative solution would be to change the cmpxchg line to perform a non-sign-extended compare, i.e. replace - tcg_gen_atomic_cmpxchg_tl(t0, addr, cpu_llval, val, - eva ? MIPS_HFLAG_UM : ctx->mem_idx, tcg_mo); -with - tcg_gen_atomic_cmpxchg_tl(t0, addr, cpu_llval, val, - eva ? MIPS_HFLAG_UM : ctx->mem_idx, tcg_mo & ~MO_SIGN); - - -I cannot send this patch to the QEMU mailing list as I am not able to setup git-send-email. -Feel free to apply this commit or the alternative solution. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1873898 b/results/classifier/zero-shot-user-mode/output/syscall/1873898 deleted file mode 100644 index 834052c1f..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1873898 +++ /dev/null @@ -1,44 +0,0 @@ -syscall: 0.577 -instruction: 0.322 -runtime: 0.101 - - - -arm linux-user: bkpt insn doesn't cause SIGTRAP - -QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signals. Test case: - -===begin bkpt.c=== -/* test bkpt insn */ - -#include <stdlib.h> -#include <stdio.h> - -int main(void) -{ - printf("breakpoint\n"); -#ifdef __aarch64__ - __asm__ volatile("brk 0x42\n"); -#else - __asm__ volatile("bkpt 0x42\n"); -#endif - printf("done\n"); - return 0; -} -===endit=== - -Compile with -$ arm-linux-gnueabihf-gcc -g -Wall -o bkpt-aa32 bkpt.c -$ aarch64-linux-gnu-gcc -g -Wall -o bkpt-aa64 bkpt.c - -Contrast aarch64 which delivers the SIGTRAP and arm which doesn't: - -$ qemu-aarch64 bkpt-aa64 -breakpoint -qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped -Trace/breakpoint trap (core dumped) -$ qemu-arm bkpt-aa32 -breakpoint -done - -This is because in linux-user/arm/cpu-loop.c we incorrectly treat EXCP_BKPT similarly to EXCP_SWI, which means that we actually perform a syscall (which one depends on what happens to be in r7...). This code has been like this (more or less) since commit 06c949e62a098f in 2006 which added BKPT in the first place. This is probably because at the time the same code path was used to handle both Linux syscalls and semihosting calls, and (on M profile) BKPT does imply a semihosting call. But these days we've moved handling of semihosting out to an entirely different codepath, so we can fix this bug by simply removing this handling of EXCP_BKPT and instead making it deliver a SIGTRAP like EXCP_DEBUG (as we do already on aarch64). \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1876373 b/results/classifier/zero-shot-user-mode/output/syscall/1876373 deleted file mode 100644 index b26d06d32..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1876373 +++ /dev/null @@ -1,54 +0,0 @@ -syscall: 0.558 -instruction: 0.271 -runtime: 0.171 - - - -segfault mremap 4096 - -a qemu-hosted process segfaults when the program calls mremap to shrink the size of a buffer to 4096 that was allocated with mmap. See below for a C program to reproduce this issue. I was able to compile this program for both i386 and 32-bit arm, and use qemu-i386 and qemu-arm to reproduce the segfault. If I run the i386 program natively on my x86_64 system, no segfault occurs. Also note that if I change the mremap size to something else such as 12288, no segfault occurs. I also confirmed using qemu's -singlestep debug option that the segfault occurs during the mremap syscall. - -If you save the source below to mremapbug.c, the following should reproduce the issue given you have gcc-multilib: - -gcc -m32 mremapbug.c -# works -./a.out -# segfault -qemu-i386 a.out - -If you can also compile to arm, the same thing happens when running "qemu-arm a.out". I also tried compiling natively and running "qemu-x86_64 a.out" but no segfault in that case, not sure if it's because it is 64-bits or if it was because it was my native target. - - -#define _GNU_SOURCE -#include <stdlib.h> -#include <stdio.h> -#include <sys/mman.h> - -int main(int argc, char *argv[]) -{ - const size_t initial_size = 8192; - - printf("calling mmap, size=%llu\n", (unsigned long long)initial_size); - void *mmap_ptr = mmap(NULL, initial_size, - PROT_READ | PROT_WRITE , - MAP_PRIVATE | MAP_ANONYMOUS, - -1, 0); - printf("mmap returned : %p\n", mmap_ptr); - if (mmap_ptr == MAP_FAILED) { - perror("mmap"); - exit(1); - } - - const size_t new_size = 4096; - printf("calling mremap, size=%llu\n", (unsigned long long)new_size); - void *remap_ptr = mremap(mmap_ptr, initial_size, new_size, 0); - printf("mremap returned: %p\n", remap_ptr); - if (remap_ptr != mmap_ptr) { - perror("mreamap"); - exit(1); - } - printf("Success: pointers match\n"); -} - - -This issue was found while I was pushing code that calls "mremap" to the Zig compiler repository, it's CI testing uses qemu-i386 and qemu-arm to run tests for non-native hosts. I've filed an issue in that repository as well with details on how to reproduce this issue with the Zig compiler as well: https://github.com/ziglang/zig/issues/5245 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1886097 b/results/classifier/zero-shot-user-mode/output/syscall/1886097 deleted file mode 100644 index 2fa678a19..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1886097 +++ /dev/null @@ -1,39 +0,0 @@ -syscall: 0.384 -instruction: 0.344 -runtime: 0.271 - - - -Error in user-mode calculation of ELF program's brk - -There's a discrepancy between the way QEMU user-mode and Linux calculate the initial program break for statically-linked binaries. I have a binary with the following segments: - - Program Headers: - Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align - EXIDX 0x065a14 0x00075a14 0x00075a14 0x00588 0x00588 R 0x4 - PHDR 0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R 0x1000 - LOAD 0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R 0x1000 - LOAD 0x000000 0x00010000 0x00010000 0x65fa0 0x65fa0 R E 0x10000 - LOAD 0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW 0x10000 - NOTE 0x000114 0x00010114 0x00010114 0x00044 0x00044 R 0x4 - TLS 0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R 0x4 - GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x8 - GNU_RELRO 0x066b7c 0x00086b7c 0x00086b7c 0x00484 0x00484 R 0x1 - LOAD 0x07e000 0x00089000 0x00089000 0x03ff4 0x03ff4 R E 0x1000 - LOAD 0x098000 0x00030000 0x00030000 0x01000 0x01000 RW 0x1000 - -The call to set_brk in Linux's binfmt_elf.c receives these arguments: - - set_brk(0xa3160, 0xa3160, 1) - -Whereas in QEMU, info->brk gets set to 0x88f00. When the binary is run in QEMU, it crashes on the second call to brk, whereas it runs fine on real ARM hardware. I think the trouble is that the program break is set to an address lower than the virtual address of a LOAD segment (the program headers, in this case). - -I believe that this discrepancy arises because in QEMU, info->brk is only incremented when the LOAD segment in question has PROT_WRITE. For this binary, the LOAD segment with write permissions and the highest virtual address is - - LOAD 0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW 0x10000 - -which overlaps with the TLS segment: - - TLS 0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R 0x4 - -However, the Linux kernel puts the program break after the loadable segment with the highest virtual address, regardless of flags. So I think the fix is for QEMU to do the same. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1893010 b/results/classifier/zero-shot-user-mode/output/syscall/1893010 deleted file mode 100644 index b4de29613..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1893010 +++ /dev/null @@ -1,11 +0,0 @@ -syscall: 0.679 -instruction: 0.249 -runtime: 0.072 - - - -qemu linux-user doesn't support OFD fcntl locks - -"Open file description locks (non-POSIX)", as they are described in fcntl(2) man page, aren't supported by qemu-user and attempting to use those results in EINVAL. I'm on Gentoo with latest QEMU version currently available (5.0.0-r2), and trying to emulate ppc64 and s390x on x86_64. - -Looking at linux-user/syscall.c, I'm guessing the issue is in (at least) `target_to_host_fcntl_cmd` where switch reaches the default clause as there're no cases for F_OFD_SETLK / F_OFD_SETLKW / F_OFD_GETLK. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1894361 b/results/classifier/zero-shot-user-mode/output/syscall/1894361 deleted file mode 100644 index 786bb606a..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1894361 +++ /dev/null @@ -1,11 +0,0 @@ -syscall: 0.956 -instruction: 0.031 -runtime: 0.013 - - - -linux-user: syscall.c lacks pselect6_time64 - -in commit 50efc69586388a975c1ebd90cb8cc8e4a7328bc4 legacy pselect6 definition -for riscv32 was removed in favour of pselect6_time64, but pselect6_time64 is -not available in syscall.c, thus leaving riscv32 without pselect syscall. \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1895 b/results/classifier/zero-shot-user-mode/output/syscall/1895 deleted file mode 100644 index 9ae6c55fc..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1895 +++ /dev/null @@ -1,152 +0,0 @@ -syscall: 0.432 -runtime: 0.352 -instruction: 0.215 - - - -qemu-user uses fixed stack size and ignores RLIMIT_STACK request, causing some guest programs to crash -Description of problem: -When compiling a source file, g++ segmentation faults in qemu-user riscv64. But it doesn't fail on real riscv64 boards. - -We discovered this problem while compiling nodejs-lts-hydrogen. The source file has been reduced to 5KB by cvise. -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. Install gcc inside the container: `sudo pacman -Syu gcc` -4. Run the following command in the container: `g++ -S testcase.i -w -fpreprocessed -o /dev/null` [testcase.i](/uploads/d63b1867a458a240ef0d90c760d76bc7/testcase.i) -5. g++ segmentation faults: `g++: internal compiler error: Segmentation fault signal terminated program cc1plus` -Additional information: -Initially I thought this is a g++ bug. But I can't reproduce this bug on real riscv64 hardware. - -g++ version: g++ (GCC) 13.2.1 20230801 - -testcase.i: - -```c++ -namespace std { -typedef long unsigned size_t; -inline namespace __cxx11 {} -} // namespace std -typedef char uint8_t; -namespace std { -template <typename _Default, typename, template <typename> class> -struct __detector { - using type = _Default; -}; -template <typename _Default, template <typename> class _Op> -using __detected_or = __detector<_Default, void, _Op>; -template <typename _Default, template <typename> class _Op> -using __detected_or_t = typename __detected_or<_Default, _Op>::type; -template <typename> class allocator; -namespace __cxx11 { -template <typename _CharT, typename = _CharT, typename = allocator<_CharT>> -class basic_string; -} -typedef basic_string<char> string; -} // namespace std -template <typename _Tp> class __new_allocator { -public: - typedef _Tp value_type; -}; -namespace std { -template <typename _Tp> using __allocator_base = __new_allocator<_Tp>; -template <typename _Tp> class allocator : public __allocator_base<_Tp> {}; -template <class _E> class initializer_list { - typedef size_t size_type; - typedef _E *iterator; - iterator _M_array; - size_type _M_len; -}; -struct __allocator_traits_base { - template <typename _Tp> using __pointer = typename _Tp::const_pointer; -}; -template <typename _Alloc> struct allocator_traits : __allocator_traits_base { - typedef typename _Alloc::value_type value_type; - using pointer = __detected_or_t<value_type, __pointer>; -}; -} // namespace std -namespace __gnu_cxx { -template <typename _Alloc> -struct __alloc_traits : std::allocator_traits<_Alloc> {}; -} // namespace __gnu_cxx -namespace std { -namespace __cxx11 { -template <typename _CharT, typename, typename _Alloc> class basic_string { - typedef __gnu_cxx::__alloc_traits<_Alloc> _Alloc_traits; - -public: - typedef typename _Alloc_traits::pointer pointer; - struct _Alloc_hider { - _Alloc_hider(pointer, _Alloc); - } _M_dataplus; - pointer _M_local_data(); - basic_string(_CharT *, _Alloc __a = _Alloc()) - : _M_dataplus(_M_local_data(), __a) {} - ~basic_string(); -}; -} // namespace __cxx11 -} // namespace std -namespace v8 { -class StartupData {}; -} // namespace v8 -namespace std { -template <typename _Tp> class vector { -public: - typedef _Tp value_type; - vector(initializer_list<value_type>); -}; -namespace builtins { -struct CodeCacheInfo { - string id; - vector<uint8_t> data; -}; -} // namespace builtins -struct IsolateDataSerializeInfo {}; -struct EnvSerializeInfo {}; -struct SnapshotMetadata { - enum { kDefault } type; - string node_version; - string node_arch; - string v8_cache_version_tag; -}; -struct SnapshotData { - enum { kNotOwned } data_ownership; - SnapshotMetadata metadata; - v8::StartupData v8_snapshot_blob_data; - IsolateDataSerializeInfo isolate_data_info; - EnvSerializeInfo env_info; - vector<builtins::CodeCacheInfo> code_cache; -} snapshot_data{ - SnapshotData::kNotOwned, - SnapshotMetadata::kDefault, - "", - "", - "", - {}, - {}, - {}, - {{""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, - {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}}}; -} // namespace std -``` diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1908551 b/results/classifier/zero-shot-user-mode/output/syscall/1908551 deleted file mode 100644 index 1e49082c9..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1908551 +++ /dev/null @@ -1,60 +0,0 @@ -syscall: 0.405 -instruction: 0.349 -runtime: 0.246 - - - -aarch64 SVE emulation breaks strnlen and strrchr - -arm optimized-routines have sve string functions with test code. - -the test worked up until recently: with qemu-5.2.0 i see - -$ qemu-aarch64 build/bin/test/strnlen -PASS strnlen -PASS __strnlen_aarch64 -__strnlen_aarch64_sve (0x490fa0, 32) len 32 returned 64, expected 32 -input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80" -__strnlen_aarch64_sve (0x490fa0, 32) len 33 returned 64, expected 32 -input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a" -__strnlen_aarch64_sve (0x490fa0, 33) len 33 returned 64, expected 33 -input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a" -__strnlen_aarch64_sve (0x490fa0, 32) len 34 returned 64, expected 32 -input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab" -__strnlen_aarch64_sve (0x490fa0, 33) len 34 returned 64, expected 33 -input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab" -__strnlen_aarch64_sve (0x490fa0, 34) len 34 returned 64, expected 34 -input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab" -__strnlen_aarch64_sve (0x490fa0, 32) len 35 returned 64, expected 32 -input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a\x00c" -__strnlen_aarch64_sve (0x490fa0, 33) len 35 returned 64, expected 33 -input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab\x00" -__strnlen_aarch64_sve (0x490fa0, 34) len 35 returned 64, expected 34 -input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80abc" -__strnlen_aarch64_sve (0x490fa0, 35) len 35 returned 64, expected 35 -input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80abc" -FAIL __strnlen_aarch64_sve - -however the test passes with - -qemu-aarch64 -cpu max,sve-max-vq=2 - -there should be nothing vector length specific in the code. - -i haven't debugged it further, to reproduce the issue clone -https://github.com/ARM-software/optimized-routines - -and run 'make build/bin/test/strnlen' with a config.mk like - -SUBS = string -ARCH = aarch64 -CROSS_COMPILE = aarch64-none-linux-gnu- -CC = $(CROSS_COMPILE)gcc -CFLAGS = -std=c99 -pipe -O3 -CFLAGS += -march=armv8.2-a+sve -EMULATOR = qemu-aarch64 - -(native compilation works too, and you can run 'make check' to -run all string tests) this will build a static linked executable -into build/bin/test. if you want a smaller test case edit -string/test/strnlen.c \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1909 b/results/classifier/zero-shot-user-mode/output/syscall/1909 deleted file mode 100644 index 65f85d647..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1909 +++ /dev/null @@ -1,56 +0,0 @@ -syscall: 0.358 -instruction: 0.340 -runtime: 0.302 - - - -regression: 8.0.0 segfaults on coverage counter increment -Description of problem: -With qemu 8.0.0, my test program segfaults while incrementing a gcov counter: - -``` -Breakpoint 2, 0x00000000004bc9a8 in __CortexA53843419_464004 () -(gdb) x/2i $pc -=> 0x4bc9a8 <__CortexA53843419_464004>: str x8, [x9, #2512] - 0x4bc9ac <__CortexA53843419_464004+4>: b 0x464008 <mock_hyp_params_Destroy+24> -(gdb) p $x8 -$10 = 1 -(gdb) p $x9 -$11 = 5234688 -(gdb) x/x $x9+2512 -0x4fe9d0 <__llvm_gcov_ctr.5>: 0x00000000 -(gdb) stepi - -Program received signal SIGSEGV, Segmentation fault. -0x00000000004bc9a8 in __CortexA53843419_464004 () -(gdb) x/x $x9+2512 -0x4fe9d0 <__llvm_gcov_ctr.5>: 0x00000000 -(gdb) shell llvm-objdump --syms --arch-name=aarch64 ./build/gcov/out/test_hyp-props.out | grep 4fe9d0 -00000000004fe9d0 l O .bss 0000000000000008 __llvm_gcov_ctr.5 -(gdb) shell qemu-aarch64 --version -qemu-aarch64 version 8.0.0 -Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers -(gdb) -``` - -With qemu 6.2.0, it doesn't segfault (at least not at this point, you -may ignore the segfault at the end due to a bug in the test program). -``` -$ /usr/bin/qemu-aarch64 --version -qemu-aarch64 version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.12) -Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers - -$ /usr/bin/qemu-aarch64 ./build/gcov/out/test_hyp-props.out -test_hyp-props.c:13:test__setup_str_prop:PASS -test_hyp-props.c:14:test__log_print_handler:PASS -test_hyp-props.c:15:test__setup_log_print_prop:PASS -test_hyp-props.c:16:test__vm_vcpu_abort_reset_handler:PASS -test_hyp-props.c:17:test__vm_info_alloc:PASS -test_hyp-props.c:18:test__memory_status_get:PASS -test_hyp-props.c:19:test__memory_status_get_fail:PASS -Segmentation fault (core dumped) -``` -Steps to reproduce: -1. Compile and link statically (with ld.lld) a test program, with clang, targetting aarch64 with: -target aarch64-linux-android -mcpu=cortex-a53, using --coverage option to generate gcov coverage. -2. Run it with qemu-aarch64 8.0.0 -3. Hopefully, it will segfault early for no good reason. diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1926521 b/results/classifier/zero-shot-user-mode/output/syscall/1926521 deleted file mode 100644 index 515d8a61b..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1926521 +++ /dev/null @@ -1,68 +0,0 @@ -syscall: 0.535 -instruction: 0.287 -runtime: 0.178 - - - -QEMU-user ignores MADV_DONTNEED - -There is comment int the code "This is a hint, so ignoring and returning success is ok" -https://github.com/qemu/qemu/blob/b1cffefa1b163bce9aebc3416f562c1d3886eeaa/linux-user/syscall.c#L11941 - -But it seems incorrect with the current state of Linux - -"man madvise" or https://man7.org/linux/man-pages/man2/madvise.2.html -says the following: ->> These advice values do not influence the semantics ->> of the application (except in the case of MADV_DONTNEED) - ->> After a successful MADV_DONTNEED operation, the semantics ->> of memory access in the specified region are changed: ->> subsequent accesses of pages in the range will succeed, ->> but will result in either repopulating the memory contents ->> from the up-to-date contents of the underlying mapped file ->> (for shared file mappings, shared anonymous mappings, and ->> shmem-based techniques such as System V shared memory ->> segments) or zero-fill-on-demand pages for anonymous ->> private mappings. - -Some applications use this behavior clear memory and it -would be nice to be able to run them on QEMU without -workarounds. - -Reproducer on "Debian 5.10.24 x86_64 GNU/Linux" as a host. - - -``` -#include "assert.h" -#include "stdio.h" -#include <sys/mman.h> -#include <errno.h> - -int main() { - char *P = (char *)mmap(0, 4096, PROT_READ | PROT_WRITE, - MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); - assert(P); - *P = 'A'; - while (madvise(P, 4096, MADV_DONTNEED) == -1 && errno == EAGAIN) { - } - assert(*P == 0); - - printf("OK\n"); -} - -/* -gcc /tmp/madvice.c -o /tmp/madvice - -qemu-x86_64 /tmp/madvice -madvice: /tmp/madvice.c:13: main: Assertion `*P == 0' failed. -qemu: uncaught target signal 6 (Aborted) - core dumped -Aborted - -/tmp/madvice -OK - - -*/ - -``` \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1926996 b/results/classifier/zero-shot-user-mode/output/syscall/1926996 deleted file mode 100644 index fa60b60af..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1926996 +++ /dev/null @@ -1,26 +0,0 @@ -syscall: 0.588 -runtime: 0.279 -instruction: 0.133 - - - -qemu-user clone syscall fails - -qemu-user fails to emulate clone() (https://linux.die.net/man/2/clone). The architecture doesn't seem to matter, tho I've mostly been testing aarch64. - -Attached is clone_test.c that demonstrates the problem. Running it natively looks like this: -$ bin/clone_test -The variable was 9 -clone returned 4177: 0 Success -The variable is now 42 - - -However, running it via qemu looks like: -$ qemu-aarch64-static --version -qemu-aarch64 version 5.2.0 (v5.2.0) -Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers - -$ qemu-aarch64-static ./clone_test -The variable was 9 -clone returned -1: 22 Invalid argument -The variable is now 9 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/1927530 b/results/classifier/zero-shot-user-mode/output/syscall/1927530 deleted file mode 100644 index 74c0bdb35..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/1927530 +++ /dev/null @@ -1,45 +0,0 @@ -syscall: 0.449 -instruction: 0.337 -runtime: 0.214 - - - -qemu-aarch64 MTE fails to report tag mismatch - -Hi, - -While running the GCC testsuite with qemu-6.0 as simulator, I noticed several errors in the hwasan testsuite (output pattern tests). - -I am attaching: -bitfield-2.exe -ld-linux-aarch64.so.1 -libc.so.6 -libdl.so.2 -libhwasan.so.0 -libm.so.6 -libpthread.so.0 -librt.so.1 - -The testcase can be executed via: -qemu-aarch64 -L . bitfield-2.exe - -it currently generates: -HWAddressSanitizer:DEADLYSIGNAL -==21137==ERROR: HWAddressSanitizer: SEGV on unknown address 0x0000000000f0 (pc 0x00550084e318 bp 0x005f01650d00 sp 0x005f01650d00 T21137) -==21137==The signal is caused by a UNKNOWN memory access. -==21137==Hint: address points to the zero page. - #0 0x550084e318 in GetAccessInfo /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339 - #1 0x550084e318 in HwasanOnSIGTRAP /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:401 - #2 0x550084e318 in __hwasan::HwasanOnDeadlySignal(int, void*, void*) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:426 - #3 0x5f01651fec (<unknown module>) - #4 0x550084b508 in __hwasan_load2 /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan.cpp:379 - #5 0x400768 in f /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:17 - #6 0x4007d0 in main /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:24 - #7 0x550124cee0 in __libc_start_main ../csu/libc-start.c:308 - #8 0x400688 (/home/christophe.lyon/qemu-bug-hwasan-aarch64/bitfield-2.exe+0x400688) - -HWAddressSanitizer can not provide additional info. -SUMMARY: HWAddressSanitizer: SEGV /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339 in GetAccessInfo -==21146==ABORTING - -while the testcase expects HWAddressSanitizer: tag-mismatch on address 0x..... \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/2027 b/results/classifier/zero-shot-user-mode/output/syscall/2027 deleted file mode 100644 index 7bbfd9fd6..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/2027 +++ /dev/null @@ -1,239 +0,0 @@ -syscall: 0.363 -runtime: 0.353 -instruction: 0.284 - - - -Go runtime panic with qemu-x86_64-static on aarch64 (bisected) -Description of problem: -I have run into some crashes with certain x86 Go binaries running on arm64 (Asahi Linux) using qemu-user-static. The issue is also reproducible on current master (9c74490bff6c8886a922008d0c9ce6cae70dd17e). I have bisected the issue to commit 2d708164e0475064e0e2167bd73e8570e22df1e0: - -``` -first bad commit: [2d708164e0475064e0e2167bd73e8570e22df1e0] linux-user: Define TASK_UNMAPPED_BASE in $guest/target_mman.h -``` -Steps to reproduce: -1. Build example Go program `GOARCH=amd64 go build -o crashing .` -2. Run it with `qemu-x86_64-static ./crashing` - -<details><summary>Go program to reproduce</summary> - -```go -package main - -import "crypto/x509" - -func main() { - x509.SystemCertPool() -} -``` - -</details> -Additional information: -<details><summary>Go program stacktrace</summary> - -``` -runtime: lfstack.push invalid packing: node=0xffff3c3a9780 cnt=0x1 packed=0xffff3c3a97800001 -> node=0xffffffff3c3a9780 -fatal error: lfstack.push - -runtime stack: -runtime.throw({0x52cb61?, 0x2ce5?}) - /usr/lib/golang/src/runtime/panic.go:1077 +0x5c fp=0xc000613f08 sp=0xc000613ed8 pc=0x433d5c -runtime.(*lfstack).push(0xa0000000002?, 0xffffffffffffefe8?) - /usr/lib/golang/src/runtime/lfstack.go:29 +0x125 fp=0xc000613f48 sp=0xc000613f08 pc=0x40ac25 -runtime.(*spanSetBlockAlloc).free(...) - /usr/lib/golang/src/runtime/mspanset.go:322 -runtime.(*spanSet).reset(0x64d220) - /usr/lib/golang/src/runtime/mspanset.go:264 +0x79 fp=0xc000613f78 sp=0xc000613f48 pc=0x42ef79 -runtime.finishsweep_m() - /usr/lib/golang/src/runtime/mgcsweep.go:260 +0x95 fp=0xc000613fb8 sp=0xc000613f78 pc=0x423455 -runtime.gcStart.func2() - /usr/lib/golang/src/runtime/mgc.go:687 +0xf fp=0xc000613fc8 sp=0xc000613fb8 pc=0x45bd8f -traceback: unexpected SPWRITE function runtime.systemstack -runtime.systemstack() - /usr/lib/golang/src/runtime/asm_amd64.s:509 +0x4a fp=0xc000613fd8 sp=0xc000613fc8 pc=0x46016a - -goroutine 1 [running]: -runtime.systemstack_switch() - /usr/lib/golang/src/runtime/asm_amd64.s:474 +0x8 fp=0xc0001bb9f0 sp=0xc0001bb9e0 pc=0x460108 -runtime.gcStart({0xc000600000?, 0x98370?, 0x307800?}) - /usr/lib/golang/src/runtime/mgc.go:686 +0x2e5 fp=0xc0001bba88 sp=0xc0001bb9f0 pc=0x418e05 -runtime.mallocgc(0x98370, 0x50bb80, 0x1) - /usr/lib/golang/src/runtime/malloc.go:1242 +0x76f fp=0xc0001bbaf0 sp=0xc0001bba88 pc=0x40caaf -runtime.makeslice(0xc0001840a8?, 0x26?, 0x0?) - /usr/lib/golang/src/runtime/slice.go:103 +0x49 fp=0xc0001bbb18 sp=0xc0001bbaf0 pc=0x449729 -os.ReadFile({0xc00035a0f0?, 0x52dcd6?}) - /usr/lib/golang/src/os/file.go:738 +0xe5 fp=0xc0001bbbf0 sp=0xc0001bbb18 pc=0x49ed25 -crypto/x509.loadSystemRoots() - /usr/lib/golang/src/crypto/x509/root_unix.go:70 +0x3d4 fp=0xc0001bbcd8 sp=0xc0001bbbf0 pc=0x4fdef4 -crypto/x509.initSystemRoots() - /usr/lib/golang/src/crypto/x509/root.go:30 +0x5c fp=0xc0001bbd10 sp=0xc0001bbcd8 pc=0x4fd9fc -sync.(*Once).doSlow(0x1?, 0xb30000c00018ada0?) - /usr/lib/golang/src/sync/once.go:74 +0xbf fp=0xc0001bbd70 sp=0xc0001bbd10 pc=0x467bff -sync.(*Once).Do(...) - /usr/lib/golang/src/sync/once.go:65 -crypto/x509.systemRootsPool() - /usr/lib/golang/src/crypto/x509/root.go:21 +0x45 fp=0xc0001bbdc0 sp=0xc0001bbd70 pc=0x4fd8a5 -crypto/x509.SystemCertPool() - /usr/lib/golang/src/crypto/x509/cert_pool.go:112 +0x25 fp=0xc0001bbf30 sp=0xc0001bbdc0 pc=0x4f6705 -main.main() - /home/cyrill/dev/goruntime-crash/main.go:6 +0xf fp=0xc0001bbf40 sp=0xc0001bbf30 pc=0x4ff18f -runtime.main() - /usr/lib/golang/src/runtime/proc.go:267 +0x2bb fp=0xc0001bbfe0 sp=0xc0001bbf40 pc=0x43673b -runtime.goexit() - /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc0001bbfe8 sp=0xc0001bbfe0 pc=0x461f61 - -goroutine 2 [force gc (idle)]: -runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) - /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004efa8 sp=0xc00004ef88 pc=0x436b8e -runtime.goparkunlock(...) - /usr/lib/golang/src/runtime/proc.go:404 -runtime.forcegchelper() - /usr/lib/golang/src/runtime/proc.go:322 +0xb3 fp=0xc00004efe0 sp=0xc00004efa8 pc=0x436a13 -runtime.goexit() - /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004efe8 sp=0xc00004efe0 pc=0x461f61 -created by runtime.init.6 in goroutine 1 - /usr/lib/golang/src/runtime/proc.go:310 +0x1a - -goroutine 3 [GC sweep wait]: -runtime.gopark(0x1?, 0x0?, 0x0?, 0x0?, 0x0?) - /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004f778 sp=0xc00004f758 pc=0x436b8e -runtime.goparkunlock(...) - /usr/lib/golang/src/runtime/proc.go:404 -runtime.bgsweep(0x0?) - /usr/lib/golang/src/runtime/mgcsweep.go:321 +0xdf fp=0xc00004f7c8 sp=0xc00004f778 pc=0x4235bf -runtime.gcenable.func1() - /usr/lib/golang/src/runtime/mgc.go:200 +0x25 fp=0xc00004f7e0 sp=0xc00004f7c8 pc=0x418945 -runtime.goexit() - /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004f7e8 sp=0xc00004f7e0 pc=0x461f61 -created by runtime.gcenable in goroutine 1 - /usr/lib/golang/src/runtime/mgc.go:200 +0x66 - -goroutine 4 [GC scavenge wait]: -runtime.gopark(0xc00006c000?, 0x570658?, 0x0?, 0x0?, 0x0?) - /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004ff70 sp=0xc00004ff50 pc=0x436b8e -runtime.goparkunlock(...) - /usr/lib/golang/src/runtime/proc.go:404 -runtime.(*scavengerState).park(0x625680) - /usr/lib/golang/src/runtime/mgcscavenge.go:425 +0x49 fp=0xc00004ffa0 sp=0xc00004ff70 pc=0x420e49 -runtime.bgscavenge(0x0?) - /usr/lib/golang/src/runtime/mgcscavenge.go:658 +0x59 fp=0xc00004ffc8 sp=0xc00004ffa0 pc=0x4213f9 -runtime.gcenable.func2() - /usr/lib/golang/src/runtime/mgc.go:201 +0x25 fp=0xc00004ffe0 sp=0xc00004ffc8 pc=0x4188e5 -runtime.goexit() - /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004ffe8 sp=0xc00004ffe0 pc=0x461f61 -created by runtime.gcenable in goroutine 1 - /usr/lib/golang/src/runtime/mgc.go:201 +0xa5 - -goroutine 17 [finalizer wait]: -runtime.gopark(0x400000?, 0x10004e670?, 0x0?, 0x0?, 0x654640?) - /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004e628 sp=0xc00004e608 pc=0x436b8e -runtime.runfinq() - /usr/lib/golang/src/runtime/mfinal.go:193 +0x107 fp=0xc00004e7e0 sp=0xc00004e628 pc=0x4179c7 -runtime.goexit() - /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004e7e8 sp=0xc00004e7e0 pc=0x461f61 -created by runtime.createfing in goroutine 1 - /usr/lib/golang/src/runtime/mfinal.go:163 +0x3d - -goroutine 18 [GC worker (idle)]: -runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) - /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004a750 sp=0xc00004a730 pc=0x436b8e -runtime.gcBgMarkWorker() - /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004a7e0 sp=0xc00004a750 pc=0x41a2c5 -runtime.goexit() - /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004a7e8 sp=0xc00004a7e0 pc=0x461f61 -created by runtime.gcBgMarkStartWorkers in goroutine 1 - /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c - -goroutine 19 [GC worker (idle)]: -runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) - /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004af50 sp=0xc00004af30 pc=0x436b8e -runtime.gcBgMarkWorker() - /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004afe0 sp=0xc00004af50 pc=0x41a2c5 -runtime.goexit() - /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004afe8 sp=0xc00004afe0 pc=0x461f61 -created by runtime.gcBgMarkStartWorkers in goroutine 1 - /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c - -goroutine 33 [GC worker (idle)]: -runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) - /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc000090750 sp=0xc000090730 pc=0x436b8e -runtime.gcBgMarkWorker() - /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc0000907e0 sp=0xc000090750 pc=0x41a2c5 -runtime.goexit() - /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc0000907e8 sp=0xc0000907e0 pc=0x461f61 -created by runtime.gcBgMarkStartWorkers in goroutine 1 - /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c - -goroutine 20 [GC worker (idle)]: -runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) - /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004b750 sp=0xc00004b730 pc=0x436b8e -runtime.gcBgMarkWorker() - /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004b7e0 sp=0xc00004b750 pc=0x41a2c5 -runtime.goexit() - /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004b7e8 sp=0xc00004b7e0 pc=0x461f61 -created by runtime.gcBgMarkStartWorkers in goroutine 1 - /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c - -goroutine 49 [GC worker (idle)]: -runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) - /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00008c750 sp=0xc00008c730 pc=0x436b8e -runtime.gcBgMarkWorker() - /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00008c7e0 sp=0xc00008c750 pc=0x41a2c5 -runtime.goexit() - /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00008c7e8 sp=0xc00008c7e0 pc=0x461f61 -created by runtime.gcBgMarkStartWorkers in goroutine 1 - /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c - -goroutine 21 [GC worker (idle)]: -runtime.gopark(0xa740c76b8ab?, 0x0?, 0x0?, 0x0?, 0x0?) - /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004bf50 sp=0xc00004bf30 pc=0x436b8e -runtime.gcBgMarkWorker() - /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004bfe0 sp=0xc00004bf50 pc=0x41a2c5 -runtime.goexit() - /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004bfe8 sp=0xc00004bfe0 pc=0x461f61 -created by runtime.gcBgMarkStartWorkers in goroutine 1 - /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c - -goroutine 22 [GC worker (idle)]: -runtime.gopark(0xa740cc9dc5e?, 0x0?, 0x0?, 0x0?, 0x0?) - /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004c750 sp=0xc00004c730 pc=0x436b8e -runtime.gcBgMarkWorker() - /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004c7e0 sp=0xc00004c750 pc=0x41a2c5 -runtime.goexit() - /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004c7e8 sp=0xc00004c7e0 pc=0x461f61 -created by runtime.gcBgMarkStartWorkers in goroutine 1 - /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c - -goroutine 23 [GC worker (idle)]: -runtime.gopark(0x654640?, 0x1?, 0xba?, 0x5f?, 0x0?) - /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004cf50 sp=0xc00004cf30 pc=0x436b8e -runtime.gcBgMarkWorker() - /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004cfe0 sp=0xc00004cf50 pc=0x41a2c5 -runtime.goexit() - /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004cfe8 sp=0xc00004cfe0 pc=0x461f61 -created by runtime.gcBgMarkStartWorkers in goroutine 1 - /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c - -goroutine 24 [GC worker (idle)]: -runtime.gopark(0xa740c58ec16?, 0x0?, 0x0?, 0x0?, 0x0?) - /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004d750 sp=0xc00004d730 pc=0x436b8e -runtime.gcBgMarkWorker() - /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004d7e0 sp=0xc00004d750 pc=0x41a2c5 -runtime.goexit() - /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004d7e8 sp=0xc00004d7e0 pc=0x461f61 -created by runtime.gcBgMarkStartWorkers in goroutine 1 - /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c - -goroutine 34 [GC worker (idle)]: -runtime.gopark(0x654640?, 0x1?, 0x7a?, 0xa3?, 0x0?) - /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc000090f50 sp=0xc000090f30 pc=0x436b8e -runtime.gcBgMarkWorker() - /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc000090fe0 sp=0xc000090f50 pc=0x41a2c5 -runtime.goexit() - /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc000090fe8 sp=0xc000090fe0 pc=0x461f61 -created by runtime.gcBgMarkStartWorkers in goroutine 1 - /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c -exit status 2 -``` - -</details> diff --git a/results/classifier/zero-shot-user-mode/output/syscall/2112 b/results/classifier/zero-shot-user-mode/output/syscall/2112 deleted file mode 100644 index cc0f0cd25..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/2112 +++ /dev/null @@ -1,32 +0,0 @@ -syscall: 0.419 -instruction: 0.400 -runtime: 0.182 - - - -Limited Support for MIPS clone syscall in QEMU User Mode -Description of problem: -Hello, - -I have been working with QEMU user mode to run programs based on the MIPS architecture and have encountered a limitation regarding the support for the MIPS clone syscall in the current implementation of QEMU user mode. Specifically, when invoking the clone syscall with certain flags, it results in the error "errno=22 (Invalid argument)" due to the absence of corresponding handling code in QEMU. - -Upon further investigation, I pinpointed the probable cause. QEMU user mode appears to check if the flags for the clone syscall include all the flags defined in CLONE_THREAD_FLAGS. If there is a mismatch, it returns "-TARGET_EINVAL". - -[source code](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c?ref_type=heads#L6564) - -The current CLONE_THREAD_FLAGS in QEMU are set to include: (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_THREAD | CLONE_SYSVSEM). - -However, in my MIPS program, the flags are only: (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND). - -Aligning my MIPS program to include all the flags as per CLONE_THREAD_FLAGS alters the clone syscall's behavior, deviating from the original semantics required by my MIPS program. - -I am seeking guidance on whether there is a way in QEMU user mode's MIPS syscall handling to exclusively use the flags (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND). Alternatively, I am interested in any possible approach to enable support for the MIPS architecture's clone syscall in QEMU user mode. - -Thank you for your time and assistance. -Steps to reproduce: -1. Write a C program that utilizes the clone function, specifying the flags as: CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND. - -strace output: -``` -clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND,child_stack=0x009359a8,parent_tidptr=0x00000f00,tls=0x00000003,child_tidptr=0x2b36d510) = -1 errno=22 (Invalid argument) -``` diff --git a/results/classifier/zero-shot-user-mode/output/syscall/2157 b/results/classifier/zero-shot-user-mode/output/syscall/2157 deleted file mode 100644 index 41c585dd5..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/2157 +++ /dev/null @@ -1,49 +0,0 @@ -syscall: 0.496 -instruction: 0.323 -runtime: 0.181 - - - -qemu-user fails to run 32-bit x86 binaries on hosts with a page size > 4KB -Description of problem: -`qemu-i386` refuses to run 32-bit x86 binaries on hosts with a page size > 4KB -(such as LoongArch, ppc64le, arm64 with 3 level page tables). -Steps to reproduce: -1. Compile x86 binary which makes a single exit(0) syscall: - ``` - cat > exit0.S << EOF - #include <sys/syscall.h> - .text - .global _start - _start: - movl $__NR_exit, %eax - movl $0, %ebx - int $0x80 - EOF - i586-linux-gnu-gcc -nostdlib -static -no-pie -o exit0 exit0.S - ``` - Alternatively one might compile it on a x86 host: - ``` - gcc -m32 -nostdlib -static -no-pie -o exit0 exit0.S - ``` - and transfer the `exit0` binary to ppc64/LoongArch/arm64 system - - 2. Run the `exit0` binary with `qemu-i386` - ``` - qemu-i386-static ./exit0 - ``` - - # -Additional information: -`.text` segment of (32-bit) x86 binaries is typically aligned at 4KB: -``` -Program Headers: - Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align - LOAD 0x000000 0x08048000 0x08048000 0x00100 0x00100 R 0x1000 - LOAD 0x001000 0x08049000 0x08049000 0x0000c 0x0000c R E 0x1000 - NOTE 0x0000b4 0x080480b4 0x080480b4 0x0004c 0x0004c R 0x4 - GNU_PROPERTY 0x0000d8 0x080480d8 0x080480d8 0x00028 0x00028 R 0x4 -``` - -Thus on a host with a page size being 64 KB (ppc64, arm64 with 3 level page tables) or 16 KB (LoongArch) -alignment requirements in [pbg_dynamic](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c?ref_type=heads#L3020) can not be satisfied. diff --git a/results/classifier/zero-shot-user-mode/output/syscall/2197 b/results/classifier/zero-shot-user-mode/output/syscall/2197 deleted file mode 100644 index bd56edb84..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/2197 +++ /dev/null @@ -1,64 +0,0 @@ -syscall: 0.546 -instruction: 0.309 -runtime: 0.145 - - - -qemu user space emulator handles syscall `setsockopt()` with `optlen=0` incorrectly -Description of problem: -Note that despite I have only tested with the parameters/environments above, this problem probably **affects ALL architectures on Linux**. - -When user program calls `setsockopt(fd, SOL_ALG, ALG_SET_KEY, NULL, 0)`, qemu intercepts the syscall and returns `-1` with `errno = ENOMEM`, which should have completed successfully returning zero. -Steps to reproduce: -1. compile this code to binary executable: -```c -#include <unistd.h> -#include <sys/types.h> -#include <sys/socket.h> -#include <stdio.h> -#include <stdlib.h> -#include <string.h> -#include <linux/if_alg.h> - -int create_alg(const char *alg) -{ - struct sockaddr_alg salg; - int sk; - - sk = socket(PF_ALG, SOCK_SEQPACKET | SOCK_CLOEXEC, 0); - if (sk < 0) - return -1; - - memset(&salg, 0, sizeof(salg)); - salg.salg_family = AF_ALG; - strcpy((char *) salg.salg_type, "hash"); - strcpy((char *) salg.salg_name, alg); - - if (bind(sk, (struct sockaddr *) &salg, sizeof(salg)) < 0) { - close(sk); - return -1; - } - - return sk; -} - -int main() { - int fd = create_alg("hmac(sha1)"); - char buf[10]; - int ret = setsockopt(fd, SOL_ALG, ALG_SET_KEY, NULL, 0); - if(ret < 0){ - perror("err"); - } - else{ - puts("SUCCESS!"); - } - return 0; -} -``` -2. run it in any qemu user space emulator - -On real Linux kernel, this program outputs a `SUCCESS!` while in qemu it prints `err: Cannot allocate memory`. - -The error is neither informative nor intuitive and could be misleading for user programs. -Additional information: -I already have a patch which fixes the issue and I'm willing to send it to mailing list as soon as I have done the testing. diff --git a/results/classifier/zero-shot-user-mode/output/syscall/2203 b/results/classifier/zero-shot-user-mode/output/syscall/2203 deleted file mode 100644 index e4cc44595..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/2203 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.663 -instruction: 0.169 -runtime: 0.167 - - - -RISC-V RVV fractional LMUL check is wrong diff --git a/results/classifier/zero-shot-user-mode/output/syscall/2223 b/results/classifier/zero-shot-user-mode/output/syscall/2223 deleted file mode 100644 index 54041f06d..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/2223 +++ /dev/null @@ -1,41 +0,0 @@ -syscall: 0.428 -instruction: 0.305 -runtime: 0.268 - - - -Weird behavior on RISC-V code running on QEMU -Description of problem: -I am currently facing some weird problems on a RISC-V project meant to run on the QEMU environment and thought that maybe someone here could give me a light on the subject. The goal is to run a project built on top of one of FreeRTOS' official demo ports that target the 'virt' QEMU board. I ran across a few weird behaviors where code execution would just hang at some point (QEMU would keep execution but the expected terminal output would never come up). I don't have sufficient knowledge to tell whether the issue is with the FreeRTOS port, the RISC-V gnu toolchain or QEMU itself, hence why I am raising my hand for help on all related channels. - -This [repository](https://bitbucket.org/softcps-investigacao-risc-v/freertos-riscv-bugs/src/master/) contains more details and a sample project that illustrates well one of the problems I've been getting lately (I also give more context about it [here](https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1434)). It basically goes like this: the program **executes fine** when a certain code snippet is encapsulated **within a function**, but "**crashes**" (i.e. hangs) when the same snippet is placed **directly in the main code**: - -```c -for(int i=0; i < NUMBER_OF_ITEMS; i++){ - createAndPushItem(i); - - // the function above does the exact same thing as the commented code below - // yet, the commented code does not work and will crash the program. but why?? - - // int index = priorities[i]; - // void *value = (void *) getValue(i + 1); - // LinkedListItem_t *item = createItem(index, value); - // if(item){ - // push(item, &list); - // } -} -``` - -The scope shouldn't matter at all here, since there is no local variable being used or anything like that. I have tested workarounds like removing compiling optimization (i.e. changing -Os for -O0) and using regular malloc() instead of FreeRTOS' dynamic allocation API, but all without success. Note that even though the project is build on top of the FreeRTOS demo port, no RTOS functionality is used within this code to make it as simple as it gets. -Steps to reproduce: -1. clone this [repository](https://bitbucket.org/softcps-investigacao-risc-v/freertos-riscv-bugs/src/master/) -2. follow the readme to install the toolchain -3. follow the readme to compile the program and run it -Additional information: -The expected output is supposed to be: - - - -but when one decides to use the commented snippet instead of the function, the program hangs right before sorting the linked list for the first time: - - diff --git a/results/classifier/zero-shot-user-mode/output/syscall/2262 b/results/classifier/zero-shot-user-mode/output/syscall/2262 deleted file mode 100644 index 602ef7d2b..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/2262 +++ /dev/null @@ -1,205 +0,0 @@ -syscall: 0.409 -runtime: 0.317 -instruction: 0.274 - - - -linux-user riscv32: wait4/waitpid returns wrong value -Description of problem: -Background job started by bash shell in riscv32 chroot environment under qemu linux-user emulation hangs indefinitely. - -strace shows repeated waitid flood `waitid(P_ALL, -1, {}, WNOHANG|WEXITED|WSTOPPED|WCONTINUED, NULL) = 0`. -Steps to reproduce: -1. cross compile a riscv32 environment with crossdev on gentoo or other way and chroot into it. -2. run `sleep 1000 &` -3. run `ls` -4. infinite hangs - -I have a small reproducer that I think may uncover the issue, but I am not 100% sure. I also tried running qemu with sanitizers enabled, but it produces no warning. Happy to provide a tar bar of my riscv32 rootfs if needed. - -<details><summary>simple_shell.c</summary> - -``` -#include <stdio.h> -#include <stdlib.h> -#include <unistd.h> -#include <string.h> -#include <sys/wait.h> -#include <signal.h> - -#define MAX_LINE 80 /* The maximum length command */ - -#define BACKGROUND 0 -#define FOREGROUND 1 - -struct Job { - pid_t pid; - char command[MAX_LINE]; - int state; // 0 for background, 1 for foreground -}; - -struct Job jobs[10]; // Maximum 10 background jobs -int num_jobs = 0; - -void handle_signal(int signum) { - // Do nothing for now -} - -int launch_process(char **args, int state) { - pid_t pid; - int status; - - pid = fork(); - if (pid == 0) { - // Child process - if (execvp(args[0], args) == -1) { - perror("Error in execvp"); - exit(EXIT_FAILURE); - } - } else if (pid < 0) { - // Error forking - perror("Error forking"); - } else { - // Parent process - if (state == FOREGROUND) { - // Wait for the child process to finish if it's foreground - do { - wait4(pid, &status, WUNTRACED, NULL); - } while (!WIFEXITED(status) && !WIFSIGNALED(status)); - } else { - // Background process, add to jobs list - jobs[num_jobs].pid = pid; - strcpy(jobs[num_jobs].command, args[0]); - jobs[num_jobs].state = BACKGROUND; - num_jobs++; - } - } - return 1; -} - -void bg_command(int job_number) { - // Send SIGCONT signal to a background job - if (kill(jobs[job_number].pid, SIGCONT) == -1) { - perror("kill"); - } else { - jobs[job_number].state = BACKGROUND; - } -} - -void fg_command(int job_number) { - // Bring a background job to foreground - if (kill(jobs[job_number].pid, SIGCONT) == -1) { - perror("kill"); - } else { - jobs[job_number].state = FOREGROUND; - int status; - wait4(jobs[job_number].pid, &status, WUNTRACED, NULL); - } -} - -int main(void) { - char *args[MAX_LINE/2 + 1]; /* command line arguments */ - int should_run = 1; /* flag to determine when to exit program */ - char command[MAX_LINE]; /* buffer to hold the command */ - char *token; /* token for parsing the command */ - - signal(SIGINT, handle_signal); /* Ignore SIGINT for now */ - signal(SIGTSTP, handle_signal); /* Ignore SIGTSTP for now */ - - while (should_run) { - printf("Shell> "); - fflush(stdout); - fgets(command, MAX_LINE, stdin); /* read command from stdin */ - command[strcspn(command, "\n")] = '\0'; /* remove newline character */ - - if (strcmp(command, "exit") == 0) { - should_run = 0; /* exit the shell */ - continue; - } - - if (strcmp(command, "") == 0) { - continue; /* skip empty commands */ - } - - if (strcmp(command, "cd") == 0) { - char *home = getenv("HOME"); - chdir(home); - continue; - } - - if (strcmp(command, "bg") == 0) { - // Run the most recent background job in the background - bg_command(num_jobs - 1); - continue; - } - - if (strcmp(command, "fg") == 0) { - // Bring the most recent background job to foreground - fg_command(num_jobs - 1); - continue; - } - - token = strtok(command, " "); - int i = 0; - while (token != NULL) { - args[i] = token; - token = strtok(NULL, " "); - i++; - } - args[i] = NULL; - - if (strcmp(args[i-1], "&") == 0) { - args[i-1] = NULL; - launch_process(args, BACKGROUND); - } else { - launch_process(args, FOREGROUND); - } - - pid_t tmp; - // Check if any background jobs have finished - for (int j = 0; j < num_jobs; j++) { - if ((tmp = wait4(jobs[j].pid, NULL, WNOHANG, NULL)) > 0) { - printf("[%d] Done\t%s\n", j, jobs[j].command); - // Remove job from list - for (int k = j; k < num_jobs - 1; k++) { - jobs[k] = jobs[k + 1]; - } - num_jobs--; - } - printf("wait4 ret: %d\n", tmp); - } - } - return 0; -} -``` - -</details> - -<details><summary>loop.c</summary> -int main() {while(1){}} -</details> - -1. compile simple_shell.c, statically for simplicity. `riscv32-unknown-gnu-gcc simple_shell.c --static -o shell_riscv32` -2. compile loop.c to riscv32 or x86_64 (x86_64 is simpler with same result) `gcc loop.c --static -o loop` -3. run shell with qemu user -``` -qemu-user-riscv32 ./shell_riscv32 -shell> ./loop & -[0] Done ./sleep_riscv32 -wait4 ret: 98298 -``` -where it is supposed to return 0 on riscv64 or x86 -Additional information: -More context: -This was found on the side when I was trying to track down a riscv32 infinite loop issue with linux-user emulation that has been blocking riscv32 gentoo bootstrap. I am not certain if my reproducer does reproduced that issue, but feels it is close. strace attached to the process repeats, -``` -waitid(P_ALL, -1, {}, WNOHANG|WEXITED, NULL) = 0 -rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 -rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 -rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 -rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 -rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 -rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 -waitid(P_ALL, -1, ^Cstrace: Process 237805 detached -``` -It appears to be first mentioned here <https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg05475.html>. diff --git a/results/classifier/zero-shot-user-mode/output/syscall/2448 b/results/classifier/zero-shot-user-mode/output/syscall/2448 deleted file mode 100644 index 489feec74..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/2448 +++ /dev/null @@ -1,52 +0,0 @@ -syscall: 0.345 -instruction: 0.338 -runtime: 0.318 - - - -linux-user as binfmt_misc fails to recognize AT_EXECFD if it's 0 and leaves it open as stdin -Description of problem: -When a `*-linux-user` is used as binfmt_misc, and... - -- The `O` (i.e. open-binary) flag is set -- File descriptor 0 is closed when running the executable - -FD 0 is opened to point at the executable and passed as `AT_EXECFD`, which QEMU fails to recognize and leaves open before handing control over to the executable, leading to the program to think stdin is opened for reading its own executable. - -Some use cases rely on closed stdin to behave correctly. For example, this problem causes the `tests/tail/follow-stdin.sh` and `tests/tac/tac-2-nonseekable.sh` tests in GNU coreutils to fail. In any case, having the executable itself be stdin is definitely incorrect and quite surprising behavior. -Steps to reproduce: -1. Set up qemu-riscv64 as binfmt_misc with `qemu-binfmt-conf.sh`, with the `--credential` flag (which enables open-binary) -2. Get a coreutils built for riscv64 (Let's say it can be found in `riscv64-coreutils/bin`) -3. Run it with something like `riscv64-coreutils/bin/cat <&- | xxd | head` (`xxd | head` to catch the binary output) - -The correct behavior is (You can see by running the native `cat <&-`): - -``` -cat: -: Bad file descriptor -cat: closing standard input: Bad file descriptor -``` - -Instead, the executable `cat` itself is dumped to stdout. - -Perhaps slightly more clear is `riscv64-coreutils/bin/ls -l /proc/self/fd <&-` which shows fd 0 unexpectedly pointing to the coreutils executable. -Additional information: -I'm interested in writing a patch to fix this issue but I'm uncertain how to proceed. This is what I've found so far: - -In `linux-user/main.c` if (effectively) `getauxval(AT_EXECFD)` is 0 it's treated as nonexistent. (https://gitlab.com/qemu-project/qemu/-/blob/0d9f1016d43302108d33d1268304a06cc3fb2021/linux-user/main.c#L758-765) - -```c - execfd = qemu_getauxval(AT_EXECFD); - if (execfd == 0) { - execfd = open(exec_path, O_RDONLY); - if (execfd < 0) { - printf("Error while loading %s: %s\n", exec_path, strerror(errno)); - _exit(EXIT_FAILURE); - } - } -``` - -However as we've seen `getauxval(AT_EXECFD)` can have 0 as a valid value. - -`qemu_getauxval` in `util/getauxval.c` implements several strategies to get the auxv, but doesn't currently give a way to distinguish not found and 0. FreeBSD `elf_aux_info` has `EINVAL` and `ENOENT` error codes but it's ignored here. On Linux, glibc sets `errno` to `ENOENT` to distinguish the two cases but only on glibc >= 2.19. Musl's `getauxval` has always had setting `errno` to `ENOENT`. - -Once we add a proper "`AT_EXECFD` doesn't exist" check this will no longer be a problem since (IIUC) `execfd` will eventually be closed after loading. How should we add "not found" support to `qemu_getauxval`? Is just simply relying on libc's `getauxval` setting `errno` okay? diff --git a/results/classifier/zero-shot-user-mode/output/syscall/2553 b/results/classifier/zero-shot-user-mode/output/syscall/2553 deleted file mode 100644 index 87fcb6f8b..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/2553 +++ /dev/null @@ -1,88 +0,0 @@ -syscall: 0.449 -runtime: 0.286 -instruction: 0.265 - - - -Joining IP multicast fails when emulating 64-bit Linux -Description of problem: -I have some code that joins IP multicast groups and I'd like to use QEMU to test it on big-endian and/or 32-bit platforms. But when I compile it for 64-bit big-endian platforms (e.g. PowerPC64) and run it under QEMU user-mode emulation, the setsockopt(IP_ADD_MEMBERSHIP) call fails with ENODEV. - -This appears to refer to the imr_ifindex ("interface index") field in struct ip_mreqn not being valid, which in turn appears to be because it's not being correctly marshalled from the binary under emulation, to the host's *actual* setsockopt system call. - -I *think* this may be because linux-user/syscall_defs.h (https://github.com/qemu/qemu/blob/master/linux-user/syscall_defs.h) contains the following at line 210: - -``` -struct target_ip_mreqn { - struct target_in_addr imr_multiaddr; - struct target_in_addr imr_address; - abi_long imr_ifindex; -}; -``` - -but the actual Linux ip_mreqn has imr_ifindex as an int (32-bit everywhere) not a long (64-bit on PPC64); the size of this structure is 12 on all Linux platforms. - -I opted to submit an issue instead of just patching it, in case there was some wider context I hadn't seen? -Steps to reproduce: -1. take the following C program (distilled from a larger program): - -``` -#include <sys/types.h> -#include <sys/socket.h> -#include <netinet/in.h> -#include <arpa/inet.h> -#include <stdio.h> -#include <stdlib.h> - -int main(int argc, char *argv[]) -{ - int fd = socket(AF_INET, SOCK_DGRAM, 0); - if (fd < 0) { - perror("socket"); - return 1; - } - - struct ip_mreqn mreq; - mreq.imr_multiaddr.s_addr = inet_addr("239.255.255.250"); - mreq.imr_address.s_addr = htonl(INADDR_ANY); - mreq.imr_ifindex = 1; - int size = sizeof(mreq); - printf("size=%u\n", size); - if (setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, - (char*) &mreq, sizeof(mreq)) < 0) { - perror("setsockopt"); - return 1; - } - printf("OK\n"); - return 0; -} -``` - -2. confirm it works compiled native on amd64/x86_64: - -``` -[peter@amd64 misc]$ gcc mcast.c -o mcast -[peter@amd64 misc]$ ./mcast -size=12 -OK -``` - -3. watch it *not* work emulated: - -``` -[peter@amd64 misc]$ powerpc64-linux-gnu-gcc mcast.c -o mcast.ppc64 -[peter@amd64 misc]$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu qemu-ppc64 ./mcast.ppc64 -size=12 -setsockopt: No such device -``` -Additional information: -If the target_ip_mreqn issue is real, the following code in syscall.c helped conceal it: - - if (optlen < sizeof (struct target_ip_mreq) || - optlen > sizeof (struct target_ip_mreqn)) { - return -TARGET_EINVAL; - } - -Should this instead be testing for size equal to target_ip_mreq or equal to target_ip_mreqn, not anywhere in between? in this case target_ip_mreq is 8 bytes, target_ip_mreqn is 16 bytes, but optlen is 12. The end result is that QEMU passes 4 bytes of uninitialised stack memory as imr_ifindex! - -The actual kernel behaviour appears to be: smaller than ip_mreq, EINVAL; between ip_mreq and ip_mreqn, silently treat as ip_mreq; larger or equal to ip_mreqn, silently treat as ip_mreqn. see https://github.com/torvalds/linux/blob/b31c4492884252a8360f312a0ac2049349ddf603/net/ipv4/ip_sockglue.c#L1234 diff --git a/results/classifier/zero-shot-user-mode/output/syscall/2569 b/results/classifier/zero-shot-user-mode/output/syscall/2569 deleted file mode 100644 index 7a691ae7f..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/2569 +++ /dev/null @@ -1,11 +0,0 @@ -syscall: 0.549 -instruction: 0.312 -runtime: 0.139 - - - -The alpha target doesn't support tcg plugin register tracking due to missing XML -Description of problem: -There is no register tracking because we build our register list based on XML and there was no XML for alpha because its so old. We could synthesise one to cover the register to fix this. -Steps to reproduce: -1. ./qemu-alpha -d plugin -plugin ./contrib/plugins/libexeclog.so,reg=\* ./tests/tcg/alpha-linux-user/hello-alpha diff --git a/results/classifier/zero-shot-user-mode/output/syscall/2604 b/results/classifier/zero-shot-user-mode/output/syscall/2604 deleted file mode 100644 index 056265b21..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/2604 +++ /dev/null @@ -1,50 +0,0 @@ -syscall: 0.388 -runtime: 0.308 -instruction: 0.304 - - - -qemu-user-static crash when executing generated NEON code due to failure to detect invalidation -Description of problem: -`qemu-arm-static` crashes 100% of times when attempting to run NEON code. The same executable, when run in `system` emulation mode, works without issue. - -I experience this particular issue when attempting to test GStreamer's Orc library with NEON codegen with QEMU user emulation. -Steps to reproduce: -1. Clone https://gitlab.freedesktop.org/gstreamer/orc.git -2. Build with `meson setup build -Ddefault_library=static; meson compile -C build` -3. Run `qemu-arm-static ./build/tools/orc-bugreport` -Additional information: -The crash always happens inside the same JIT code. It is not a memory access, so there is no reason for QEMU to report SIGSEGV: - -``` -Program received signal SIGSEGV, Segmentation fault. -0x409e503c in ?? () -(gdb) bt -#0 0x409e503c in ?? () -#1 0x00408bc6 in orc_executor_run (ex=0x51cfc0) at ../orc/orcexecutor.c:51 -#2 0x00489692 in orc_test_compare_output_full_for_target (program=0x4bcd90, flags=0, - target_name=0x0) at ../orc-test/orctest.c:800 -#3 0x00489004 in orc_test_compare_output_full (program=0x4bcd90, flags=0) - at ../orc-test/orctest.c:664 -#4 0x00404826 in test_opcode_src (opcode=0x4b098c <opcodes+2400>) - at ../tools/orc-bugreport.c:252 -#5 0x004045d8 in test_opcodes () at ../tools/orc-bugreport.c:188 -#6 0x004043f2 in main (argc=1, argv=0x40800704) at ../tools/orc-bugreport.c:118 -(gdb) disas 0x409e5030 -No function contains specified address. -(gdb) disas 0x409e5030, +10 -Dump of assembler code from 0x409e5030 to 0x409e503a: - 0x409e5030: vld1.8 {d4-d5}, [r3] - 0x409e5034: vst1.8 {d4-d5}, [r2] - 0x409e5038: add r2, r2, #16 -End of assembler dump. -(gdb) disas 0x409e5030, +20 -Dump of assembler code from 0x409e5030 to 0x409e5044: - 0x409e5030: vld1.8 {d4-d5}, [r3] - 0x409e5034: vst1.8 {d4-d5}, [r2] - 0x409e5038: add r2, r2, #16 -=> 0x409e503c: add r3, r3, #16 - 0x409e5040: subs r12, r12, #1 -End of assembler dump. -(gdb) -``` diff --git a/results/classifier/zero-shot-user-mode/output/syscall/2606 b/results/classifier/zero-shot-user-mode/output/syscall/2606 deleted file mode 100644 index d9d9d83a7..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/2606 +++ /dev/null @@ -1,204 +0,0 @@ -syscall: 0.401 -instruction: 0.321 -runtime: 0.278 - - - -PowerPC host code is broken on Darwin -Description of problem: -Existing code is just wrong for Darwin ppc, it won’t compile. Assembler syntax needs to be fixed and likely adjusted to correct ABI. -Steps to reproduce: -1. Run the build of qemu on Darwin ppc, see it fail. -Additional information: -This is a patch I used earlier to fix the build (together with few minor unrelated to powerpc fixes): -``` ---- common-user/host/ppc/safe-syscall.inc.S.orig 2022-04-20 03:10:27.000000000 +0800 -+++ common-user/host/ppc/safe-syscall.inc.S 2023-08-18 18:08:15.000000000 +0800 -@@ -25,17 +25,11 @@ - # else - # error "Unknown ABI" - # endif --#endif -- --#ifndef _CALL_SYSV --# error "Unsupported ABI" - #endif - -- - .global safe_syscall_base - .global safe_syscall_start - .global safe_syscall_end -- .type safe_syscall_base, @function - - .text - -@@ -47,11 +41,8 @@ - * arguments being syscall arguments (also 'long'). - */ - safe_syscall_base: -- .cfi_startproc -- stwu 1, -8(1) -- .cfi_def_cfa_offset 8 -- stw 30, 4(1) -- .cfi_offset 30, -4 -+ stwu r1, -8(r1) -+ stw r30, 4(r1) - - /* - * We enter with r3 == &signal_pending -@@ -64,14 +55,14 @@ - * and returns the result in r3 - * Shuffle everything around appropriately. - */ -- mr 30, 3 /* signal_pending */ -- mr 0, 4 /* syscall number */ -- mr 3, 5 /* syscall arguments */ -- mr 4, 6 -- mr 5, 7 -- mr 6, 8 -- mr 7, 9 -- mr 8, 10 -+ mr r30, r3 /* signal_pending */ -+ mr r0, r4 /* syscall number */ -+ mr r3, r5 /* syscall arguments */ -+ mr r4, r6 -+ mr r5, r7 -+ mr r6, r8 -+ mr r7, r9 -+ mr r8, r10 - - /* - * This next sequence of code works in conjunction with the -@@ -83,25 +74,22 @@ - */ - safe_syscall_start: - /* if signal_pending is non-zero, don't do the call */ -- lwz 12, 0(30) -- cmpwi 0, 12, 0 -+ lwz r12, 0(r30) -+ cmpwi cr0, r12, 0 - bne- 2f - sc - safe_syscall_end: - /* code path when we did execute the syscall */ -- lwz 30, 4(1) /* restore r30 */ -- addi 1, 1, 8 /* restore stack */ -- .cfi_restore 30 -- .cfi_def_cfa_offset 0 -+ lwz r30, 4(r1) /* restore r30 */ -+ addi r1, r1, 8 /* restore stack */ -+ - bnslr+ /* return on success */ - b safe_syscall_set_errno_tail - - /* code path when we didn't execute the syscall */ --2: lwz 30, 4(1) -- addi 1, 1, 8 -- addi 3, 0, QEMU_ERESTARTSYS -+2: lwz r30, 4(r1) -+ addi r1, r1, 8 -+ addi r3, 0, QEMU_ERESTARTSYS - b safe_syscall_set_errno_tail - -- .cfi_endproc -- - .size safe_syscall_base, .-safe_syscall_base - - ---- common-user/host/ppc64/safe-syscall.inc.S.orig 2022-04-20 03:10:27.000000000 +0800 -+++ common-user/host/ppc64/safe-syscall.inc.S 2022-05-31 13:23:21.000000000 +0800 -@@ -13,7 +13,6 @@ - .global safe_syscall_base - .global safe_syscall_start - .global safe_syscall_end -- .type safe_syscall_base, @function - - .text - -@@ -23,19 +22,10 @@ - * second one the system call number (as a 'long'), and all further - * arguments being syscall arguments (also 'long'). - */ --#if _CALL_ELF == 2 --safe_syscall_base: -- .cfi_startproc -- .localentry safe_syscall_base,0 --#else -- .section ".opd","aw" -+ - .align 3 - safe_syscall_base: -- .quad .L.safe_syscall_base,.TOC.@tocbase,0 -- .previous --.L.safe_syscall_base: -- .cfi_startproc --#endif -+ - /* We enter with r3 == &signal_pending - * r4 == syscall number - * r5 ... r10 == syscall arguments -@@ -46,16 +36,15 @@ - * and returns the result in r3 - * Shuffle everything around appropriately. - */ -- std 14, 16(1) /* Preserve r14 in SP+16 */ -- .cfi_offset 14, 16 -- mr 14, 3 /* signal_pending */ -- mr 0, 4 /* syscall number */ -- mr 3, 5 /* syscall arguments */ -- mr 4, 6 -- mr 5, 7 -- mr 6, 8 -- mr 7, 9 -- mr 8, 10 -+ std r14, 16(r1) /* Preserve r14 in SP+16 */ -+ mr r14, r3 /* signal_pending */ -+ mr r0, r4 /* syscall number */ -+ mr r3, r5 /* syscall arguments */ -+ mr r4, r6 -+ mr r5, r7 -+ mr r6, r8 -+ mr r7, r9 -+ mr r8, r10 - - /* This next sequence of code works in conjunction with the - * rewind_if_safe_syscall_function(). If a signal is taken -@@ -66,29 +55,20 @@ - */ - safe_syscall_start: - /* if signal_pending is non-zero, don't do the call */ -- lwz 12, 0(14) -- cmpwi 0, 12, 0 -+ ld r12, 0(r14) -+ cmpdi cr0, r12, 0 - bne- 2f - sc - safe_syscall_end: - /* code path when we did execute the syscall */ -- ld 14, 16(1) /* restore r14 */ -+ ld r14, 16(r1) /* restore r14 */ - bso- 1f - blr - - /* code path when we didn't execute the syscall */ --2: ld 14, 16(1) /* restore r14 */ -- addi 3, 0, QEMU_ERESTARTSYS -+2: ld r14, 16(r1) /* restore r14 */ -+ addi r3, 0, QEMU_ERESTARTSYS - - /* code path setting errno */ - 1: b safe_syscall_set_errno_tail - nop /* per abi, for the linker to modify */ -- -- .cfi_endproc -- --#if _CALL_ELF == 2 -- .size safe_syscall_base, .-safe_syscall_base --#else -- .size safe_syscall_base, .-.L.safe_syscall_base -- .size .L.safe_syscall_base, .-.L.safe_syscall_base --#endif -``` -(Obviously, it is not made in a portable way – that was not needed at the time.) - -Unfortunately, while build itself worked, the binary crashed on launch. So something is not quite right, maybe with ABI compliance. diff --git a/results/classifier/zero-shot-user-mode/output/syscall/2619 b/results/classifier/zero-shot-user-mode/output/syscall/2619 deleted file mode 100644 index a366c0a2a..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/2619 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.384 -runtime: 0.357 -instruction: 0.259 - - - -INTEGER_OVERFLOW in nios2.c diff --git a/results/classifier/zero-shot-user-mode/output/syscall/2730 b/results/classifier/zero-shot-user-mode/output/syscall/2730 deleted file mode 100644 index 8c45ba698..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/2730 +++ /dev/null @@ -1,16 +0,0 @@ -syscall: 0.458 -instruction: 0.392 -runtime: 0.149 - - - -riscv Calculation error！ -Steps to reproduce: -The following command will produce an error output - -```asm - lui s0, 0x80000 - lw a1, -48(s0) -``` -The value of a1 becomes 0xffffffff - diff --git a/results/classifier/zero-shot-user-mode/output/syscall/2815 b/results/classifier/zero-shot-user-mode/output/syscall/2815 deleted file mode 100644 index a6c01fb16..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/2815 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.362 -runtime: 0.357 -instruction: 0.281 - - - -clang 17 and newer -fsanitize=function causes QEMU user-mode to SEGV when calling TCG prologue diff --git a/results/classifier/zero-shot-user-mode/output/syscall/2878 b/results/classifier/zero-shot-user-mode/output/syscall/2878 deleted file mode 100644 index ed39a398c..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/2878 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.456 -instruction: 0.340 -runtime: 0.204 - - - -Support for avx512 in qemu user space emulation. diff --git a/results/classifier/zero-shot-user-mode/output/syscall/326 b/results/classifier/zero-shot-user-mode/output/syscall/326 deleted file mode 100644 index 0c7033e6e..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/326 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.579 -runtime: 0.303 -instruction: 0.118 - - - -QEMU-user ignores MADV_DONTNEED diff --git a/results/classifier/zero-shot-user-mode/output/syscall/355 b/results/classifier/zero-shot-user-mode/output/syscall/355 deleted file mode 100644 index 18fecb618..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/355 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.419 -instruction: 0.401 -runtime: 0.180 - - - -A possible divide by zero bug in get_whole_cluster diff --git a/results/classifier/zero-shot-user-mode/output/syscall/356 b/results/classifier/zero-shot-user-mode/output/syscall/356 deleted file mode 100644 index c26f1221b..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/356 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.397 -runtime: 0.315 -instruction: 0.288 - - - -qemu linux-user doesn't translate host/target data for iovec I/O diff --git a/results/classifier/zero-shot-user-mode/output/syscall/385 b/results/classifier/zero-shot-user-mode/output/syscall/385 deleted file mode 100644 index 4c297c914..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/385 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.519 -runtime: 0.313 -instruction: 0.169 - - - -ARM user regression since 87b74e8b6edd287ea2160caa0ebea725fa8f1ca1 diff --git a/results/classifier/zero-shot-user-mode/output/syscall/449 b/results/classifier/zero-shot-user-mode/output/syscall/449 deleted file mode 100644 index 3a3298db4..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/449 +++ /dev/null @@ -1,74 +0,0 @@ -syscall: 0.360 -runtime: 0.337 -instruction: 0.302 - - - -s390x linux-user assertion fires in vector asm on master -Description of problem: -Seeing a assert being fired when running this go program that executes vector instructions: - -[ecdsaexample.go](/uploads/f5162a12747f93f060cfcabaea786d92/ecdsaexample.go) - -``` -qemu-s390x-static: ../qemu/target/s390x/translate.c:1063: get_field1: Assertion `have_field1(s, o)' failed. -SIGABRT: abort -PC=0x5b660 m=0 sigcode=4294967290 - -goroutine 1 [running]: -runtime.sigpanic() - /home/jalbrecht/s390x/15/go/src/runtime/signal_unix.go:723 fp=0xc000198998 sp=0xc000198998 pc=0x5b660 -crypto/elliptic.p256SqrInternalVMSL() - /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1488 fp=0xc0001989a0 sp=0xc0001989a0 pc=0xda600 -p256SqrInternal() - /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1695 +0x18 fp=0xc0001989d8 sp=0xc0001989a0 pc=0xd95b8 -crypto/elliptic.p256SqrAsm(0xc000198bc0, 0x20, 0x20, 0xc000198ce0, 0x20, 0x20, 0x0, 0xc, 0x30, 0x4000802560, ...) - /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1849 +0x3c fp=0xc0001989e0 sp=0xc0001989d8 pc=0xdaa6c -crypto/elliptic.p256Sqr(...) - /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:81 -crypto/elliptic.p256Inverse(0xc000198bc0, 0x20, 0x20, 0xc000198ce0, 0x20, 0x20) - /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:324 +0x66 fp=0xc000198b28 sp=0xc0001989e0 pc=0xd7da6 -crypto/elliptic.initTable() - /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:436 +0x192 fp=0xc000198d00 sp=0xc000198b28 pc=0xd87d2 -crypto/elliptic.initP256Arch(...) - /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:57 -crypto/elliptic.initP256() - /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256.go:40 +0x2c0 fp=0xc000198d38 sp=0xc000198d00 pc=0xd2960 -crypto/elliptic.initAll() - /home/jalbrecht/s390x/15/go/src/crypto/elliptic/elliptic.go:397 +0x24 fp=0xc000198d40 sp=0xc000198d38 pc=0xd1ab4 -sync.(*Once).doSlow(0x2168e8, 0x122be8) - /home/jalbrecht/s390x/15/go/src/sync/once.go:66 +0x12c fp=0xc000198d98 sp=0xc000198d40 pc=0x7ee5c -sync.(*Once).Do(...) - /home/jalbrecht/s390x/15/go/src/sync/once.go:57 -crypto/elliptic.P256(...) - /home/jalbrecht/s390x/15/go/src/crypto/elliptic/elliptic.go:433 -main.main() - /home/jalbrecht/s390x/ecdsaexample.go:17 +0x7de fp=0xc000198f80 sp=0xc000198d98 pc=0xe4a2e -runtime.main() - /home/jalbrecht/s390x/15/go/src/runtime/proc.go:204 +0x214 fp=0xc000198fd8 sp=0xc000198f80 pc=0x472e4 -runtime.goexit() - /home/jalbrecht/s390x/15/go/src/runtime/asm_s390x.s:779 +0x2 fp=0xc000198fd8 sp=0xc000198fd8 pc=0x77c52 - -r0 0x0 r1 0xc000198bc0 -r2 0xc000198ce0 r3 0xc000198ce0 -r4 0x1401a0 r5 0xc000198be0 -r6 0xc000198bc0 r7 0x1c00f0 -r8 0xda600 r9 0xc0001989a8 -r10 0x217810 r11 0x0 -r12 0x4000800378 r13 0xc000000180 -r14 0xda600 r15 0xc000198998 -pc 0x5b660 link 0xda600 -exit status 2 -``` -Steps to reproduce: -On an amd64 linux host: -1. Download attached ecdsaexample.go file -2. Download and untar an s390x go distro (1.15 and 1.16 both show this issue): https://golang.org/dl/go1.15.13.linux-s390x.tar.gz -3. Build a qemu-s390x-static from current master -4. qemu-s390x-static -E PATH=/path/to/s390x/15/go/bin -L /usr/s390x-linux-gnu /path/to/s390x/15/go/bin/go run ecdsaexample.go -Additional information: -@davidhildenbrand could you have a look? I tracked it down to this series of patches: https://lore.kernel.org/qemu-devel/20210608092337.12221-1-david@redhat.com/. I tried reverting just this series from current master and then the program runs with no issues. - -This crash is seen whenever eg. certificates are checked when connecting via https so it is likely to happen in real programs. - -cc: @ruixinbao diff --git a/results/classifier/zero-shot-user-mode/output/syscall/470 b/results/classifier/zero-shot-user-mode/output/syscall/470 deleted file mode 100644 index be0145cab..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/470 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.809 -instruction: 0.136 -runtime: 0.055 - - - -qemu linux-user requires read permissions on memory passed to syscalls that should only need write access diff --git a/results/classifier/zero-shot-user-mode/output/syscall/570 b/results/classifier/zero-shot-user-mode/output/syscall/570 deleted file mode 100644 index a07dd9db0..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/570 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.423 -instruction: 0.309 -runtime: 0.268 - - - -linux-user/sh4/termbits.h:276: warning: "TIOCSER_TEMT" redefined diff --git a/results/classifier/zero-shot-user-mode/output/syscall/602 b/results/classifier/zero-shot-user-mode/output/syscall/602 deleted file mode 100644 index bbd134206..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/602 +++ /dev/null @@ -1,19 +0,0 @@ -syscall: 0.560 -instruction: 0.340 -runtime: 0.100 - - - -Failure to translate host to target errno in IP_RECVERR, IPV6_RECVERR emulation -Description of problem: -In translated IP_RECVERR (and IPV6_RECVERR) control messages, the `ee_errno` is not translated, so host errnos are observed on guests. E.g., `ECONNREFUSED` is 111 on x86_64 host, but expected to be 146 in MIPS ABI. -Steps to reproduce: -1. https://cirrus-ci.com/task/5914289870471168 -Additional information: -The bugs are on [lines 1970 and 2014 here](https://github.com/qemu/qemu/blob/211364c21e7f757ae1acf4e72b5df39c498fb88b/linux-user/syscall.c#L1970-L2014). - -The fix is something like: - -``` -__put_user(host_to_target_errno(errh->ee.ee_errno), &target_errh->ee.ee_errno); -``` diff --git a/results/classifier/zero-shot-user-mode/output/syscall/695 b/results/classifier/zero-shot-user-mode/output/syscall/695 deleted file mode 100644 index afbe64a60..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/695 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.409 -instruction: 0.346 -runtime: 0.245 - - - -MIPS: nanomips p32 ABI not supported diff --git a/results/classifier/zero-shot-user-mode/output/syscall/754635 b/results/classifier/zero-shot-user-mode/output/syscall/754635 deleted file mode 100644 index 58e1beab6..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/754635 +++ /dev/null @@ -1,61 +0,0 @@ -syscall: 0.339 -instruction: 0.335 -runtime: 0.326 - - - --d option outs wrong info about sections - -For example, after run ./qemu-i386 -d in_asm /bin/ls from 0.14.0 release, I received this qemu.log file: -$ cat /tmp/qemu.log | grep -A7 guest -Relocating guest address space from 0x08048000 to 0x8048000 -guest_base 0x0 -start end size prot -00048000-0005f000 00017000 r-x -0005f000-00069000 0000a000 rw- -00040000-00041000 00001000 --- -00041000-00041800 00000800 rw- -00041800-0005d800 0001c000 r-x -0005d800-0005f800 00002000 rw- - -But such command in 0.12.5 release outs this: -$ cat /tmp/qemu.log | grep -A7 guest -guest_base 0x0 -start end size prot -00f38000-00f39000 00001000 --- -08048000-0805f000 00017000 r-x -0805f000-08061000 00002000 rw- -40000000-40080000 00080000 rw- -40080000-40081000 00001000 --- -40081000-4009d000 0001c000 r-x - -It looks correct. -I received such differences and with qemu-microblaze. - -After comparing 0.12.5 and 0.14.0 releases I found this differences in exec.c: -in 0.12.5: -end = (i << (32 - L1_BITS)) | (j << TARGET_PAGE_BITS); - -in 0.14.0: -int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT, - -V_L1_SHIFT in my case is 10, but 32 - L1_BITS is 22 - -I make this changes: -$ diff -up qemu-0.14.0/exec.c exec.c ---- qemu-0.14.0/exec.c 2011-04-08 17:26:00.524464002 +0400 -+++ exec.c 2011-04-08 17:26:09.800464003 +0400 -@@ -2340,7 +2340,7 @@ int walk_memory_regions(void *priv, walk - data.prot = 0; - - for (i = 0; i < V_L1_SIZE; i++) { -- int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT, -+ int rc = walk_memory_regions_1(&data, (abi_ulong)i << (V_L1_SHIFT + TARGET_PAGE_BITS), - V_L1_SHIFT / L2_BITS - 1, l1_map + i); - if (rc != 0) { - return rc; - -After this outputs looks correct. - -I don't know code base good, and think what may to do more general corrections. -Host system: linux i386 \ No newline at end of file diff --git a/results/classifier/zero-shot-user-mode/output/syscall/836 b/results/classifier/zero-shot-user-mode/output/syscall/836 deleted file mode 100644 index 659538049..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/836 +++ /dev/null @@ -1,91 +0,0 @@ -syscall: 0.616 -instruction: 0.257 -runtime: 0.127 - - - -qemu-riscv32: Syscall LSEEK returns -14 (EFAULT) -Description of problem: -The lseek() system call returns -14 (EFAULT) if the file descriptor is correct, -which it should never do (According to the lseek(2) man page). - -Here is some demonstrative code: -``` -/* System Call numbers, according to https://github.com/riscv-software-src/riscv-pk/blob/master/pk/syscall.h */ -.set SYS_OPENAT, 0x38 -.set SYS_CLOSE, 0x39 -.set SYS_LSEEK, 0x3e -.set SYS_READ, 0x3f -.set SYS_WRITE, 0x40 -.set SYS_EXIT, 0x5d - -.set SEEK_CUR, 1 - -/* According to https://elixir.bootlin.com/linux/v5.16.2/C/ident/AT_FDCWD */ -.set AT_FDCWD, (-100) - -.section .text -.global _start -_start: - -/* Open the file with SYS_OPENAT, because SYS_OPEN does not exist on riscv32 for some reason. - Effectively: - s0 = open(argv[1], 0, 0644); */ -li a7, SYS_OPENAT -li a0, AT_FDCWD -lw a1, 8(sp) -li a2, 0 -li a3, 0644 -ecall - -/* Error checking. This succeeds. */ -blt a0, zero, unrelated_error - -mv s0, a0 - -/* The broken lseek() call. - Same also happens no matter the position in the file. - Effectively: - lseek(s0, 0, SEEK_CUR); */ -li a7, SYS_LSEEK -mv a0, s0 -li a1, 0 -li a2, SEEK_CUR -ecall - -/* XXX: lseek() returns -14 */ -blt a0, zero, lseek_error - -/* Close the file. */ -li a7, SYS_CLOSE -mv a0, s0 -ecall - -/* Error checking. This also succeeds. */ -blt a0, zero, unrelated_error - -/* exit(0); */ -li a7, SYS_EXIT -li a0, 0 -ecall - -/* exit(-return_value); */ -lseek_error: -li a7, SYS_EXIT -sub a0, zero, a0 -ecall - -unrelated_error: -li a7, SYS_EXIT -li a0, 128 -ecall -``` -Steps to reproduce: -1. riscv32-unknown-linux-gnu-as test.s -o test.o -2. riscv32-unknown-linux-gnu-ld test.o -3. qemu-riscv32 ./a.out test -4. echo $? # This returns 14 -Additional information: -Complete test setup: - -[test.tgz](/uploads/af68c9a5236628a9c6f31f2ce94e2f04/test.tgz) diff --git a/results/classifier/zero-shot-user-mode/output/syscall/871 b/results/classifier/zero-shot-user-mode/output/syscall/871 deleted file mode 100644 index 63c267ad3..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/871 +++ /dev/null @@ -1,20 +0,0 @@ -syscall: 0.478 -instruction: 0.394 -runtime: 0.128 - - - -qemu-x86_64 don't support unshare(CLONE_NEWUSER) -Description of problem: -Why qemu-x86_64 call unshare(CLONE_NEWUSER) fail? -``` - fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ qemu-x86_64 /bin/unshare --user /bin/bash - unshare: unshare failed: Invalid argument - fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ /bin/unshare --user /bin/bash - nobody@ubuntu:~/Desktop/afl/AFLplusplus$ -``` -Steps to reproduce: -1.execute `qemu-x86_64 /bin/unshare --user /bin/bash` ,it will fail <br/> -2.execute `/bin/unshare --user /bin/bash` ,it will ok - -How i fix that? diff --git a/results/classifier/zero-shot-user-mode/output/syscall/885 b/results/classifier/zero-shot-user-mode/output/syscall/885 deleted file mode 100644 index ade59d036..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/885 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.445 -instruction: 0.412 -runtime: 0.142 - - - -linux-user: `getsockopt` on `SO_RCVTIMEO_NEW`/`SO_SNDTIMEO_NEW` writes unexpected `int` diff --git a/results/classifier/zero-shot-user-mode/output/syscall/890 b/results/classifier/zero-shot-user-mode/output/syscall/890 deleted file mode 100644 index a717518f1..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/890 +++ /dev/null @@ -1,7 +0,0 @@ -syscall: 0.775 -runtime: 0.192 -instruction: 0.034 - - - -Misinterpretation of arm neon invalid insn diff --git a/results/classifier/zero-shot-user-mode/output/syscall/957 b/results/classifier/zero-shot-user-mode/output/syscall/957 deleted file mode 100644 index 128614572..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/957 +++ /dev/null @@ -1,77 +0,0 @@ -syscall: 0.402 -runtime: 0.306 -instruction: 0.292 - - - -qemu-m68k: python runtime failures, "The futex facility returned an unexpected error code." -Description of problem: -The python interpreter (both Python 3.9 and Python 3.10) crashes during a rebuild of Python itself (fairly reproducible but not always at the same point of the build; using MAKEOPTS=-j1 or running under high system load decreases the probability, as does using the qemu -systrace switch). The output is -``` -The futex facility returned an unexpected error code. -``` - -Digging into glibc sources, this error together with an abort occurs when the return value of a futex call is not in a short list of allowed values, see ``nptl/futex-internal.c`` and ``sysdeps/nptl/futex-internal.h``. - -Running qemu with QEMU_STRACE=1 decreases the probability of the error greatly, but after some attempts I was able to get a log. Several threads seem to write at the same time, leading to rather garbled output, but my interpretation is an error value of "Invalid argument". - - -``` -116876 get_thread_area(0x00000001) = 989882672 -116876 116876 get_thread_area(0x00000001)get_thread_area(0x00000018) = 989882672 - = 1065219744 -116876 get_thread_area(0x00000000) = 1065219744 -116876 futex(0x3f5003fa,FUTEX_PRIVATE_FLAG|FUTEX_WAIT116876 ,2,116876 NULL,0x3fffda10,get_thread_area(0xffffffff) = 1065219744 -futex(0x3f5003fa,1073732112)FUTEX_PRIVATE_FLAG|FUTEX_WAIT = ,2,NULL,-1 errno=22 (Invalid argument)116876 get_thread_area(0x00000000) - = 1065219744 -0x3fffda10,116876 get_thread_area(0x00000000)1073732112 = )1065219744 -116876 futex(0x3f7d4c34,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL, = 0)-1 errno=22 (Invalid argument) - = 0 - = 116876 get_thread_area(0x3f7d4c34)1 = -116876 get_thread_area(0x00000000) = 1065219744 -926968112 -116876 get_thread_area(0x00000016) = 926968112 -116876 get_thread_area(0x00000000) = 1065219744 -116876 get_thread_area(0x00000000) = 1065219744 -116876 get_thread_area(0x00000001)116876 = futex(116876 0x3f5003fa,get_thread_area(0x00000000)FUTEX_PRIVATE_FLAG| = 926968112 -116876 get_thread_area(0x00000000) = 926968112FUTEX_WAKE -,1,116876 NULL,0x3fffda10,get_thread_area(0x00000000) = 926968112 -1065219744 -116876 get_thread_area(0x00000001)116876 = 1065219744 -1073732112) = 116876 -1 errno=22 (Invalid argument) -futex(0x3ba005fc,FUTEX_PRIVATE_FLAG|FUTEX_CLOCK_REALTIME|FUTEX_WAIT_BITSET,0,NULL,NULL,get_thread_area(0x00000000)0 = 926968112) -116876 get_thread_area(0x00000000) = 926968112 -116876 futex(0x3f7d4c38,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,0x40007bf8,1073773560) = 0 -116876 futex(0x40053a8c,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 1 - = 0 -116876 get_thread_area(0x40053a8c) = 885025072 -116876 get_thread_area(0x00000001) = 885025072 -116876 get_thread_area(0x00b4b456) = 885025072 -116876 get_thread_area(0x00000000) = 885025072 -116876 get_thread_area(0x00000000) = 885025072 -116876 Unknown syscall 403 -116876 get_thread_area(0x00000000) = 885025072 -116876 get_thread_area(0x00003baa) = 885025072 -116876 get_thread_area(0x00003b01) = 885025072 -116876 get_thread_area(0x00003b01) = 885025072 -116876 116876 futex(get_thread_area(0x00b4b456)0x3f7d4c30,FUTEX_PRIVATE_FLAG|FUTEX_WAIT_BITSET,0,0x34bfe62c,NULL,0) = 926968112 -116876 get_thread_area(0x00000018) = 926968112 -116876 get_thread_area(0x3ed5b9c8) = 926968112 -116876 get_thread_area(0x00000000) = 926968112 -116876 get_thread_area(0x00000000) = 926968112 -116876 get_thread_area(0x00000000) = 926968112 -116876 get_thread_area(0x00000000) = 926968112 -116876 get_thread_area(0x00000000) = 926968112 -116876 futex(0x3f7d4c30,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 1 -116876 get_thread_area(0x00000000) = 926968112 -116876 get_thread_area(0x00000001) = 926968112 -116876 get_thread_area(0x0000000f) = 926968112116876 = 0 - -116876 get_thread_area(0x00000001) = 926968112 -116876 get_thread_area(0x00000001) = 926968112 -116876 get_thread_area(0x00000001)writev(2,0x3affed88,0x1) = 926968112 -The futex facility returned an unexpected error code. -116876 get_thread_area(0x3f7d4c30) = 885025072 -``` - -Advice on how to do further debuggging is appreciated. diff --git a/results/classifier/zero-shot-user-mode/output/syscall/982 b/results/classifier/zero-shot-user-mode/output/syscall/982 deleted file mode 100644 index 0dc12f114..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/982 +++ /dev/null @@ -1,43 +0,0 @@ -syscall: 0.514 -instruction: 0.353 -runtime: 0.133 - - - -linux-user: --strace incorrectly decodes writev arguments for 64-bit binaries on 32-bit machine -Description of problem: -With `--strace`, the arguments to `writev` appear to be decoded incorrectly. -The syscall still succeeds and has the expected effects. -Steps to reproduce: -``` -$ cat main.c -#include <sys/uio.h> - -int main(void) { - struct iovec iov; - iov.iov_base = "hello, world!\n"; - iov.iov_len = 14; - return writev(1, &iov, 1); -} - -$ aarch64-unknown-linux-gnu-gcc -static -o aarch64-main main.c - -$ x86_64-pc-linux-gnu-gcc -static -o x86_64-main main.c - -$ i686-pc-linux-gnu-gcc -static -o i686-main main.c - -$ ./i686-main -hello, world! - -$ strace ./i686-main |& grep writev -writev(1, [{iov_base="hello, world!\n", iov_len=14}], 1hello, world! - -$ qemu-i386 --strace ./i686-main |& grep writev -21953 writev(1,0x407ffe54,0x1) = 14 - -$ qemu-x86_64 --strace ./x86_64-main |& grep writev -22218 writev(1,(nil),0x407ffcc0) = 14 - -$ qemu-aarch64 --strace ./aarch64-main |& grep writev -22523 writev(1,(nil),0x407ffcc8) = 14 -``` diff --git a/results/classifier/zero-shot-user-mode/output/syscall/993 b/results/classifier/zero-shot-user-mode/output/syscall/993 deleted file mode 100644 index a86b686c6..000000000 --- a/results/classifier/zero-shot-user-mode/output/syscall/993 +++ /dev/null @@ -1,87 +0,0 @@ -syscall: 0.359 -instruction: 0.327 -runtime: 0.314 - - - -Invalid opcode vzeroupper -Description of problem: -Got many invalid opcode error with Fedora 36 -See fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=2076410 - -Crash stack and disassemble. -``` -Downloading separate debug info for /lib64/liblzma.so.5... -Downloading separate debug info for /home/penghuang/Sources/system-supplied DSO at 0x7fff30f55000... -[Thread debugging using libthread_db enabled] -Using host libthread_db library "/lib64/libthread_db.so.1". -Core was generated by `flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo'. -Program terminated with signal SIGILL, Illegal instruction. -#0 0x00007f89783cbe4a in sha512_block_data_order_avx2 () from /lib64/libgnutls.so.30 -[Current thread is 1 (Thread 0x7f8972ada640 (LWP 5083))] -(gdb) bt -#0 0x00007f89783cbe4a in sha512_block_data_order_avx2 () from /lib64/libgnutls.so.30 -#1 0x00007f89783bf042 in x86_sha512_update (ctx=0x7f8972ad9090, length=128, data=0x7f8972ad8f90 '\\' <repeats 128 times>, "@\255") - at sha-x86-ssse3.c:215 -#2 0x00007f897810879b in nettle_hmac_set_key (outer=<optimized out>, inner=0x7f8972ad9168, state=<optimized out>, - hash=0x7f897848b6c0 <x86_sha384>, key_length=0, key=0x7f89783ff943 "") at /usr/src/debug/nettle-3.7.3-3.fc36.x86_64/hmac.c:83 -#3 0x00007f89783bce3a in wrap_x86_hmac_fast (algo=<optimized out>, nonce=<optimized out>, nonce_size=<optimized out>, key=0x7f89783ff943, - key_size=0, text=0x7f8972ad9430, text_size=48, digest=0x55a79d80b948) at hmac-x86-ssse3.c:294 -#4 0x00007f89782d4b57 in _gnutls_mac_fast (algorithm=GNUTLS_MAC_SHA384, key=0x7f89783ff943, keylen=0, text=0x7f8972ad9430, textlen=48, - digest=0x55a79d80b948) at hash_int.c:167 -#5 0x00007f89782f524d in gnutls_hmac_fast (algorithm=GNUTLS_MAC_SHA384, key=key@entry=0x7f89783ff943, keylen=keylen@entry=0, - ptext=0x7f8972ad9430, ptext_len=ptext_len@entry=48, digest=digest@entry=0x55a79d80b948) at crypto-api.c:640 -#6 0x00007f897830d2ff in _tls13_init_secret2 (prf=0x7f897848f888 <hash_algorithms+168>, psk=<optimized out>, psk@entry=0x0, psk_size=48, - psk_size@entry=0, out=out@entry=0x55a79d80b948) at secrets.c:59 -#7 0x00007f897830d3d0 in _tls13_init_secret (session=session@entry=0x55a79d80a1c0, psk=psk@entry=0x0, psk_size=psk_size@entry=0) at secrets.c:35 -#8 0x00007f89782c66c0 in read_server_hello (datalen=<optimized out>, data=<optimized out>, session=0x55a79d80a1c0) at handshake.c:2097 -#9 _gnutls_recv_handshake (session=session@entry=0x55a79d80a1c0, type=type@entry=GNUTLS_HANDSHAKE_SERVER_HELLO, optional=optional@entry=0, - buf=buf@entry=0x0) at handshake.c:1656 -#10 0x00007f89782c8dbb in handshake_client (session=0x55a79d80a1c0) at handshake.c:3072 -#11 gnutls_handshake (session=0x55a79d80a1c0) at handshake.c:2871 -#12 0x00007f89784a694f in g_tls_connection_gnutls_handshake_thread_handshake (tls=0x55a79d80c250, timeout=<optimized out>, - cancellable=<optimized out>, error=0x7f8972ad9b10) at ../tls/gnutls/gtlsconnection-gnutls.c:968 -#13 0x00007f89784a8942 in handshake_thread (task=0x7f8968007ec0, object=object@entry=0x55a79d80c250, task_data=task_data@entry=0x55a79d766e60, - cancellable=cancellable@entry=0x55a79d748760) at ../tls/base/gtlsconnection-base.c:1564 -#14 0x00007f89784a8c02 in async_handshake_thread (task=<optimized out>, object=0x55a79d80c250, task_data=0x55a79d766e60, - cancellable=0x55a79d748760) at ../tls/base/gtlsconnection-base.c:1848 -#15 0x00007f89882dbaf3 in g_task_thread_pool_thread (thread_data=0x7f8968007ec0, pool_data=<optimized out>) at ../gio/gtask.c:1441 -#16 0x00007f8988111b72 in g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/gthreadpool.c:354 -#17 0x00007f898810f172 in g_thread_proxy (data=0x55a79d7e1360) at ../glib/gthread.c:827 -#18 0x00007f8987efdcc7 in start_thread (arg=<optimized out>) at pthread_create.c:442 -#19 0x00007f8987f82e00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 -(gdb) -(gdb) disassemble -Dump of assembler code for function sha512_block_data_order_avx2: - 0x00007f89783cbe00 <+0>: mov %rsp,%rax - 0x00007f89783cbe03 <+3>: push %rbx - 0x00007f89783cbe04 <+4>: push %rbp - 0x00007f89783cbe05 <+5>: push %r12 - 0x00007f89783cbe07 <+7>: push %r13 - 0x00007f89783cbe09 <+9>: push %r14 - 0x00007f89783cbe0b <+11>: push %r15 - 0x00007f89783cbe0d <+13>: sub $0x520,%rsp - 0x00007f89783cbe14 <+20>: shl $0x4,%rdx - 0x00007f89783cbe18 <+24>: and $0xfffffffffffff800,%rsp - 0x00007f89783cbe1f <+31>: lea (%rsi,%rdx,8),%rdx - 0x00007f89783cbe23 <+35>: add $0x480,%rsp - 0x00007f89783cbe2a <+42>: mov %rdi,0x80(%rsp) - 0x00007f89783cbe32 <+50>: mov %rsi,0x88(%rsp) - 0x00007f89783cbe3a <+58>: mov %rdx,0x90(%rsp) - 0x00007f89783cbe42 <+66>: mov %rax,0x98(%rsp) -=> 0x00007f89783cbe4a <+74>: vzeroupper - 0x00007f89783cbe4d <+77>: sub $0xffffffffffffff80,%rsi - 0x00007f89783cbe51 <+81>: mov (%rdi),%rax - 0x00007f89783cbe54 <+84>: mov %rsi,%r12 - 0x00007f89783cbe57 <+87>: mov 0x8(%rdi),%rbx - 0x00007f89783cbe5b <+91>: cmp %rdx,%rsi - 0x00007f89783cbe5e <+94>: mov 0x10(%rdi),%rcx - 0x00007f89783cbe62 <+98>: cmove %rsp,%r12 - 0x00007f89783cbe66 <+102>: mov 0x18(%rdi),%rdx - 0x00007f89783cbe6a <+106>: mov 0x20(%rdi),%r8 - 0x00007f89783cbe6e <+110>: mov 0x28(%rdi),%r9 - 0x00007f89783cbe72 <+114>: mov 0x30(%rdi),%r10 - 0x00007f89783cbe76 <+118>: mov 0x38(%rdi),%r11 - 0x00007f89783cbe7a <+122>: jmp 0x7f89783cbe80 <sha512_block_data_order_avx2+128> - 0x00007f89783cbe7c <+124>: nopl 0x0(%rax) -``` |