On 9/14/24 3:33 AM, Jeff Xu wrote: > On Mon, Aug 19, 2024 at 3:05 AM Muhammad Usama Anjum > <Usama.Anjum@xxxxxxxxxxxxx> wrote: >> >> 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@xxxxxxxxxxxxx> wrote: >>>> >>>> The __NR_mmap isn't found on armhf. The mmap() is commonly available > > What is armhf ? > is that arm64 ? I was able to build arm64 correctly. It is arm architecture. Use following toolchain with it: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- Please test your patches on it. > > -Jeff > >>>> 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(). >> >> -- >> BR, >> Muhammad Usama Anjum >> -- BR, Muhammad Usama Anjum
