Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Richard Braun]

On Fri, Apr 11, 2014 at 11:51:44PM +0200, Samuel Thibault wrote:
> It's indeed:
> 
> /* This function is called at program startup time to make sure that
>    mmap, munmap, and getpagesize are resolved if linking dynamically.
>    We want to resolve them while we have enough stack for them, rather
>    than calling into the dynamic linker while low on stack space.  */
> 
> void
> __morestack_load_mmap (void)
> {
>   /* Call with bogus values to run faster.  We don't care if the call
>      fails.  Pass __MORESTACK_CURRENT_SEGMENT to make sure that any
>      TLS accessor function is resolved.  */
>   mmap (__morestack_current_segment, 0, PROT_READ, MAP_ANONYMOUS, -1, 0);
>   mprotect (NULL, 0, 0);
>   munmap (0, getpagesize ());
> }
> 
> Yes...
> 
> So, do we really want to let munmap poke a hole at address 0 and thus
> let further vm_map() return address 0?

We probably don't. AIUI, the first page is always mapped, and always
with PROT_NONE to make sure null pointers are catched. Considering other
systems have predefined ranges depending on the mapping type, instead
of blindly starting at the beginning of the map like vm_map() does, it's
perfectly valid to unmap the first page, which is normally the right
way to catch null pointers. So, since we do want to catch null pointers,
we do want to keep that first page, but only the first page. Or rather,
a range large enough to catch accesses through null pointers, e.g. it
could even be 64 or 128 KiB. We could alter glibc so that the first
mapping has this special size, and have munmap override its given range
to skip that area.

-- 
Richard Braun