Instead, just don't do anything on x86/amd64, and on !x86, use either A)
__clear_cache from libgcc, or B) sys_icache_invalidate for OS X (and
iOS.)

Signed-off-by: Austin Seipp <austin@well-typed.com>

Authored-by: Authored-by: Luke Iannini <lukexi@me.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Arash Rouhani <rarash@student.chalmers.se>
Reviewed-by: Austin Seipp <austin@well-typed.com>

This adds code for jumping to given addresses for ARM, written by Ben
Gamari.

However, when allocating new infotables for bytecode (which is where
this jump code occurs), we need to be sure to flush the cache on the
execute pointer returned from allocateExec() - on systems like ARM, the
processor won't reliably read back code or automatically cache flush,
where x86 will.

So we add a new flushExec primitive to call out to GCC's
__builtin___clear_cache primitive, which will properly generate the
correct code (nothing on x86, and a call to libgcc's __clear_cache on
ARM) and make sure we use it after writing the code out.

Authored-by: Ben Gamari <bgamari.foss@gmail.com>
Authored-by: Austin Seipp <austin@well-typed.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

This creates a new C API:

   initLinker_ (int retain_cafs)

The old initLinker() was left as-is for backwards compatibility.  See
documentation in Linker.h.

Retained CAFs must keep an object file alive.

This resurrects some old code and makes it work again.  The idea is
that we want to get an error message if we ever enter a CAF that has
been GC'd, rather than following its indirection which will likely
cause a segfault.  Without this patch, these bugs are hard to track
down in gdb, because the IND_STATIC code overwrites R1 (the pointer to
the CAF) with its indirectee before jumping into bad memory, so we've
lost the address of the CAF that got GC'd.

Some associated refactoring while I was here.

This is the RTS part of a patch to base's topHandler to handle exiting
by a signal.

The intended behaviour is that on Unix, throwing ExitFailure (-sig)
results in the process terminating with that signal. Previously
shutdownHaskellAndSignal was only used for exiting with SIGINT due to
the UserInterrupt exception.

Improve shutdownHaskellAndSignal to do the signal part more carefully.
In particular, it (should) now reliably terminates the process one way
or another. Previusly if the signal was blocked, ignored or handled then
shutdownHaskellAndSignal would actually return!

Also, the topHandler code has two paths a careful shutdown and a "fast
exit" where it does not give finalisers a chance to run. We want to
support that mode also when we want to exit by signal. So rather than
the base code directly calling stg_exit as it did before, we have a
fastExit bool paramater for both shutdownHaskellAnd{Exit,Signal}.

It wasn't actually broken, but it wasn't obviously right either.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

This is a fun one.

In the RTS, `cas` expects a pointer to StgWord which will translate to
unsigned long (8 bytes under LP64.) But we had previously declared
token_locked as *StgBool* - which evaluates to 'int' (4 bytes under
LP64.) That means we fail to provide enough storage for the cas
primitive, causing it to corrupt memory on a 64bit platform.

Hilariously, this somehow did not affect little-endian platforms (ARM,
x86, etc) before. That's because to clear our lock token, we would say:

    token_locked = 0;

But because token_locked is 32bits technically, this only writes to
half of the 64bit quantity. On a Big-Endian machine, this won't do
anything. That is, token_locked starts as 0:

 / token_locked
 |
 v
 0x00000000

and the first cas modifies the memory to:

 / valid    / corrupted
 |          |
 v          v
 0x00000000 0x00000001

We then clear token_locked, but this doesn't change the corrupted 4
bytes of memory. And then we try to lock the token again, spinning until
it is released - clearly a deadlock.

Related: Windows (amd64) doesn't follow LP64, but LLP64, where both
int and long are 4 bytes, so this shouldn't change anything on these
platforms.

Thanks to Reid Barton for helping the diagnosis. Also, thanks to Jens
Peterson who confirmed this also fixes building GHC on Fedora/ppc64 and
Fedora/s390x.

Authored-by: Gustavo Luiz Duarte <gustavold@linux.vnet.ibm.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

GlobalMemoryStatusEx actually requires _WIN32_WINNT to be defined as
0x0501 (Windows XP) for availability.

For completeness, I bumped WIN32_WINNT in Ticker and OSThreads as well.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Darwin doesn't support _SC_PHYS_PAGES, but we can get the exact number
of bytes of physical memory via 'hw.memsize', so we use that instead.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

It needs freeStablePtr, which tripped my validate build, due to an
implicit declaration warning. I'm quite surprised this somehow did not
trip the build before.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

This includes both executables (by correcly setting the rpath to the
topDir) and libffi, and GHC itself, so that everything works with no
build tree.

Authored-by: Christiaan Baaj <christiaan.baaij@gmail.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

This is encoded as RtsFlags.GcFlags.maxStkSize == 0.

This requires that stackOverflow() in RtsUtils.c be passed a reference
to the current TSO. This requires a small change in libraries/base.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>

Spotted by Bertram Felgenhauer.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>