On 5/31/20 03:59, Andy Lutomirski wrote: > > I’m suggesting that the kernel learn how to help you, maybe like this: > > prctl(PR_SET_SYSCALL_THUNK, target, address_of_unredirected_syscall, 0, 0, 0, 0); > > This would be inherited on clone/fork and cleared on execve. > If we are talking about explicit specification of syscall addresses to be trapped by Wine, the problem here is that we don't have any way of knowing the exact addresses of syscalls to be redirected. We would need some way to find those syscalls in the highly obfuscated dynamically generated code, the whole purpose of which is to prevent disassembling, debugging and finding things like that in it. What we do know is that if a syscall is executed from any memory which Wine allocates for Windows application then it should be treated as Windows syscall and routed to the Wine's dispatch function. Those code areas can be dynamically allocated and deallocated. If we are talking about explicit specification of syscall addresses not to be trapped, it might be technically possible but at the moment looks so messy so might be considered not feasible. Wine has a great number of external dependencies. Most of them depends on some other libraries in turn. Loading of those libraries goes out of Wine control. Linux libraries are allowed to issue direct syscalls from their code. I am not sure we can depend on them not doing it and always calling the same glibc wrapper.
