*BSD support in 6.8.3

[Simon Marlow]

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 <marlowsd at gmail.com> 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