On May 12, 2010, at 2:30 PM, Charles Davis wrote:
In Mac OS X 10.5, mmap() was changed to conform to UNIX '03. Among other things, this means that mmap() no longer supports unaligned file offsets (like Linux).
What problems does this cause?
However, by reading Darwin source, I learned that the check for unaligned file offsets is done at the library level, and not in the kernel. This is to support older binaries compiled for Tiger and earlier. This means that Wine compiled for Tiger should support unaligned file offsets, like want. But it also means that, if we make the syscall ourselves instead of calling libc, we can support them on Leopard (and by extension, Snow Leopard) too! This patch series does just that.
Can't we achieve that just by avoiding the mapping of the "mmap" identifier to the _mmap$UNIX2003 symbol?
http://developer.apple.com/mac/library/releasenotes/Darwin/SymbolVariantsRel...
It may be sufficient to #define _NONSTD_SOURCE, #include <sys/mman.h> as the first header, #undef _NONSTD_SOURCE, and then continue to include any other headers.
Alternatively, you can probably use an approach like this:
http://source.winehq.org/git/wine.git/?a=commitdiff;h=028b763f2f51e780841299...
Regards, Ken
On 5/12/10 5:37 PM, Ken Thomases wrote:
What problems does this cause?
It makes Wine use more memory than it needs to.
http://wiki.winehq.org/UnalignedMmap
Can't we achieve that just by avoiding the mapping of the "mmap" identifier to the _mmap$UNIX2003 symbol?
We could for 32-bit, but not 64-bit.
It may be sufficient to #define _NONSTD_SOURCE, #include <sys/mman.h> as the first header, #undef _NONSTD_SOURCE, and then continue to include any other headers.
Not on 64-bit (when support for that finally gets here). If you try that in a 64-bit program, you get an error.
Alternatively, you can probably use an approach like this:
http://source.winehq.org/git/wine.git/?a=commitdiff;h=028b763f2f51e780841299...
Again, it won't work for 64-bit. On 64-bit, only the "conforming" version is available. (Use nm on the System Library, /usr/lib/libSystem.dylib, and see for yourself. Note that it doesn't have the $UNIX2003 on the end because the UNIX '03 version is the only one available there.)
The 32-bit version was ugly anyway. I'll submit a new patch series.
Chip
On May 12, 2010, at 6:53 PM, Charles Davis wrote:
On 5/12/10 5:37 PM, Ken Thomases wrote:
What problems does this cause?
It makes Wine use more memory than it needs to.
http://wiki.winehq.org/UnalignedMmap
Can't we achieve that just by avoiding the mapping of the "mmap" identifier to the _mmap$UNIX2003 symbol?
We could for 32-bit, but not 64-bit.
And does the problem still matter in 64-bit?
Also, are unaligned PE images also prevalent for 64-bit executables? There are many cases in which 64-bit ABIs impose stricter alignment requirements. I don't know if this is one of them.
-Ken
On 5/12/10 6:10 PM, Ken Thomases wrote:
On May 12, 2010, at 6:53 PM, Charles Davis wrote:
On 5/12/10 5:37 PM, Ken Thomases wrote:
What problems does this cause?
It makes Wine use more memory than it needs to.
http://wiki.winehq.org/UnalignedMmap
Can't we achieve that just by avoiding the mapping of the "mmap" identifier to the _mmap$UNIX2003 symbol?
We could for 32-bit, but not 64-bit.
And does the problem still matter in 64-bit?
Probably. Everything I've read seems to indicate that the 64-bit PE format is just that--a 64-bit version of the PE format. In particular, it seems to me that disk alignment can still be less than one page.
Also, are unaligned PE images also prevalent for 64-bit executables?
I wouldn't know, I've never seen an actual Win64 executable.
There are many cases in which 64-bit ABIs impose stricter alignment requirements.
That's certainly true.
I don't know if this is one of them.
Somehow I doubt it is.
Chip
Charles Davis cdavis@mymail.mines.edu writes:
On 5/12/10 5:37 PM, Ken Thomases wrote:
What problems does this cause?
It makes Wine use more memory than it needs to.
In theory, but in practice it's not worth the trouble. We used to do this on Linux but it has been removed. It's definitely not worth breaking libwine compatibility for this.
-
Alexandre Julliard -
Charles Davis -
Ken Thomases