On Monday 01 May 2006 20:59, Mike Hearn wrote:
- Is this working around a bug in WoW? (my guess - almost certainly yes)
Perhaps, but there are other problems with the Linux kernel not using the entire address space.
- What exactly is it doing?! No comments! It seems to be forcing the kernel to follow an NT allocation pattern.
Sort of. NT's allocation pattern is somewhat erratic. I started looking into it last weekend. The allocation pattern varies depending on the calls you make (GlobalAlloc and VirtualAlloc use address space in a different order, I have not checked file mapping yet).
However NT will start allocating at around 0x00100000, whereas Wine starts allocating in the 0x66000000 range, so this patch makes initial allocations appear much closer to the NT range than raw Wine.
The other problem is that the Linux kernel will not map anything below 0x40000000 unless an mmap call explicitly requests such an address, so after we lock out 0x80000000-0xe0000000 we are left with 1GB of usable address space for everything (Wine, native libraries, data) unless we decide ourselves where mappings without a start address should begin. The problem with that is that something else may have mapped stuff where we plan to map something.
- How should we fix this properly? Forcing the rtld to map every DSO in a predictable manner seems awfully hard work. Likewise, kernel patches would kind of suck ...Is this approach of a new preloader region and then doing manual mmap management going to work?
Mapping of DSOs is not the immediate problem, although it would be nice if we could force all native shared libraries above 0x80000000 (and above 0xc0000000 on architectures where address space above there is available) so that Windows apps have the largest possible address space available to them.
The solution is that we need to know about all memory allocations, which means hooking into mmap and related calls in libc and making the system call ourselves so that we have a record of "all" memory mappings other than those made by libraries that make their system calls directly (hopefully the intersection of this set with the set of libraries we use is empty). If we record the mappings, then ntdll could make the decision on where to map things based on Windows allocation patterns and knowledge of allocated space. If the allocation fails because something is mapped there already we would display a FIXME and then use a search algorithm to identify the allocated block (or grovel at /proc, but Alexandre has indicated before he prefers not to do that).