Increase the signal stack size on AArch64

[yuyichao]

The default size is too small for libunwind and causes a stack overflow. (The symptom is error/segfault on exit due to random corruption of heap memory, a lot of the time a segfault in __cxa_finalize).

Also add a guard page to the signal stack making it easier to detect such problems in the future. (Segfault instead of weird corruption...)

P.S. The default size for linux x86_64 is also quite small (8k), I'm a little surprised that our signal handler works fine in such a shallow stack....

c.c. @vtjnash

[yuyichao]

The new value (64k) is simply copied from JL_USE_INTEL_JITEVENTS and it seems to be big enough. I'm wondering if we should just make this the default everywhere....

[ViralBShah]

With all the work on Aarch64, is there a way to at least test the build regularly? Perhaps we should set up cross compilation on travis? Through qemu we can at least have a couple of simple tests run.

Is anyone aware of a service like @scaleway that will provide Aarch64 machines? Scaleway only seems to have 32-bit, although I suspect they should add 64-bit at some point naturally.

[yuyichao]

Also use a separate function to unblock the signal in order to save some stack space (sigset_t is quite large (128bytes)). Note that this alone doesn't really solve the stack overflow on AArch64 though.

@ViralBShah Maybe https://www.datacentred.co.uk/ ? Not quite the same and more expensive than scaleway if you want to use it all the time (even for the cheapest option). Also couldn't find what hardware they are using.

With this patch merged (which somehow mainly causes issue with parallel testing....) the compilation takes ~20min and the whole test suite (with a few tests disabled) takes ~30min to run on my board so it's not too bad for me to run it every night right now.

[tkelman]

broken on mac?

In file included from /Users/osx/buildbot/slave/build_osx10_9-x64/build/src/signal-handling.c:46:
./signals-unix.c:297:58: error: use of undeclared identifier 'MAP_ANONYMOUS'
                           MAP_NORESERVE | MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);

[vtjnash]

mac uses the other name (MAP_ANON), although it looks like 10.11 may have added MAP_ANONYMOUS as a synonym