World of Warcraft (WoW) patch/more address space layout stuff
wine at troy.rollo.name
Mon May 1 18:20:16 CDT 2006
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
> * 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
More information about the wine-devel