Closed dmik closed 8 years ago
Apparently, it fails due to MAP_FIXED not being supported by our mmap. In this particular case, MMAP_FIXED basically just assigns another file to the same memory region. We actually may easily support at least this particular case, it's not a big deal at all. Given this is an autoconf test case, I now have a suspicion that this is may be the most commonly used MAP_FIXED case over there.
An alternative would be to change this test case in autoconf so that MAP_FIXED isn't used on OS/2 's now all configure
-based projects will have MMAP support turned off. But I don't like this approach because there may be some projects that rely on MAP_FIXED given that the test passes. And also because it's quite easy to implement this on OS/2.
Well, as I now see, they first munmap()
the region at addr2
then map a new one at the same location but with MAP_FIXED and a different file descriptor (the comment in the source is actually misleading). This isn't that easy to support as just changing the associated file...
On the second thought, It's not just "not easy", it's simply impossible to make the above snippet work on OS/2 because for shared memory OS/2 uses different address range than for private memory and we can't really control that.
The only theoretical approach to implement MAP_FIXED working this way is to use DosAliasMem
for shared memory allocated for MAP_SHARED and return the resulting address which is from the private range to the caller. However, this means that for each MAP_SHARED mapping we will waste both the shared address space and the private address space (and we will have to call DosAliasMem
multiple times to get the same address in all processes for MAP_SHARED mappings). I don't like this approach very much.
So I'm afraid for now we will have to hack autoconf to make it not use MAP_FIXED at all on OS/2.
Further testing shows that the above snippet fails not on MAP_FIXED but on creating a mapping of 4096 bytes (1 page) long on a file which is 1 bytes long. Apparently, Linux and other platforms support it, thus allowing to read and write beyond the end of the associated file. The comments in the snippet suggest that reading in such a case should return zeroes and writing should expand the file it seems. We will have to support that.
After fixing #18, conftest now fails right at MAP_FIXED, so it's the next task.
Well, the autoconf fix is very trivial (already did it and checked), but I will first learn if we should support MAP_FIXED in VirtualBox style (i.e. w/o unmapping the "root" mapping, see #14). If yes, then a fix to autoconf will be different (removing munmap
in the middle rather than completely disable the MAP_FIXED code).
I committed the autoconf fix in http://trac.netlabs.org/ports/changeset/1752/autoconf and released new autoconf RPMs. In order for the mmap test to succeed LIBCx must be passed in LIBS (e.g. like LIBS="-lcx"
) prior to configure
execution (the old mmap library fails much earlier so it won't trigger enabling autoconf mmap defines and such).
That's it for now.
Valerius discovered that the standard autoconf test AC_FUNC_MMAP fails to succeed given our
mmap()
implementation. Here is the failing test case (from http://trac.netlabs.org/ports/browser/autoconf/trunk/lib/autoconf/functions.m4):