Subject: Re: Wine & NetBSD?
To: Bang Jun-Young <bjy@mogua.org>
From: Todd Vierling <tv@wasabisystems.com>
List: tech-kern
Date: 11/20/2001 17:44:08
On Wed, 21 Nov 2001, Bang Jun-Young wrote:

: > In particular, the straw example you gave had a completely bogus
: > expectation:  you thought that mmap(0x50000000, ...)  without MAP_FIXED
: > would remap 0x50000000.  It *cannot*, from the citation I gave:
:
: I know it cannot, but why can we never mmap at 0x500000 while we can at
: 0x50000000? This is definitely not Wine's fault.

You can map anywhere you wish *as long as you specify MAP_FIXED*, and as
long as the address is not in unusable memory (there are some memory ranges,
such as stack, break, kernel-reserved, and MMU-inaccessible blocks on
different architectures).

If you don't specify MAP_FIXED, you cannot expect anything from the result
except a mapping to an arbitrary memory location.  If you even get close to
the address you request without MAP_FIXED, you're simply lucky.

Wine is still broken, and only Wine can be fixed to work correctly.  Now, if
it needs an *extension* to mmap() in order to indicate some failure state
that it's looking for, we can perhaps talk about that.  But the current
NetBSD kernel semantics are already correct and do not need to change.

: > The current implementation works perfectly well based on my experience and
: > reading of the spec.  `If it ain't broke, don't fix it.'
: >
: > Changing the NetBSD kernel just to make one program's bogus expectations
: > work is not the solution.  Wine will still have bogus expectations.
:
: No, without this patch COMPAT_PECOFF would be also mostly useless. Then
: you should remove it from the repository. This is NetBSD's problem and
: should be fixed.

COMPAT_PECOFF works just dandy for me without your patch.  The PEACE
developers seem to be having no problems with this implementation of
mmap(2).

From a look at their source code, every call to mmap(2) save one uses
MAP_FIXED.  The one which does not is only called when ld.so.dll knows that
the DLL's mapping base address crosses the mappable memory base address, and
would thus cause an overlapping mmap.

(Note that properly compiled Win32 DLLs *are* relocateable by the loader;
this just results in slower startup.  Such DLLs can be mapped arbitrarily
without MAP_FIXED, of course, provided that they are always relocated after
such a mmap.)

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/