[libc-commits] [libc] [libc][mmap] implement mmap in terms of mmap2 for 32b targets (PR #96700)

[Nick Desaulniers via libc-commits]

================
@@ -8,56 +8,91 @@
 
 #include "src/sys/mman/mmap.h"
 
+#include "config/linux/app.h"    // app
+#include "hdr/sys_auxv_macros.h" // AT_PAGESZ
+#include "hdr/sys_mman_macros.h" // MAP_FAILED
+#include "hdr/types/off64_t.h"
+#include "hdr/types/off_t.h"
 #include "src/__support/OSUtil/syscall.h" // For internal syscall function.
+#include "src/__support/block.h"          // align_up
 #include "src/__support/common.h"
-
 #include "src/errno/libc_errno.h"
-#include <linux/param.h> // For EXEC_PAGESIZE.
+#include "src/sys/auxv/getauxval.h"
+
+#include <stddef.h>      // size_t
+#include <stdint.h>      // PTRDIFF_MAX
 #include <sys/syscall.h> // For syscall numbers.
 
 namespace LIBC_NAMESPACE {
 
+// Older 32b systems generally have a SYS_mmap2 that accepts a 32b value which
+// was a 64b value shifted down by 12; this magic constant isn't exposed via
+// UAPI headers, but its in kernel sources for mmap2 implementations.
+#ifdef SYS_mmap2
+
+// TODO: move these helpers to OSUtil?
+#ifdef LIBC_FULL_BUILD
+unsigned long get_page_size() { return app.page_size; }
+#else
+unsigned long get_page_size() {
+  // TODO: is it ok for mmap to call getauxval in overlay mode? Or is there a
+  // risk of infinite recursion?
+  return ::getauxval(AT_PAGESZ);
----------------
nickdesaulniers wrote:

Probably also isn't correct since we don't express in cmake a dependency on `getauxval` for `mmap` (which leads to inf recursion in our cmake).

https://github.com/llvm/llvm-project/pull/96700