Hmm, the do_fork() code is a bit inconsistent there. Generally in linux-user/ functions should either: (1) return -1 with host errno set to a host errno; the caller then must use get_errno() to convert to the negative-target-errno that we need to return from do_syscall() (2) return negative-target-errno; the caller then need do nothing
In this case do_fork() is supposed to be using approach 2, but some code paths are using approach 1 and the callers are all using get_errno(). This hybrid approach works OK as long as none of the negative-target- errno values returned are -1 (which happens to be TARGET_EPERM for all architectures, and which we only use once in linux-user, in the sigaltstack handling). In an ideal world we'd clean this up to consistently use approach 2, but I don't think the code as it stands is actually buggy. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1727737 Title: qemu-arm stalls on a GCC sanitizer test since qemu-2.7 Status in QEMU: Incomplete Bug description: Hi, I have noticed that several GCC/sanitizer tests fail with timeout when executed under QEMU. After a bit of investigation, I have noticed that this worked with qemu-2.7, and started failing with qemu-2.8, and still fails with qemu-2.10.1 I'm attaching a tarball containing: alloca_instruments_all_paddings.exe : the testcase, and the needed libs: lib/librt.so.1 lib/libdl.so.2 lib/ld-linux-armhf.so.3 lib/libasan.so.5 lib/libc.so.6 lib/libgcc_s.so.1 lib/libpthread.so.0 lib/libm.so.6 To reproduce the problem: $ qemu-arm -cpu any -R 0 -L $PWD $PWD/alloca_instruments_all_paddings.exe returns in less than a second with qemu-2.7, and never with qemu-2.8 Using -d in_asm suggests that the program "almost" completes and qemu seems to stall on: 0x40b6eb44: e08f4004 add r4, pc, r4 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1727737/+subscriptions