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.