Proposed patch at https://patchwork.ozlabs.org/patch/1022092/
NB: my guess is that your pwrite on 32-bit arm test is behaving like that because it isn't going via the pwrite64 syscall, or possibly because glibc there is dealing with the NULL special case early. Use QEMU's -strace argument (or strace on real h/w) to see what libc is actually turning that pwrite() function call into at the syscall level. ** Changed in: qemu Status: New => In Progress -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1810433 Title: aarch64-linux-user master: inconsistent pwrite behaviour Status in QEMU: In Progress Bug description: Hello, I am running aarch64-linux-user from master, commit 20d6c7312f1b812bb9c750f4087f69ac8485cc90 And I've found the following inconsistent emulation of pwrite() call when buf==NULL and len=0. Minimal reproducible sample is the following: #define _GNU_SOURCE #include <stdlib.h> #include <stdio.h> #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <string.h> /* System | Result -------------------------+---------------- Native x86_64 4.12.14 | pwrite ret = 0 Native aarch64 4.4.159 | pwrite ret = 0 qemu-aarch64 at x86_64 | pwrite ret = -1 ( 20d6c7312f1b8 ) | */ int main(int argc, char** argv) { int fd = open("test.dat", O_CREAT | O_RDWR, 0644); if (fd < 0) { perror("open"); return 1; } int ret = fallocate(fd, 0, 0, 1000); if (ret < 0) { perror("fallocate"); return 1; } ssize_t ret_pwrite = pwrite(fd, NULL, 0, 0); printf("pwrite ret = %ld\n", ret_pwrite); close(fd); return 0; } Please note, that the same binary executable prints different output at native aarch64 platform and under aarch64-linux-user To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1810433/+subscriptions