It should be a patch pretty similar to commit 58cfa6c2e6eb51b23cc98f8, but in the pwrite64 codepath. Slightly complicated by needing to deal with the offset possibly being in two input arguments, but basically the same thing.
-- 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: New 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