[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:

> you could stash the page size at libc startup

We do, which is what's done for the `LIBC_FULL_BUILD` check.  The issue becomes that llvm-libc supports building with literally just `mmap` as the only symbol in the resulting libc.a, so we also additionally need to support "getting the page size" without the ability to reach into the system libc's private book keeping.

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