On Sun, Jun 20, 2004 at 04:57:43PM +0200, Gerald Pfeifer wrote:
On Thu, 17 Jun 2004, John Birrell wrote:
"wine: failed to initialize: /something/lib/wine/ntdll.dll.so: mmap of entire address space failed: Cannot allocate memory"
is caused by Wine attempting to mmap memory outside the user process address space. I see mmap addr around 0xd8100000 (mostly 0xd81eccd8) whereas the user address space limit on FreeBSD current is 0xbfc00000 (at least on my system). [...] I ran a test of mmap on FreeBSD current to see what address space I was able to mmap. Using objdump to identify the pages that the test program was linked to load in, the test program was able to mmap MAP_ANON, MAP_FIXED, MAP_NOCORE all memory from 0x0 to 0xbfc00000, except the pages at which the test program was mapped at.
Thanks for the fine analysis, John!
I wonder, is there some way to avoid the "bad" mmapping on FreeBSD, change Wine, or do we have to get FreeBSD changes?
From what I can see, the FreeBSD mmap address allocation behaviour that I see
isn't documented. From the documentation, I would have expected the Wine code to work - it doesn't seem unreasonable to me.
I think the FreeBSD kernel code needs to change. If this is to happen, it will only be in the FreeBSD5 tree. It is too late in the FreeBSD4 branch to make that sort of change since it's not really a bug fix.
To get Wine to work on FreeBSD4, there needs to be a way of making the reservation code optional. A simple mmap test in configure which snaffles memory above 0x80000000 and then tries to mmap some more memory without specifying a fixed address would detect if mmap is behaving in a way that would allow the Wine reservation code to function.
For FreeBSD5, which will become the stable branch sometime soon, I think the kernel code needs to change. I have a FreeBSD src commit bit, but I'm not a vm person, so I can only prototype a change and submit it for review. I'm not sure if the other developers will regard this change favourably, though. They may take the attitude that if Wine can be made to work with the FreeBSD kernel code as is, then Wine should be coded accordingly.
If the Wine code was restructured to make the reservation code optional, that would cover both FreeBSD4 and FreeBSD5. Then, if the FreeBSD mmap algorithm was to change in the future, the build could start using the reservation code at that time.