Re: Fix pthread_create on some devices failing to initialize guard area

[Rich Felker <dalias@libc.org>]

On Wed, Feb 01, 2017 at 10:21:40AM -0800, Eric Hassold wrote:
> 
> On 2/1/17 1:52 AM, Szabolcs Nagy wrote:
> >* Eric Hassold <hassold@gmail.com> [2017-01-31 14:44:52 -0800]:
> >>On 1/31/17 1:18 PM, Eric Hassold wrote:
> >>>Long story short, no odd behavior of the mmap in kernel, but Musl not
> >>>supporting correctly non-4k page systems, impacting pthread_create but
> >>>probably also malloc and mprotect. Given non-4k page systems are getting
> >>>more and more common (on arm and arm64 architectures at least), this
> >>>might be an important issue to fix. Should I start new "support for
> >>>non-4k page systems" discussion here ?
> >>>
> >>>Eric
> >>>
> >>Just removing the "#define PAGE_SIZE 4096" from arch/arm/bits/limits.h makes
> >>PAGE_SIZE to be defined by internal/libc.h as libc.page_size which is
> >>initialized correctly at runtime, making the correct page size be used all
> >>around musl. Since a page size of 4k is no more a valid assumption on
> >>arm-linux target, is removing this compile time define a right fix?
> >it is ok to remove PAGE_SIZE but i thought arm elf
> >binaries would depend on the 4k page size.. making it
> >less useful to support other page sizes, but if 32k
> >works in practice then i think musl should support it.
> 
> Binutils was updated couple years ago to support up to 64KB page
> size and default text alignment to 64kB boundary for armel and match
> changes in kernel:
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=7572ca8989ead4c3425a1500bc241eaaeffa2c89
> 
> So yes, executables built with older toolchains can't be deployed as
> is on such 32kB pagesize systems, but no issue with with executables
> built with recent  (binutils 2.27 && gcc 5.4) toolchain we are
> using.

OK, so this was a generalization of the ABI that we weren't aware
about. Bleh. But if the rest of the world is no longer considering 4k
page size part of the ABI, we should update musl to reflect this.

> Any further action on my side to proceed? I guess no much value in
> submitting a patch though mail here for such one liner change...

No further action needed. Thanks for being patient with my hesitance
to accept the initial patch and for working through this to find the
real problem.

Rich