Comment 4 for bug 1163034

Actually, assuming the guest ARM glibc doesn't have the printf() bug the code is testing for, we shouldn't take the SIGSEGV anyway, so that's a red herring. The actual problem here is the setrlimit().

The conftest.c test case works by using rlimit to limit the address space. This generally doesn't work on QEMU because we just pass the rlimit syscall through to the host, and end up limiting not just the guest program but also QEMU itself. QEMU doesn't expect its own allocations to fail and typically dies in confusing ways as a result. (Sometimes we do check allocations and call abort(), which then under linux-user doesn't work properly because we treat the resulting signal as if it were caused by the guest and not by QEMU's own code; IIRC we end up hanging in that situation.) In this particular instance we segfault in tb_alloc_page() because it doesn't check that page_find_alloc() didn't return NULL.

[Confirmed by running qemu-arm under gdb.]

Fixing this would require us to implement the address space rlimits entirely in QEMU by keeping track of how much memory we've handed the guest so we can fail mmap() etc. That is probably relatively speaking fairly tractable, though it's not a five minute job.

Unsupported syscall bugs are usually easy fixes, incidentally (though occasionally they are nasty); also often QEMU will warn but things will continue OK because the guest libc/userspace supports fallback code for when a native kernel hasn't yet implemented the new syscall.