On 8/14/24 3:29 AM, Jeff Xu wrote:
Hi Muhammad
On Fri, Aug 9, 2024 at 1:25 AM Muhammad Usama Anjum usama.anjum@collabora.com wrote:
The __NR_mmap isn't found on armhf. The mmap() is commonly available system call and its wrapper is presnet on all architectures. So it should be used directly. It solves problem for armhf and doesn't create problem for architectures as well. Remove sys_mmap() functions as they aren't doing anything else other than calling mmap(). There is no need to set errno = 0 manually as glibc always resets it.
The mseal_test should't have dependency on libc, and mmap() is implemented by glibc, right ?
I just fixed a bug to switch mremap() to sys_mremap to address an issue that different glibc version's behavior is slightly different for mremap().
What is the reason that __NR_mmap not available in armhf ? (maybe it is another name ?) there must be a way to call syscall directly on armhf, can we use that instead ?
It seems __NR_mmap syscall is deprecated for arm. Found this comment in arch/arm/include/asm/unistd.h: /* * The following syscalls are obsolete and no longer available for EABI: * __NR_time * __NR_umount * __NR_stime * __NR_alarm * __NR_utime * __NR_getrlimit * __NR_select * __NR_readdir * __NR_mmap * __NR_socketcall * __NR_syscall * __NR_ipc */
The glibc mmap() calls mmap2() these days by adjusting the parameters internally. From man mmap: C library/kernel differences: This page describes the interface provided by the glibc mmap() wrapper function. Originally, this function invoked a system call of the same name. Since Linux 2.4, that system call has been superseded by mmap2(2), and nowadays the glibc mmap() wrapper function invokes mmap2(2) with a suitably adjusted value for offset.
I'm not sure if behaviour of glibc mmap() and syscall mmap2() would be same, but we should use glibc at most places which accounts for different architectures correctly. Maybe the differences were only present in case of mremap().