GitLab

Tell the linker that we barf in lockFile now. Nuked an evil $Id$ on the way.

Enable GHCi on OpenBSD
     1. fix dlopen(NULL, ..) not working
     2. set USE_MMAP to overcome malloc'd memory not being executable

Fix uninitialised ref.

Submitted by: Julian Seward (who else!)

Remove unused hooks

Instead of grabbing the handle to the executable by calling
dlopen(NULL,...), use RTLD_DEFAULT as the handle to lookup symbols if
it is available.  It seems that RTLD_DEFAULT may be required on
certain systems, although I'm not sure it is available everywhere, so
I've left the old code as fallback in case it isn't available.

Add performMajorGC

Undo part of previous merge: the HEAD doesn't export saved_termios (it
is accessed by functions in RtsStartup instead).

merge rev. 1.128.2.11

ocResolve_PEi386(): improve(&flush) warning re: overflown relocation field.

merge to stable

More RTLD_* symbols are now available on OpenBSD.
This does not mean that ghci works yet, though.

Add support for .bss (zero-initialized) sections on Mac OS X

Merge to stable.

Remove apostrophe from #error directive text, as gcc doesn't like that,
even if the #error is ifdef'd out.

All other C compilers I know claim that this is correct C :-(.

merge to stable

Mac OS X/PowerPC:
Learn to cope with out-of-range relative jumps.

PowerPC relative branch instructions have a 24 bit displacement field.
As PPC code is always 4-byte-aligned, this yields a +-32MB range.
If a particular imported symbol is outside this range, we have to redirect
the jump to a short piece of new code that just loads the 32bit absolute
address and jumps there.

New implementation & changed type signature of forkProcess

forkProcess now has the following type:
forkProcess :: IO () -> IO ProcessID

forkProcessAll has been removed as it is unimplementable in the threaded RTS.

forkProcess using the old type (IO (Maybe ProcessID)) was impossible to
implement correctly in the non-threaded RTS and very hard to implement
in the threaded RTS.
The new type signature allows a clean and simple implementation.

Saving/restoring termios is only done for GHC

Update Linker following changes to saved_termios.

Add saved_termios symbol

Move forkOS_createThread into the RTS so its implementation can be
dependent on RTS_SUPPORTS_THREADS, which means we can provide a stub
implementation in the !RTS_SUPPORTS_THREADS case, and hence not depend
on pthread_create, which requires -lpthread.  The upshot is that GHCi
now works again when !RTS_SUPPORTS_THREADS.

Bound Threads
=============

Introduce a way to use foreign libraries that rely on thread local state
from multiple threads (mainly affects the threaded RTS).

See the file threads.tex in CVS at haskell-report/ffi/threads.tex
(not entirely finished yet) for a definition of this extension. A less formal
description is also found in the documentation of Control.Concurrent.

The changes mostly affect the THREADED_RTS (./configure --enable-threaded-rts),
except for saving & restoring errno on a per-TSO basis, which is also necessary
for the non-threaded RTS (a bugfix).

Detailed list of changes
------------------------

- errno is saved in the TSO object and restored when necessary:
ghc/includes/TSO.h, ghc/rts/Interpreter.c, ghc/rts/Schedule.c

- rts_mainLazyIO is no longer needed, main is no special case anymore
ghc/includes/RtsAPI.h, ghc/rts/RtsAPI.c, ghc/rts/Main.c, ghc/rts/Weak.c

- passCapability: a new function that releases the capability and "passes"
  it to a specific OS thread:
ghc/rts/Capability.h ghc/rts/Capability.c

- waitThread(), scheduleWaitThread() and schedule() get an optional
  Capability *initialCapability passed as an argument:
ghc/includes/SchedAPI.h, ghc/rts/Schedule.c, ghc/rts/RtsAPI.c

- Bound Thread scheduling (that's what this is all about):
ghc/rts/Schedule.h, ghc/rts/Schedule.c

- new Primop isCurrentThreadBound#:
ghc/compiler/prelude/primops.txt.pp, ghc/includes/PrimOps.h, ghc/rts/PrimOps.hc,
ghc/rts/Schedule.h, ghc/rts/Schedule.c

- a simple function, rtsSupportsBoundThreads, that returns true if THREADED_RTS
  is defined:
ghc/rts/Schedule.h, ghc/rts/Schedule.c

- a new implementation of forkProcess (the old implementation stays in place
  for the non-threaded case). Partially broken; works for the standard
  fork-and-exec case, but not for much else. A proper forkProcess is
  really next to impossible to implement:
ghc/rts/Schedule.c

- Library support for bound threads:
    Control.Concurrent.
      rtsSupportsBoundThreads, isCurrentThreadBound, forkOS,
      runInBoundThread, runInUnboundThread
libraries/base/Control/Concurrent.hs, libraries/base/Makefile,
libraries/base/include/HsBase.h, libraries/base/cbits/forkOS.c (new file)

Mac OS X:

Bypass the dlfcn compatibility layer in lookupSymbol, use Apple's
NSModule functions directly instead. This protects us from differences
between different implementations of the dlcompat library (regarding
treatment of prefixed underscores).
Note that the compatibility layer is still used in addDLL (it's needed by
the POSIX library anyway).

Also, add a little more sanity checking (checkProddableBlock) to the Mach-O
linker itself.

MERGE TO STABLE

Quick hack to work around the dynamic exception crashes in GHCi.  The
problem is this: the Data.Typeable library (Data.Dymamic in previous
versions of GHC) maintains an internal cache mapping type names to
unique numbers, and this cache is used for fast comparisons on
TypeReps.  In GHCi, there are actually two versions of the
Data.Typeable library loaded: one linked to GHCi itself, and the other
dynamically loaded, so there are two copies of the hash tables.

The problem is that if we have a Dynamic value generated using one set
of hash tables, it will erroneously appear to be of a different type
when the other hash tables are used.

The hack I've instigated is to use the central RTS genSym (which
already exists) to generate the unique Ids, so that the two copies of
the dynamic library will be using distinct Ids, and Dynamics from one
will never be recognisable to the other.

Initial x86-64 (aka amd64) support.

Unregisterised it works perfectly.  Registerised, I think it's almost
there, except that I seem to be running into the known codegen bug in
GCC with register variables (bug #7871 in the gcc bugzilla), which
means registerised support is basically hosed until the GCC folks
can get their act together.

We get 8 more registers on amd64, but only 2 more callee-saves
registers.  The calling convention seems to pass args in registers by
default, using the previously-callee-saves %rsi and %rdi as two of the
new arg registers.

I think GHCi should work, since we already have 64-bit ELF support
thanks to Mat Chapman's work on the IA64 port.  I haven't tried GHCi,
though.

The native code generator should be a breeze, because it's so similar
to plain x86.

x86 OpenBSD moves into ELF land
(and sparc, alpha, sparc64 were already there)

Also, it needs sligtly different header files.

And dlopen can only be called with the DL_LAZY argument on this
system.

Unbreak GHCi: Add stg_BLACKHOLE_BQ_info and awakenBlockedQueue to
RTS_SYMBOLS.

Unbreak GHCi: Add raiseIOzh_fast to RTS_SYMBOLS

Warning police: Fixed Sym macro to generate a real function prototype

Eliminate warnings for ELF_*

Update IA64 port to work with gcc 3.3.

merge rev. 1.119.2.1:

Couple of extra local syms needed when using mingw2

Unbreak Mac OS X build (#ifdef mixup)

On 32-bit platforms, add a bunch of symbols from libgcc.a used to
support 64-bit arithmetic.

It looks like these symbols are defined in libc on some platforms but
not others, but it shouldn't do any harm to include them in the list
of symbols that the linker knows about even if they're also in libc.
They were already included for some platforms (cygwin, mingw, and
darwin), this commit just includes then whenever we're compiling with
gcc on a 32-bit platform.

Include NetBSD support

Submitted by: Urban Boquist <boquist@crt.se>

to ease replacement of the underlying allocator used by stgMallocBytes() and friends, provide (&use) RtsUtils.c:stgFree()

Asynchronous / non-blocking I/O for Win32 platforms.

This commit introduces a Concurrent Haskell friendly view of I/O on
Win32 platforms. Through the use of a pool of worker Win32 threads, CH
threads may issue asynchronous I/O requests without blocking the
progress of other CH threads. The issuing CH thread is blocked until
the request has been serviced though.

GHC.Conc exports the primops that take care of issuing the
asynchronous I/O requests, which the IO implementation now takes
advantage of. By default, all Handles are non-blocking/asynchronous,
but should performance become an issue, having a per-Handle flag for
turning off non-blocking could easily be imagined&introduced.

[Incidentally, this thread pool-based implementation could easily be
extended to also allow Haskell code to delegate the execution of
arbitrary pieces of (potentially blocking) external code to another OS
thread. Given how relatively gnarly the locking story has turned out
to be with the 'threaded' RTS, that may not be such a bad idea.]

Mac OS X:
add one more relocation type (PPC_RELOC_BR24)
and add more C run-time library symbols to the symbol table
(made more difficult by the fact that these symbols don't
have an underscore prefix, while everything else on Mac OS X has)

Add some missing symbols.

Should fix several recent test breakages with GHCi.

- re-instate setProgArgv, it is used in System.Environment (bah, could
  have sworn I grepped for it and found nothing...)

- Remove init_stack symbol from the Linker's symbol table; this is
  now static.

- Remove setProgArgv
- Belatedly add startupHaskell/shutdownHaskell

The hook NoRunnableThreads() is not used; kill it.

Warning police: #undef SymX_redirect before it gets redefined.  :-P