Though the application should test mprotect()'s success before assuming it
succeeded, let's be extra sure and kill it. (By Avi's request)

mprotect() is normally used on mmap()ed memory. It usually makes little
sense to for applications to mprotect() memory they got from malloc()ed,
for several reasons including the fact that free()ing this memory without
mprotect()ing it back to normal back is a recipe for big trouble (while
with munmap(), there is no need to mprotect() back). We therefore don't
expect Java to use mprotect() on malloc()ed memory.

For us, mprotect() on malloc() memory is particularly undesirable, because
malloc() returns addresses in the linear map, and mprotect()ing that can
"downgrade" this map (change huge pages into small pages) which will never
be fixed later, not even when if mprotect()ing the memory back to normal.
So for now, I'll just forbid mprotect() on addresses in the linear map.

In the existing code, #PF was handled correctly (generating a SIGSEGV),
but on most other x86 hardware exceptions, we just abort()ed the kernel.

The #DE (divide error) exception should, like #PF, generate a signal
(the inappropriately-named SIGFPE), and this patch does this. Strangely,
the SPECjvm2008 benchmark depends on this behavior (I didn't check its
source code to figure out why).

To make it easier to generate other signals in the future, I abstracted
the existing function handle_segmentation_fault() into a more general
generate_signal() which is used in both #PF and #DE handling.

Added the missing TLB flush to the mmap()/munmap()/mprotect() operations.
Note that currently I only do this on the processor running mmap(), which
is incorrect (I put in a TODO), but is good enough for Java's use case
(which is to do these things on startup).

Also added more tests, and fixed a bug on mmap(PROT_NONE) (mprotect(PROT_NONE)
used to work, but mmap(PROT_NONE) didn't).

Java uses mprotect(..., PROT_NONE) for guard pages (e.g., to catch stack
overflow). This patch implements it by removing the present bit on these
pages' mappings, which does not mean the pages have been unmapped (their
memory is kept intact, and running mprotect again can make them readable
again.

some of the small pages were allocated twice and one was leaked).
Also, prepare mmap/munmap for supporting PROT_NONE in mprotect: instead
of relying on present-bit to say which pages are free, rely on the
information in vma_list, and double-check this (with assertions added)
against zeroing of the PTE when a page is freed.
I'll add support for mprotect(PROT_NONE) in a following patch.

is not currently supported, and PROT_READ is used instead (i.e., instead of
inaccessible memory, one gets read-only memory). Inaccessible memory
complicates the code because it means using the non-present bit on
still-allocated pages, and then unpopulate() can't use the present bit to
decide which pages are allocated and need to be freed.
To fix this, I'll need to:
1. unpopulate_page() and unpopulate_huge_page() should assume it is only
ever called on allocated pages (evacute() actually ensures that!), and not
return on non-present ptes.
2. change_perm() should use the read_perm to set the present bit.
3. protect() shouldn't rely on present bit to know when to return 0 or 1,
   rather it must be wrapped in something like evacute() which knows to
   find mapped ranges, and only call protect() for actually mapped ranges.
I'll try this tomorrow.

The JVM calls these when running Volanomark.

Also improve debugging of unhandled getrlimit cases.

We don't use syscall except for gettid which is called directly by java.
If we are going to implement these they should be direct API functions.

This only implements SIGSEGv delivery to the thread that triggered it
(i.e., it must be unblocked).

We're already in namespace elf.

Don't go though the stdio/vfs layer.

Mutex is much better now and should be sufficient.

To avoid overflowing sem_t, we have to use a pointer instead of embedding
the mutex.

printfs uses ~80K stack; this easily overflows and causes corruption.

We can't simply increase the stack size since this huge stack footprint
means that stack guard pages won't work.

Reduce the footprint for now, later switch to per-cpu allocation or some
other scheme.

While easy to use, auto-starting threads generates problems when more
complicated initialization takes place.

Rather than making auto-start optional (as Guy suggested), remove it
completely, to keep the API simple.

Use thread::start() to start a thread.  Unstarted threads ignore wakeups
until started.

fixes loading unit tests with "main" as the entry point.

The glibc headers define those as macros, need to undefine before declaring
as functions.

Found with mode=release.

A mutex will also call wait_until, which doesn't tolerate nesting.

Fail the build if not.

Needed by bench.jar suddenly.

Running tests is now done by editing the command line in build.mak

This makes it easy to configure a thread with various parameters.  The first
is the existing stack_info parameter.