On Tue, 16 Jun 2020 at 17:08, Alex Bennée <alex.ben...@linaro.org> wrote: > Apart from "a more perfect emulation" is there a particular use case > served by the extra functionality? AIUI up until this point we've > basically supported glibc's use of clone() which has generally been > enough. I'm assuming you've come across stuff that needs this more fine > grained support?
There are definitely cases we don't handle that cause problems; notably https://bugs.launchpad.net/qemu/+bug/1673976 reports that newer glibc implement posix_spawn() using CLONE_VM|CLONE_VFORK which we don't handle correctly (though it is now just "we don't report failures correctly" rather than "guest asserts"). The problem has always been that glibc implicitly assumes it knows what the process's threads are like, ie that it is the only thing doing any clone()s. (The comment in syscall.c mentions it "breaking mutexes" though I forget what I had in mind when I wrote that comment.) I haven't looked at these patches, but the risk of being clever is that we end up implicitly depending on details of glibc's internal implementation in a potentially fragile way. I forget whether QEMU can build against musl libc, but if we do then that might be an interesting test of whether we have accidental dependencies on the libc internals. thanks -- PMM
