> Linux has a EXEC_PAGESIZE macro, exposed in asm/param.h, typically > accessed via linux/param.h, then sys/param.h. This is now taken for > granted in glibc:
It's not clear that EXEC_PAGESIZE means anything in particular in Linux. It's not used anywhere in the kernel itself. It also has ELF_EXEC_PAGESIZE defined in <asm/elf.h>--and not exposed in user-visbile headers at all. It's ELF_EXEC_PAGESIZE that controls the value passed via AT_PAGESZ. > + ._dl_pagesize = EXEC_PAGESIZE, > +size_t _dl_pagesize = EXEC_PAGESIZE; I can't really see the reasons for these static initializers at all. Perhaps there is some path of early initialization before the dynamic setup has happened? It seems best if we can just be sure that nothing looks at GLRO(dl_pagesize) before the initialization gets done. > And why do we need a __vm_page_size plus vm_page_size weak alias, and > don't only use GLRO(dl_pagesize)? The vm_page_size name was traditionally available in Mach code, so we always provided it. __vm_page_size was the internal form for the usual name space reasons, but it was always exported in the DSO too (and not in GLIBC_PRIVATE, which came later), so we have to keep it so. Since the rest of libc now uses GLRO(dl_pagesize), there is no special reason that the libc-internal uses of __vm_page_size couldn't use that too. But there's no particular reason to change them now. > Then, additionally in libio/libioP.h, I found this bit of code: That's just silly. If anything it should test MAP_ANON and anothing else. Thanks, Roland
