On 24.05.2018 15:13, Valery Ushakov wrote: > On Thu, May 24, 2018 at 12:48:52 +0200, Martin Husemann wrote: > >> On Thu, May 24, 2018 at 10:33:11AM +0000, Martin Husemann wrote: >>> so there are even more bugs :-/ >> >> To sum up: both syscall(2) and __syscall(2) are very hard to use and do not >> really provide any value. >> >> Neither of them can be used to invoke mmap(2) correctly and properly >> return the value. > > You probably can by playing the horrible ABI tricks similar to what Go > does (as reported in the PR), by manually splitting 64-bit arguments > into 32-bit parts (with all the ifdefs for bitness and endianness). > I resign from attempting to improve the syscall(2) API. > But I don't think I ever saw a coherent story of why the syscall(2) > tricks are really necessary here in the sanitizers in the first place. > They are not necessary, they are just convenient. We cannot call mmap() for internal purposes as it will trigger interceptor. In the Go case, we will need to implement now each syscall manually or semimanually. With kernel compat we can have a transition period for switching. > -uwe >
Attachment:
signature.asc
Description: OpenPGP digital signature