World of Warcraft (WoW) patch/more address space layout stuff

[Troy Rollo]

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).

-- 
Troy Rollo - wine at troy.rollo.name