http://bugs.winehq.org/show_bug.cgi?id=16023
Tijl Coosemans tijl@ulyssis.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tijl@ulyssis.org
--- Comment #18 from Tijl Coosemans tijl@ulyssis.org 2008-12-27 08:15:41 --- The main reason the reservation code is still disabled on FreeBSD is because mmap(NULL) only tries addresses after the executable + some malloc heap space. Wine is located at 0x7bf00000. The heap size is currently set to 0x02000000 by the wine-freebsd loader, which is thought to be the absolute minimum required to support FreeBSD 6, where malloc doesn't fall back on mmap if it runs out of this heap space. It's not enough to run certain games for instance. Although I suspect there are memory leaks in certain DRI drivers, these games do run with a much larger heap space, like 512MiB. Anyway, so mmap(NULL) looks for free memory after about 0x7e000000. If you reserve everything beyond the 2GiB user space limit, that means there's about 32MiB left for all mmap(NULL) calls that might exist in code outside Wine, like for instance the ELF loader. A large portion of that 32MiB is already taken by DSOs. Wine itself translates all mmap(NULL) calls into mmap(0x110000) and this is why the virtual heap ends up at the beginning of address space.
Getting Wine to run on different mmap implementations is more complicated than just getting the reservation code working.
Also, as a comment to the patch above. You shouldn't have to hack around how FreeBSD allocates stacks for threads. If the standard stack allocation fails, Wine should allocate a stack for each thread and specify it with pthread_attr_setstack(3). I thought it already did this though...