Tijl Coosemans tijl@coosemans.org writes:
With this patch it is possible that a .dll.so is loaded beyond the 2GiB limit, but this does not seem to be a problem in practice. All mmap calls from within Wine and thus all .dll stay below 2GiB and core .dll.so such as ntdll, kernel32, user32,... are also loaded below 2GiB because they are loaded early and are placed in the 32MiB mentioned above. Also note that a .dll.so is only loaded above 2GiB when needed, i.e. the program wouldn't have worked at all without this patch. It is preferred that Wine at least makes an attempt at running the program and therefore loosens the restriction on the use of addresses above 2GiB, especially since it seems to work so far.
It would be better to fix this properly. If there's no way to convince FreeBSD's mmap to use all available space, you'll have to move the loader down to make some room.
On Monday 20 September 2010 15:10:58 Alexandre Julliard wrote:
Tijl Coosemans tijl@coosemans.org writes:
With this patch it is possible that a .dll.so is loaded beyond the 2GiB limit, but this does not seem to be a problem in practice. All mmap calls from within Wine and thus all .dll stay below 2GiB and core .dll.so such as ntdll, kernel32, user32,... are also loaded below 2GiB because they are loaded early and are placed in the 32MiB mentioned above. Also note that a .dll.so is only loaded above 2GiB when needed, i.e. the program wouldn't have worked at all without this patch. It is preferred that Wine at least makes an attempt at running the program and therefore loosens the restriction on the use of addresses above 2GiB, especially since it seems to work so far.
It would be better to fix this properly. If there's no way to convince FreeBSD's mmap to use all available space, you'll have to move the loader down to make some room.
I've attached a patch that takes a different approach. I still need to test it more extensively, but is this patch acceptable in principle?
It adds an mmap symbol to the loader thereby overriding the libc symbol. This captures all calls to libc mmap and allows modifying the address argument if needed. It doesn't capture cases that call the kernel syscall directly, so shared libraries for instance are all still loaded in the narrow address space close to the 2GiB boundary. This patch also increases that space to 48MiB. It might work, but needs more testing.
On Monday, September 20, 2010 2:20:00 pm Tijl Coosemans wrote:
I've attached a patch that takes a different approach. I still need to test it more extensively, but is this patch acceptable in principle?
It adds an mmap symbol to the loader thereby overriding the libc symbol.
I've actually been working on a patch recently that does this, and will probably be RFC'ing it here soon. It overrides the mmap/munmap calls and redirects them to use the process heap when possible. You have to be careful, though, because 'mmap' uses off_t. On 32-bit systems this is by default a 32- bit type, but with _FILE_OFFSET_BITS=64, off_t becomes a 64-bit type and mmap is redirected to mmap64.
On Monday 20 September 2010 23:37:28 Chris Robinson wrote:
On Monday, September 20, 2010 2:20:00 pm Tijl Coosemans wrote:
I've attached a patch that takes a different approach. I still need to test it more extensively, but is this patch acceptable in principle?
It adds an mmap symbol to the loader thereby overriding the libc symbol.
I've actually been working on a patch recently that does this, and will probably be RFC'ing it here soon. It overrides the mmap/munmap calls and redirects them to use the process heap when possible. You have to be careful, though, because 'mmap' uses off_t. On 32-bit systems this is by default a 32-bit type, but with _FILE_OFFSET_BITS=64, off_t becomes a 64-bit type and mmap is redirected to mmap64.
On FreeBSD off_t is always 64 bit.
On Monday, September 20, 2010 2:42:51 pm Tijl Coosemans wrote:
On FreeBSD off_t is always 64 bit.
Even on 32-bit systems? I'll have to take that into account, then.
-
Alexandre Julliard -
Chris Robinson -
Tijl Coosemans