Boostraped rustc fails in thread initialization on NetBSD

[MartinHusemann]

Trying to build rustc on NetBSD fails, after creating a local rustc, it fails when invoked for the first time:

thread 'main' panicked at 'unable to reset the guard page',libstd/sys/unix/thread.rs:361:21

I have no idea why that mprotect() call fails, it would be helpfull if the panic would mention the address and the return value.

Unfortunately I can't just invoke the same binary manually as it needs some secret/hidden environment setup to work.

[MartinHusemann]

I could at least trace it, so the failing call is:

8094 1 rustc CALL mprotect(0x7f7fff006000,0x1000,3)
8094 1 rustc RET mprotect -1 errno 13 Permission denied

which looks like a properly aligned stack address, 1 page, and RW mapping request.

[MartinHusemann]

... and the corresponding mmap worked and returned the same address, so all looks fine:

8094 1 rustc CALL mmap(0x7f7fff006000,0x1000,PROT_NONE,0x1012<PRIVATE,FIXED,,,>,0xffffffff,0,0)
8094 1 rustc RET mmap 140187715788800/0x7f7fff006000

I'm puzzled

[MartinHusemann]

Found it:
with PAX MPROTECT enabled (which we do by default), it is not allowed to mprotect() to something less restrictive than the initial mmap() did.

Fix is simple: change the initial mmap() to MAP_READ|MAP_WRITE and do an mprotect(0) right away. This creates a mapping that allows later mprotect(MAP_READ|MAP_WRITE).