at least that it should at least refuse a MAP_FIXED mmap that would overwrite things the JIT is using.
Unfortunately, there are a few problems in this approach of refusing to overwrite memory mappings used by the QEMU Linux user-mode emulator:
1. **Emulator detection**. We cannot reliably detect presence of QEMU in a way that is guaranteed to work in past and current *as well as* future QEMU versions. Any method of qemu-user detection would rely on the fact that the environment provided by QEMU is different in some way from a native one. As QEMU gets closer and closer to perfectly emulating the real thing, the discrepancies used to detect QEMU will become fewer and fewer, possibly rendering our detection method unusuable.
2. **Bug detection**. In the event that the bug is eventually fixed in a future QEMU version, it's not certain that there will be a way to detect this. For example, the SIGSEGV signal due to vDSO unmapping is not currently forwarded to the guest, so there's no way for the preloader to detect presence of the bug, or absence thereof.
I don't know if there is a significant portion of Wine user base that uses QEMU to run x86 apps on other architectures. If this is the case, though, we could implement a (possibly hacky) way to warn the user of such occasion, in a separate patch set.
But changing from a strategy where wine wants to clobber it to one where wine just wants to move it might give qemu-user some better options. I haven't put enough thought into it yet to have a specific idea, just that this PR seemed like it would be helpful.
Now, here's the good news: with this patch set, you can elect to avoid unmapping or remapping the vDSO *entirely*. Simply specify the `WINEPRELOADREMAPVDSO=never` environment variable.