Re: *BSD support in 6.8.3

29 May 2008

      Ok, I've now modified the patch and attached a new version to the ticket:

http://hackage.haskell.org/trac/ghc/attachment/ticket/2013/2013.patch

*BSD folks please test.

Wilhelm B. Kloke wrote:
...
Simon Marlow  schrieb:
...
...
So, try the patch to get the patch to compile against ghc
6.8.3-snapshot, and see if it works on OpenBSD?
It's not just a case of testing the patch, there are a couple of issues to 
address:
- it has a couple of wired-in addresses: one place to load object files,
    another to put jump tables at.  This is necessary because *BSD doesn't
    have the MAP_32BIT flag for mmap().  However, the particular wired-in
    addresses needed will probably vary on the different *BSDs.  Someone
    needs to look at the memory map and make sure we're picking sensible
    addresses.
It is not very likely that the adresses change between *BSDs because
they are resulting from simple hardware-related constraints. Though,
a test is necessary.
These are virtual addresses, so hardware doesn't really come into it, 
right?  I remember seeing memory maps change between versions of Linux in 
the past (i.e. where shared libraries are loaded, where the binary is 
loaded, etc.).  We need to avoid clashing with anything else, otherwise the 
OS might allocate us an address outside the 2Gb range.
...
OTOH, has anybody from the GHC team asked the *BSD developers to add
a MAP_32BIT flag already? I know that these people are very reluctant
to change requests, this one may find their mercy if the right persons
ask for it.
That's a good idea, I might try it.
...
I looked into the patch, and it doesn't look as if it would break other
platforms, as the changed code is inside proper ifdefs mostly. Some
parts may be superfluous. The easiest check is to compile the
FreeBSD-patched code under one of the other platforms (are there other than
Linux and OSX?).
So the patch as it stands always passes 1Gb as the address to mmap().  This 
might have undesirable effects on other systems.  I fixed that in the new 
version of the patch (see above).

Cheers,
	Simon